Build 何时使用门控签入？

我正在使用TFS2010。目前，我只在主干（主）分支上使用门控签入构建。而且，我在开发和发布分支上使用CI

• 为什么不在所有分支上使用门控签入构建
• 在什么情况下，您不应该在DEV和RELEASE分支上使用门控签入构建
• 总是在每个分支上使用门控签入构建是否更好

---

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

---

持续集成（我认为是以滚动构建的形式优化的）允许开发人员签入其代码，而不必担心代码是否会被接受。重要的是，开发人员总是必须尽快面对签入的负面最终结果。如果你能做到这一点，我更喜欢它，而不是门控签入。
在我们庞大的团队中，我们也在主分支中进行门控，在开发/功能分支（其中许多分支）中进行CI
门控为分支提供了更多的保护，但是如果整个开发团队都在该分支中进行更改，那么门控拥有一个非常大的团队和大量的代码库，它可以备份队列
CI为开发人员提供了更多的保护，他们也知道任何问题都会很快被发现。它更乐观一些，允许团队更快地移动，这对于开发分支来说是合适的
在这两种情况下，开发人员都会运行单元测试并测试他们正在更改的代码。CI（影响团队）和门控（占用队列中的时间）不应该取代测试——应该有一个比我没有尝试过的更复杂的合理解释
整个团队都在功能/开发分支中，在周期的大部分时间使用CI，在游戏结束稳定期间，在更高的分支中有更多的人-后两种情况都支持门控

---

在大型团队中，我们还需要并行完成CI构建和滚动测试，以便在构建时间不平凡且完整测试套件也不平凡的情况下更快地发现问题。在这种情况下，人们正在签入，CI正在接收最后一批签入，运行一个构建，当一个构建丢失时，另一台机器正在接收并运行测试套件
我更喜欢到处都有门控签入，因为它限制了开发人员签入的痛苦，而不是在有人（不可避免地）犯错误时与整个团队分享痛苦

---

如前所述，快速办理登机手续很重要。有时，我会有一个门控签入来运行最重要的检查，然后是一个在门控签入成功后启动的CI构建来运行更耗时的检查。
你能用自己的话解释一下触发构建和进行持续集成之间的区别吗？Kroonwijk；我纠正了我的问题。它应该说是门控签入，而不是触发。谢谢！现在很清楚了。相关：在一个拥有大量代码库的大型团队中，门控只在更高级别的发布类型分支中得到保证。团队负担不起feature/dev分支的费用。由于团队的规模和代码库，它会备份。请看下面我的帖子。我不确定这是否能解决问题。在我的工作中，在新硬件上进行完整构建+所有测试需要24小时。我们有冒烟测试，我们可以在30分钟内运行，但问题是，自然地，更彻底或只是经验上更耗时的测试（例如，您可以使用大量数据成功地从数据库的一个版本迁移到另一个版本的测试）被推到“长”类别。通常，smoke不会捕获任何内容，然后CI将运行“long”类别，并且有十几个测试失败。到那时，审阅者通常已经批准了代码，而且无论如何，团队的其他成员都受到了伤害。如果门控队列正在备份，那么团队似乎会从合并提交中受益。假设大多数更改不会被拒绝，一次验证2个或更多更改可以减少队列等待时间。