Cruisecontrol和Hudson是两个流行的持续集成系统。尽管两个系统都能很好地完成自动连续构建，但是创建批处理或者bash构建脚本，然后使用Windows Scheduler或者cron来调度构建似乎要容易得多。

是否有更好的C ++项目持续集成系统可用？还是仅使用脚本和调度程序是更简单的方法？

解决方案

我已经成功地将Buildbot用于Spring RTS引擎项目。

我们一直在C ++项目上使用CruiseControl for CI。虽然这是我们唯一用于ant的东西，但CruiseControl的ant构建脚本只是启动我们的常规构建脚本，因此它非常简单，而且我们确实不需要很长时间进行更新。因此，CrusieControl基于Java的事实对我们来说根本不是一个问题。

使用巡航控制之类的主要好处是

• 一个不错的网页，显示构建状态
• 每次构建后或者构建失败后发送电子邮件
• 提交到源代码控制系统后自动构建
• 一个firefox插件来监视构建状态
• 显示任何构建错误的输出。
• 显示自上次构建以来哪些文件已更改(有助于查看哪个开发人员破坏了投标)

当然，我们可以自己编写一个脚本来完成所有这些工作，但是为什么所有这些都能起作用？从长远来看，设置CruiseControl(或者类似的东西)的额外初始成本可能比维护和更新自定义CI构建脚本的成本低得多。

如果我们仅需要启动每日构建，而由cron启动的简单脚本就可以满足需求，则一定可以这样做。但是，CI的优点之一是，我们每次签入后都会得到一份构建状态报告。编写脚本来完成这项工作需要更多的工作，而CruiseControl已经做到了。

我们一直在使用Dart仪表板。它是开源的，但由KitWare驱动。从那以后，他们将名称更改为CDash，我认为它仍然可以使用。我们正在进行多种测试，包括以调试和发布模式在10个不同平台上进行夜间和连续集成，以及运行1000项应用程序测试并在其中报告结果。

我们也可以尝试JetBrains的TeamCity。这是一种商业产品，但它免费提供多达20种构建配置的许可证。

我们将Hudson用于CI，将SonarQube用于代码指标。它们已经集成在一起，而且Hudson有一些插件，这些插件是cronjob所无法比拟的。

CI Game是一个很好的插件，它对谁破坏了构建以及谁提交却没有破坏它进行了评分。 Hudson有可与VMWare，Selenium，SVN，CSV，Git一起使用的插件。它具有RSS联合组织，可以自动执行其他所有操作。

哈德森很棒...

持续集成(CI)工具的一项不错的功能是，每次将某些内容检查到源代码控制存储库中时，都会触发生成。

如果那不是我们所需要的，那么最好使用Windows Task Scheduler或者cron作业。

此外，CI工具还带有(网络)仪表板和高级日志记录功能。

在我看来，问题更像是"我为什么要使用CI工具"，而不是"我应该使用哪种CI工具"。如果批处理脚本满足需求，请使用该脚本。仅当不需要CI工具作为添加组件时，(重新)创建构建环境才会变得更加容易。如果要源控制触发构建，仪表板，旧构建结果的存储或者其他日志记录，请使用CI工具，并避免在批处理或者Shell脚本中开发所有此类功能。