TFS门禁办理登机手续的缺点

Question

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

使用门禁办理登机手续有什么不利之处吗？因为如果它阻止团队检查损坏的代码,那么CI触发器的目的是什么？

Answer 1

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

持续集成是不同的 - 在CI中,无论构建的结果如何,都会提交代码.如果由于提交了错误的代码而导致CI构建失败,则代码仍然存在于源代码管理中,可供所有人使用.

现在对于基于意见的部分:如果你有大量具有不同技能/经验水平的开发人员,那么门控签入很棒,因为它可以防止破解代码进入源代码控制.缺点是它增加了代码被提交和代码可供其他人使用之间的时间,因此可能导致人们坐在他们的拇指周围等待构建成功完成的情况.

我建议使用门控办理登机手续作为权宜之计.如果您有大量的封闭式签入构建失败,那么它正在完成其工作并防止错误的代码被提交.如果随着时间的推移,团队成熟并且门禁签到版本很少失败,那么它的用途就会减少,并且应该切换到持续集成并纠正失败的版本,而不是延迟每次提交的机会,而是出现问题.

Answer 2

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

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

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

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

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