我正在使用TFS 2010.目前我只在主干（MAIN）分支上使用Gated Check-in构建。而且，我在DEV和RELEASE分支上使用CI。
答案 0 :(得分：10)
在我们非常庞大的团队中，我们也在主分支和开发/功能分支（其中许多）中进行了门控。
Gated为分支机构提供了更多保护，但是如果整个开发团队在该分支中进行了更改，则可以使用庞大的团队和庞大的代码库来备份队列。
CI提供保护，对开发人员更加信任，也知道任何问题都会很快被发现。它更加乐观，并允许团队更快地移动，这适合开发分支。
在这两种情况下，开发人员都会运行单元测试并测试他们正在更改的代码。 CI（影响团队）和Gated（消耗队列中的时间）不应该取代测试 - 应该有一个比我没有尝试过的更复杂的合理解释。
整个团队在功能/开发分支中使用CI进行大部分周期，在更高的分支中，在结束游戏稳定期间有更多的人 - 后两种条件都支持门控的情况。
在一个大型团队中，我们还需要并行完成CI构建和滚动测试，以便在构建时间不是微不足道时更快地发现问题，并且完整的测试套件也不是一件容易的事。在这种情况下，人们正在检查，CI正在接收最后一批签入，运行构建，当构建丢失时，另一台机器正在启动并运行测试套件。
答案 1 :(得分：4)
我没有理由知道为什么不对您所做的每项更改进行门禁签到。然而，（通常）进行门控登记的先决条件是：您的总体构建时间不应超过几分钟，包括您希望在办理登机手续之前执行的任何（单位）测试。否则，需要花费很多时间才能接受办理登机手续，或者让开发人员更糟糕的是被拒绝。对于开发团队来说，它也有点复杂，或者至少需要习惯。
持续集成（在我看来，以滚动版本的形式进行优化）允许开发人员签入其代码而不会有不确定性，如果它将被接受。重要的是，开发人员必须尽快与办理登机手续的负面结果面对面。如果你能做到这一点，我比门禁签到更喜欢它。
答案 2 :(得分：2)
我更喜欢Gated Check-In无处不在，因为它限制了开发人员办理登机手续时的痛苦，而不是在某人（不可避免地）犯错时与整个团队分享这种痛苦。
如上所述，快速保持Gated Check-Ins非常重要。我有时会有一个运行最重要检查的门控Checkin，然后是在门控检查成功运行更耗时的检查后启动的CI构建。