脚本开发生命周期管理

Studio 提供可帮助您管理脚本开发生命周期的工具：

• 通过开发工作流阶段（例如开发、测试和生产）进行脚本提升。
• 与第三方版本控制系统集成。 目前，GitHub 是受支持的提供商。
• 能够查看脚本的更改历史记录并恢复到 Studio 或 Desktop Studio 中的过去版本。

Studio 中的软件开发生命周期

在软件工程中，许多组织遵循使用多阶段方法进行开发的方法。 在这些方法中，软件开发生命周期 (SDLC) 由规划、设计、开发、测试和部署软件变更的阶段组成。 遵循多阶段 SDLC 方法有助于提高最终产品的质量并简化开发流程。

为了帮助您管理脚本开发生命周期，Studio 提供了内置开发工作流阶段。 这可以使您的脚本开发流程受益，因为：

• 每个阶段对脚本的访问都受到权限的保护。 这可使您根据开发阶段控制哪些 Studio 用户可以与脚本交互。
• 随着开发过程的进展，脚本必须从一个阶段提升到下一阶段。 提升脚本的能力由权限控制，因此您可以限制谁可以提升脚本。
• 脚本可以复制到较低的阶段。 例如，您可以将脚本从测试文件夹复制到开发文件夹来解决问题。 这有助于确保您在需要更改或增强时从最新版本的脚本开始。
• 您可以建立在脚本提升到下一阶段之前必须验证的要求。 例如，您可能需要在进入预部署之前对所有脚本进行同行评审和测试。 提升要求未内置于 Studio 中。 它们是您公司必须在 Studio 之外实施的策略和程序。

在 Studio 中使用开发工作流阶段有助于保护您的 CXone Mpower 系统 免受脚本引起的意外问题。 它可减少将不完整的脚本或未经过充分测试的脚本投入生产的可能性。

Studio 开发阶段

在 Studio 中，开发工作流由四个内置阶段组成：

• 开发
• 测试
• 部署前
• 生产

您可以启用与您公司的脚本开发流程一致的阶段。 例如，如果您不使用测试或预部署阶段，则可以忽略这些阶段，仅启用开发和生产。 如果您的公司没有已建立的多阶段开发流程，您可以在规划脚本开发生命周期时使用内置阶段。

每个阶段都与 Studio 中的一个文件夹关联。 当前工作流中的所有脚本都存在于该文件夹中。 当脚本提升到下一个阶段或向下复制到较低阶段时，它会被复制到该阶段的文件夹中。

内置阶段的名称无法更改。 但是，当您为每个阶段创建顶级文件夹时，您可以将它们命名为您喜欢的任何名称。 当 Studio 用户提升或复制脚本时，文件夹名称会显示在 UI 中。 例如，如果您的公司使用名称 Staging 作为预部署阶段，您可以创建一个名为 Staging 的文件夹，并将其分配给 Studio。 您可以在每个阶段的顶级文件夹下创建子文件夹。

您可以使用 Jenkins 等工具构建自己的自动化，以便与 Studio 开发工作流阶段一起使用。

脚本升级和复制

拥有开发工作流阶段的“升级为”权限的 Studio 用户可以将脚本从上一个阶段升级到他们有权限的阶段。 例如，拥有测试阶段的升级为权限的脚本编写者可以将脚本从开发阶段升级到测试阶段。 只能将脚本提升到 CXone Mpower 系统 中启用的下一个阶段。 它们不能跳过阶段。

脚本还可以向下复制到较低的阶段。 当脚本需要更改或增强时，这很有用。 例如，如果在部署前阶段的脚本中发现缺陷，您可以将其向下复制到开发阶段以纠正问题。 然后，脚本必须经过公司的工作流，然后才能再次提升到部署前阶段。 将脚本复制到较低阶段不需要权限。 但是，对于他们从中复制脚本的阶段的文件夹，用户必须具有查看权限。  您可以从以下位置复制脚本：

• 生产到预部署、测试或开发。
• 预部署以进行测试或开发。
• 测试到开发。
• 开发到相同或另一个开发子文件夹。

升级或向下复制脚本时，它会被复制到目标阶段的文件夹中。 这意味着脚本最终在每个阶段的文件夹中可能都有版本。 如果下一级文件夹中已有该脚本的某个版本，则该版本会被覆盖。 从正确的阶段文件夹提升或向下复制非常重要。 如果不确定要复制哪个版本，可使用每个阶段的脚本版本历史记录来确定需要提升或向下复制哪个版本。

可从脚本画布或 Studio 中的“脚本”页面升级脚本。 在脚本页面上，您可以同时提升多个脚本。 如果您已使用第三方版本控制系统配置了 Studio，则还会将提升提交到指定的存储库。

脚本版本控制

版本控制可使您在开发过程中跟踪和管理对脚本的更改。 这可使您在出现问题时研究它们。 如有必要，您可以还原到脚本的先前版本，以撤消有问题的更改。

Studio 为脚本版本控制提供了两个选项：

• 第三方版本控制系统：Studio 可将脚本更改提交到第三方版本控制系统。 目前，GitHub 是唯一受支持的提供程序。 该功能是受控发布计划的一部分。 如果您有兴趣了解更多信息，请联系您的 客户代表。
• 脚本历史记录：Studio 保留每个脚本过去版本的可配置数量。 每次保存脚本时，其都会创建该历史版本的记录。 如果需要，您可以查看先前版本并还原到它们。 在 Desktop Studio 和 Studio 支持此选项。 该功能不是受控发布计划的一部分。

脚本版本控制的这两个选项可协同工作。 如果您使用版本控制系统，您仍可以查看并还原到 Studio 保留的脚本的过去版本。

同样，如果您在 Studio 中使用开发工作流阶段，则可查看脚本的过去版本。 然而，过去版本仅限于每个阶段中的版本。 要从不同阶段查看过去版本，您必须查看该阶段的脚本。 查看不同阶段的脚本需要您拥有在该阶段工作的权限。

第三方版本控制系统

您可以将第三方版本控制系统与 Studio 结合使用。 当您将存储库连接到 Studio 时，对每个脚本的更改都会被提交到该存储库。 所有更改都被提交到主分支。 Studio 目前仅支持单分支开发。

当 Studio 用户第一次尝试向存储库提交更改时，系统会提示他们输入该存储库的访问令牌。 通过系统身份验证后，系统不会再次提示他们输入凭据，除非 Studio 遇到问题并需要重新对用户进行身份验证。

该功能仅在 Studio 中受支持。 因此，版本控制系统中仅保存每个脚本的 JSON 版本。

非脚本文件

版本控制仅适用于脚本文件。 诸如 ASR 允许联系人通过说话、按手机按键或两者的结合来响应录制的语音提示。 语法文件或预录制音频提示文件等其他文件没有已保存的历史版本。 也无法在第三方版本控制系统（例如 GitHub）中对它们进行跟踪。 要跟踪非脚本文件的版本，您可以使用基于名称的版本管理方法。

在基于名称的版本管理方法中，您可以在文件名中包含版本名称或版本号。 例如，greetingPrompt_v1.wav。 当您对文件进行更改时，您将保存具有更新版本号的新副本。 例如，greetingPrompt_v1.wav 将变为 greetingPrompt_v2.wav。

您无法在 CXone Mpower 中更改这些文件的名称。 但是，您可以将该文件下载到您的计算机，对其重命名，然后上传新版本。 您可以删除不再需要的文件的版本。

组织

设置开发工作流时，您必须在 Studio 中创建一个组织。 该组织定义一组阶段以及与其关联的文件夹。 如果您使用该选项，它还定义一个第三方版本控制系统存储库。

您可以创建其他组织。 组织可映射到公司中的不同团队、业务线或其他划分部分。 如果您的公司符合以下条件，您可能想要创建多个组织：

• 想要为其脚本使用多个存储库。
• 在不同的群组或团队中使用不同的开发工作流阶段。
• 希望将来自不同业务线的脚本彼此分开。

每个组织在 CXone Mpower 系统 中都有自己的文件夹。 每个组织的所有脚本都存储在该文件夹中。 在每个文件夹中，您可以创建子文件夹来保存您使用的每个开发工作流阶段的脚本。 每个工作流阶段的文件夹中都可以包含其他子文件夹。 如果您有多个组织，Studio 中的文件夹结构将类似于以下示例：

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

您可以根据每个组织的需要配置脚本安全性。 视图 允许您控制用户能够在 CXone Mpower 中看到的信息。和 Studio 权限提供对谁可以访问公司脚本并与之交互的精细控制。