使用 Azure DevOps Services 设置门控签入策略

封闭式签入是一种限制开发人员将损坏的代码合并到源代码控制系统的过程，这是每家软件公司都希望建立的。在这样做时，组织需要问几个问题：

• 如何制定门禁签到政策？
• 制定此政策时应遵循哪些最佳做法？
• 如果这项政策得以完善，将给组织带来什么好处？
• 可以配置哪些功能？

本指南将澄清这些问题，并阐明如何设置可使用 Azure DevOps Services（以前称为 VSTS）为门控签入流程配置的不同策略。

让我们首先了解分支策略和相关功能。

Azure DevOps 具有一项称为分支策略的功能，用于设置门控签入流程。分支策略可帮助团队保护其重要的开发分支。在团队中强制执行策略以提高代码质量并帮助改善管理代码标准。

简而言之，您可以设置以下策略：

• 配置分支策略
• 要求最低数量的审阅者
• 检查链接的工作项
• 检查评论解决方案
• 构建验证
• 自动包含代码审阅者

现在是时候深入研究每项策略，并利用分支策略功能的强大功能来实现门控签入流程。以下部分将详细解释每项策略，并提供配置分支策略的提示。

要设置分支策略，请导航至Repos > Branches，如下图所示。

一旦您单击“分支”选项，它就会在 Web 门户中启动“分支”页面，如下图所示。

选择…按钮，然后从上下文菜单中选择分支策略。

现在您可以在设置页面上配置各种策略。请参阅本指南的其余部分以了解每种策略类型的描述。

要求最低限度的审阅者数量的政策对大多数软件开发项目都有帮助。代码审查是应遵循的最佳实践，也是确保代码质量改进的推荐方法。

若要要求团队在完成拉取请求之前审查其更改，请选择“需要最少数量的审阅者”选项。建议将最少两名审阅者设置为最佳实践。

在开发人员的代码合并到主分支之前，此政策还有助于所有软件行业。它提供了各种选项来配置政策以及最低数量的审阅者。让我们详细探讨这些选项。

如果选择此选项，拉取请求的创建者可以对其批准进行投票。如果没有，那么他们的投票将不会计入最低审阅者人数。建议拉取请求的创建者不要对自己的请求进行投票。

如果启用此选项，则强制职责分离。这意味着最近的推送会自动使推送者的投票不计算在内。

如果不启用此选项，当部分审阅者投票拒绝时，请求代码的拉取将不会合并到主分支。建议除非必要，否则不要启用此选项。

如果拉取请求的创建者向同一 PR 提交了新的更改，则此选项可让您重置代码审阅者的投票。这样，审阅者便可了解新的更改，并可决定是否批准 PR。

此策略使您能够建立拉取请求和工作项之间的关联，以确保您的分支即将发生的更改具有适当的可追溯性。

您可以将此策略设置为必需或可选，以检查拉取请求中的关联工作项。建议将此选项设置为必需，这意味着除非用户至少有一个关联的工作项，否则将阻止拉取请求完成。

类似地，分支策略使您能够在任何评论处于活动状态时阻止拉取请求的完成。

Azure DevOps 提供两个选项：必需和可选。建议将此选项设置为必需，这样用户将无法完成其 PR，除非所有评论都得到解决。

设置构建验证是门控签入流程的关键部分。此选项可让您更好地控制代码质量，使用各种流程保护代码，例如要求所有单元或集成测试都通过、SonarQube 代码质量门获得批准、构建成功等。

构建策略可减少中断并保证测试结果通过。它可以与开发分支上的持续集成 (CI) 完美集成，以便尽早发现问题。

在设置此策略之前，先要启动并运行构建管道。构建策略需要在源分支更新时触发的管道。此策略在设置期间为您提供以下选项：

**1. 触发选项**

• 自动（推荐）：源分支更新时触发器自动构建
• 手动：用户需要根据需要手动触发构建

2. 政策要求

• 必需（推荐）：必须构建成功才能完成拉取请求
• 可选：构建失败不会阻止拉取请求的完成

**3. 构建到期**

• 立即：主分支更新时
• 持续时间（推荐）：如果主分支已更新，则在 N 小时后
• 永不：构建永不过期

此过滤器可让您在提交新的拉取请求时自动包含代码审阅者。要配置此策略，团队需要确定审阅者的姓名和策略要求，如下图所示。

• 如果选择“必需”，则拉取请求必须等到每个添加为审阅者的用户都批准更改后才能完成。

• 如果您选择“可选”，则拉取请求不需要他们的批准即可完成。

• 您可以设置允许请求者批准他们自己的更改。

• 当所有上述条件都满足时，拉取请求即可完成。

在本指南中，您了解了如何使用分支策略功能在 Azure DevOps 中配置门控签入流程。总的来说，这有助于团队建立更好的流程，提高代码质量，并专注于业务问题。

为了进一步完善本指南，您可以设置其他选项，如路径过滤器、绕过分支策略、状态检查等。Azure DevOps 为您提供了分支权限（安全）功能来实现它们。感谢您的阅读。