TFS 门禁登记的缺点

Question

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

使用门禁值机有什么缺点吗？ 因为如果它阻止团队检查损坏的代码，那么 CI 触发器的目的是什么？

Answer 1

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

持续集成是不同的——在 CI 中，无论构建结果如何，代码都会被提交。 如果 CI 构建因提交错误代码而失败，代码仍然存在，在源代码控制中，可供所有人获取。

现在是基于意见的部分：如果您拥有大量不同技能/经验水平的开发人员，门控签入非常有用，因为它可以防止损坏的代码进入源代码控制。 不利的一面是，它增加了代码提交和代码可供其他人使用之间的时间，因此可能导致人们坐在一起摆弄他们的拇指等待构建成功完成的情况。

我建议使用门禁登记作为权宜之计。 如果您有大量的门控签入构建失败，那么它正在发挥作用并防止提交错误代码。 如果随着时间的推移，团队逐渐成熟并且门控签入构建很少失败，那么它的用途就更少了，应该切换到持续集成并在失败时纠正它们，而不是在出现问题时推迟每次提交.

Answer 2

门控签入从根本上是有缺陷的，因为它们验证脏的本地状态，而不是版本化状态，因此它们不能替代基于干净的板岩（例如在 CI 管道中）的独立检查。 同样，QA 通常需要使用环境矩阵（不同的编译器版本、不同的浏览器、不同的操作系统等）来完成，设置成本最好投资于中央 CI。

门控签入也使提交变得更加困难和缓慢。 这通常是一件坏事，因为：

• 在 TDD 中，成员应该能够在测试失败时推送提交
• 将错误报告为失败的测试非常有用
• 在 WIP（进行中）分支上进行合作时，成员应该能够推送脏的更改以使其快速提供给其他人
• 在进行重大更改时，让其他成员在花时间完成之前先查看未完成的工作会很有用
• 许多人喜欢定期提交不完整的工作作为快照/备份的形式
• 在分支之间频繁切换时提交未完成的工作是很好的（仅存储有限的帮助，特别是对于新文件）
• QA 不能有时间限制，但提交时间不应太长

因此，门控检查的场景可以作为解决方法或快速和肮脏的缓解：

• 您的 VCS 使分支变得困难，或者您的公司不允许分支
• 项目很小
• 只有一位开发者
• 不存在 CI
• 只有特定的长期分支受到门的保护（但这不是 CI 的替代品）