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