LUIS 的 DevOps 实践

  • 项目

重要

LUIS 将于 2025 年 10 月 1 日停用，从 2023 年 4 月 1 日开始，你将无法创建新的 LUIS 资源。 建议将 LUIS 应用程序迁移到对话语言理解，以便从持续的产品支持和多语言功能中受益。

正在开发语言理解 (LUIS) 应用的软件工程师可以通过遵循这些指南，对源代码管理、自动生成、测试和发布管理应用 DevOps 实践。

LUIS 的源代码管理和分支策略

DevOps 成功的关键因素之一是源代码管理。 源代码管理系统允许开发人员围绕代码开展协作并跟踪更改。 使用分支可允许开发人员在不同版本的代码库之间进行切换，并允许独立于团队的其他成员开展工作。 开发人员提出拉取请求提议从一个分支更新到另一个分支时，或合并更改时，可能会触发自动生成进程生成并连续测试代码。

通过使用本文档所述的概念和指南，你可以在跟踪源代码管理系统中的更改的同时开发 LUIS 应用程序，然后按照以下软件工程最佳做法进行操作：

  • 源代码管理

    • LUIS 应用的源代码采用人类易于阅读的格式。
    • 可以反复从源生成模型。
    • 可以通过源代码存储库管理源代码。
    • 凭据和机密（例如密钥）永远不会存储在源代码中。

  • 分支和合并

    • 开发人员可以使用独立分支。
    • 开发人员可以同时使用多个分支。
    • 可以通过变基或合并将 LUIS 应用的更改从一个分支集成到另一个分支。
    • 开发人员可以将 PR 合并到父分支。

  • 版本控制

    • 应对大型应用程序中的每个组件单独进行版本控制，使开发人员可以通过直接查看版本号来检测重大更改或更新。

  • 代码评审

    • PR 中的更改显示为易于阅读的源代码，可以在接受 PR 之前查看该代码。

源代码管理

若要在源代码管理系统中维护 LUIS 应用的应用架构定义，请使用应用的 LUDown 格式 (.lu) 表示形式。 .lu 格式优于 .json 格式，因为前者易于阅读，这使开发人员可以更轻松地在 PR 中进行更改和查看更改。

将 LUIS 应用另存为 LUDown 格式

若要将 LUIS 应用另存为 .lu 格式，并将其置于源代码管理下方：

  • 任一方法：从 LUIS 门户将应用版本导出为 .lu，然后将其添加到源代码管理存储库

  • 或：使用文本编辑器为 LUIS 应用创建 .lu 文件，然后将其添加到源代码管理存储库

提示

如果 LUIS 应用是以 JSON 格式导出，则可以将其转换为 LUDown。 使用 --sort 选项可确保意向和言语按字母顺序排序。
请注意，LUIS 门户中内置的 .LU 导出功能已对输出进行了排序。

从源生成 LUIS 应用

对于 LUIS 应用，从源生成意味着通过导入 .lu 源新建 LUIS 应用版本、训练版本以及发布版本。 可以在 LUIS 门户中或在命令行中执行此操作：

在源代码管理下维护的文件

LUIS 应用程序的以下类型的文件应在源代码管理下进行维护：

未签入凭据和密钥

请勿在签入到存储库的文件中包含密钥或类似的机密值，否则未经授权的人员可能会看到这些信息。 应阻止签入的密钥和其他值包括：

  • LUIS 创作和预测密钥
  • LUIS 创作和预测终结点
  • Azure 资源密钥
  • 访问令牌，例如自动化身份验证中所使用的 Azure 服务主体的令牌

安全管理机密的策略

安全管理机密的策略包括：

  • 如果使用的是 Git 版本控制，则可以将运行时机密存储到本地文件，然后通过添加将文件名与 .gitignore 文件匹配的模式来阻止签入文件
  • 在自动化工作流中，可以将机密安全地存储在该自动化技术提供的参数配置中。 例如，如果使用的是 GitHub Actions，则可以将机密安全地存储在 GitHub 机密中。

分支和合并

Git 等分布式版本控制系统使团队成员可以灵活地通过与他人共享的开发分支来发布、共享、查看和迭代代码更改。 采用适用于团队的 Git 分支策略。

无论采用哪种分支策略，所有策略的主要原则如下：团队成员可以独立于功能分支以外的其他分支中的工作，来使用该功能分支中的解决方案。

若要支持独立地使用 LUIS 项目中的分支，请执行以下操作：

  • 主分支有自己的 LUIS 应用。 该应用表示项目解决方案的当前状态，并且其当前活动版本应始终映射到主分支中的 .lu 源。 应检查和测试此应用中对 .lu 源的所有更新，以便随时部署该应用以生成环境（例如生成环境）。 .lu 的更新从功能分支合并到主分支时，你应在 LUIS 应用中创建新版本，然后增大版本号。

  • 每个功能分支都必须使用自己的 LUIS 应用实例。 开发人员可以在功能分支中使用该应用，不会影响使用其他分支的开发人员。 该“开发分支”应用是工作副本，应在删除功能分支时将其删除。

Git feature branch

开发人员可以使用独立分支

开发人员可以通过以下方式独立于其他分支在 LUIS 应用中进行更新：

  1. 从主分支创建功能分支（取决于分支策略，通常是主分支或开发分支）。

  2. 仅在 LUIS 门户中新建 LUIS 应用（“开发分支应用”）以支持使用功能分支。

    • 如果分支中已存在解决方案的 .lu 源，则由于该源是在项目早期使用另一个分支后保存的，因此请通过导入 .lu 文件来创建开发分支 LUIS 应用。

    • 如果你是开始处理新项目，则存储库中尚没有主 LUIS 应用的 .lu 源。 你完成功能分支中的工作后将通过从门户中导出开发分支应用来创建 .lu 文件，然后将其作为 PR 的一部分提交。

  3. 使用开发分支应用的活动版本以实现所需的更改。 对于所有功能分支工作，建议只使用开发分支应用的一个版本。 如果在开发分支应用中创建多个版本，请谨慎跟踪哪个版本包含要在提出 PR 时签入的更改。

  4. 测试更新 - 有关测试开发分支应用的详细信息，请参阅 LUIS DevOps 测试。

  5. 从版本列表中将开发分支应用的活动版本导出为 .lu。

  6. 签入你的更新并邀请对你的更新进行同级评审。 如果使用的是 GitHub，你将提出拉取请求。

  7. 更改获批后，将更新合并到主分支。 此时，你将使用主分支中更新的 .lu 创建新版本的主 LUIS 应用。 有关设置版本名称的注意事项，请参阅版本控制。

  8. 删除功能分支后，最好删除为功能分支工作创建的开发分支 LUIS 应用。

开发人员可以同时使用多个分支

如果遵循开发人员可以使用独立分支中的模式，则你将在每个功能分支中使用唯一的 LUIS 应用程序。 一个开发人员可以同时使用多个分支，只要能够为当前正在使用的分支切换到正确的开发分支 LUIS 应用即可。

建议对功能分支和为功能分支工作创建的开发分支 LUIS 应用使用同一名称，降低意外使用错误应用的可能性。

如上所述，为简单起见，建议在每个开发分支应用中使用一个版本。 如果使用的是多个版本，请在切换开发分支应用时注意使用正确的版本。

多个开发人员可以同时使用同一分支

你可以支持多个开发人员同时使用同一功能分支：

  • 开发人员可以签出同一功能分支，并推送和拉取自己和其他开发人员提交的更改，同时工作将如常进行。

  • 如果遵循开发人员可以使用独立分支中的模式，则该分支将使用唯一的 LUIS 应用程序支持开发。 该“开发分支”LUIS 应用将由开始使用功能分支的开发团队中的第一个成员创建。

  • 将团队成员以参与者身份添加到开发分支 LUIS 应用。

  • 功能分支工作完成后，从版本列表中将开发分支 LUIS 应用的活动版本导出为 .lu，将更新的 .lu 文件保存到存储库，然后签入并 PR 更改。

通过变基或合并，将更改从一个分支合并到另一个分支

你团队中使用其他分支的其他一些开发人员可能已对 .lu 源进行了更新，并在你创建功能分支后将更新合并到了主分支。 你可能想要将他们的更改合并到你的工作版本中，然后继续在自己的功能分支内进行自己的更改。 你可以按照其他任何代码资产中的方式，通过变基或合并到主分支来实现这一目标。 由于 LUDown 格式的 LUIS 应用易于阅读，因此它支持使用标准合并工具进行合并。

如果要在功能分支中对 LUIS 应用进行变基，请遵循以下提示：

  • 在变基或合并之前，请先从门户重新导出应用，确保应用的 .lu 源的本地副本具有你通过 LUIS 门户应用的所有最新更改。 这样可以确保在门户中进行的但尚未导出的所有更改都不会丢失。

  • 在合并过程中，使用标准工具解决任何合并冲突。

  • 完成变基或合并后，请勿忘记将应用重新导回门户，以便在继续应用自己的更改时使用更新的应用。

合并 PR

PR 获批后，可以将更改合并到主分支。 LUIS 应用的 LUDown 源没有特殊的注意事项：它易于阅读，因此它支持使用标准合并工具进行合并。 可以以其他源文件中的方式解决任何合并冲突。

合并 PR 后，建议将其清除：

  • 删除存储库中的分支

  • 删除为功能分支工作创建的“开发分支”LUIS 应用。

你应该以应用程序代码资产中的方式编写单元测试，为 LUIS 应用更新做补充。 你应采用持续集成工作流进行测试：

  • PR 合并前 PR 中的更新
  • PR 获批后且更改合并到主分支后的主分支 LUIS 应用。

有关 LUIS DevOps 测试的详细信息，请参阅 LUIS 的 DevOps 测试。 有关实现工作流的更多详细信息，请参阅 LUIS DevOps 的自动化工作流。

代码评审

LUDown 格式的 LUIS 应用易于阅读，它支持在适用于审查的 PR 中关于更改进行通信。 单元测试文件也是 LUDown 格式，也易于在 PR 中审查。

版本控制

应用程序由多个组件组成，其中可能包括 Azure AI 语音服务等。 若要实现松散耦合的应用程序，请使用版本控制以便独立地对应用程序的每个组件进行版本控制，使开发人员可以通过直接查看版本号来检测重大更改或更新。 如果在 LUIS 应用自己的存储库中对其进行维护，则可以独立于其他组件轻松地对其进行版本控制。

主分支的 LUIS 应用应该应用版本控制方案。 将 LUIS 应用的 .lu 的更新合并到主分支后，然后将更新后的该源导入到主分支的 LUIS 应用中的新版本。

建议对主 LUIS 应用版本使用数字版本控制方案，例如：

major.minor[.build[.revision]]

每次更新后，版本号的最后一位递增。

主要/次要版本可用于指示 LUIS 应用功能的更改范围：

  • 主版本：重大更改，例如支持新意向或实体
  • 次版本：后向兼容的次要更改，例如在重要的新培训之后
  • 内部版本：不会更改任何功能，只是另一个内部版本。

确定最新版的主 LUIS 应用的版本号后，你需要生成和测试新的应用版本，然后将其发布到可用于各种内部版本环境（例如质量保证或生产）的终结点。 强烈建议自动执行持续集成 (CI) 工作流中的所有这些步骤。

请参阅：

对“功能分支”LUIS 应用进行版本控制

使用为支持功能分支中的工作而创建的“开发分支”LUIS 应用时，你将在完成工作后导出你的应用，然后在 PR 中加入更新后的 'lu。 PR 合并到主分支后，应删除存储库中的分支和“开发分支”LUIS 应用。 由于该应用仅用于支持功能分支中的工作，因此无需在该应用中应用特定的版本控制方案。

PR 中的更改合并到主分支时，应该应用版本控制，以便独立地对主分支的所有更新进行版本控制。

后续步骤