指令碼開發生命週期管理

本頁面中的檔案適用於受控發佈 (CR) 版本中的產品或功能。 如果您不是 CR 群組成員,但希望獲得更多資訊,請聯絡 客戶代表

除非另有說明,本說明頁面的資訊僅適用於Studio

Studio提供可協助您管理指令碼開發生命週期的工具:

  • 開發工作流程階段(如開發、測試和生產)指令碼推進。
  • 與第三方版本控制系統整合。 目前,GitHub是支援的提供者。
  • StudioDesktop Studio中檢視指令碼的變更歷史和還原為過去版本的能力。

開發工作流程階段和指令碼推進僅適用於Studio。 為了保護各階段中指令碼的安全性,指派給開發工作流程階段的資料夾在Desktop Studio中是不可見的。

Studio中的軟體開發生命週期

在軟體工程中,許多組織遵循使用多階段方式進行開發的方法。 在這些方法中,軟體開發生命週期 (SDLC) 包含規劃、設計、開發、測試和部署軟體變更的各個階段。 遵循多階段 SDLC 方法有助於提高最終產品的品質,並簡化開發流程。

為了幫助您管理指令碼開發的生命週期,Studio提供內建的開發工作流程階段。 這可以讓您的指令碼開發流程受益,因為:

  • 在每個階段存取指令碼都受到權限保護。 這可以讓您控制哪些Studio使用者可以根據其開發階段與指令碼互動。
  • 指令碼在開發過程中,必須從一個階段推進到下一個階段。 推進指令碼的能力由權限控制,因此您可以限制誰可以推進指令碼。
  • 指令碼可以向下複製到較低的階段。 例如,您可以將指令碼從測試資料夾複製到開發資料夾來解決問題。 當指令碼需要變更或增強時,這有助於確保您從最新版本的指令碼開始。
  • 您可以建立指令碼推進至下一階段前必須驗證的要求。 例如,您可能會要求所有指令碼在進入預部署階段之前,都必須經過同行檢閱和測試。 推進要求不被構建到Studio中。 這些是貴公司必須在Studio以外實作的原則與程序。

Studio中使用開發工作流程階段有助於保護您的CXone Mpower 系統免於指令碼造成的意外問題。 這可以減少不完整的指令碼或未經過完整測試的指令碼投入生產的幾率。

Studio開發階段

Studio中,開發工作流程包含四個內建階段:

  • 開發
  • 測試
  • 部署前
  • 生產

您可以啟用符合貴公司指令碼開發流程的階段。 例如,如果您不使用測試或預部署階段,您可以省略這些階段,只啟用開發和生產階段。 如果您的公司沒有既定的多階段開發流程,您可以在規劃指令碼開發生命週期時使用內建的階段。

每個階段都與Studio中的資料夾關聯。 目前工作流程中的所有指令碼都儲存在該資料夾中。 當指令碼推進到下一階段或向下複製到較低階段時,指令碼會被複製到該階段的資料夾中。

無法變更內建階段的名稱。 但是,當您為每個階段建立頂層資料夾時,您可以為它們命名任何您喜歡的名稱。 當Studio使用者推進或向下複製指令碼時,資料夾名稱會出現在使用者介面。 例如,如果您的公司使用「階段化」作為預部署階段的名稱,您可以建立一個名為階段化的資料夾,並將其指派給Studio中的預部署階段。 您可以在每個階段的頂層資料夾下建立子資料夾。

您可以使用 Jenkins 等工具,建立自己的自動化以用於Studio開發工作流程階段。

指令碼提升和復制

Studio 對開發工作流程階段擁有提升到權限的使用者可以將指令碼從上一個階段提升到他們擁有權限的階段。 例如,測試階段的「提升到」權限的指令碼編寫者可以將指令碼從開發階段提升到測試階段。 指令碼只能推進到在您的CXone Mpower 系統中啟用的下一個階段。 指令碼不能跳過階段。

指令碼也可以復製到較低的階段。 當指令碼需要變更或增強時,這會很有用。 例如,如果在預部署階段的指令碼中發現缺陷,您可以將其複製到開發階段以修正問題。 之後,指令碼必須經過貴公司的工作流程,才能再次提升為預部署。 將指令碼向下複製到較低的階段不需要權限。 但是,使用者必須擁有複製指令碼時指令碼來自的資料夾的檢視權限。  您可以從以下位置複製指令碼:

  • 生產到部署、測試或開發前。
  • 部署前到測試或開發。
  • 測試到開發。
  • 開發到相同的或另一個開發子資料夾。

當指令碼提升或向下複製時,會將其複製到目標階段的資料夾中。 這表示指令碼可能會在每個階段的資料夾中出現各種版本。 如果下一層的資料夾中已有指令碼版本,則會覆寫。 從正確的階段資料夾推進或向下複製是很重要的。 如果您不確定要向下複製哪個版本,您可以使用每個階段的指令碼版本歷史來判斷您需要推進或向下複製的版本。

指令碼可以從指令碼的畫布或從Studio 的指令碼頁面提升。 在指令碼頁面中,您可以同時推進多個指令碼。 如果您已經配置Studio為使用第三方版本控制系統,推進也會被提交到指定的儲存庫。

指令碼版本控制

版本控制可讓您追蹤和管理指令碼開發過程中的變更。 這可讓您在問題發生時進行研究。 必要時,您可以還原到指令碼的先前版本,以撤銷有問題的變更。

Studio提供兩個指令碼版本控制的選項:

  • 第三方版本控制系統Studio可以將指令碼變更提交到第三方版本控制系統。 目前,GitHub僅是支援的提供者。 此功能是受控發布計劃的一部分。 如有興趣了解更多資訊,請聯絡您的客戶代表
  • 指令碼歷史Studio儲存可配置的多個每個指令碼過去版本。 每次儲存指令碼時,都會建立該歷史版本的記錄。 您可以檢視先前版本還原為先前版本(如果需要)。 Desktop StudioStudio支援此選項。 此功能不是受控發布計劃的一部分。

指令碼版本控制的兩個選項同時運作。 如果您使用版本控制系統,您仍然可以檢視並還原到Studio保留的指令碼過去版本。

同樣,如果您使用Studio中的開發工作流程階段,您可以檢視指令碼的過去版本。 但是,過去版本僅限於每個階段的版本。 若要檢視不同階段的過去版本,您必須檢視該階段中的指令碼。 檢視不同階段的指令碼需要您擁有在該階段操作的權限

第三方版本控制系統

您可以對Studio使用第三方版本控制系統。 當您連接一個儲存庫到Studio時,每個指令碼的變更都會提交到該儲存庫。 所有變更已提交至主分支。 Studio目前只支援單分支開發。

Studio使用者首次嘗試提交變更到儲存庫時,系統會提示使用者輸入該儲存庫的存取權杖。 系統認證之後,除非Studio遇到問題並需要重新認證使用者,否則不會再提示使用者進行憑證。

該功能僅支援Studio。 因此,版本控制系統中只會儲存每個指令碼的 JSON 版本。

非指令碼檔案

版本控制僅適用於指令碼檔案。 其他檔案,例如ASRClosed 允許聯絡人透過說話、點擊手機按鍵或兩者組合的方式來回應錄音的語音提示。文法檔案或預錄製音訊提示檔案,沒有儲存的歷史版本。 這些檔案也無法在第三方版本控制系統中追蹤,例如GitHub。 若要追蹤非指令碼檔案的版本,您可以使用基於命名的版本管理方式。

在基於命名的版本管理方法中,您會在檔案名稱中包含版本名稱或編號。 例如,greetingPrompt_v1.wav。 當您變更檔案時,您會以更新的版本號儲存新的副本。 例如,greetingPrompt_v1.wav會變成greetingPrompt_v2.wav

您無法變更CXone Mpower中這些檔案的名稱。 不過,您可以下載檔案到您的電腦,對其重新命名,然後再上傳新版本的檔案。 您可以刪除不再需要的檔案版本。

組織

當您設定開發工作流程時,您必須在Studio中建立組織。 組織定義一組階段和與之關聯的資料夾。 如果您使用該選項,其中也定義了一個第三方版本控制系統儲存庫。

您可以建立其他組織。 組織可對應到公司內不同的團隊、業務線或其他內容。 如果您的公司是如下情況,您可能要建立一個以上的組織:

  • 希望為指令碼使用一個以上的儲存庫。
  • 在不同的群組或團隊中使用不同的開發工作流程階段。
  • 希望將不同業務線的指令碼彼此分開。

在您的CXone Mpower 系統中,每個組織都有自己的資料夾。 每個組織的所有指令碼都儲存在該資料夾。 在每個資料夾內,您會建立子資料夾,以存放您使用的每個開發工作流程階段的指令碼。 每個工作流程階段的資料夾可以有額外的子資料夾。 如果您有多個組織,您在Studio中的資料夾結構會與以下範例相似:

  • \Classics
    • \開發者
    • \測試
    • \階段化
    • \生產
  • \類別文字
    • \開發
    • \UAT
    • \生產

您可以根據每個組織的需要,配置指令碼安全性檢視Closed 允許您控制使用者可以在CXone Mpower中看到的資訊。Studio權限可對誰可以存取您公司的指令碼以及與指令碼互動提供精細控制。