我从事一个中型项目，该项目使用持续集成来执行常规构建。我们的项目目前有相当长的构建时间（45-55 分钟），我们一直在研究可以进行哪些优化来减少这个时间。
建议的优化之一是消除我们在每次构建开始时的清理步骤，即删除整个构建目录并从源代码控制中获取所有源文件。相反，只需检索已更改的文件并开始新的构建。粗略估计，每次构建可以为我们节省 10-20 分钟，但这个建议让我有点不舒服。
所以我求助于 Stack Overflow 社区，看看最佳实践是什么……您的持续集成是否总是能进行干净的构建？是否有特别的理由支持和/或反对这一点？
我将在下面发表我的想法，以免对任何人产生偏见，但我真的很想听听其他意见。
【问题讨论】：
标签： continuous-integration build-process
对于持续集成，快速周转非常重要。我以前做过这种权衡，我会说这是值得的。有时，它会让事情顺利通过，但尽早获得反馈的好处是值得的。
除了执行频繁的增量构建之外，还要减少清洁构建的频率。这为您提供了两种方法的大部分好处。
【讨论】：
持续集成的原因是及早发现所有问题，而不是快速发现一些问题和其他问题 - 嗯，任何时候都可以。
不清理会导致问题在很长一段时间内未被发现。大多数部分构建系统仍然依赖文件时间戳来保证完整性，需要我多说。
清洁通常是确定构建良好的唯一方法。另一种方法可能是定期清洁（比如每晚），因此最坏的情况是在检测到问题前一天（是否足够早？）。
您对改进构建服务器的预算是多少。你能让你的构建更快吗 - 优化、更多/更快的硬件、并行构建步骤、更快的编译器等。你能使用更快的构建工具，例如 scons 或类似的工具，它将利用构建服务器中的所有 8 个 CPU （特别是如果你使用 make）？
我会清洁。
【讨论】：
持续集成就是关于可重复性。如果您每次都可以在不清洁的情况下生成可靠的构建，请执行此操作。不删除构建目录的问题是，从 SCM 中删除的文件可能不会从构建目录中删除，因此可能会导致部署和测试混乱。
我个人建议清理你的构建目录，但不要删除你的源代码。这假设您的 SCM 可以正确同步您的源。
清洁需要大约 15 分钟？那是相当长的时间，我很想知道什么需要这么长时间。
【讨论】：