Build 缓慢的复杂构建&；哈德逊vs.电云 是Hdson是复杂C++构建的正确工具吗？ 我有一个C++构建，大约需要4个小时。编译和打包大约需要1/2的时间，而测试则消耗另一半的时间。目前，我们正在使用一个自主开发的系统，但由于我们在所有java构建中都使用了它，因此我们需要向hudson迁移

我的问题是，连续集成不是很连续，每4小时一次。我想要一个能够让我以一种可以理解的方式并行化构建的工具

HydSon对于小型构建或Java构建非常棒，我坐在大型Maven项目的顶部，但我认为它不会对复杂的C++构建有很好的扩展性。

---

您的经验是什么？

您不能将构建拆分为多个部分吗

你提到过这项工作有几个不同的部分。Hudson的一般指导是在一项工作中完成构建部分，在另一项工作中进行测试，在另一项工作中进行打包，等等

---

您可以在作业A中编译代码并归档输出，然后让作业B从作业A中删除代码并对其运行测试。同时，由于进一步提交到源存储库，可以启动另一个作业A。

这里似乎有一些问题：

>强>我应该使用CI服务器管理我的C++构建吗？< /强>这个答案是肯定的。你自己开发的系统可能已经足够了，但它不是标准的，扩展它可能很困难，维护它会分散你对工作的注意力

Hudson是我的项目的正确选择吗？它可能会完成工作，而且它的优势是已经在您的站点部署。但是，您特别提到您需要一个能够很好地支持并行化的工具，我认为Hudson并不适合这个要求。问题是哈德逊的设计没有考虑到平行性。看，Hudson中构建过程的表示是一个“作业”，它只是一系列按顺序执行的步骤——签出、编译、测试、打包等等。没有办法让这些步骤并行运行。现在，您可以通过使用多个作业对流程进行建模来解决这个问题。每个作业都是完全独立的，因此它们当然可以并行运行；您可以使用类似的方法来协调作业，但整个过程比它应该的复杂得多，而且有点笨拙--不是单个作业代表构建过程的单个运行，而是多个未连接的作业，最多通过命名约定连接在一起

电子云能帮上忙吗？再一次，明确的回答是肯定的。Electric Cloud提供了ElectricCommander，这是一款从一开始就内置了并行支持的CI服务器。与Hudson一样，作业用于表示构建过程，但是作业中的步骤可以轻松地并行运行（只需选中这些步骤上的“并行”框），因此您不必求助于附加组件和kludges：一个运行构建过程就是一个作业，具有任意多个并行步骤

正确的CI服务器是否会将“连续性”放回我的集成中？CI服务器只会让您走到这一步。问题是，CI服务器可以为您提供粗粒度的并行性——例如，只需做一点工作，您就可以将其设置为与测试并行运行打包。再多做一点工作，您就可以将测试阶段分成几个独立的部分，这些部分可以并行运行。
您没有给出很多细节，但是让我们假设您的构建是90分钟的编译、30分钟的打包和2小时的测试，这些测试可以分解为4个30分钟的部分。进一步假设您可以同时进行打包和测试。这将使您的4小时流程减少到总共2小时。在这一点上，流程中的“长极”是编译阶段，尽管您可以手动将其分解为可由CI服务器并行运行的部分，但事实是CI服务器不是该工作的合适工具。
一个更好的选择是使用一个构建工具，它可以在编译阶段为您提供自动的细粒度并行性。例如，如果您已经在使用gmake，您可以尝试

gmake-j8

一次运行8个编译。如果您的makefile是干净的，依赖项都是正确的，并且您有一个强大的构建服务器，那么这可以给您带来相当好的性能提升。您还可以使用ElectricAccelerator，Electric Cloud的另一款产品，它专门设计用于加速构建过程的这一部分，即使对于由于不正确或不完整的依赖关系而无法安全使用

gmake-j

的构建也是如此

---

希望这能有所帮助。

听起来问题在于构建过程（生成文件？、msbuild？）而不是Hudson。Hudson只是简单地执行构建过程，就像用户从命令行执行构建过程一样。有可能优化您的构建过程吗

---

即使4小时的构建过程不可避免，Hudson也会有所帮助，因为您可以连接无限数量的从机，这些从机都可以并行运行多个构建，只要有足够的硬件马力。

即使是简单的增量构建也需要4小时，还是干净的构建时间？如果是后者，你能做增量构建吗？问题中是否应该有与电子云相关的东西