清洁或不清洁

Question

我在一个中型项目上工作，该项目使用持续集成来执行常规构建。我们的项目目前有相当长的构建时间（45-55分钟），我们一直在研究可以通过哪些优化来缩短这段时间。

建议的一个优化是消除我们在每次构建开始时所拥有的干净步骤，即删除整个构建目录并从源代码控制中获取所有源文件。相反，只需检索已更改的文件并启动新构建。粗略估计这可以为我们节省10-20分钟每个版本，但这个建议让我有点不舒服。

所以我转向Stack Overflow社区，了解最佳实践是什么......您的持续集成是否总是进行干净的构建？有没有特别的理由和/或反对这个？

我会在下面发表我的想法，试图不要偏见任何人，但我真的很想听听其他一些意见。

Answer 1

对于持续集成，快速周转非常重要。我以前做过这种权衡，我认为这是值得的。偶尔，它会让事情漏掉，但获得反馈的好处是值得的。

除了执行频繁的增量构建之外，还需要不那么频繁的清理构建。这为您提供了两种方法的大部分好处。

Answer 2

持续整合的原因是尽早发现所有问题，而不是快速发现一些问题，以及其他问题 - 嗯，当时。

不清洁可以让问题在很长一段时间内无法检测到。大多数部分构建系统仍然依赖文件时间戳来保证完整性，我需要说的更多。

清洁通常是确保构建良好的唯一方法。一个替代方案可能是定期清理（比如每晚），所以最糟糕的情况是在检测到问题前一天（那是否足够早？）。

您是否预算改进了构建服务器。你能否让你的构建变得更快 - 优化，更多/更快的硬件，并行构建步骤，更快的编译器等。你可以使用更快的构建工具，如scons或类似的，将使用构建服务器中的所有8个CPU （特别是如果你使用make）？

我会干净。

Answer 3

持续集成完全是为了重复性。如果您每次都可以生产出可靠的构造而无需清洁。不删除构建目录的问题是从SCM中删除的文件可能不会从构建目录中删除，因此可能会破坏部署和测试。

我个人建议清理您的构建目录，但不要删除您的源代码。这假设您的SCM可以正确同步您的来源。

---

清洁需要约15分钟？那是相当长的一段时间，我很想知道这么长时间。