我目前正在使用jenkins / hudson进行持续集成，主要是一个C ++项目。我们为主干和每个分支都有单独的项目。此外，还有一些Java代码的相关项目，但是这些项目的设置现在相当基础（我们可能会在稍后做更多）。 C ++项目执行以下操作：
一切都可以配置为自动构建，可选配置为按需构建。在下面，有一个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之外，还有许多其他解决方案：
事实上，只要您正在执行它们的代理（即节点）支持这些任务，关于您正在做什么的细节就不那么重要了。
当构建发生更改以触发新构建（和测试），发布工件以及发布测试结果时，CI服务器的优点在于注意到。
当您比较我们提到的CI工具时，请考虑其界面的可用性，分支（以及它可能提供的功能，如自动合并），通知（如XMPP / jabber）或信息辐射（如挂钩）等功能监视器始终显示状态）。产品支持是另一个需要考虑的事项 - 詹金斯的支持与您在提出问题时回答社区问题一样好。
我个人最喜欢的是Bamboo，但需要许可费。
我是评估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有一个很棒的功能，它允许您使用其他模块的构建参数化构建（参数类型是run）。
*）在Buildbot中建立模块之间的依赖关系比较棘手。假设您有一个三个二进制文件所依赖的库，并且您希望每次库更改时都重建这些二进制文件。 Jenkins在用户界面中内置了triggers。如果你想在Buildbot中做触发器，你必须使用schedulers.Dependent编写脚本，并且它会导致Schedulers UI中的大量项目拥塞。
*）当您在Buildbot中工作时，似乎几乎所有的配置都是在代码中的master.cfg中完成的。这太棒了，令人沮丧。
*）除了worker服务器之外，Buildbot还会强制你创建一个master。对于单个构建服务器足够的初学者和系统来说，这很烦人。
经过两天的Buildbot评估后，我的印象是我们会坚持使用Jenkins，主要是因为它有artifacts。如果我们有更广泛的定制需求和时间，我们只会使用Buildbot。
关于buildbot和工件的主题 - 我没有足够的用户评分来发表评论 - 你可以通过内置的文件/目录上传动作从buildbot 2.x系列中获得很多文件。但是，您很少想要移动文件。通常，您会创建一个触发的构建步骤，直接从工作程序部署，以获得最佳结果。例如，推送到云存储，容器，第三方（蒸汽上传）等。
通过这种方式，您可以获得上传的指标并更好地有条件地控制它们（甚至可以跨工作机器混合和匹配工件）。