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

c++ continuous-integration hudson jenkins buildbot

36641 观看

5回复

1810 作者的声誉

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

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

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

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

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

编辑:有人问为什么我没有发现哈德森/詹金斯是理想的。简短的回答是一切都可以改进。我只是想知道Jenkins是否是我用例的最佳解决方案,或者是否有更好的东西(buildbot?),从长远来看,即使新的要求出现也会更容易维护。

作者: deuberger 的来源 发布者: 2011 年 4 月 13 日

回应 (5)


41

3355 作者的声誉

决定

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

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

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

希望它会有所帮助。

作者: Christophe Muller 发布者: 06.05.2011 10:14

6

61 作者的声誉

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

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

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

作者: Terry 发布者: 20.07.2011 01:53

6

631 作者的声誉

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

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

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

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

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

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

作者: macetw 发布者: 03.09.2013 05:23

1

2029 作者的声誉

我是评估Buildbot的长期Jenkins用户,并且想为考虑将Buildbot用于多模块解决方案的人们提供一些项目:

*)Buildbot没有artifacts与每个构建相关的任何开箱即用的文件概念。它不在UI中,据我所知,它不在任何内置的“步骤”模块中:

http://docs.buildbot.net/current/manual/configuration/buildsteps.html

......我没有看到第三方插件:

https://github.com/buildbot/buildbot/wiki/PluginList#steps

Buildbot会收集给定构建的所有控制台输出,但是关键的是,您无法收集与其相关的文件

*)鉴于不支持工件,创建“收集器”项目并不容易,因为单个安装程序会带来多个模块。Jenkins有一个很棒的功能,它允许您使用其他模块的构建参数化构建(参数类型为a run)。

*)在Buildbot中建立模块之间的依赖关系比较棘手。 假设您有一个三个二进制文件所依赖的库,并且您希望每次库更改时都重建这些二进制文件。 Jenkins已经triggers内置到UI中。如果你想在Buildbot中做触发器,你必须使用它们编写脚本schedulers.Dependent,这会导致SchedulersUI中的大量项目拥塞。

*)当您在Buildbot中工作时,似乎几乎所有的配置都是master.cfg在代码中完成的。这太棒了,令人沮丧。

*)Buildbot强制您workermaster服务器之外创建一个。对于单个构建服务器足够的初学者和系统来说,这很烦人。

经过两天的Buildbot评估后,我的印象是我们会坚持使用Jenkins,主要是因为它有artifacts。如果我们有更广泛的定制需求和时间,我们只会使用Buildbot。

作者: mpr 发布者: 09.01.2019 08:20

0

1 作者的声誉

关于buildbot和工件的主题 - 我没有足够的用户评分来发表评论 - 你可以通过内置的文件/目录上传动作从buildbot 2.x系列中获得很多文件。但是,您很少想要移动文件。通常,您会创建一个触发的构建步骤,直接从工作程序部署,以获得最佳结果。例如,推送到云存储,容器,第三方(蒸汽上传)等。

通过这种方式,您可以获得上传的指标并更好地有条件地控制它们(甚至可以跨工作机器混合和匹配工件)。

作者: Terry Hendrix II 发布者: 29.03.2019 10:52
32x32