スクリプト開発ライフサイクル管理

特に明記されていない限り、このヘルプ ページの情報は Studioにのみ適用されます。 さまざまな段階のスクリプトのセキュリティを保護するために、開発ワークフロー段階に割り当てられたフォルダーはDesktop Studioには表示されません。

Studio は、企業のスクリプト開発ライフサイクルの管理に役立つ開発ステージのシステムを提供します。 開発ステージは、スクリプトを整理し、スクリプト開発ライフサイクルを通じてスクリプトのプロモーションを管理するためのツールです。

開発ステージでは、開発プロセスのどこにあるかに基づいてスクリプトが整理されます。 スクリプト開発者が従うプロセスに合わせて、最大 4 つのステージを構成できます。 たとえば、開発、テスト、本番のステージを使用できます。 スクリプト開発者がスクリプトを作成または編集する場合は、開発段階で作業します。 その後、スクリプトのテスト準備が整ったら、次の段階に進めることができます。

開発ワークフローの構造

Studio は、スクリプト フォルダー構造内での開発ワークフローをサポートします。 これを管理する正確な方法は、CXone Mpower システム部門クローズ済 事業部門間でデータを安全に分離します。 データは所属する部門内からのみアクセスできます。用に構成されているかどうかによって異なります。 システムで 部門が使用されている場合、スクリプトの構成は部門に合わせて調整されます。 システム で分割を使用しない場合は、Studio組織を使用してスクリプトを編成できます。

組織と部門は両方とも Studio内のフォルダーに割り当てられます。 フォルダは ACD ファイル ストレージ CXone Mpowerにあります。 各組織または部門には独自のフォルダー セットがあり、最上位フォルダーと、その組織または部門で使用される各開発段階のフォルダー 1 つで構成されます。 各ステージ フォルダー内にサブフォルダーを作成してスクリプトを整理します。 唯一必要なサブフォルダは最下位レベルの開発ステージにあり、そこには mainというフォルダが必要です。

スクリプト開発者は、スクリプトをある段階から次の段階に進めます。 次の段階で宛先フォルダを選択できます。 各組織または部門の必要に応じて、スクリプト セキュリティを設定できます。 Studio 権限により、段階ごとに会社のスクリプトに誰がアクセスして操作できるかをきめ細かく制御できます。 部門の場合、開発ワークフロー権限により、各部門内でスクリプトへのアクセスをより細かく制御できます。

組織との開発ワークフロー

Studio では、開発ワークフローを設定するときに組織を作成する必要があります。 組織は Studio内のみのエンティティです。 それらの唯一の目的は、開発段階とそこに含まれるスクリプトを整理することです。

組織は、開発ステージのセットとそれに関連付けられたフォルダーを 1 つ定義します。 Studioでサードパーティのバージョン管理システムを使用する場合、組織はスクリプトがコミットされるリポジトリも定義します。 組織ごとに異なるリポジトリを使用できます。

複数の組織を作成できます。 組織は、会社内のさまざまなチーム、事業部門、またはその他の区分にマッピングできます。 コンタクト センターが小規模である場合、または会社の構造が単純でシンプルな場合は、 1 つの組織だけで十分な場合があります。 ただし、会社が次のような場合には、複数の組織を作成する必要があるかもしれません。

  • スクリプトに複数のリポジトリを使用したい場合。
  • 異なるグループまたはチームで異なる開発段階を使用します。
  • 異なるグループ、チーム、または事業部門のスクリプトを互いに分離しておく必要があります。

各組織には、CXone Mpower システム内に独自のフォルダーがあります。 各組織のすべてのスクリプトはそのフォルダーに保存されます。

会社で複数の組織が必要ない場合は、組織のスクリプト用のフォルダーを作成する必要はありません。 つまり、開発段階のフォルダーは、Studio ファイル構造のルートの下に配置できます。

部門別開発ワークフロー

部門により、組織はCXone Mpower システム内のデータを安全にセグメント化し、異なる事業分野を分離することができます。 彼らはCXone Mpower内に存在する実体です。 有効にすると、分割はすべての プラットフォーム データ、Studio スクリプトを含むに影響します。

CXone Mpower 管理者は 内に Admin部門を作成アプリケーションする必要があります。 その後、Studio内のフォルダーに部門をマッピングできます。 Studio 内のフォルダー構造は、CXone Mpower システム内の部門の階層構造と一致する必要があります。 部門を担当する プラットフォーム 管理者が階層の決定をお手伝いします。

各部門には独自の開発段階があります。 Studioでサードパーティのバージョン管理システムを使用する場合、リポジトリは部門別に割り当てられます。 各部門は異なるリポジトリを使用できます。

組織と部門の比較

次の表は、組織と部門の違いと、開発ワークフロー機能のサポートをまとめたものです。

  組織 部門
CXone Mpower内のエンティティ いいえ はい

Studioのトップレベルフォルダの要件

複数の組織にはそれぞれ、Studio内に割り当てられた独自の最上位フォルダが必要です。

1 つの組織では最上位のフォルダーは必要ありません。 ルートを使用して開発段階のフォルダーを保持できます。

各部門には独自のフォルダーが必要です。

フォルダ構造は、プラットフォーム内の部門構造と一致する必要があります。

開発段階をサポート

はい

各組織には、独自のステージとステージ フォルダーのセットがあります。

はい

各部門には、独自のステージとステージ フォルダーのセットがあります。

サードパーティのバージョン管理システムとの統合をサポート

はい

各組織は独自のリポジトリを使用できます。

はい

各部門は独自のリポジトリを使用できます。

スクリプトとステージへのユーザーアクセスを制御する権限をサポートします はい はい

開発段階

開発ステージは、スクリプト開発ライフサイクルを管理する上で中核となります。 会社の確立されたプロセスに合わせて最大 4 つのステージを定義できます。 たとえば、会社の開発ライフサイクルに dev と prod の 2 つのステップがある場合は、Studio でそれに合わせて開発ステージを設定できます。 スクリプト開発者が慣れている名前に合わせて、開発ステージの名前をカスタマイズできます。

開発ステージは、の構成に応じて、CXone Mpower組織または部門システムの子になります。 各組織または部門には独自の開発段階のセットがあります。 これにより、組織または部門ごとに開発ワークフローをカスタマイズできます。

最初の段階では、main というフォルダーが存在する必要があります。 これは、バージョン管理システムのメイン ブランチGitHubなどを表します。 すべてのスクリプトは メイン フォルダに配置する必要があります。 スクリプト開発者は、main 内にサブフォルダーを作成してスクリプトを整理できます。 でサードパーティのバージョン管理システムを使用する場合は、メイン フォルダーStudioが必要です。 バージョン管理を使用する予定がない場合でも、最下位レベルのステージにあるすべてのスクリプトを メイン フォルダーに保存する必要があります。

他のステージでは、同じフォルダー命名要件はありません。 他の 3 つのステージでは、任意の数のサブフォルダーを作成でき、任意の名前を付けることができます。 これにより、サブフォルダーを使用して、リリース別など、会社のニーズに合った方法でスクリプトを整理できるようになります。

Classics, Inc. の管理者である Christopher Robin が開発段階を設定しています。Studio Classics, Inc. 同社には、大学生に教科書を販売・レンタルする Classic Texts と、書店カフェ チェーンの Classic Cafe and Books という 2 つの事業分野 (LOB) があります。

まず、CXone Mpower Admin で、4 つのステージすべてに作成、編集、昇格する権限を持つロールを自分自身に作成して割り当てます。

Christopher は、各 LOB の Studio スクリプト チームのマネージャーと相談し、各チームの開発ライフサイクルについて学びます。 次に、Studioのワークフロー開発ページで、ClassicTexts と ClassicCafe という 2 つの組織とそれぞれの適切な開発ステージを作成します。

次に、Christopher はStudioにフォルダー構造を作成します。 各 LOB の組織ごとに一時スクリプトを作成し、フォルダー パスを入力するオプションを選択して、両方の組織に \dev\main という名前を付けます。

最後に、クリストファーは各組織で作成した各ステージを通じて一時的なスクリプトを推進します。 上位ステージではサブフォルダを作成しません。 代わりに、スクリプトをステージのフォルダーに昇格するだけです。 最後に、一時的なスクリプトを無効にします。

Christopher は、Studioで次のフォルダー構造を確認できるようになりました。

\クラシックカフェ

\開発

\主要

\製品

\クラシックテキスト

\開発

\主要

\QA

\製品

スクリプトのプロモーションとコピーダウン

スクリプトが次のステージに進む準備ができたら、適切な権限を持つスクリプト開発者がそれを昇格できます。 スクリプトは次の上位のステージにのみ昇格できます。 また、スクリプト開発者が所属する組織または部門用に設定されたステージにのみ昇格できます。

スクリプトを昇格すると、宛先ステージにスクリプトのコピーが作成されます。 また、ステージ フォルダーを除くパス内のすべてのフォルダーをスクリプトの場所にコピーします。 これにより、スクリプト開発者が作成した組織構造が強制されます。

Tigger Tiggerson は Classic Texts のスクリプト開発者です。 彼は、/QA/Jan2025/TiggerTest/IBVoice にある ScriptA に取り組んでいます。 彼はそれを Prod ステージに昇格させます。 Prod フォルダーを確認すると、/Jan2025/TiggerTest/IBVoice のパス全体が ScriptA ファイルとともにコピーされていることがわかります。 /QA フォルダはステージフォルダなのでコピーされませんでした。

デフォルトでは、スクリプトが昇格されると、それらは宛先の開発ステージの同じサブフォルダーに保存されます。 スクリプト開発者は、新しいフォルダーの作成を含め、スクリプトが保存されるサブフォルダーを変更できます。

会社では、スクリプトをステージからステージへと昇格させる条件を定義するための内部プロセスを開発できます。 Studio はこれらの条件を追跡したり、条件が満たされていることを検証したりしません。 ただし、CXone Mpower ロールと権限を使用して、どの Studio ユーザーを各ステージに昇格できるかを制御することができます。 各ステージでスクリプトを表示、作成、編集できるユーザーを制御することもできます。

プロモーションスクリプトの変更

一般的なスクリプト開発ライフサイクル ワークフローに従うということは、上位段階のスクリプトに変更が必要になった場合、スクリプト開発者は開発用に指定された段階のスクリプトのコピーで作業する必要があることを意味します。 ただし、スクリプトが上位ステージで変更されている場合は、最下位レベルのフォルダに 複製される可能性があります。 これが必要になるのは、緊急の修正が必要で、上位ステージのスクリプトに直接修正が加えられた場合のみです。

スクリプトが別の開発ステージに昇格または複製されると、宛先ステージのフォルダーにコピーされます。 スクリプトが 1 つのステージのフォルダー内のサブフォルダーにある場合、サブフォルダーとそのパスが宛先ステージのフォルダーにコピーされます。

スクリプトを他の開発段階に昇格および複製するには、権限が必要です。 スクリプト開発者には次のものが必要です。

  • スクリプトを昇格するステージに対する「昇格先」権限。
  • スクリプトを複製するステージの作成/編集権限。
  • スクリプトが現在配置されているステージの表示権限。

スクリプトを別の開発ステージに昇格または複製すると、宛先ステージに古いバージョンのスクリプトが存在する場合は上書きされます。 必要に応じて、スクリプト開発者はプロモーションまたは複製する前にスクリプトを比較して違いを判断できます。 また、スクリプトのバージョン履歴を表示したり、変更が上書きされた場合に古いバージョンに戻すこともできます。

スクリプトとデータアクセス制御

Studioで定義した開発段階ごとに、スクリプトにアクセスできるユーザーを制御できます。 Adminのロールに割り当てられた権限を使用すると、スクリプト開発者が各ステージでスクリプトを表示、作成、編集、および非アクティブ化する機能を制限できます。 開発者がスクリプトをどのステージに昇格できるかを制御することもできます。

これらの権限は組織と部門に適用されます。

  • 組織の場合、権限によってスクリプト開発者が他の組織のスクリプトを表示できなくなることはありません。 開発者に開発ステージのスクリプトを表示する権限がある場合、各組織の dev フォルダ内のすべてのスクリプトを表示できます。

  • 部門クローズ済 事業部門間でデータを安全に分離します。 データは所属する部門内からのみアクセスできます。を使用すると、スクリプト開発者は、自分が割り当てられている部門内、または自分が割り当てられている部門の子部門内のスクリプトのみを表示できます。 たとえば、割り当てられた部門の開発段階のスクリプトを表示する権限を持つスクリプト開発者は、同じまたは上位の階層レベルにある他の部門の開発段階のフォルダーを表示できません。

ステージによるスクリプト管理

開発ステージが設定されると、スクリプト開発者はシステム内で作業を開始できます。 開発者が、設定したシステム内でどのように作業するかを理解していることを確認する必要があります。

プロセスを設計する際には、次の点を考慮してください。

  • Studioにどのようなステージを設定しましたか。
  • スクリプトを各開発段階にいつ、どのように昇格できるかの基準。
  • 誰がどのステージにスクリプトを宣伝できるか。
  • 上位レベルのスクリプトを変更する必要がある場合の対処方法。 たとえば、開発段階でそのスクリプトのコピーに取り組み、それを上の段階に昇格させる必要があります。
  • 上位の段階でスクリプトにブレークフィックスの変更が加えられた場合はどうすればよいですか。 たとえば、そのバージョンのスクリプトを dev にコピーする必要がありますか? スクリプト開発者はスクリプトを比較して、どちらが新しいバージョンかを確認できます。
  • スクリプト開発のために会社が定めているその他のガイドラインまたはガードレール。

スクリプトのバージョン管理

バージョン管理により、開発中にスクリプトに加えられた変更を追跡および管理できます。 これにより、問題が発生したときに調査することができます。 必要に応じて、問題のある変更を元に戻す方法として、スクリプトの以前のバージョンに戻すことができます。

Studioはスクリプトのバージョン管理に次の2つのオプションを用意しています。

  • スクリプト履歴Studioは各スクリプトの過去のバージョンを設定可能な数だけ保存します。 スクリプトが保存されるたびに、その履歴バージョンの記録が作成されます。 以前のバージョンを表示し、必要に応じて元に戻すことができます。 このオプションはDesktop StudioおよびStudioでサポートされています。
  • サードパーティのバージョン管理システム:Studioはスクリプトの変更をサードパーティのバージョン管理システムにコミットできます。 現在、GitHubが唯一サポートされているプロバイダーです。 この機能は、限定リリースプログラムの一部です。 詳細については、担当のアカウント担当者に問い合わせてください。

スクリプトバージョン管理の2つのオプションは連携して機能します。 バージョン管理システムを使用している場合は、Studioが保持しているスクリプトの過去のバージョンを表示して元に戻すことができます。 しかし、GitHubはそれを逆戻りとは見ていない。 代わりに、元に戻されたスクリプトは新しい変更として認識されます。

同様に、Studioで開発ステージを使用すると、スクリプトの過去のバージョンを表示できます。 ただし、過去のバージョンは各段階のバージョンのみに限られます。 別の段階の過去のバージョンを表示するには、その段階のスクリプトを表示する必要があります。 異なる段階のスクリプトを表示するには、その段階で作業する権限が必要です。

開発段階に関する重要な事実Studio

  • 会社で部門クローズ済 事業部門間でデータを安全に分離します。 データは所属する部門内からのみアクセスできます。を使用している場合は、部門ごとに個別の開発段階を設定できます。 Studio ユーザーは、自分の部門内で、表示権限を持つフォルダーにあるスクリプトにのみアクセスできます。
  • 部門を使用しない場合、Studio ユーザーは、表示権限を持つ開発段階にあるスクリプトにのみアクセスできます。
  • 最大 4 つの開発ステージを設定し、会社の用語に合わせて名前をカスタマイズできます。 Admin の権限ページ内の名前は固定です。 ただし、Studioでは、独自の名前を定義することができます。 Studio で各ステージに割り当てた名前は、Studioを使用するスクリプト開発者に表示される名前になります。
  • 各ステージ内で、スクリプト開発者はサブフォルダーを作成してスクリプトを整理できます。

  • サードパーティのバージョン管理システムとの統合を構成できます。 これにより、スクリプト開発者はスクリプトを指定されたリポジトリにプッシュできるようになります。 現在、GitHubがサポートされているプロバイダーです。