CruiseControl（或任何其他 CI 工具）比编写良好的 (n)Ant 提供了什么？

Question

我们拥有大量用于构建各种产品的 nAnt 脚本。它们几乎都具有以下结构：

1. 删除旧的工作副本。
2. 从版本控制中查看完整的新副本。
3. 在适当的文件中增加内部版本号（自定义 nAnt 任务）。
4. 运行静态分析（StyleCop、Perl 脚本）
5. 使用 Visual Studio 构建解决方案 - 以 MSI 输出结束。
6. 运行单元测试（nUnit、JSUnit）
7. 运行静态分析 (FxCop)
8. 将可交付成果（MSI、自述文件等）压缩到命名良好的包中。
9. 将此压缩包放到服务器共享中。
10. 将结果通过电子邮件发送给团队。

从我们的研究来看，CruiseControl(.net?)/Hudson/BuildBot 似乎只会添加导致构建的触发器，目前正在通过远程桌面和状态仪表板双击 nAnt 脚本。

我们是否遗漏了其他重要的东西？

Answer 1

这个问题是主观的，因此我的回答也是如此。

在我之前自动化的项目中，CruiseControl 主要用于一个目的：因此我们不必远程进入构建机器并触发构建。 CI 部分是 CruiseControl 将为您监控存储库，以您定义的时间间隔触发构建。

它还为我们提供了仪表板，可以从中触发发布，或者返回检查过去构建的日志和人工制品。

对我们来说，实施 CruiseControl 的好处就足够了。也许在你完成它之前它“看起来”并不多，一个月后你意识到你不必接触你的构建系统，因为它默默地为你做着它的事情，而且吃力不讨好。

Answer 2

Hudson 等持续集成服务器会为您执行 1、2、3、9 和 10，这样您就不必自己实现它们。如果你已经让它工作了，这对你当前的项目来说可能不是一个巨大的改进，但它会让后续项目的事情变得更简单。正如您所提到的，它还会处理触发构建的时间。

Hudson 还将绘制各种随时间变化的趋势图，例如测试覆盖率、构建时间、静态分析结果。如果您愿意，您还可以拥有比电子邮件更复杂的通知。

Answer 3

它为您提供的最重要的东西是视觉反馈（屏幕越大越好）。当您拥有一台专门用于显示构建结果且对所有团队成员可见的机器时，它就像催化剂一样让人们看到有问题并进行修复。

如果你有这样的东西站在老板可以看到的地方问你“嘿威尔金森，为什么这个屏幕是红色的？”你会更快地修复你的构建吗？

它们看起来都一样，您可以选择您认为适合您的任何东西，只需设置一个并运行。