用于C++持续集成的buildbot vs hudson/jenkins

Question

我目前正在使用jenkins/hudson进行持续集成,主要是一个C++项目.我们为主干和每个分支都有单独的项目.此外,还有一些Java代码的相关项目,但是这些项目的设置现在相当基础(我们可能会在稍后做更多).C++项目执行以下操作:

• 使用选项构建所有内容,以便重新配置,执行干净的构建或使用新的签出
• 可选择构建并运行所有测试
• 可选择使用Valgrind的memcheck运行所有测试
• 运行cppcheck
• 生成doxygen文档
• 发布报告:单元测试,valgrind,cppcheck,编译器警告,SLOC,打开任务和代码覆盖(使用gcov,gcovr和cobertura插件)
• 每晚或按需部署代码到测试环境和包存储库

一切都可以配置为自动构建,可选配置为按需构建.在下面,有一个bash脚本控制其中的大部分内容,这更依赖于我们的构建系统,它使用automake和autoconf以及自定义bash脚本.

我们开始使用Hudson(当时)因为这是Java人员正在使用的东西,我们只想要夜间构建.从那时起,我们增加了很多,并继续增加更多.在某些方面哈德森很棒,但肯定不理想.

我已经看过其他解决方案了,唯一看起来像是替代品的是buildbot.buildbot会更好地适应这种情况吗？自从我们已经在使用Hudson以来,投资是否值得？为什么？

编辑:有人问为什么我没有发现哈德森/詹金斯是理想的.简短的回答是一切都可以改进.我只是想知道,如果詹金斯是我的使用情况或是否有更好的东西(buildbot？),这将是更容易保持在即使有新的要求上来从长远看目前最好的解决方案.

Answer 1

两者都是开源项目,但您不需要更改buildbot代码来"扩展"它,实际上很容易在其配置中导入您自己的包,您可以使用自己的添加对大多数功能进行子类化.示例:您自己的编译或测试代码,一些解析输出/错误将给予后续步骤,您自己格式化警报电子邮件等等,有很多可能性.

通常我会说buildbot是最"通用"的自动构建工具.然而,Jenkins可能与运行测试最相关,尤其是以很好的方式解析和呈现结果(结果,细节,图表......点击一下),buildbot不会做"开箱即用"的事情.我实际上正在考虑使用两者来获得更性感的测试结果页面.. :-)

另外,作为经验法则,创建一个新工具的配置并不困难:如果要做什么(配置,构建,测试)的规范太难以从一个工具切换到另一个工具,那么它是一个(坏)标志没有足够的配置脚本移动到源.Buildbot(或Jenkins)应该只调用简单的命令.如果运行测试很简单,那么开发人员也会这样做,这会提高成功率,而如果只有持续集成系统运行测试,那么你将在它之后运行以修复新的代码失败,并且会松动它的非回归值,只是我的0.02欧元:-)

希望它会有所帮助.

Answer 2

"结果集成"也在jenkins/hudson中,您可以相对轻松地捕获构建产品,而无需"将它们复制到别处".

对于我们的实例,覆盖报告和单元测试指标以及java代码的javadoc都是集成的.对于我们的C++代码,插件有点缺乏,但你仍然可以获得大部分.

我们从0.7之前开始运行buildbot,现在运行0.8并且现在只看到任何真正的切换原因,因为buildbot 0.8在很长一段时间内忘记了windows奴隶并且支持非常差.

Answer 3

除了Jenkins/Hudson/BuildBot之外,还有许多其他解决方案:

• Jetbrains的TeamCity
• Atlassian的竹子
• 通过Thoughtworks去
• 巡航控制
• OpenMake Meister

事实上,只要您正在执行它们的代理(也称为节点)支持这些任务,您所做的事情的具体细节就不那么重要了.

当构建发生更改以触发新构建(和测试),发布工件以及发布测试结果时,CI服务器的优点在于注意到.

当您比较我们提到的CI工具时,请考虑其界面的可用性,分支(以及它可能提供的功能,如自动合并),通知(如XMPP/jabber)或信息辐射(如挂钩)等功能监视器始终显示状态).产品支持是另一个需要考虑的事项 - 詹金斯的支持与您在提出问题时回答社区问题一样好.

我个人最喜欢的是Bamboo,但需要许可费.