首页 文章

buildbot vs hudson / jenkins用于C持续集成

提问于
浏览 次
73

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

  • 使用选项构建所有内容，以便重新配置，执行干净的构建或使用新的签出

  • 可选择构建并运行所有测试

  • 可选择使用Valgrind的memcheck运行所有测试

  • 运行cppcheck

  • 生成doxygen文档

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

  • 每晚或按需将代码部署到测试环境和软件包存储库

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

我们开始使用Hudson（当时）因为这是Java人员正在使用的东西，我们只想要夜间构建 . 从那时起，我们增加了很多，并继续增加更多 . 在某些方面哈德森很棒，但肯定不理想 .

我已经看过其他解决方案了，唯一看起来像是替代品的是buildbot . buildbot会更好地适应这种情况吗？自从我们已经在使用Hudson以来，投资是否值得？为什么？

EDIT ：有人问为什么我只是想知道Jenkins是否是我当前使用案例中最好的解决方案，或者是否有更好的东西（buildbot？），即使有新的要求，也会更容易维护 .

c++ continuous-integration hudson jenkins buildbot

5 回答

  • 6

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

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

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

    希望它会有所帮助 .

    回复于
  • 6

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

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

    我们从0.7之前开始运行buildbot，现在运行0.8并且现在只看到任何真正的切换原因，因为buildbot 0.8在很长一段时间内忘记了windows奴隶并且支持非常差 .

    回复于
  • 41

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

    • Jetbrains的TeamCity

    • Atlassian的竹子

    • 转到Thoughtworks

    • 巡航控制

    • OpenMake Meister

    事实上，只要您正在执行它们的代理（也称为节点）支持这些任务，您所做的事情的具体细节就不那么重要了 .

    当构建发生更改以触发新构建（和测试），发布工件以及发布测试结果时，CI服务器的优点在于注意到 .

    当您比较我们提到的CI工具时，请考虑其可用性等功能界面，分支（以及它可能提供的功能，如自动合并），通知（如XMPP / jabber）或信息辐射（如连接监视器以始终显示状态）是多么容易 . 产品支持是另一个需要考虑的事项 - 詹金斯的支持与您在提出问题时回答社区问题一样好 .

    我个人最喜欢的是Bamboo，但需要许可费 .

    回复于
  • 1

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

    *）Buildbot没有任何与每个构建相关的文件 artifacts 的开箱即用概念 . 据我所知，'s not in the UI and it'不在任何内置"steps"模块中：

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

    ......我没有看到第三方插件：

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

    Buildbot会收集给定构建的所有控制台输出，但是关键的是，您无法收集与其相关的文件 .

    *）鉴于不支持工件，创建"collector"项目并不容易将多个模块放入单个安装程序中 . Jenkins有一个很棒的功能，它允许您使用其他模块的构建参数化构建（参数类型是 run ） .

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

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

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

    经过两天的Buildbot评估后，我的印象是我们会坚持使用Jenkins，主要是因为它有 artifacts . 如果我们有更广泛的定制需求和时间，我们只会使用Buildbot .

    回复于
  • 0

    关于buildbot和工件的主题 - 我没有足够的用户评分来发表评论 - 你可以通过内置的文件/目录上传动作从buildbot 2.x系列中获得很多文件 . 但是，您很少想要移动文件 . 通常，您会创建一个触发的构建步骤，直接从工作程序部署，以获得最佳结果 . 例如，推送到 Cloud 存储，容器，第三方（蒸汽上传）等 .

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

    回复于

相关问题