指令碼開發生命週期管理
除非另有說明,否則本說明頁面上的資訊僅適用於Studio。 為了保護各階段中指令碼的安全性,指派給開發工作流程階段的資料夾在Desktop Studio中是不可見的。
Studio 提供了一個開發階段系統來幫助您管理公司的指令碼開發生命週期。 開發階段是在指令碼開發生命週期中組織指令碼和管理指令碼升級的工具。
開發階段根據指令碼在開發過程中所處的位置來組織指令碼。 您最多可以配置四個階段,以符合指令碼開發人員遵循的流程。 例如,您可以使用階段進行開發、測試和生產。 當指令碼開發人員建立或編輯指令碼時,他們會在開發階段工作。 然後,當指令碼準備好進行測試時,他們可以將其提升到下一階段。
在軟體工程中,許多組織遵循使用多階段方式進行開發的方法。 在這些方法中,軟體開發生命週期 (SDLC) 包含規劃、設計、開發、測試和部署軟體變更的各個階段。 遵循多階段 SDLC 方法有助於提高最終產品的品質,並簡化開發流程。
開發工作流程的結構
Studio支援指令碼資料夾結構中的開發工作流程。 管理此操作的確切方式取決於您的CXone Mpower 系統是否配置為分部
在業務線之間安全地分離資料。 資料只能從其所屬部門內存取。。 如果您的系統使用分部,指令碼的組織將與您的分部保持一致。 如果您的系統不使用分部,Studio允許您使用組織來組織指令碼。
組織和部門都被指派給Studio內的資料夾。 資料夾位於 ACD 檔案儲存中 CXone Mpower。 每個組織或部門都有自己的一組資料夾,其中包含一個頂層資料夾和一個資料夾,用於該組織或部門中使用的每個開發階段。 在每個階段資料夾中,您可以建立子資料夾來組織指令碼。 唯一必要的子資料夾位於最低層級的開發階段,其中必須有一個名為 main的資料夾。
指令碼開發人員將指令碼從一個階段提升到下一個階段。 他們可以在下一階段選擇目標資料夾。 您可以根據需要為每個組織或部門配置指令碼安全性。 Studio權限可逐步控制誰可以存取貴公司的指令碼並與之互動。 對於部門,開發工作流程權限允許您在每個部門內進行更精細的控制,以控制對指令碼的存取。
組織的開發工作流程
Studio要求您在設定開發工作流程時建立組織。 組織只是Studio內的實體。 它們的唯一目的是組織開發階段及其包含的腳本。
組織會定義一組開發階段,以及與這些階段相關聯的資料夾。 如果您搭配Studio使用第三方版本控制系統,組織也會定義指令碼提交到的儲存庫。 每個組織可以使用不同的儲存庫。
您可以建立多個組織。 組織可對應到公司內不同的團隊、業務線或其他內容。 如果您的聯絡中心規模較小,或者您的公司結構簡單明了,那麼您可能只需要一個組織。 但是,如果您的公司符合以下條件,則可能需要建立多個組織:
- 希望為指令碼使用一個以上的儲存庫。
- 在不同的群組或團隊中使用不同的開發階段。
- 想要將來自不同群組、團隊或業務線的指令碼彼此分開。
在您的CXone Mpower 系統中,每個組織都有自己的資料夾。 每個組織的所有指令碼都儲存在該資料夾。
如果您的公司不需要多個組織,則無需為組織的指令碼建立資料夾。 這表示開發階段的資料夾可以位於Studio檔案結構的根目錄下。
有部門的開發工作流程
部門允許組織安全地細分其CXone Mpower 系統內的資料,以分隔不同的業務線。 它們是存在於CXone Mpower中的實體。 啟用後,分部會影響所有平台資料,包括Studio指令碼。
CXone Mpower管理員必須在中Admin建立部門應用程式。 之後,您可以將分部映射到Studio中的資料夾。 Studio中的資料夾結構必須與CXone Mpower 系統內部門的階層結構相符。 負責部門的平台管理員可以協助您確定階層。
每個部門都有自己的一套發展階段。 如果您將第三方版本控制系統與 Studio一起使用,則儲存庫將按部門指派。 每個部門可以使用不同的儲存庫。
組織和部門的比較
下表總結了組織和部門之間的差異及其對開發工作流程功能的支援。
| 組織 | 部門 | |
|---|---|---|
| 在CXone Mpower內的實體 | 否 | 是 |
|
Studio中的頂層資料夾要求 |
多個組織必須在Studio中擁有自己指派的頂層資料夾。 一個組織不需要頂層資料夾。 您可以使用根目錄來保存開發階段資料夾。 |
每個分部必須有自己的資料夾。 資料夾結構必須與平台中的分割結構相符。 |
| 支援開發階段 |
是 每個組織都有一組唯一的階段和階段資料夾。 |
是 每個分部都有一組唯一的階段和階段資料夾。 |
| 支援第三方版本控制系統整合 |
是 每個組織都可以使用自己的儲存庫。 |
是 每個部門都可以使用自己的儲存庫。 |
| 支援控制使用者對指令碼和階段存取的權限 | 是 | 是 |
發展階段
開發階段是管理指令碼開發生命週期的核心。 您最多可以定義四個階段,以符合公司既定的流程。 例如,如果貴公司的開發生命週期有兩個步驟:開發和生產,您可以在Studio中設定開發階段以匹配。 您可以自訂開發階段的名稱,以符合指令碼開發人員習慣的名稱。
開發階段是組織或部門的子項,具體取決於CXone Mpower 系統的設定方式。 每個組織或部門都有自己獨特的發展階段。 這允許您為每個組織或部門自訂開發工作流程。
在第一階段,必須有一個名為 main 的資料夾。 這代表版本控制系統中的主要分支,例如 GitHub。 所有指令碼必須位於 main 資料夾中。 指令碼開發人員可以在 main 中建立子資料夾來組織指令碼。 如果您想將第三方版本控制系統與 一起使用,則需要 main Studio資料夾。 即使您不打算使用版本控制,也必須將最低層級階段的所有指令碼儲存在 main 資料夾中。
其他階段沒有相同的資料夾命名要求。 您可以在其他三個階段中擁有任意數量的子資料夾,而且可以命名為任何名稱。 這允許您使用子資料夾以符合公司需求的方式組織指令碼,例如按發行。
Classics, Inc. 的Studio管理員 Christopher Robin 正在設定開發階段。 Classics, Inc. 有兩條業務線 (LOB),Classic Texts,向大學生銷售和出租教科書,以及 Classic Cafe and Books,連鎖書店咖啡館。
他首先在CXone Mpower Admin中建立並指派一個角色,該角色具有建立、編輯和晉升到所有四個階段的權限。
Christopher 會諮詢每個 LOB 的 Studio 指令碼團隊經理,並了解每個團隊的開發生命週期。 然後,他建立了兩個組織:ClassicTexts 和 ClassicCafe,每個組織在Studio的「工作流程開發」頁面上都有適當的開發階段。
接下來,Christopher 在Studio中建立資料夾結構。 他會為每個 LOB 的組織建立暫存腳本,並選擇輸入資料夾路徑的選項,並將這兩個組織命名為 \dev\main。
最後,克里斯托弗通過他在每個組織中創建的每個階段來推廣臨時劇本。 他不會在較高階段建立任何子資料夾。 相反,他只是將劇本提升到舞台的文件夾中。 最後,他停用臨時指令碼。
Christopher 現在可以在Studio中看到以下資料夾結構:
\經典咖啡館
\開發
\主要
\產品
\經典文字
\開發
\主要
\品質保證
\產品
指令碼提升和復制
當指令碼準備好進入下一階段時,具有適當權限的指令碼開發人員可以將其升級。 指令碼只能提升到下一個最高階段。 它們也只能提升到為指令碼開發人員所屬的組織或部門配置的階段。
升級指令碼會在目的地階段建立指令碼的副本。 它還會複製指令碼位置路徑中的所有資料夾,但舞台資料夾除外。 這會強制執行指令碼開發人員建立的組織結構。
跳跳虎跳跳虎是 Classic Texts 的腳本開發人員。 他正在開發 ScriptA,該 ScriptA 位於 /QA/Jan2025/TiggerTest/IBVoice。 他將其提升到 Prod 階段。 當他查看 Prod 資料夾時,他看到 /Jan2025/TiggerTest/IBVoice 的整個路徑已與 ScriptA 檔案一起複製。 /QA 資料夾未複製,因為它是舞台資料夾。
依預設,升級指令碼時,它們會儲存在目的地開發階段的相同子資料夾中。 指令碼開發人員可以變更指令碼的儲存子資料夾,包括建立新資料夾。
您的公司可以開發內部流程,以定義何時將指令碼從一個階段提升到另一個階段的條件。 Studio 不會追蹤這些條件或驗證是否已滿足這些條件。 但是,您可以使用CXone Mpower角色和權限來控制哪些Studio使用者可以提升到每個階段。 您也可以控制哪些人員可以在每個階段檢視、建立和編輯指令碼。
對升級指令碼的變更
遵循典型的指令碼開發生命週期工作流程意味著當需要對處於較高階段的指令碼進行變更時,指令碼開發人員應該處理處於指定開發階段的指令碼副本。 但是,如果指令碼在較高階段被修改,則可以將其複製到最低層級資料夾中。 唯一需要這樣做的情況是需要緊急修復並直接對較高階段的指令碼進行。
當指令碼升級或複製到另一個開發階段時,它會複製到目的地階段的資料夾中。 如果腳本位於一個階段資料夾內的子資料夾中,則子資料夾及其路徑將複製到目標階段的資料夾中。
需要權限將指令碼升級和複製到其他開發階段。 指令碼開發人員必須具備:
- 他們要將指令碼提升到的階段的提升到權限。
- 他們要將指令碼複製到的階段的建立/編輯權限。
- 指令碼目前所在階段的檢視權限。
將指令碼升級或複製到不同的開發階段會覆寫舊版本的指令碼(如果該指令碼存在於目標階段)。 如有需要,指令碼開發人員可以在升級或複製之前比較指令碼以確定差異。 他們還可以檢視指令碼的版本歷程記錄並在變更被覆寫時還原到舊版本。
指令碼和資料存取控制
您可以在Studio中定義的每個開發階段控制誰可以存取指令碼。 使用指派給 Admin中角色的權限,您可以限制指令碼開發人員在每個階段檢視、建立、編輯和停用指令碼的能力。 您也可以控制開發人員可以將指令碼提升到哪些階段。
這些權限適用於組織和部門:
-
對於組織,權限不會阻止指令碼開發人員能夠查看其他組織的指令碼。 如果開發人員有權限查看開發階段的指令碼,他們將能夠看到每個組織的開發資料夾中的所有指令碼。
-
使用部門
在業務線之間安全地分離資料。 資料只能從其所屬部門內存取。,指令碼開發人員只能看到他們被指派到的部門或他們被指派到的部門的任何子部門中的指令碼。 例如,具有檢視其指派部門中開發階段指令碼權限的指令碼開發人員將無法看到相同或更高階層層級上其他部門的開發階段資料夾。
具有階段的指令碼管理
設定開發階段後,指令碼開發人員就可以開始在系統內工作。 您需要確保您的開發人員了解如何在您設定的系統中工作。
設計流程時,請考慮下列事項:
- 您在Studio中設定了哪些階段。
- 何時以及如何將指令碼提升到每個開發階段的條件。
- 誰可以將指令碼提升到哪個階段。
- 如果需要修改更高層級的指令碼該怎麼辦。 例如,他們應該在開發階段處理該指令碼的副本,並在各個階段將其升級回來。
- 如果在較高階段對指令碼進行了中斷修復變更,該怎麼辦。 例如,該版本的指令碼是否應該複製到 dev? 指令碼開發人員可以比較指令碼以查看哪個版本較新。
- 貴公司為指令碼開發制定的任何其他指導方針或護欄。
指令碼版本控制
版本控制可讓您追蹤和管理指令碼開發過程中的變更。 這可讓您在問題發生時進行研究。 必要時,您可以還原到指令碼的先前版本,以撤銷有問題的變更。
Studio提供兩個指令碼版本控制的選項:
- 指令碼歷史:Studio儲存可配置的多個每個指令碼過去版本。 每次儲存指令碼時,都會建立該歷史版本的記錄。 您可以檢視先前版本並還原為先前版本(如果需要)。 Desktop Studio和Studio支援此選項。
- 第三方版本控制系統:Studio可以將腳本變更提交到第三方版本控制系統。 目前,GitHub僅是支援的提供者。 此功能是受控發佈計劃的一部分。 如有興趣了解更多資訊,請聯絡您的客戶代表。
指令碼版本控制的兩個選項同時運作。 如果您使用版本控制系統,您仍然可以檢視並還原到Studio保留的指令碼過去版本。 然而,GitHub並不認為這是回歸。 相反地,它會將還原的指令碼視為新的變更。
同樣,如果您在Studio中使用開發階段,則可以檢視指令碼的過去版本。 但是,過去版本僅限於每個階段的版本。 若要檢視不同階段的過去版本,您必須檢視該階段中的指令碼。 檢視不同階段的指令碼需要您擁有在該階段操作的權限。
關於Studio發展階段的關鍵事實
- 如果您的公司使用部門
在業務線之間安全地分離資料。 資料只能從其所屬部門內存取。,您可以在每個部門內設定單獨的開發階段。 Studio使用者只能存取其部門內位於其有權限檢視的資料夾中的指令碼。 - 如果您不使用分部,Studio使用者只能存取位於其有權限檢視的開發階段的指令碼。
- 您最多可以配置四個開發階段,並自訂名稱以符合您公司的術語。 Admin 中權限頁面中的名稱是固定的。 但是,在Studio中,您可以定義自己的名稱。 您在Studio中指派給每個階段的名稱是為使用 Studio的指令碼開發人員顯示的名稱。
-
在每個階段中,指令碼開發人員可以建立子資料夾來組織指令碼。
- 您可以設定與第三方版本控制系統的整合。 這允許指令碼開發人員將指令碼推送到指定的儲存庫。 目前,GitHub是支援的提供者。