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

我目前正在使用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？），即使出现了新的需求，从长远来看，它也更容易维护。

两者都是开源项目，但是您无需更改buildbot代码来“扩展”它，实际上很容易在其配置中导入您自己的软件包，在其中您可以使用自己的附加功能对大多数功能进行分类。例如：您自己的编译或测试代码，将要进行下一步的输出/错误分析，您自己的警报电子邮件格式等。存在很多可能性。

通常，我会说buildbot是最“通用”的自动构建工具。然而，Jenkins可能与运行测试最相关，尤其是对于以很好的方式（结果，详细信息，图表……只需单击一下即可）解析和呈现结果的情况下，buildbot不会“开箱即用”。我实际上是想同时使用这两种方法来使测试结果页更性感.. :-)

根据经验，创建新工具的配置也不难：如果要执行的操作（配置，构建，测试）的规范很难从一种工具切换到另一种工具，则这是一个（不好的）迹象没有足够的配置脚本移动到源。Buildbot（或Jenkins）应仅调用简单命令。如果运行测试很简单，那么开发人员也将这样做，这将提高成功率，而如果仅持续集成系统运行测试，则您将在运行它之后修复新的代码失败，并且将会松动。它的非回归值，只有我的0.02€:-)

希望能对您有所帮助。

jenkins / hudson中也有“结果集成”，您可以相对轻松地捕获构建产品，而不必“将它们复制到其他地方”。

对于我们的实例，Java代码的覆盖率报告和单元测试指标以及javadoc都已集成。对于我们的C ++代码，虽然缺少一些插件，但是您仍然可以获取大部分插件。

我们从0.7之前的版本开始运行buildbot，现在正在运行0.8，并且直到现在才发现有任何真正的理由进行切换，因为buildbot 0.8长时间以来都忘记了Windows从站，并且支持非常差。

除了Jenkins / Hudson / BuildBot，还有许多其他解决方案：

• Jetbrains的TeamCity
• 竹由Atlassian
• 进入Thoughtworks
• 巡航控制
• OpenMake Meister

实际上，只要您在代理上执行的代理（即节点）支持这些任务，那么有关所执行操作的细节并不那么重要。

配置版本发生更改以触发新的版本（和测试），发布工件以及发布测试结果时，CI服务器的魅力就在于注意到了。

在比较我们提到的CI工具时，请考虑其接口的可用性等功能，分支的容易程度（以及它可能提供的功能，如自动合并），通知（如XMPP / jabber）或信息辐射器（如挂钩）显示器以始终显示状态）。产品支持是要考虑的另一件事-Jenkins的支持仅与在您有问题时谁在回答社区问题一样好。

我个人最喜欢的是Bamboo，但它附带许可证费用。

我是Jenkins的长期用户，正在评估Buildbot，并想为考虑将Buildbot用于多模块解决方案的人们提供一些建议：

*）Buildbot没有artifacts与每个构建相关的任何现成的文件概念。据我所知，它不在UI中，也不在任何内置的“步骤”模块中：

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

...而且我看不到任何第三方插件：

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

Buildbot确实会收集给定构建中的所有控制台输出，但重要的是，您不能收集与此相关的文件。

*）鉴于不支持工件，因此创建将多个模块整合到一个安装程序中的“收集器”项目并不容易。Jenkins具有一项强大的功能，可让您使用其他模块的构建参数化构建（参数类型为run）。

*）在Buildbot中建立模块之间的依赖关系比较棘手。 假设您有一个依赖于三个二进制文件的库，并且希望每次库更改时都重新构建这些二进制文件。 Jenkins已triggers内置到UI中。如果要在Buildbot中执行触发器，则必须使用编写脚本脚本schedulers.Dependent，这会在SchedulersUI中引起很多项目拥塞。

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

*）Buildbot强制您创建worker除master服务器之外的服务器。对于单个构建服务器就足够的初学者和系统而言，这很烦人。

经过Buildbot评估两天后，我的印象是我们将继续使用Jenkins，主要是因为它具有artifacts。Buildbot是一种工具，只有在我们有更广泛的自定义需求以及执行时间时，才使用它。

关于buildbot和工件的问题-我没有足够的用户评分，不能发表评论-您可以通过内置的文件/目录上传操作轻松地从buildbot 2.x系列中获取工件。但是，您很少只想移动文件。通常，您执行触发的构建步骤，该步骤直接在工作人员之外进行部署以获得最佳结果。例如，推送到云存储，容器，第三方（蒸汽上传）等。

这样，您可以获取上载的指标，并有条件地更好地控制它们（甚至可以在工作机之间混合并匹配工件）。