什么持续集成工具最适合 C++ 项目？
Cruisecontrol 和 Hudson 是两种流行的持续集成系统。 尽管两个系统都能够很好地执行自动连续构建，但创建批处理或 bash 构建脚本，然后使用 Windows 调度程序或 cron 来安排构建似乎要容易得多。
是否有更好的持续集成系统可用于 C++ 项目？ 或者只是使用脚本和调度程序是更简单的方法？
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（6）
我们一直在 C++ 项目上使用 CruiseControl 进行 CI。 虽然这是我们唯一使用 ant 的用途，但 CruiseControl 的 ant 构建脚本只是启动我们的正常构建脚本，因此它非常简单，而且我们已经很长一段时间没有真正需要更新它了。 因此，CrusieControl 基于 Java 这一事实对我们来说根本不是问题。
使用巡航控制之类的东西的主要好处是
当然您可以自己编写一个脚本来完成所有这些操作，但是为什么所有这些都有效呢？ 从长远来看，设置 CruiseControl（或类似的东西）的额外初始成本可能远低于维护和更新自定义 CI 构建脚本的成本。
如果您需要的只是启动每日构建，并且由 cron 启动的简单脚本足以满足您的需求，那么请务必执行此操作。 然而，CI 的优点之一是您在每次签入后都会获得构建状态报告。编写脚本来完成这需要更多的工作，而 CruiseControl 已经做到了。
We have been using CruiseControl for CI on a C++ project. While it is the only thing we use ant for, the ant build script for CruiseControl just starts our normal build script, so it is very simple and we haven't really needed to update it in a long while. Therefore the fact that CrusieControl is Java based has not really been an issue at all for us.
The main benefits of using something like cruise control are
Of course you can write a script yourself which does all of this, but why do all that work? In the long run the extra initial cost of setting up CruiseControl (or something similar) is probably much less than the cost of maintaining and updating a custom CI build script.
If all you need is to launch a daily build and a simple script started by cron is sufficient for your needs then by all means do that. However, one of the advantages of CI is that you get a build status report after every check in. Writing a script to do that takes more work and CruiseControl already does it.
我们使用 Hudson 进行 CI，SonarQube 用于代码指标。 它们是集成的，Hudson 有一些 cronjob 无法击败的插件。
CI Game 是一个很棒的插件，它会记录谁破坏了构建以及谁在不破坏构建的情况下提交的信息。 Hudson 拥有可与 VMWare、Selenium、SVN、CSV、Git 配合使用的插件。 它具有 RSS 联合功能，可以帮助您自动化更多其他工作。
哈德森太棒了...
We use Hudson for CI and SonarQube for code metrics. They're integrated, and Hudson has a handful of plugins that no cronjob can beat.
One great plugin is CI Game, which keeps a score about who breaks the builds and who commits without breaking it. Hudson has plugins to play with VMWare, Selenium, SVN, CSV, Git. It has RSS syndication, which can help you to automate even more everything else.
Hudson is great...
我们一直在使用 Dart 仪表板。 它是开源的，但由 KitWare 驱动。 此后，他们将名称更改为 CDash，我认为它仍然有能力。 我们正在进行多种测试，包括在调试和发布模式下跨 10 个不同平台进行夜间和持续集成，以及运行数千个应用程序测试并报告结果。
We've been using Dart Dashboard. It's open source but driven by KitWare. They've since changed the name to CDash which I presume is still as capable. We're doing several kinds of testing including nightly and continuous integration across 10 different platforms in both debug and release mode as well as running 1000s of application tests and reporting the results there too.
我一直在为 Buildbot /" rel="nofollow noreferrer">Spring RTS 引擎 项目成功。
I've been using Buildbot for the Spring RTS engine project succesfully.
您还可以尝试 JetBrains 的 TeamCity。 它是一个商业产品，但它提供最多 20 个构建配置的免费许可证。
You can also try JetBrains' TeamCity. It's a commercial product but it gives a free license for up to 20 build configurations.
持续集成 (CI) 工具的优点之一是，每次将某些内容签入源代码控制存储库时都会触发构建。
如果这不是您所需要的，那么您最好使用 Windows 任务计划程序或 cron 作业。
此外，CI 工具还附带（Web）仪表板和高级日志记录功能。
在我看来，你的问题更像是“我为什么要使用 CI 工具”，而不是“我应该使用哪个 CI 工具”。 如果批处理脚本满足您的需求，请使用它。 如果您不需要 CI 工具作为附加组件，（重新）创建构建环境只会变得更加容易。 如果您想要源代码控制触发的构建、仪表板、旧构建结果的存储或其他日志记录，请使用 CI 工具并避免在批处理或 shell 脚本中开发所有此类功能。
One of the nice features of a continuous integration (CI) tool is that a build gets triggered every time something is checked into your source control repository.
If that is not something you need then you are probably better of using the windows task scheduler or cron jobs.
In addition CI tools also come with a (web) dashboard and advanced logging capabilities.
Your question seems to me more "why would I use a CI tool" then "which CI tool should I use". If a batch script serves your needs, please use that. (Re)creating a build environment only becomes easier if you do not need a CI tool as an additional component. If you want source control triggered build, a dashboard, storage of old build results or other logging, use a CI tool and avoid developing all such functions in batch or shell scripts.