CruiseControl 到底是做什么的？我不明白。我用它来做什么？有人告诉我，它可以跟踪你的构建日期，以及构建是成功还是失败，但我到底为什么需要它？我假设如果出现构建错误，它可以给你发送电子邮件，但除此之外（假设构建时间很长，我每晚或晚上都进行构建），我还能用它做什么？作为业余爱好者，还是在少于 5 人的小项目中？
答案1
持续构建系统的优势最常被称赞为多开发人员项目，但对于较小的团队或单个开发人员来说，它确实具有一些优势。
首先让我们看一下典型的用例：一个拥有大量提交者的大型项目。有时，构建可能会中断。也许某人的本地环境与服务器不匹配，他们提交的代码只能在他们的机器上编译，或者某人因为匆忙而没有检查他们的代码是否编译，或者某人在编辑和提交时签出的内容不是最新的。
无论如何，构建现在已损坏。该错误需要修复，但可能不清楚究竟是谁造成的，而且时间至关重要！当人们更新到 head 时，他们将不再拥有可编译的代码，这使他们更难完成工作。
监控构建状态有助于避免许多此类事件的发生。一旦有问题的代码进入仓库，构建就会失败，但他们会立即知道，这样人们就不会将其签出。由于它是当前的 head，因此更容易恢复。即使人们最终得到了该代码，至少他们知道是谁造成的，以及是哪个提交。
甚至可能（取决于构建速度）将构建检查作为预提交的钩子，从而首先阻止坏代码进入中央代码库。
那么它能给小型团队或单独的开发人员带来什么呢？
好吧，了解构建是否中断可能仍然很方便，这取决于您编写和测试代码的工作习惯。在小型团队中，如果存在地理隔离，我认为了解构建中断以及谁在何时以及什么原因中断了构建很有用。
您还可以用它做其他事情。如果您已设置它，那么您就拥有一个始终拥有最新版本副本的服务器。如果服务器面向 Web，您现在可以轻松让人们试用最新版本的软件（例如 Firefox nightlies 等）。项目之外的人可能还对代码是否在他们的平台上构建或是否通过特定测试感兴趣。
最后，看一下Chromium 的 CI 仪表板了解您可以获得哪些类型的信息。我们可以看到每个平台上的构建状态、提交及其对平台的影响、代码覆盖率统计、下载最新版本，对于失败的构建，我们可以看到失败的测试以及错误消息。太酷了！
答案2
CruiseControl（以及其他持续构建 [CI] 系统，如 Hudson、Anthill 等）的常见用例是定期（每分钟？）检查查询中央源代码管理系统 (SCM)，或者在发生更改时从存储库获取通知。然后 CI 应该构建代码。
除此之外，还可以在每次构建时运行测试、部署工件（例如部署到 maven repo 或演示服务器）。您可能有多个构建，例如，一个构建将由 SCM 中的每个更改触发，另一个构建将在每个晚上和午休时间触发。“真正的”CI 构建将只编译代码并运行单元测试，而“大型”构建可能会运行集成测试和其他耗时的任务。
我认为 CI 系统的一个好处是至少有一个与开发机器不同的构建环境。例如，可以修改环境以模仿客户的环境。另一个不错的功能是构建失败时会发出通知。这样，就可以更轻松地找出构建失败的原因以及如何修复它。
您还可以在 CI 机器上配置手动运行的构建，并自动执行推出过程（如果您的应用程序和客户允许这样做）。或者有一个构建，为需要生成应用程序快照版本以进行测试的非开发人员创建可执行文件。
CI 系统用途广泛，即使是小团队也应该拥有它。业余爱好者可能不需要这样的工具，但如果至少有 2 名开发人员参与，拥有 CI 是件好事！