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

このページの内容は、制御リリース(CR)中の製品または機能に関するものです。 CRグループに参加していない場合で、詳細情報を知りたい方は、アカウント担当者にお問い合わせください。

特に明記されていない限り、このヘルプページの情報はStudioにのみ適用されます。

Studioはスクリプト開発ライフサイクルの管理に役立つツールを提供します。

  • 開発、テスト、本番稼働などの開発ワークフロー段階を通じてのスクリプトのプロモーション。
  • サードパーティのバージョン管理システムとの統合。 現在、GitHubがサポートされているプロバイダーです。
  • またはでスクリプトの変更履歴を表示し、StudioまたはDesktop Studioで過去のバージョンに戻す機能。

開発ワークフロー段階とスクリプトのプロモーションは、Studioでのみ利用可能です。 さまざまな段階のスクリプトのセキュリティを保護するために、開発ワークフロー段階に割り当てられたフォルダーはDesktop Studioには表示されません。

Studioのソフトウェア開発ライフサイクル

ソフトウェアエンジニアリングでは、多くの組織が開発に多段階アプローチを使用する方法論に従っています。 このような方法論では、ソフトウェア開発ライフサイクル(SDLC)は、ソフトウェアの変更の計画、設計、開発、テスト、および展開の各段階で構成されます。 多段階のSDLC方法論に従うことで、最終製品の品質が向上し、開発プロセスが合理化されます。

スクリプト開発ライフサイクルの管理を支援するために、Studioは組み込みの開発ワークフロー段階を提供します。 これは、次のような理由でスクリプト開発プロセスに役立ちます。

  • 各段階でのスクリプトへのアクセスは権限によって保護されます。 これにより、開発段階に基づいて、どのStudioユーザーがスクリプトを操作できるかを制御できます。
  • スクリプトは、開発プロセスが進むにつれて、ある段階から次の段階へとプロモートされる必要があります。 スクリプトをプロモートする機能は権限によって制御されるため、スクリプトをプロモートできるユーザーを制限できます。
  • スクリプトは下位ステージにコピーできます。 たとえば、問題を解決するために、テストフォルダーから開発フォルダーにスクリプトをコピーできます。 これは、スクリプトの変更や拡張が必要な場合に、スクリプトの最新バージョンから開始していることを確認するのに役立ちます。
  • スクリプトを次の段階にプロモートする前に検証する必要がある要件を設定できます。 たとえば、展開前段階に移行する前に、すべてのスクリプトをピアレビューしてテストすることが必要になる場合があります。 プロモーション要件はStudioに組み込まれていません。 これらは、会社がStudioの外部で実装する必要があるポリシーと手順です。

Studioの開発ワークフロー段階を使用すると、CXone Mpower システムをスクリプトによって発生する予期しない問題から保護できます。 不完全なスクリプトや十分にテストされていないスクリプトが本番環境に入り込む可能性が減ります。

Studio開発段階

Studioでは、開発ワークフローは次の4つの組み込み段階で構成されます。

  • 開発
  • テスト
  • 展開前
  • 本番稼働

会社のスクリプト開発プロセスに合わせて段階を有効にすることができます。 たとえば、テスト段階や展開前段階を使用しない場合は、それらを省略して、開発段階と本番稼働段階のみを有効にすることができます。 会社に確立されたマルチ段階開発プロセスがない場合は、スクリプト開発ライフサイクルを計画する際に組み込みの段階を使用できます。

各段階はStudio内のフォルダーに関連付けられています。 現在ワークフロー内にあるすべてのスクリプトはそのフォルダーに存在します。 スクリプトが次の段階にプロモートされるか、下位の段階にコピーされると、その段階のフォルダーにコピーされます。

組み込みの段階の名前は変更できません。 ただし、各ステージにトップレベルフォルダーを作成する場合は、任意の名前を付けることができます。 Studioユーザーがスクリプトをプロモートまたはコピーすると、フォルダー名がUIに表示されます。 たとえば、会社が展開前段階にStagingという名前を使用している場合は、Stagingというフォルダーを作成し、それをStudioの展開前段階に割り当てることができます。 各ステージの最上位フォルダーの下にサブフォルダーを作成することができます。

Jenkinsなどのツールを使用して、Studio開発ワークフロー段階で使用する独自の自動化を構築できます。

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

開発ワークフローステージでのプロモート先権限を持つStudioユーザーは、前のステージから権限を持つステージにスクリプトをプロモートできます。 たとえば、テスト段階でプロモート先権限を持つスクリプト作成者は、スクリプトを開発段階からテスト段階にプロモートできます。 スクリプトは、CXone Mpower システムで有効になっている次の段階にのみプロモートできます。 段階をスキップすることはできません。

スクリプトは、下のステージにコピーすることもできます。 これは、スクリプトに変更や拡張が必要な場合に役立ちます。 たとえば、展開前段階でスクリプトに欠陥が見つかった場合、それを開発段階にコピーして問題を修正できます。 その後、スクリプトは、会社のワークフロープロセスを経てから、再度展開前段階にプロモートする必要があります。 スクリプトを下位ステージにコピーするのに権限は不要です。 ただし、ユーザーはスクリプトのコピー元の段階のフォルダーに対する表示権限を持っている必要があります。  スクリプトは以下からコピーできます:

  • 本番環境から展開前、テスト、または開発まで。
  • テストまたは開発への展開前。
  • テストから開発まで。
  • 同じまたは別の開発サブフォルダーへの開発。

スクリプトがプロモートまたはコピーダウンされると、宛先ステージのフォルダーにコピーされます。 つまり、スクリプトは各段階のフォルダーにバージョンが保存される可能性があることになります。 次のレベルのフォルダーにスクリプトのバージョンがすでに存在する場合は、上書きされます。 正しい段階のフォルダーからプロモートまたはコピーすることが重要です。 どのバージョンをコピーすればよいかわからない場合は、各段階でスクリプトのバージョン履歴を使用して、どのバージョンをプロモートまたはコピーする必要があるかを判断できます。

スクリプトは、スクリプトのキャンバスまたはStudioのスクリプトページから昇格させることができます。 スクリプトページでは、複数のスクリプトを同時にプロモートできます。 サードパーティのバージョン管理システムでStudioを設定している場合は、プロモーションも指定されたリポジトリにコミットされます。

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

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

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

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

スクリプトバージョン管理の2つのオプションは連携して機能します。 バージョン管理システムを使用している場合は、Studioが保持しているスクリプトの過去のバージョンを表示して元に戻すことができます。

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

サードパーティのバージョン管理システム

Studioでサードパーティのバージョン管理システムを使用できます。 リポジトリをStudioに接続すると、各スクリプトへの変更がそのリポジトリにコミットされます。 すべての変更はメインブランチにコミットされます。 Studioは現在、単一ブランチの開発のみをサポートしています。

Studioユーザーが初めてリポジトリに変更をコミットしようとすると、そのリポジトリのアクセストークンを入力するように求められます。 システムで認証された後は、Studioに問題が発生してユーザーの再認証が必要になる場合を除き、再度資格情報の入力を求められることはありません。

この機能はStudioでのみサポートされています。 このため、バージョン管理システムには各スクリプトのJSONバージョンのみが保存されます。

非スクリプトファイル

バージョン管理はスクリプトファイルに対してのみ使用できます。 ASR閉じた コンタクトが録音された音声プロンプトに対して、話す、電話のキーを押す、またはその両方の組み合わせで応答できる機能。文法ファイルやレコード済みの音声プロンプトファイルなどの他のファイルには、履歴バージョンが保存されていません。 また、GitHubなどのサードパーティのバージョン管理システムでは追跡できません。 スクリプト以外のファイルのバージョンを追跡するには、名前ベースのバージョン管理アプローチを使用できます。

名前ベースのバージョン管理アプローチでは、ファイル名にバージョン名または番号を含めます。 たとえば、greetingPrompt_v1.wavなどです。 ファイルに変更を加えると、更新されたバージョン番号を持つ新しいコピーが保存されます。 たとえば、greetingPrompt_v1.wavgreetingPrompt_v2.wavになります。

CXone Mpowerでこれらのファイルの名前を変更することはできません。 ただし、ファイルをコンピューターにダウンロードし、名前を変更して、新しいバージョンをアップロードすることはできます。 不要になったファイルのバージョンを削除できます。

組織

開発ワークフローを設定するときは、Studioで組織を作成する必要があります。 組織は、段階とそれに関連付けられたフォルダーのセットを1つ定義します。 また、サードパーティのバージョン管理システムリポジトリも1つ定義します(そのオプションを使用する場合)。

追加の組織を作成できます。 組織は、会社内のさまざまなチーム、事業部門、またはその他の区分にマッピングできます。 会社が次のような場合は、複数の組織を作成することをお勧めします。

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

各組織には、CXone Mpower システム内に独自のフォルダーがあります。 各組織のすべてのスクリプトはそのフォルダーに保存されます。 各フォルダー内にサブフォルダーを作成すると、使用する開発ワークフローの各段階でスクリプトを保持できます。 各ワークフロー段階のフォルダーには、追加のサブフォルダーを含めることができます。 複数の組織がある場合、Studioのフォルダー構造は次の例のようになります。

  • \Classics
    • \Dev
    • \Test
    • \Staging
    • \Prod
  • \ClassTexts
    • \Develop
    • \UAT
    • \Prod

各組織の必要に応じてスクリプトセキュリティを設定できます。 ビュー閉じた CXone Mpowerでユーザーが閲覧できる情報を制御できる機能。Studio権限により、会社のスクリプトにアクセスして操作できるユーザーをきめ細かく制御できます。