buildbot 与 hudson/jenkins 的 C++ 持续集成

buildbot vs hudson/jenkins for C++ continuous integration

提问by deuberger

I'm currently using jenkins/hudson for continuous integration a large mostly C++ project. We have separate projects for trunk and every branch. Also, there are some related projects for the Java code, but the setup for those are fairly basic right now (we may do more later though). The C++ projects do the following:

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

• Builds everything with options for whether to reconfigure, do a clean build, or use a fresh checkout
• Optionally builds and runs all tests
• Optionally runs all tests using Valgrind's memcheck
• Runs cppcheck
• Generates doxygen documentation
• Publishes reports: unit tests, valgrind, cppcheck, compiler warnings, SLOC, open tasks, and code coverage (using gcov, gcovr, and the cobertura plugin)
• Deploys code nightly or on demand to a test environment and a package repository

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

Everything is configurable for automatic builds and optional for on demand builds. Underneath, there's a bash script that controls much of this, which farther depends on our build system, which uses automake and autoconf along with custom bash scripts.

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

We started using Hudson (at the time) because that's what the Java guys were using and we just wanted nightly builds. Since then, we've added a lot more and continue to add more. In some ways Hudson is great, but certainly isn't ideal.

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

I've looked at other solutions and the only one that looks like it could be a replacement is buildbot. Would buildbot be better for this situation? Is the investment worth it since we're already using Hudson? Why?

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

EDIT: Someone asked why I haven't found Hudson/Jenkins to be ideal. The short answer is that everything can be improved. I'm simply wondering if Jenkins is the best current solution for my use case or whether there is something better (buildbot?) that would be easier to maintain in the long run even as new requirements come up.

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

采纳答案by Christophe Muller

Both are open source projects, but you do not need to change buildbot code to "extend" it, it is actually quite easy to import your own packages in its configuration in which you can sub-class most of the features with your own additions. Examples: your own compilation or test code, some parsing of outputs/errors to be given to the next steps, your own formating of alert emails etc. there are lots of possibilities.

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

Generally I would say that buildbot is the most "general purpose" automatic builds tools. Jenkins however might be the best related to running tests, especially for parsing and presenting results in nice ways (results, details, charts.. some clicks away), things that buildbot does not do "out-of-the-box". I'm actually thinking of using both to have sexier test result pages.. :-)

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

Also as a rule of thumb it should not be difficult to create a new tool's config: if the specification of what to do (configs, builds, tests) is too hard to switch from one tool to another, it is a (bad) sign that not enough configuration scripts are moved to the sources. Buildbot (or Jenkins) should only call simple commands. If it is simple to run tests, then developers will do it as well and this will improve the success rate, whereas if only the continuous integration system runs the tests, you will be running after it to fix the new code failures, and will loose its non-regression value, just my 0.02 :-)

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

Hope it'll help.

希望它会有所帮助。

回答by Terry

The 'result integration' is also in jenkins/hudson, and you can relatively easily capture build products without having to 'copy them elsewhere'.

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

For our instance, the coverage reports and unit test metrics and javadoc for the java code is all integrated. For our C++ code, the plugins are a little lacking, but you can still get most of it.

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

we ran buildbot since pre 0.7, and are now running 0.8 and are only now seeing any real reason to switch, as buildbot 0.8 forgot about windows slaves for an extended period of time and the support was pretty poor.

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

回答by macetw

There are many other solutions out there, besides Jenkins/Hudson/BuildBot:

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

• TeamCity by Jetbrains
• Bamboo by Atlassian
• Go by Thoughtworks
• Cruise Control
• OpenMake Meister

• Jetbrains 的 TeamCity
• 竹子 by Atlassian
• 通过思想工作
• 巡航控制
• OpenMake大师

The specifics about what you are doing are not so important, in fact, as long as the agents (aka nodes) that you are doing them on support those tasks.

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

The beauty of a CI server is noticing when the build changes to trigger a new build (and test), publish the artifacts, and publish test results.

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

When you compare CI tools like those we mentioned, consider features like the usability of its interface, how easy is branching (and features it might offer like automatic merging), notifications (like XMPP/jabber), or an information-radiator (like hooking up a monitor to always show status). Product support is another thing to consider - Jenkins' support is only as good as who is responding to community questions at the time you have questions.

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

My personal favorite is Bamboo, but it comes with a license fee.

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

回答by mpr

I'm a long-time Jenkins user in the middle of evaluating Buildbot and would like to offer a few items for folks considering using Buildbot for multi-module solutions:

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

*) Buildbot doesn't have any out-of-the-box concept of file artifactsrelated to each build. It's not in the UI and it's not in any of the builtin "steps" modules as far as I can see:

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

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

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

...and I see no third party plugin:

...我看不到第三方插件：

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

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

Buildbot does collect all the console output from a given build, but critically, you can't collect filesrelated to it.

Buildbot 确实会从给定的构建中收集所有控制台输出，但至关重要的是，您无法收集与其相关的文件。

*) Given that artifacts are not supported, it's not easy to create "collector" projects that bring multiple modules into say, a single installer. Jenkins has a great feature that lets you parameterize a build with builds from other modules (the parameter type is a run).

*) 鉴于不支持工件，创建将多个模块整合为单个安装程序的“收集器”项目并不容易。Jenkins 有一个很棒的功能，可以让您使用来自其他模块的构建参数化构建（参数类型是 a run）。

*) Establishing dependencies between modules is trickier in Buildbot. Say you have a library that three binaries depend on, and you want those binaries to rebuild each time the library changes.Jenkins has triggersbuilt into the UI. If you want to do triggers in Buildbot you have to script them using schedulers.Dependent, and it causes a lot of item congestion in the SchedulersUI.

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

*) When you're working in Buildbot, it seems that pretty much all of the configuration is done in master.cfgin code. This is awesome and frustrating.

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

*) Buildbot forces you to create a workerin addition to a masterserver. This is annoying for beginners and systems for which a single build server is sufficient.

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

My impression after two days of Buildbot evaluation is that we'll stick with Jenkins, primarily due to it having artifacts. Buildbot is a tool we'd only use if we had more extensive customization needs, and the time to do it.

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

回答by Terry Hendrix II

On the subject of buildbot and artifacts -- I don't have enough user score to make a comment -- you can get artifacts from buildbot 2.x series pretty easy with built-in file/directory upload actions. However you rarely want to just move files. Typically you make a triggered buildstep that does deployment directly off the worker for best results. eg push to cloud storage, containers, thirdparty (steam uploads), etc.

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

This way you can get metrics on the uploads and conditionally control them better (or even mix and match artifacts across worker machines).

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