Nothing threatens to slow the velocity of development more than the unexpected. In the case of teams that develop around Git branching strategies, unexpected or otherwise injected bugs can have a way of ruining the day. Using gated check ins, it is possible to catch faults like these before they make it to the release portions of the codebase. This process is meant to ensure code is tested against a known-good version as well as to coordinate the merging of multiple developers’ feature branches.
Gated check ins may also be used to help with additional workflows, such as those that require approval from other stakeholders like change management. Other gates allow for linking to work items to ensure a proper chain of audit is available. When set up properly, gated check ins can prevent a problem with broken builds before they spread to critical release branches.
Here, we will discuss gated check ins in a bit more detail as well as how they can help free up your workload by preventing problems from making it into code used for releases. We will also look at some examples of when to use and when not to use them. Finally, we will run through some of the available options as they apply to Azure DevOps gated check ins.
突发状况最容易影响项目的推进速度。对使用 Git 分支策略的团队来说，意料之外的差错，或无意输入的 bug，都可能让一天的工作前功尽弃。使用封闭签入（Gated Check in，又称门控签入），可以将错误在进入代码库之前拦截，确保代码与当前版本匹配，协调与多个功能分支的合并。
此外，封闭签入也可帮助处理其他工作流，例如需不同岗位审批的变更管理进程。其他封闭签入可链接到工作项，确保更改的代码得到有效检查。如设置正确，封闭签入可以避免错误构建损坏主要发布分支。
在本篇博文中，我们将更详细地讨论封闭签入，以及如何通过有效防止问题代码的发布来减轻工作负载。另外，我们还将了解一些封闭签入适用与不适用的具体用例。最后，我们将介绍一些适用于 Azure DevOps 封闭签入的功能。
什么是封闭签入
Git 和 Git 分支策略主要用于保护企业代码库，并为自动化构建、测试和部署开辟道路。但这种方法的缺点是，无效的代码提交可能会影响产品发布的稳定性。封闭签入，通过添加一个自动控制层扩展 Git 的功能，可有效防止错误代码合并到关键的发布分支中。
拦截错误代码至关重要，因为新的开发通常是当前发布代码的分支，分支代码完成修改后，将并入下一次发布。假设代码在 Git 中的 Release 分支中，更改后的代码将经过编译并发送到各个环境，最后进行生产。理想中的 CI/CD 进程中，开发人员会从 Release 分支拉出新的分支，用于开发新功能。
以上都是开发进程的正常状态。但问题也经常出现，发布代码可能会创建新的故障。由于所有新功能开发都基于同一个不稳定的版本，因此问题很可能已渗入其他开发人员的代码，并进一步传播。而结合封闭签入与拉取请求，团队可以有效将问题代码拒之门外。
何时需要封闭签入？
简单来说，当希望停止系统内自动合并代码时，我们应该使用封闭签入：
- 在合并到关键代码分支之前，确保 CI/CD 构建成功。
- 提供同行评审（Peer Review）的机会，通过拉取请求限定最低数量的审查者。
- 作为链接工作项的工具。
在 Azure DevOps 封闭签入中，保护代码库的一种常见做法，是对成功的构建进行封闭签入。这意味着，只要新签入代码的构建通过，合并就视为安全的。如预期，失败构建显而易见，但仅限于管道中不发布的部分。
对许多开发团队来说，为了确保代码合乎逻辑、产品功能完整，同行评审不可或缺。作为封闭签入过程的一部分，同行评审可以根据团队需要限制审查者的最低人数，并设置其他可调整标志。
在行业中，变更管理链的重要性愈发凸显，特别是针对跨国项目的监管。变更管理的一部分，是需要跟踪或审计变更。在分支合并之前，链接到工作项，是确保数据保留的一种方法。此外，因为涉及到实际代码的更改，封闭签入也保证了敏捷性。
封闭签入在什么时候不适用？
但封闭签入有时也会带来一些麻烦。最典型的就是，当构建的等待时间很长时，封闭签入就不适用了。这是因为封闭签入是以成功的 CI 构建为基础，因此总体作业数量增加了。当很多开发人员共同开发同一分支时，封闭签入往往就难以应付了。
另外，还要考虑构建测试方面。开发人员可以将包含本地测试的工作流设为第一道防线，而不用将所有权放在自动化 CI/CD 进程中。这种方式可降低构建服务器的压力，帮助减少备份。
Azure DevOps 封闭签入实践
Azure DevOps 提供了许多方法来剔除问题代码。其中也包括前面提到的封闭签入。我们将了解如何设置，以及使用 Azure DevOps 封闭签入的一些基本功能选择。
1.我们需要决定保护哪个分支。在 Azure DevOps 中，浏览到 Repos 区域并从左侧菜单中选择分支。
2.打开需要保护的分支上的右键菜单，选择分支策略。
3. 接下来，我们可以配置前面讨论的项目：
a.设定最低数量审查者——一些团队需要至少 2 名以上的开发人员进行同行评审，设定完成后，同行评审将在此数值要求下进行。
b. 检查链接的工作项——这对于显示与代码更改相关工作项的轨迹非常重要。团队可凭此确保每一个变更都具有有效的工作项进行证明。
c. 检查注释解析——在拉取请求时，可以在合并之前对需要解析的请求添加注释。
d. 限制合并类型——用于防止 Git 中某些类型分支的合并。这个功能可帮助保留特定变更历史，但一般默认情况下不常用。
e. 构建验证——用于识别损坏构建，并阻止合并。
f. 状态检查——不太常用的功能，使用状态 API 提供成功/失败等信息，更多相关内容，可点击链接了解。
g. 自动包含审查者——将相关或特定审查者自动添加到同行审查进程。这个功能还可以防止提出拉动请求的开发师自行通过更改。
- 相关阅读: Azure DevOps 构建进程全攻略
结论
使用封闭签入的这些功能，团队能够借助自动化完成许多工作，节省时间并减少工作负担。封闭签入确保了准确无误的代码合并到发布分支，同时，提供更多质量检查的机会。使用封闭签入扩展分支工作流，可有效帮助提升团队开发。
