buildbot vs hudson/jenkins的c++持续集成

buildbot vs hudson/jenkins for C++ continuous integration

本文关键字：c++ 集成 jenkins vs hudson buildbot      更新时间：2023-10-16

我目前正在使用jenkins/hudson进行持续集成，主要是一个大型的c++项目。我们对主干和每个分支都有单独的项目。此外，还有一些与Java代码相关的项目，但这些项目的设置现在还相当基础(稍后我们可能会做更多)。c++项目做以下工作:

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

对于自动构建，一切都是可配置的，对于按需构建，一切都是可选的。在底层，有一个bash脚本来控制这些，它进一步依赖于我们的构建系统，它使用automake和autoconf以及自定义bash脚本。

我们开始使用Hudson(当时)，因为Java人员正在使用它，我们只是想要每晚构建。从那以后，我们添加了更多，并继续添加更多。在某些方面，哈德逊是伟大的，但肯定不是理想的。

我看过其他的解决方案，唯一一个看起来可以替代的是buildbot。对于这种情况，buildbot会更好吗?既然我们已经在用哈德森了，这笔投资值得吗?为什么?

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

都是开源项目，但您不需要更改buildbot代码来"扩展"它，实际上很容易在其配置中导入您自己的包，您可以在其中子类化您自己添加的大多数功能。例如:你自己的编译或测试代码，对输出/错误的一些解析，给下一步，你自己的警告电子邮件的格式等等，有很多可能性。

一般来说，我会说buildbot是最"通用"的自动构建工具。Jenkins可能是运行测试的最佳工具，尤其是在解析和以良好的方式呈现结果(结果、细节、图表……)一些点击)，事情，buildbot不做"开箱即用"。我实际上在考虑使用两者都有性感的测试结果页…: -)

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

希望对你有帮助。

'结果集成'也在jenkins/hudson中，您可以相对容易地捕获构建产品，而不必'将它们复制到其他地方'。

对于我们的实例，覆盖报告和单元测试度量以及java代码的javadoc都是集成的。对于我们的c++代码，插件有点缺乏，但你仍然可以得到它的大部分。

我们从0.7版本开始运行buildbot，现在运行的是0.8版本，直到现在才有真正的理由切换，因为buildbot 0.8在很长一段时间内忘记了Windows slave，而且支持非常差。

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

  • TeamCity by Jetbrains
    • Bamboo by Atlassian
  • Go by Thoughtworks
  • 巡航控制
  • OpenMake Meister

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

CI服务器的美妙之处在于，它会注意到何时构建发生变化，从而触发新的构建(和测试)，发布工件，并发布测试结果。

当您比较我们提到的那些CI工具时，请考虑其界面的可用性、分支的容易程度(以及它可能提供的功能，如自动合并)、通知(如XMPP/jabber)或信息散热器(如连接监视器以始终显示状态)等特性。产品支持是另一件要考虑的事情——Jenkins的支持只有在你有问题的时候回应社区问题的人才算好。

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

我是一个长期的Jenkins用户，正在评估Buildbot，我想为那些考虑使用Buildbot进行多模块解决方案的人提供一些项目:

*) Buildbot没有任何与每个构建相关的文件artifacts的开箱概念。它不在UI中也不在任何内置步骤中modules as far as I can see:

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

…我没有看到第三方插件:

https://github.com/buildbot/buildbot/wiki/PluginList步骤

Buildbot收集给定构建的所有控制台输出，但关键是，您不能收集与相关的文件。

*)鉴于工件不受支持，创建"collector"并不容易。在单个安装程序中引入多个模块的项目。Jenkins有一个很棒的特性，可以让你用其他模块的构建参数化一个构建(参数类型是一个run)。

*)在Buildbot中建立模块之间的依赖关系更加棘手。假设您有一个三个二进制文件依赖的库，并且您希望这些二进制文件在每次库更改时重新构建。 Jenkins在UI中内置了triggers。如果你想在Buildbot中做触发器，你必须使用schedulers.Dependent来编写脚本，这会导致Schedulers UI中的许多项目拥塞。

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

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

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

关于buildbot和工件的主题——我没有足够的用户分数来发表评论——您可以从buildbot 2中获得工件。X系列相当容易与内置的文件/目录上传动作。然而，您很少希望只是移动文件。通常，您会创建一个触发的构建步骤，直接在worker之外进行部署，以获得最佳效果。例如推送到云存储、容器、第三方(steam上传)等

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

相关文章：