原文：http://www.ibm.com/developerworks/cn/linux/l-buildbot/
持续集成（CI）是发扬以下原则的一个软件开发流程：
- 维护单源存储库
- 自动化构建过程
- 实现自测试构建
- 每个人每天都有贡献
- 每一份贡献都应用于在一个集成机上构建主线
- 加快构建过程
- 在一个相同的生产环境中执行测试
- 使任何人都可以简单获取最新的可执行文件
- 每个人都可以看到当前状况
- 自动化部署
经 Martin Fowler 大力普及，CI 的基本理念就是持续测试并构建每个分支程序和将分支代码合并后的软件。这可以从总体上提高代码库的健康状况。还可以增加与团队成员的交流，并有机会获取对代码整体质量的反馈。人们通常使用这个周期来生成代码覆盖报告和其他统计信息。
Buildbot 类似于其他 CI 系统，有助于自动化这个检查、构建和测试流程。Buildbot slaves 通常运行于不同的平台，比如 Win32、Solaris、Intelx64 等。当一个构建（build）中断时，Buildbot 可以发送一个电子邮件通知，它追踪所有运行中的构建，这样开发人员就可以鸟瞰整个流程。最后，人们常常利用自动化周期构建既定时间内软件质量的度量标准。本文结尾将谈及该度量标准以及在一个 CI 系统内运行它们的原因。
Buildbot 简介
在我们深入探讨 Buildbot 之前，先看一下其架构。如图 1 所示，在构建流程的顶部主要有三个层。首先是一个版本控制层，它从一个版本控制系统钩入通知。其次是一个构建层，它从构建主服务器那里获取通信，并返回构建结果。最后是一个通知层，用于在构建失败时发送电子邮件或一个 IRC 消息，或让一个 web 页面显示构建的累积结果。
图 1. Buildbot 架构概览
Buildbot 架构的中心特性之一是对基于 Python 的 Twisted 库的依赖性，用于处理主服务器（master）和伺服机（slave）之间的异步通信。这个基于回调的架构支持一个很简单、但健壮的主/伺服反馈圈。在本文后面的 参考资料 部分可以找到有关 Twisted 的更多信息。
如果您尚未听说过 Buildbot，在 Google 上搜索一下就会找到大量与大小开源项目相关的主服务器和伺服机。关于伺服机，我在前面简单地提及了一下，它本义上是一个由主 Buildbot 服务器控制的伺服机器。一般来讲，一个伺服机是多个运行不同测试平台的伺服机之一。这是 Buildbot 服务器中一个很重要的概念。例如，您可能在一个开源项目的邮件列表上，听到有人说，“有人自愿充当 Windows 伺服机的虚拟机吗？”
Python 语言项目本身使用大量 Buildbot 伺服机，在尽可能多的平台上持续构建和测试最新版的 Python。图 2 显示了运行 Python 主干的许多伺服机以及测试。随着虚拟化技术的发展，现在可以常常要求开发社区成员托管一个 Buildbot 伺服机，或仅仅运行模拟不同硬件配置的几个虚拟机。
图 2. Python Buildbot；参见 放大图
另一个备受瞩目的 Buildbot 用户是 Google Chrome 浏览器项目。图 3 显示了一个高度定制的 Buildbot，它极大地增强了 Buildbot 用户界面的外观。幸运的是，Google 将这些增强的开放代码提供给 Buildbot，从下面的 参考资料 部分，您可以获取源代码并构建这个定制版本。
图 3. Google Chrome 增强的 Buildbot；参见 放大图
构建这个配置不在本文讨论范围内，但是我建议您自己看一下。现在我们看一下如何使一个 Buildbot 主服务器快速运转起来。