14

我正在使用 TFS 2010。目前我仅在主干 (MAIN) 分支上使用 Gated Check-in 构建。而且，我在 DEV 和 RELEASE 分支上使用 CI。

  • 为什么不在所有分支上使用 Gated Check-in 构建？
  • 在什么情况下，您不应该在 DEV 和 RELEASE 分支上使用 Gated Check-in 构建？
  • 在每个分支上始终使用 Gated Check-in 构建会更好吗？
4

3 回答 3

10

在我们非常庞大的团队中，我们还在主分支中进行了门控，在开发/功能分支（其中很多）中进行了 CI。

Gated 为分支提供了更多保护，但由于团队非常庞大且代码库很大，如果整个开发团队都在该分支中进行更改，它可以备份队列。

CI 为开发人员提供了更多的信任，也知道任何问题都会很快被发现。它有点乐观，允许团队更快地移动，这适合开发分支。

在这两种情况下，开发人员都会运行单元测试并测试他们正在更改的代码。CI（影响团队）和 Gated（在队列中消耗时间）不应该取代测试——应该有一个比我没有尝试过的更复杂的合理解释。

在整个周期的大部分时间里，整个团队都在使用 CI 的特性/开发分支中，并且在最终游戏稳定期间，在更高的分支中，有更多的人——后两种情况都支持门控的情况。

在大型团队中，我们还需要并行完成 CI 构建和滚动测试，以便在构建时间不重要且完整的测试套件也不重要时更快地发现问题。在那种情况下，人们正在签入，CI 正在接受最后一批签入，运行构建，当构建下降时，另一台机器正在启动并运行测试套件。

于 2011-10-01T01:25:17.230 回答
4

我没有真正的理由知道为什么不对您所做的每项更改进行门控签入。但是，（通常）进行门控签入有一个先决条件：您的整体构建时间不应超过几分钟，包括您希望在签入被接受之前执行的任何（单元）测试. 否则，签入需要很长时间才能被接受，或者更糟糕的是，开发人员会被拒绝。对于开发团队来说，它也有点复杂，或者至少要习惯一些东西。

持续集成（在我看来以滚动构建的形式进行了优化）允许开发人员签入其代码，而不必不确定它是否会被接受。重要的是，开发人员必须尽快面对签入的负面最终结果。如果你能做到这一点，我比门控签到更喜欢它。

于 2011-09-30T19:01:10.770 回答
2

我更喜欢 Gated Check-In 无处不在，因为它限制了开发人员签入的痛苦，而不是当有人（不可避免地）犯错时与整个团队分担这种痛苦。

如上所述，保持快速办理登机手续很重要。有时我会有一个运行最重要检查的 Gated Checkin，然后在 Gated Checkin 成功后启动 CI 构建以运行更耗时的检查。

于 2012-03-23T03:01:07.297 回答