持续集成：哪个频率？

我总是在每次提交后启动构建，但是在这个新项目中，架构师只是要求我将频率更改为“每15分钟构建一次”，而我只是不明白为什么这是一个很好的理由，而不是“以每次提交为基础”。

首先，一些细节：

• Objective-C（iOS 5）项目
• 10名开发人员
• 每个构建实际上需要大约1分钟的时间，其中包括构建和单元测试。
• 集成服务器是Mac Mini，因此这里的计算能力并不是真正的问题
  • 我们将Jenkins与XCode插件一起使用

我的观点是，如果您在每次提交时都进行构建，那么您现在就可以查看出了什么问题，并且可以直接更正您的错误，而不会过于困扰其他开发人员。另外，这样我们的测试仪就不会受到UT错误的困扰。他的论点是，开发人员将被“构建错误”邮件淹没（这不是完全正确的，因为可以将Jenkins配置为仅针对第一个损坏的构建发送邮件），并且如果频率频繁，则无法正确完成指标构建数太高。

那么，您对此有何看法？

快速失败是一个很好的原则-您越早知道构建已损坏，就越早可以确定有问题的提交并修复构建。

建立在每次提交上都是正确的事情。

如果项目在这样的时间范围内有大量的提交，则每15分钟进行一次构建可能毫无意义-跟踪错误的提交将花费更长的时间，并且可能难以确定（其中一种情况可能是多个提交具有不同的事物，破坏构建）。还有一种可能是，在安静的时间（夜间），尽管没有进行任何更改，但最终还是要重建。

如果构建经常中断而导致出现问题，请回答该问题，以重新培训团队，以确保构建不中断的重要性以及确保这种情况不会发生的技术（频繁获取，签入跳舞，编译和运行单元测试）本地等）。

如果没有任何变化，那么每15分钟进行一次构建几乎没有意义。但是同样没有缺点，afaik，jenkins只会通过电子邮件发送失败和成功的信息，而不会发送介于两者之间的所有信息（例如10条失败信息）。

我们在每次提交时都这样做。但是，我们每隔15分钟就会对存储库进行一次轮询，并检查是否有更改，也许这就是您的同事所指的。

您希望您的10个开发人员每15分钟提交一次以上？这听起来似乎是一个很高的估计。10开发人员的意思是，每隔150分钟，同一个人再次提交内容，因此需要2.5个小时。因此，在您的平均一天中，每个开发人员都会提交3次。就我个人而言，我一次提交约2天，有时更多，有时更少。

如果仅每15分钟发送一次，就会给开发人员带来更多邮件。这是因为它无法确定是谁破坏了构建版本，从而向更多人发送邮件。

至于指标，如果确实存在问题（由于我不知道他们认为哪个指标存在问题而无法告诉我），则始终可以进行另一项工作来收集指标。

也许要求的标准是“ 每15分钟最多构建一次”。这对于提交活动非常频繁的项目（即几分钟内多次提交）并且构建时间较长的项目可能是有意义的。当然，这还取决于构建的使用方式。对于测试人员来说，在15分钟内获得多个版本可能会有些混乱...

但是我同意，如果一切都没有改变，那毫无意义。

某些开发人员希望被允许以一种方式提交提交，即属于一个功能更改的文件不在单个原子过程中提交。他们需要两到三分钟的时间来执行“逻辑提交”，其中包括一些“物理提交”。当您的开发人员不使用DVCS而直接提交到中央存储库时，通常就是这种情况。

对于这种情况，最好让CI服务器在上一次提交后等待一段时间，然后再开始新的构建。但是15分钟似乎是一个很高的数字，5分钟或更短的时间就足够了。

或者，更好的方法（！），尝试引导您的开发人员每次仅做一小部分，只做一小部分，这使得仅执行“功能完整的”物理提交变得容易得多。然后，每次提交后的构建将无法正常工作。

即使您已设置Jenkins来构建对项目或其任何依赖项的源代码管理，也不会阻止开发人员在不首先提交源代码控制的情况下将其部署到工件存储库。如果他们在工件库中部署了不协调的API更改或错误，那么这可能会破坏您的构建而不会触发Jenkins作业。我个人想尽快了解一下。

理想情况下，您将为每次提交构建计划，并按时间表进行计划，以检查类似我刚才描述的情况。从概念上讲，这意味着您至少每15分钟构建一次。

如果您将Jenkins作业设置为在依赖项工件部署上运行（并且如果执行... Bravo），则如果单元测试是可靠的（这意味着它们不测试依赖项）并且您的设备可以运行，则可以推迟预定的构建集成/功能测试不是Jenkins工作的一部分。

至于“电子邮件泛滥”的问题，我说在破碎的构建中充斥电子邮件是一件好事。确保您强迫开发人员对电子邮件进行描述并回复您，并且您会看到破损的版本下降了，相信我。

您说您不理解他们的推理，所以您必须询问他们。不要仅仅猜测他们想要的东西并尝试实现它，当然也不要仅仅在理解他们为什么要求的情况下实现他们的要求。

也就是说，要回答一般性问题，取决于您使用的开发哲学。如果期望每个提交都能正常工作，则应该测试每个提交。如果您使用DVCS的原理是每次推送都应该起作用，那么请测试每个推送。

总的来说，最好告诉人们他们不知道的事情，然后重复他们所知道的事情。例如，如果他们想减少收到的冗余电子邮件的数量，请调整电子邮件设置，而不要调整构建频率。