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

【问题标题】：buildbot vs hudson/jenkins for C++ continuous integration用于 C++ 持续集成的 buildbot vs hudson/jenkins
【发布时间】：2011-08-04 22:23:25
【问题描述】：

我目前正在使用 jenkins/hudson 来持续集成一个主要是 C++ 的大型项目。我们为主干和每个分支都有单独的项目。此外，还有一些与 Java 代码相关的项目，但这些项目的设置现在相当基本（不过我们以后可能会做更多）。 C++ 项目执行以下操作：

构建所有内容，可选择重新配置、执行干净构建或使用全新结帐
可选择构建和运行所有测试
可选择使用 Valgrind 的 memcheck 运行所有测试
运行 cppcheck
生成 doxygen 文档
发布报告：单元测试、valgrind、cppcheck、编译器警告、SLOC、打开的任务和代码覆盖率（使用 gcov、gcovr 和 cobertura 插件）
每晚或按需将代码部署到测试环境和包存储库

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

我们（当时）开始使用 Hudson，因为 Java 开发人员正在使用它，而我们只是想要每晚构建。从那时起，我们添加了更多内容，并继续添加更多内容。在某些方面，Hudson 很棒，但肯定不理想。

我查看了其他解决方案，唯一看起来可以替代的解决方案是 buildbot。 buildbot 会更适合这种情况吗？既然我们已经在使用 Hudson，这项投资值得吗？为什么？

编辑：有人问我为什么没有发现 Hudson/Jenkins 是理想的。简短的回答是，一切都可以改进。我只是想知道 Jenkins 是否是我用例的最佳当前解决方案，或者是否有更好的东西（buildbot？）即使出现新的需求，从长远来看也更容易维护。

【问题讨论】：

我没有看过 Buildbot，但我们几乎可以完成您在 Hudson 上的多个 C++ 项目中提到的所有内容。您认为 Hudson/Jenkins 有哪些不理想的事情？
到目前为止，我们对 Jenkins/Hudson 非常满意。我们还没有真正遇到过任何我们认为它不足或缺乏的案例。
@SooWeiTan 很好，用户界面..
@Pithikos 自从我上次发表评论以来一直在使用 Jenkins。我开始同意了。当您开始安装插件时，情况会变得更糟。我们在 Jenkins 生态系统中根深蒂固，尽管切换系统将是一项巨大的努力。
投票结束过于广泛。更广泛的一个：stackoverflow.com/questions/25902/…

标签： c++ continuous-integration hudson jenkins buildbot

【解决方案1】：

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

通常我会说 buildbot 是最“通用”的自动构建工具。然而，Jenkins 可能是与运行测试相关的最好的，特别是在以很好的方式（结果、细节、图表......我实际上正在考虑使用两者来获得更性感的测试结果页面.. :-)

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

希望对你有所帮助。

【讨论】：

感谢 Christophe 的投入以及对每个优点和缺点的良好概述。
“Buildbot（或 Jenkins）应该只调用简单的命令”——金句

【解决方案2】：

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

在我们的例子中，覆盖率报告和单元测试指标以及 java 代码的 javadoc 都是集成的。对于我们的 C++ 代码，插件有点少，但你仍然可以得到大部分。

我们从 0.7 之前的版本开始运行 buildbot，现在正在运行 0.8，直到现在才看到任何真正的切换理由，因为 buildbot 0.8 很长一段时间都忘记了 windows slaves 并且支持很差。

【讨论】：

那么对于大型 C++ 项目，你推荐 Jenkins 还是 buildbot？

【解决方案3】：

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

Jetbrains 的 TeamCity
Atlassian 的竹子
Thoughtworks 前行
巡航控制
OpenMake 大师

事实上，你正在做的事情的细节并不那么重要，只要你正在做的代理（又名节点）支持这些任务。

CI 服务器的美妙之处在于当构建更改以触发新构建（和测试）、发布工件和发布测试结果时注意到。

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

我个人最喜欢的是 Bamboo，但它需要支付许可费。

【讨论】：

感谢您的建议。在我们的案例中，我们希望坚持使用 FOSS 解决方案，它消除了除巡航控制之外的所有这些选项。如果您能说明我可能想要切换到巡航控制系统的原因，那可能会有所帮助。
去吧：Jenkins 在 FOSS 社区中的支持比 Cruise Control 更好。全力以赴，伙计！
Go 实际上最近也开源了。

【解决方案4】：

我是一名长期 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 在 UI 中内置了 triggers。如果您想在 Buildbot 中执行触发器，则必须使用 schedulers.Dependent 编写它们的脚本，这会导致 Schedulers UI 中的大量项目拥塞。

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

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

经过两天的 Buildbot 评估后，我的印象是我们会坚持使用 Jenkins，主要是因为它有 artifacts。 Buildbot 是一个我们只有在我们有更广泛的定制需求并且有时间去做的时候才会使用的工具。

【讨论】：

【解决方案5】：

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

通过这种方式，您可以获得关于上传的指标并有条件地更好地控制它们（甚至可以在工作机器之间混合和匹配工件）。

【讨论】：