hudson是复杂C ++构建的正确工具吗？
我的C ++版本大约需要4个小时。编译和打包大约需要1/2的时间，测试会消耗另一半。目前，我们正在使用一个自行开发的系统，但是因为我们将它用于所有的java版本，所以有一些移动要去哈德森。
我的问题是持续整合不是很频繁......每隔4小时连续一次。我想要一个工具，让我以可理解的方式并行化构建。
Hudson非常适合小型构建或java构建，我坐在大型maven项目的顶端，但我认为它不会很好地适用于复杂的c ++构建。
您的经历是什么？
3 个答案:
答案 0 :(得分：7)
好像你在这里有几个问题：
- 我应该使用CI服务器来管理我的C ++构建吗？答案是肯定的。你自己开发的系统可能已经足够了，但它不是标准的，扩展它可能很困难，而维护它会分散你实际付出的工作。
- Hudson是我项目的正确选择吗？它可能会完成工作，并且它具有已经在您的网站上部署的优势。但是，你特别提到你想要一个支持并行化的工具，我不认为Hudson真的符合要求。问题是Hudson的设计并没有考虑并行性。看，Hudson中构建过程的表示是一个“工作”，它只是按顺序执行的一系列步骤 - checkout，compile，test，package等。没有办法让这些步骤并行运行。现在，您可以通过使用多个作业对流程建模来解决这个问题。每项工作都是完全独立的，所以当然它们可以并行运行;您可以使用类似Locks and Latches plugin之类的东西来协调作业，但整个过程比它应该更复杂，而且有点笨拙 - 而不是代表构建过程的单个作业的单个作业，有几个未连接的工作，最好通过命名约定捆绑在一起。
- 电气云可以帮助吗？再一次，明确的是。 Electric Cloud提供的PowerCommander是一个CI服务器，从一开始就内置了并行支持。与Hudson一样，作业用于表示构建过程，但作业中的步骤可以轻松并行运行（只需检查这些步骤中的“并行”框），因此您不必诉诸添加 - ons和kludges：一个运行构建过程是一个工作，你可以使用尽可能多的并行步骤。
- 正确的CI服务器是否会将“连续”恢复到我的集成中？ CI服务器只会让您到目前为止。问题是，CI服务器可以为您提供粗粒度并行性 - 例如，只需稍加工作，您就可以将其设置为与测试并行运行打包。通过更多的工作，您可以将测试阶段分成几个可以并行运行的独立部分
你没有提供很多细节，但我们假设你的构建是90分钟的编译，30分钟的打包和2小时的测试，可以分解为4个30分钟的部分。进一步假设您可以同时进行包装和测试。这将使您的4小时过程总共减少到2小时。此时，您的流程中的“长极”是编译阶段，虽然您可以手动将其分解为可由CI服务器并行运行的部分，但事实是CI服务器只是不适合那份工作。
一个更好的选择是使用一个构建工具，它可以在编译阶段为您提供自动细粒度并行性。例如，如果您已经使用gmake，则可以尝试gmake -j 8一次运行8次编译。如果您的makefile是干净的并且您的依赖项都是正确的，并且您有一个强大的构建服务器，这可以为您提供相当好的性能提升。您还可以使用ElectricA的另一个产品ElectricAccelerator，它专门用于加速构建过程的这一部分，即使是由于不正确或不完整的依赖而无法安全使用gmake -j的构建。
希望有所帮助。
答案 1 :(得分：0)
你能否将构建分成多个部分？
你确实提到这份工作有几个不同的部分。 Hudson的一般指导是将构建部分放在一个作业中，在另一个作业中进行测试，在另一个作业中进行打包，等等。
您可以编译作业A中的代码并归档输出，然后从作业A告诉作业B copy these artifacts并对它们运行测试。同时，由于对源存储库的进一步提交，可以启动另一个Job A ..
答案 2 :(得分：0)
听起来像我的问题在于您的构建过程（make files？，msbuild？）而不是Hudson。 Hudson只是以与用户从命令行相同的方式执行构建过程。是否可以优化您的构建过程？
即使4小时的构建过程是不可避免的，Hudson也可以提供帮助，因为你可以附加无限数量的从机，这些机器可以并行运行多个构建，并给出足够的硬件功能。