3) 分阶段构建(Staged Build)

　　分阶段构建是Cruise(已经更名为Go)引入的重要概念。其主要的意义在于：

　　分离关注度不同的验证阶段，比如Commit Build和Regression Tests，团队会对不同的验证阶段采取不同的策略

　　构建流程可视化

　　通过分阶段并发构建来缩短反馈周期

　　当构建的时间过长时，我们通常会要求开发人员只运行速度较快的价值较高的构建阶段可以继续自己的开发任务，而不必等待漫长的次级构建完成。这里作者提到ThoughtWorks不同的团队有很多有趣的实践，我们将在第二部分向读者介绍其中的一部分。

　　报告

　　作者在第二版中专门拿出一节“每个人都能看到进度(Everyone Can See What’s Happening)”来介绍有关持续集成报告的内容。因为：

　　持续集成的目的是为了沟通。

　　这是第二版相对于第一版来说一个非常明显的变化。在第一版中通知的手段还主要是电子邮件，实际上在作者撰写第二版的时候，ThoughtWorks已经不赞成将电子邮件作为主要的持续集成通知工具了。更好的沟通工具包括音乐、熔岩灯、显示器等。

　　对于沟通的重视从工具的角度也可以体现出来。Cruise Control主要做的事情是任务调度，在报告部分做的相对来说非常粗糙，比较有价值的报告大部分是从Cruise移植过去的。Cruise在从一开始 非常重视这一点，通过Cruise你可以非常清晰地知道，代码发生了什么变化、正在进行的构建的状态和历史构建的状态。网页的形式对于分布式团队来说具 有不可替代的优势。

　　正如我们前面所说的，音乐、熔岩灯等物理手段，具有更强的信息辐射能力。站起来往周围看一看知道哪个团队的构建成功了，哪个失败了。

　　4) 持续部署

　　持续集成实践有一个基本的思想是：越是痛苦的事情，越要经常做。集成之后更令人心惊胆颤的事情是——部署。部署到生产环境的流程通常要严格得多，然而所有的工作必须经历了生产环境的验证才算是成功的，所以——持续部署才是王道。Martin在第二版中建议：

　　你应该有一个脚本帮助你很容易地将系统部署到生产环境中去。……同时要特别考虑的是要能够自动回滚。

　　引入持续集成的建议

　　作者在第二版中特别给出了逐步引入持续集成的建议。包括：

　　引入版本控制。

　　实现自动化构建。

　　添加自动化测试。

　　加快提交构建。

　　寻找帮助。(比如ThoughtWorks)

　　第二部分 持续集成领域的新进展

　　正如前文所说，ThoughtWorks中国公司在过去的几年里面对于持续集成实践和帮助客户实施持续集成都积累了很多的经验，同时在理论体系方面也更加丰富完整。这也使ThoughtWorks在这个领域继续保持了行业的位置。

　　正如我们在第一部分讲到的，持续集成不应该只作为一个孤立的实践来应用。我们的经验表明如果只把持续集成作为一个孤立的实践应用很难从持续集成长期 受益。持续集成往往进入“长红”或者“长绿”的不正常的状态。长红意味着系统长期无法集成;长绿则往往意味着缺少足够的验证。为了术语上的澄清，我们明确 地将持续集成的定义区分为狭义的持续集成和广义的持续集成。

　　狭义的持续集成：基于某种或者某些变化对系统进行的经常性的构建活动。