buildbot vs hudson / jenkins for C ++持续集成 [英] buildbot vs hudson/jenkins for C++ continuous integration

问题描述

我目前使用jenkins / hudson连续集成一个大多数C ++项目。我们有单独的项目为树干和每个分支。此外，还有一些Java代码的相关项目，但是这些的设置现在是相当基本的（我们可以做更多的事情）。 C ++项目执行以下操作：

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:

• 构建一切，包括是否重新配置，执行干净构建或使用新的检出<


• 可选择运行所有测试


• 运行cppcheck


• 生成doxygen文档


• 发布报告：单元测试，valgrind，cppcheck，编译器警告，SLOC，打开的任务和代码覆盖（使用gcov，gcovr和cobertura插件）


• 将测试环境和软件包存储库夜间或按需部署。

• 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

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

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.

我们开始使用Hudson （当时），因为这是Java家伙正在使用，我们只是想每晚构建。从那时起，我们增加了更多，并继续添加更多。在某些方面，Hudson是伟大的，但肯定是不理想。

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.

我看过其他解决方案，只有一个看起来像是可以替换的是buildbot 。将buildbot更好的这种情况？这个投资值得吗，因为我们已经在使用哈德森了？为什么？

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?

编辑：有人问我为什么没有发现哈德森/詹金斯是理想的。简单的答案是，一切都可以改进。我只是想知道Jenkins是否是我的用例的最好的解决方案，或者是否有更好的东西（buildbot？），即使在新需求出现时，更容易维护。

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.

推荐答案

这两个都是开源项目，但你不需要改变buildbot代码来扩展它，实际上很容易导入自己的包其配置中，您可以使用您自己的添加子类的大多数功能。示例：您自己的编译或测试代码，一些解析输出/错误给下一步，您自己形成警报电子邮件等。有很多可能性。

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是最通用的自动构建工具。 Jenkins可能是与运行测试最相关的，特别是以很好的方式解析和呈现结果（结果，细节，图表，一些点击），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.. :-)

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

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 vs hudson / jenkins for C ++持续集成的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！