脚本开发 生命周期 管理
除非另有说明,否则本帮助页面上的信息仅适用于 Studio。 为保护各个阶段中脚本的安全,分配给开发工作流阶段的文件夹在 Desktop Studio 中不可见。
Studio 提供了一个开发阶段系统,以帮助您管理公司的脚本开发生命周期。 开发阶段是组织脚本和在脚本开发生命周期中管理脚本推广的工具。
开发阶段根据脚本在开发过程中所处的位置对其进行组织。 您可以配置最多四个阶段,以匹配您的脚本开发人员遵循的流程。 例如,你可以使用开发、测试和生产阶段。 脚本开发者创建或编辑脚本时,他们处于开发阶段。 然后,当脚本准备好进行测试时,他们就可以将其提升到下一阶段。
在软件工程中,许多组织遵循使用多阶段方法进行开发的方法。 在这些方法中,软件开发生命周期 (SDLC) 由规划、设计、开发、测试和部署软件变更的阶段组成。 遵循多阶段 SDLC 方法有助于提高最终产品的质量并简化开发流程。
您的开发工作流程结构
Studio 支持您在脚本文件夹结构内的开发工作流程。 具体管理方式取决于您的 CXone Mpower 系统 是否配置为 部门
安全地隔离不同业务部门之间的数据。 数据只能在其所属部门内访问。。 如果您的系统使用 部门,则脚本的组织方式与您的部门保持一致。 如果你的 系统 不使用 divisions,Studio 允许你使用 organizations 来组织脚本。
组织和部门都被分配到 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),分别是向大学生销售和出租教科书的经典教材,以及连锁书店咖啡馆经典咖啡书店。
他首先在 CXone Mpower Admin 中创建并给自己分配一个角色,该角色拥有创建、编辑和推广到所有四个阶段的权限。
Christopher 与各业务线的 Studio 脚本团队经理进行沟通,了解每个团队的开发生命周期。 然后,他在 Studio 的“工作流开发”页面上创建了两个组织,ClassicTexts 和 ClassicCafe,每个组织都有其相应的开发阶段。
接下来,Christopher 在 Studio 中创建文件夹结构。 他为每个 LOB 组织创建一个临时脚本,并选择输入文件夹路径的选项,将两个组织的文件夹路径都命名为 \dev\main。
最后,克里斯托弗在每个组织中创建的每个阶段都推广了这个临时脚本。 在更高阶段,他没有创建任何子文件夹。 相反,他只是将剧本移到了舞台文件夹里。 最后,他停用了临时脚本。
克里斯托弗现在可以在 Studio 中看到以下文件夹结构:
经典咖啡馆
开发
\主要的
\Prod
经典文本
开发
\主要的
QA
\Prod
脚本升级和复制
当一个脚本准备好进入下一阶段时,具有相应权限的脚本开发者可以将其提升。 脚本只能晋升到下一个更高阶段。 他们也只能晋升到为脚本开发者所属的组织或部门配置的阶段。
提升脚本会在目标阶段创建该脚本的副本。 它还会将路径中的所有文件夹复制到脚本所在位置,但暂不包括 stage 文件夹。 这样可以强化脚本开发人员创建的组织结构。
Tigger Tiggerson 是 Classic Texts 的一名剧本开发人员。 他正在处理 ScriptA,它位于 /QA/Jan2025/TiggerTest/IBVoice。 他将其提升到生产阶段。 当他查看 Prod 文件夹时,他发现 /Jan2025/TiggerTest/IBVoice 的整个路径都与 ScriptA 文件一起复制了上去。 由于 /QA 文件夹是暂存文件夹,因此没有将其复制上去。
默认情况下,脚本在提升时会存储在目标开发阶段的相同子文件夹中。 脚本开发者可以更改脚本存储的子文件夹,包括创建新文件夹。
贵公司可以制定内部流程,以定义何时将剧本从一个阶段提升到下一个阶段的条件。 Studio 不跟踪这些条件,也不验证这些条件是否已得到满足。 但是,您可以使用 CXone Mpower 角色和权限来控制哪些 Studio 用户可以晋升到每个阶段。 您还可以控制每个阶段谁可以查看、创建和编辑脚本。
推广脚本的变更
遵循典型的脚本开发生命周期工作流程意味着,当需要对处于较高阶段的脚本进行更改时,脚本开发人员应该在指定用于开发的阶段的脚本副本上进行操作。 但是,如果脚本在更高阶段被修改,则可以将其复制到最低级别的文件夹中。 只有在需要紧急修复并且直接在更高阶段对脚本进行修复时,才需要这样做。
当脚本被提升或复制到另一个开发阶段时,它会被复制到目标阶段的文件夹中。 如果脚本位于一个阶段文件夹内的子文件夹中,则该子文件夹及其路径将复制到目标阶段的文件夹中。
需要权限才能将脚本提升和复制到其他开发阶段。 脚本开发者必须具备:
- 推广至他们要推广剧本的舞台的权限。
- 他们拥有将脚本复制到的舞台的创建/编辑权限。
- 脚本当前所在舞台的查看权限。
将脚本提升或复制到不同的开发阶段会覆盖目标阶段中已存在的旧版本脚本。 如有需要,脚本开发人员可以比较脚本以确定差异,然后再进行提升或复制。 他们还可以查看脚本的版本历史记录,如果更改被覆盖,则可以恢复到旧版本。
脚本和数据访问控制
您可以控制在 Studio 中定义的每个开发阶段谁可以访问脚本。 使用分配给 Admin 中角色的权限,您可以限制脚本开发人员在每个阶段查看、创建和编辑以及停用脚本的能力。 您还可以控制开发者可以将脚本提升到哪些阶段。
这些权限适用于组织和部门:
-
对于组织而言,这些权限并不能阻止脚本开发者查看其他组织的脚本。 如果开发人员有权查看开发阶段的脚本,他们将能够看到每个组织中开发文件夹内的所有脚本。
-
使用 divisions
安全地隔离不同业务部门之间的数据。 数据只能在其所属部门内访问。,脚本开发人员只能看到他们被分配到的部门或他们被分配到的部门的任何子部门中的脚本。 例如,有权查看其所在部门开发阶段脚本的脚本开发人员将无法查看同一层级或更高层级其他部门的开发阶段文件夹。
阶段式脚本管理
开发阶段设置完成后,脚本开发人员就可以开始在系统中工作了。 你需要确保你的开发人员了解如何在你搭建的系统中工作。
在设计流程时,请考虑以下因素:
- 你在Studio中设置了哪些阶段?
- 决定剧本何时以及如何晋升到各个开发阶段的标准。
- 谁可以推广剧本,以及可以推广到哪个阶段。
- 如果需要修改更高级别的脚本,该怎么办? 例如,他们应该在开发阶段完善该剧本的文案,并使其逐步推进到下一个阶段。
- 如果脚本在更高阶段进行了破坏性修复更改,该怎么办? 例如,是否应该将该版本的脚本复制到开发环境? 脚本开发者可以比较脚本,看看哪个是较新的版本。
- 贵公司针对剧本开发制定的任何其他准则或限制措施。
脚本版本控制
版本控制可使您在开发过程中跟踪和管理对脚本的更改。 这可使您在出现问题时研究它们。 如有必要,您可以还原到脚本的先前版本,以撤消有问题的更改。
Studio 为脚本版本控制提供了两个选项:
- 脚本历史记录:Studio 保留每个脚本过去版本的可配置数量。 每次保存脚本时,其都会创建该历史版本的记录。 如果需要,您可以查看先前版本并还原到它们。 在 Desktop Studio 和 Studio 支持此选项。
- 第三方版本控制系统: Studio可以将脚本更改提交到第三方版本控制系统。 目前,GitHub 是唯一受支持的提供程序。 该功能是受控发布计划的一部分。 如果您有兴趣了解更多信息,请联系您的 客户代表。
脚本版本控制的这两个选项可协同工作。 如果您使用版本控制系统,您仍可以查看并还原到 Studio 保留的脚本的过去版本。 然而,GitHub 并不认为这是一个回退。 相反,它将还原后的脚本视为新的更改。
同样地,如果您在 Studio 中使用开发阶段,您可以查看脚本的过去版本。 然而,过去版本仅限于每个阶段中的版本。 要从不同阶段查看过去版本,您必须查看该阶段的脚本。 查看不同阶段的脚本需要您拥有在该阶段工作的权限。
关于Studio中发展阶段的关键事实
- 如果贵公司采用部门
安全地隔离不同业务部门之间的数据。 数据只能在其所属部门内访问。,则可以在每个部门内设置单独的开发阶段。 Studio 用户只能访问其所在部门中他们有权查看的文件夹中的脚本。 - 如果您不使用部门,则 Studio 用户只能访问他们有权查看的开发阶段中的脚本。
- 您可以配置最多四个开发阶段,并自定义名称以匹配您公司的术语。 Admin 中的权限页面名称是固定的。 但是,在 Studio 中,您可以定义自己的名称。 您在 Studio 中为每个阶段指定的名称将显示给使用 Studio 的脚本开发人员。
-
在每个阶段中,脚本开发者可以创建子文件夹来组织脚本。
- 您可以配置与第三方版本控制系统的集成。 这样一来,脚本开发者就可以将脚本推送到指定的存储库。 目前,GitHub 是受支持的提供商。