TFS中门控签入的缺点

我一直使用TFS中的持续集成（CI）构建。然而，在我的上一个项目中，我们开始使用门控签入触发器

---

使用门控签入是否有任何缺点？因为如果它阻止团队签入损坏的代码，CI触发器的目的是什么？

门控签入是一种持续集成构建的形式。在TFS中，它创建一个包含正在验证的代码的搁置集，然后运行该代码的构建。只有当代码成功构建并且所有配置的单元测试都通过时，代码才会真正提交

持续集成是不同的——在CI中，无论构建结果如何，代码都是提交的。如果CI构建由于提交了错误代码而失败，那么代码仍然存在，在源代码管理中，每个人都可以获取

现在来看基于意见的部分： 如果您有大量不同技能/经验水平的开发人员，那么门控签入是非常好的，因为它可以防止断开的代码进入源代码控制。缺点是，它增加了代码提交和代码可供其他人使用之间的时间，因此可能导致人们坐在那里无所事事，等待构建成功完成

---

我建议使用门控签入作为权宜之计。如果有大量的门控签入构建失败，那么它正在完成它的工作，并防止提交错误代码。如果随着时间的推移，团队逐渐成熟，并且门控签入构建很少失败，那么它的作用就越来越小，应该切换到持续集成，并在构建失败时进行纠正，有问题的时候不是延迟每个提交。

门控签入从根本上说是有缺陷的，因为它们验证脏的本地状态，而不是版本化状态，因此它们无法替换基于干净记录的独立检查（例如在CI管道中）。类似地，QA通常需要使用一系列环境（不同的编译器版本、不同的浏览器、不同的操作系统等），设置成本最好投资在一个中央CI上

封闭签入也会使提交变得更加困难和缓慢。这通常是一件不好的事情，因为：

• 在TDD中，成员应该能够在测试失败的情况下推送提交
• 将bug报告为测试失败非常有用
• 在WIP（在制品）分支上进行合作时，成员应该能够推动脏的更改，以使其他人能够快速使用这些更改
• 在进行重大更改时，让其他成员在投入时间完成之前回顾未完成的工作可能会很有用
• 许多人喜欢以快照/备份的形式定期提交不完整的工作
• 在分支之间频繁切换时，提交未完成的工作非常重要（仅存储有限的帮助，尤其是新文件）
• QA不能有时间限制，但提交不应花费很长时间

因此，选通的场景可以作为解决方案或快速而肮脏的缓解措施：

• 您的风投使分支变得困难，或者您的公司不允许分支
• 这个项目很小
• 只有一个开发者
• 不存在CI
• 只有特定的长寿命分支受门保护（但这不是CI的替代方案）

---

另一个考虑因素。如果构建基础设施不可用，门控签入将阻止开发人员发布其代码；因此，我建议制定一个计划B（可以是几个脚本，将构建类型从门控更改为CI，然后再更改），如果您使用Git，您可以使用构建策略来实现类似的门控签入工作流：澄清，人们不必等待GC完成（“摆弄拇指等待”）。他们可以选择不在本地保留更改，继续执行下一个任务。当然，如果他们依赖于该部分，他们可以保留本地更改并继续，在GC完成后，他们可以获取最新的更改并协调服务器/本地更改。我们是这样做的，它让人们不再等待，并使GC成为一个权宜之计。@SnapJag虽然是真的，但我发现在实践中，搁置/取消搁置工作流程相当繁琐，会导致拇指旋转。如果构建要运行5分钟，并且有被拒绝的风险，我将不愿意切换上下文并开始其他工作。因此，您已经定义了自己的场景和工作流程。其他人可能会发现我的信息有助于了解不利因素并不是规则。我们的工作流程非常好，我们不需要等待构建完成。我们的构建和单元测试超过5分钟。我们还在签入之前执行构建和测试，以保持GC的高效性和可预测性。祝你的工作流程好运。有很多方法可以解决这些问题。没有在所有分支上强制执行“门”可以缓解许多这些缺点。请随意添加一个答案，解释一个有用的分支策略，让任何感兴趣的人发挥他们的想象力或自己搜索。把我的评论看作是一个提示。这里提到的许多缺点可以通过搁置（主要是代码审查和上下文切换）来缓解，只需考虑一点：永远不要低估新开发人员弄乱存储库的能力。无论构建等待时间如何，门控签入对于大规模开发来说都是非常宝贵的。