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