持续集成理论和实践的新进展(2)

　　第二版中的原则增加了对构建的支持6：

　　任何人都可以找到一台干净的机器，做一次取出(checkout)动作，然后对系统执行一次完整的构建。

　　分阶段构建(Staged Build)

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

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

　　构建流程可视化

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

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

　　报告

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

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

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

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

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

　　持续部署

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

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

　　引入持续集成的建议

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

　　引入版本控制。

　　实现自动化构建。

　　添加自动化测试。

　　加快提交构建。

　　寻找帮助。(比如ThoughtWorks)

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

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

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

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

　　广义的持续集成：软件开发团队在上述活动的约束下所采用的开发流程。

　　狭义的持续集成

　　一般来说，狭义的持续集成包括如下几个方面：持续检查、持续编译(链接)、持续验证、持续部署、持续基础设施、持续报告等6个方面。

　　持续检查

　　持续检查的目的是保证代码风格一致，主要关注于代码的静态质量和内部质量，比如变量命名方式、大括号位置等等。大部分的现代集成开发环境(IDE)都具备实时检查代码质量的功能。为了保证主线上的代码质量能够达到一致的标准，应当在持续集成脚本中加入静态检查阶段。比如，Java的 PMD、 FindBugs等等。

　　持续编译

　　持续编译是一个很朴素的想法，就是保证主线上的代码始终处于可编译的状态。但是这对于很多大中型团队来说却并非想当然的简单。这是因为很多团队并未采用集体代码所有权策略，导致存在依赖的团队的代码无法编译。针对这样的问题，一方面我们建议采用集体代码所有权;另一方面，对于确实因为安全原因需要隔离的代码应该明确边界与接口，很少存在大部分代码需要对大部分人保密的情况。

　　持续检查和持续编译是持续集成中最基本的验证手段。

　　持续验证

　　持续验证的目的是检查主线上的代码是否能够实现所要求的功能，或者已有的功能是否被破坏。在大部分的构建中，验证部分是耗时最长、成本最高的部分，但同时也是收益最大的部分。在这个阶段，我们看到的主要问题是验证不充分和验证时间过长。针对这样的问题，我们通常采用分层分级的持续集成策略。后面有详细的描述。

　　持续部署

　　于大型软件应用来说，部署往往是一个费时费力又容易出错的步骤，因为这里面涉及到数据迁移、版本兼容等各种棘手的问题。持续部署的思想是将这些工作标准化自动化，使其能够可靠地、自动地、快速地运行。持续部署是当前DevOps运动中的热门话题之一。

　　持续基础设施集成

　　现代大型软件开发，尤其是互联网应用开发中经常依赖于一些常见的基础设施——比如Spring、Tomcat、Database等等。这些基础设施发生变化的时候，我们应当及时地触发持续集成，以确保我们的系统是能够与新的基础设施一起工作的。

　　持续报告

　　报告是将持续集成的状态以适当的形式展现给关系人的基本手段。报告是持续集成的晴雨表，所以它必须直观、易懂，而且对关注点不同的角色展现不同的内容和粒度。比如，开发人员可能更关心错误的日志;项目经理可能更关心测试覆盖率;产品经理可能更关心持续集成通过率的趋势等等。

原文转自：http://kb.cnblogs.com/page/109735/