缓慢的复杂构建和Hudson与电子云

Question

哈德森是复杂C++构建的正确工具吗？

我有一个大约4个小时的C++构建.编译和打包大约需要1/2的时间,测试会消耗另一半.目前,我们正在使用一个自行开发的系统,但是因为我们将它用于所有的java版本,所以有一些移动要去哈德森.

我的问题是持续集成不是很频繁......每隔4小时连续一次.我想要一个工具,让我以可理解的方式并行化构建.

Hudson非常适合小型构建或java构建,我坐在一个大型maven项目的顶部,但我认为它不会很好地适用于复杂的c ++构建.

你有什么经历？

Answer 1

好像你在这里有几个问题:

1. 我应该使用CI服务器来管理我的C++构建吗？ 答案是肯定的.你自己开发的系统可能已经足够了,但它并不标准,扩展它可能很困难,而维护它可能会分散你实际付出的工作.
2. 哈德森是我项目的正确选择吗？ 它可能会完成工作,并且它具有已经在您的站点部署的优势.但是,你特别提到你想要一个支持并行化的工具,我不认为Hudson真的符合要求.问题是Hudson的设计并没有考虑并行性.看,Hudson中构建过程的表示是一个"工作",它只是按顺序执行的一系列步骤 - checkout,compile,test,package等.没有办法让这些步骤并行运行.现在,您可以通过使用多个作业对流程建模来解决这个问题.每项工作都是完全独立的,所以当然它们可以并行运行; 你可以使用Locks和Latches插件之类的东西 协调工作,但整个过程比它应该更复杂,而且有点笨拙 - 而不是代表构建过程的单个工作的单个工作,你有几个未连接的工作,最好通过命名捆绑在一起惯例.
3. 电动云可以帮忙吗？ 再次,明确的是.Electric Cloud提供的PowerCommander是一个CI服务器,从一开始就内置了并行支持.与Hudson一样,作业用于表示构建过程,但作业中的步骤可以轻松并行运行(只需检查这些步骤中的"并行"框),因此您不必诉诸添加 - ons和kludges:一个运行构建过程是一个工作,你可以使用尽可能多的并行步骤.
4. 正确的CI服务器是否会"连续"回到我的集成中？ CI服务器只会让你到目前为止.问题是,CI服务器可以为您提供粗粒度并行性 - 例如,只需稍加工作,您就可以将其设置为与测试并行运行打包.通过更多的工作,您可以将测试阶段分成几个可以并行运行的独立部分.
     你没有提供很多细节,但我们假设你的构建是90分钟的编译,30分钟的打包和2小时的测试,可以分解为4个30分钟的部分.进一步假设您可以同时进行包装和测试.这将使您的4小时过程总共减少到2小时.此时,您的流程中的"长极"是编译阶段,虽然您可以手动将其分解为可由CI服务器并行运行的部分,但事实是CI服务器只是不是那份工作的合适工具.
     一个更好的选择是使用一个构建工具,它可以在编译阶段为您提供自动细粒度并行性.例如,如果您已经使用gmake,则可以尝试gmake -j 8一次运行8次编译.如果您的makefile是干净的并且您的依赖项都是正确的,并且您有一个强大的构建服务器,这可以为您提供相当好的性能提升.您还可以使用ElectricAccelerator,它是Electric Cloud的另一个产品,专门用于加速构建过程的这一部分,即使对于gmake -j由于不正确或不完整的依赖而无法安全使用的构建也是如此.

希望有所帮助.