TFS 中门控签到的缺点 [英] Disadvantages of a gated check-in in TFS

问题描述

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

I've always worked with the Continuous Integration (CI) build in TFS. However, in my last project we started to use the gated check-in trigger.

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

Are there any disadvantages when using a gated check-in? Because if it prevents the team from checking in broken code, what's the purpose of a CI trigger?

推荐答案

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

Gated checkin is a form of continuous integration build. In TFS, it creates a shelveset containing the code that's being validated, then runs a build of that code. Only if that code builds successfully and all configured unit tests pass does the code actually get committed.

持续集成不同——在 CI 中，无论构建结果如何，都会提交代码.如果由于提交了错误代码而导致 CI​​ 构建失败，代码仍然存在，在源代码管理中，可供所有人获取.

Continuous integration is different -- in CI, the code is committed regardless of what happens as a result of the build. If a CI build fails due to bad code being committed, the code is still there, in source control, available for everyone to grab.

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

Now for the opinion-based part: Gated checkin is great if you have a large number of developers of varying levels of skill/experience, since it prevents broken code from going into source control. The downside is that it increases the time between code being committed and code being available for others, and thus can lead to situations where people are sitting around twiddling their thumbs waiting for the build to complete successfully.

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

I recommend using gated check-in as a stopgap. If you have a ton of gated check-in build failing, then it's doing its job and preventing bad code from getting committed. If, over time, the team matures and gated check-in builds fail infrequently, then it's serving less purpose and should be switched over to continuous integration and correcting failing builds as they come, instead of delaying every commit in the off chance there's a problem.

这篇关于TFS 中门控签到的缺点的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！