我一直在使用TFS中的持续集成（CI）构建。但是，在我上一个项目中，我们开始使用门控签入触发器。
使用门禁办理登机手续有什么不利之处吗？因为如果它阻止团队检查损坏的代码，那么CI触发器的目的是什么？
门控签入是一种持续集成构建的形式。在TFS中，它创建一个包含正在验证的代码的shelveset，然后运行该代码的构建。只有当代码成功构建并且所有已配置的单元测试都通过时，代码才会实际提交。
持续集成是不同的 - 在CI中，无论构建的结果如何，都会提交代码。如果由于提交了错误的代码而导致CI构建失败，则代码仍然存在于源代码管理中，可供所有人使用。
现在对于基于意见的部分：如果你有大量具有不同技能/经验水平的开发人员，那么门控签入很棒，因为它可以防止破解代码进入源代码控制。缺点是它增加了代码被提交和代码可供其他人使用之间的时间，因此可能导致人们坐在他们的拇指周围等待构建成功完成的情况。
我建议使用门控办理登机手续作为权宜之计。如果您有大量的封闭式签入构建失败，那么它正在完成其工作并防止错误的代码被提交。如果随着时间的推移，团队成熟并且门禁签到版本很少失败，那么它的用途就会减少，并且应该切换到持续集成并纠正失败的版本，而不是延迟每次提交的机会，而是出现问题。
门控签到使得更难和更慢。这通常是一件坏事，因为：
那么gated检查的场景是可以的：