TFS 中门控签入的缺点
Disadvantages of a gated check-in in TFS
我一直使用 TFS 中的持续集成 (CI) 构建。但是，在我的上一个项目中，我们开始使用 gated check-in 触发器。
使用门控签入有什么缺点吗？ 因为如果它阻止团队签入损坏的代码，那么 CI 触发器的目的是什么？ ？
门控签入是持续集成构建的一种形式。在 TFS 中，它创建一个 shelveset 包含正在验证的代码，然后运行该代码的构建。只有当该代码成功构建并且所有配置的单元测试都通过时，代码才会真正提交。
持续集成不同——在 CI 中，无论构建结果如何，代码都会提交。如果 CI 构建由于提交错误代码而失败，代码仍然存在于源代码管理中，可供所有人获取。
现在是基于意见的部分：
如果您有大量不同级别 skill/experience 的开发人员，门控签入非常有用，因为它可以防止损坏的代码进入源代码管理。缺点是它增加了提交代码和其他人可以使用代码之间的时间，因此可能导致人们坐在那里摆弄拇指等待构建成功完成的情况。
我建议使用门控签到作为权宜之计。如果你有大量的门控签入构建失败，那么它正在完成它的工作并防止错误代码被提交。如果，随着时间的推移，团队成熟并且门控签入构建很少失败，那么它的目的就更少了，应该切换到持续集成并在失败的构建出现时纠正它们，而不是延迟每次提交以防出现问题.
门控签入存在根本性缺陷，因为它们验证脏 本地状态 ，而不是 版本化状态 ，因此它们无法替代基于独立检查在干净的平板上（例如在 CI 管道中）。类似地，QA 通常需要使用一系列环境（不同的编译器版本、不同的浏览器、不同的 OS、...），设置成本最好投资于中央 CI。
门控签入也使提交变得更加困难和缓慢。这通常是 不好的 事情，因为：
- 在 TDD 中，成员应该能够推送测试失败的提交
- 在测试失败时报告错误非常有用
- 在 WIP（进行中的工作）分支上合作时，成员应该能够推送脏更改，以便其他人可以快速使用它们
- 进行重大更改时，让其他成员在投入时间完成之前检查未完成的工作会很有用
- 许多人喜欢以 snapshot/backup
的形式定期提交未完成的工作
- 在分支之间频繁切换时，提交未完成的工作非常好（仅隐藏有限的帮助，特别是对于新文件）
- QA 不能有时间限制，但提交应该不会花很长时间
因此门控检查的场景可以作为解决方法或快速而肮脏的缓解措施：
- 您的 VCS 使分支变得困难，或者您的公司不允许分支
- 项目很小
- 只有一位开发者
- 无CI存在
- 只有特定的长寿命分支受到门的保护（但这不能替代 CI）
我一直使用 TFS 中的持续集成 (CI) 构建。但是，在我的上一个项目中，我们开始使用 gated check-in 触发器。
使用门控签入有什么缺点吗？ 因为如果它阻止团队签入损坏的代码，那么 CI 触发器的目的是什么？ ？
门控签入是持续集成构建的一种形式。在 TFS 中，它创建一个 shelveset 包含正在验证的代码，然后运行该代码的构建。只有当该代码成功构建并且所有配置的单元测试都通过时，代码才会真正提交。
持续集成不同——在 CI 中，无论构建结果如何，代码都会提交。如果 CI 构建由于提交错误代码而失败，代码仍然存在于源代码管理中，可供所有人获取。
现在是基于意见的部分： 如果您有大量不同级别 skill/experience 的开发人员，门控签入非常有用，因为它可以防止损坏的代码进入源代码管理。缺点是它增加了提交代码和其他人可以使用代码之间的时间，因此可能导致人们坐在那里摆弄拇指等待构建成功完成的情况。
我建议使用门控签到作为权宜之计。如果你有大量的门控签入构建失败，那么它正在完成它的工作并防止错误代码被提交。如果，随着时间的推移，团队成熟并且门控签入构建很少失败，那么它的目的就更少了，应该切换到持续集成并在失败的构建出现时纠正它们，而不是延迟每次提交以防出现问题.
门控签入存在根本性缺陷，因为它们验证脏 本地状态 ，而不是 版本化状态 ，因此它们无法替代基于独立检查在干净的平板上（例如在 CI 管道中）。类似地，QA 通常需要使用一系列环境（不同的编译器版本、不同的浏览器、不同的 OS、...），设置成本最好投资于中央 CI。
门控签入也使提交变得更加困难和缓慢。这通常是 不好的 事情，因为：
- 在 TDD 中，成员应该能够推送测试失败的提交
- 在测试失败时报告错误非常有用
- 在 WIP（进行中的工作）分支上合作时，成员应该能够推送脏更改，以便其他人可以快速使用它们
- 进行重大更改时，让其他成员在投入时间完成之前检查未完成的工作会很有用
- 许多人喜欢以 snapshot/backup 的形式定期提交未完成的工作
- 在分支之间频繁切换时，提交未完成的工作非常好（仅隐藏有限的帮助，特别是对于新文件）
- QA 不能有时间限制，但提交应该不会花很长时间
因此门控检查的场景可以作为解决方法或快速而肮脏的缓解措施：
- 您的 VCS 使分支变得困难，或者您的公司不允许分支
- 项目很小
- 只有一位开发者
- 无CI存在
- 只有特定的长寿命分支受到门的保护（但这不能替代 CI）