78

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

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

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

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

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

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

4

5 回答 5

44

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

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

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

希望它会有所帮助。

于 2011-05-06T10:14:56.030 回答
6

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

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

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

于 2011-07-20T13:53:27.927 回答
6

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

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

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

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

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

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

于 2013-09-03T17:23:41.360 回答
2

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

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

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

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

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

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

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

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

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

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

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

于 2019-01-09T20:20:43.077 回答
1

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

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

于 2019-03-29T22:52:45.057 回答