来自于 Rational Edge：本文是对持续集成的概念和实践的一个介绍。它解释了如何用支持工具实现持续集成，这些工具包括IBM Rational ClearCase，IBM Rational ClearQuest 和一个开放源码工具 CruiseControl。

持续集成在软件开发世界中是一个热门话题。尽管经常与敏捷过程连接在一起，例如极限编程，但是概念和实践都不是什么新的－－只是众所周知的软件开发最佳实践上的一种变体。在这篇文章里，我将会讨论什么是持续集成，它适用于软件开发生命周期的哪些地方，以及如何用一个支持工具集来实现它。

什么是持续集成？

持续集成最初是由一组工具支持的一个过程。Martin Fowler和Matthew Foemmel 将它定义为1：

……一个全自动化和可再生的构建，包括测试，一天运行多次。这使得每个开发人员可以进行每日集成，这样可以减少集成问题。

要举例说明持续集成实际上新的事物，在Grady Booch的应用程序的面向对象分析和设计2一书的第二版中给出了一个一般定义：

面向对象开发的宏过程是一种“持续集成”...按照定期的间隔，“持续集成”过程产生可执行的发布版本，每个发布版本都增加功能...正是通过这些里程碑，管理可以度量进度和质量，因此可以预见、确定风险，并且然后积极地将风险系在一个正在进行的基础上。

对于我来说，也许一个关于持续集成的更切实和完整的定义是:

1、一个团队所有成员的中央储存库，包括

最新的代码（至少）

最新的可执行程序

2、一个自动化的构建和测试所有项目资产的过程：

一天可以运行多次

自己是足够的

最好是将持续集成认为是一种意识思维和描述，使你通过频繁地集成增量的软件开发变更以减少风险。基本上，它代表了一种通用软件开发最佳实践的实现和改进：每日构建和冒烟测试。

环境中的持续集成

通常，你可以将三种构建配置类型应用到任何系统或应用程序上，如下面的图1所示。

图1：三种系统构建的类型

私有构建是由开发人员个人在他们自己的工作区中手工执行的，以对他们正在开发的组件进行构建和单元测试。集成构建是由集成员在一个集中工作区执行的，通常是手工的。在持续集成中，要促进频繁的变更集成，构建有必要是自动的，并且是由工具来执行的(例如CruiseControl) 。3 通常，持续集成构建的结果并不部署到顾客或产品环境中；相反，要手工执行一个额外的发布构建，并且要十分小心。例如，发布构建通常是必须的，你可以准确地到构建的输入（例如变更请求，故障），并且在一个单独的受控环境（例如，一个单独的工作区）中执行构建。这使你能在同一时间继续集成构建，并为了审计和追踪的目的，记录发布构建的准确内容。

构建过程通常有许多阶段（参见图2），可以无缝地执行，但是有多个目标。在开始时，通常有一些构建的输入规格说明表，来确定必须被构建的范围（持续集成假定所有输入－－或所有被检入的文件－－将被构建）。接着，有一些脚本表单，确定构建输入如何被合并在一起以产生所期望的输出。一般的例子是用于Make的makefile 和用于Ant的build.xml。然后执行这个构建脚本，手动的或者自动的。最终，构建结果被报告出来，通过一个简单的日志文件或者一个更详细的机制。很明显，任何构建过程也需要一个在其中运行的环境。这通常是支持软件配置管理（SCM）环境，其提供软件版本、基线和跟踪。

图2：构建过程中的阶段

通常，这些阶段中的每一个都是被一个工具或工具组合实现的。图2显示了用于Java领域的一个普通的工作集。

用CruiseControl实现持续集成

为完成持续集成，你需要一些工具，包括一个软件配置管理工具，例如Rational ClearCase；一个构建工具，例如 Ant, Make, ClearCase clearmake4，定制构建脚本，自定义工作版本脚本, 或类似的；和一些自动化执行并报告你的构建结果的工具。达成此目的的一个通常的工具是CruiseControl。一个典型的CruiseControl实施的基本结构如下面的图3所示。

图3：一个典型的CruiseControl实施的基本结构

图3显示了许多实体：

开发人员桌面，开发人员在那里修改代码。

SCM储存库，存放团队的公共变化。

集成构建服务器，包含CruiseControl 应用程序和工作版本执行的地方。

开发应用程序或Web服务器，如果被开发的应用程序能够被部署到一个Web服务器或运行时容器。

CruiseControl缺省情况下遵循的过程是监测SCM储存库的变化；用Rational ClearCase时，它检查一个分支或一个流（通常是项目的集成流）上的check-in。如果发现变动，然后按照一个日程表，CruiseControl通过你已有的Ant或Maven脚本来构建你的应用程序，运行你的JUnit测试集，并报告你构建的结果。它可以通过电子邮件将这些结果自动地发送到一组用户那里，并且/或者将这些结果集中放在一个构建结果Web站点上。CruiseControl也可以部署你的应用程序，并且执行任何其它的你所需要的脚本化任务。

图4：带有CruiseControl构建结果的电子邮件

CruiseControl配置是通过一个重要的XML文件，通常是config.xml，5还有其它内容，让你来确定你的构建进度表－－这可能是持续集成中最重要的定义。本来，你必须回答个问题，“我要等多久才能得到集成错误的通知？”没有预定义的进度表；你需要找到最适合你的“项目节奏”，这是基于你的构建要花费多长时间，开发人员多久提交一次，等等。持续集成可以预定一天构建多次，每二十分钟，每个小时，或者每天只进行一次（作为每夜构建的一部分)。但是，用CruiseControl，如果自最近的构建以来没有检入任何文件，那么进度表通常将不会强制进行构建。

你对何时构建取得成功的定义也是重要的。何时进行编译？何时运行完所有单元测试？何时完成部署？实际上，你的标准应当是这些里程碑的一个组合；当然构建应当已经编译完并且单元测试成功执行完。然而，有了持续集成，你可以将每次失败都看作一个成功，因为它将暴露一个潜在的问题－－并且足够早地对该问题做些事情！如果你看到构建错误，那么最佳实践就是马上修复它们（通常破坏这次构建的开发人员会做这项工作）。一次被破坏的构建意味你不能成功地集成更多的开发人员的变化，一直到你修复了这些问题。

你的单元测试的质量也在持续集成中扮演着一个及其重要的角色。对于每个代码模块，你应当有测试其所有方法的一组单位测试。如果你遵循测试驱动开发的实践，那么实际上你将在开发你的代码之前开发你的测试。这个实践与持续集成组合在一起，就是非常强有力的和高效的。事实上，这是许多敏捷开发方法的支柱。

用IBM Rational ClearCase 和 IBM Rational ClearQuest 实现持续集成

在IBM Rational SCM 工具集给你提供了许多种不同的方式来实现持续集成。例如，IBM Rational ClearCase中的统一变更管理（UCM）功能可以进行配置，为你的集成和发布构建使用不同的流。要完成这项工作，使用你的缺省项目集成流来执行CruiseControl集成构建，然后创建一个集成流的子流作为你的发布流（如图5中的RatlBank_Rel流)。然后发布流可以通过变基到一个作为成功的CruiseControl集成构建结果的基线，被进行“播种”。要隔离集成构建过程，你应当也在集成流上创建一个特定的Rational ClearCase视图，单独用于执行持续集成构建。

图5：UCM流层次

为每个开发人员或开发组提供一个流是UCM中的一个标准实践。这使得开发人员可以进行隔离工作，接着再执行一个UCM变基和交付－－产生一个可控的集成过程。然而，这个过程产生以下假想：

总是有一个要变基的集成基线。由于一天要执行多次构建，对持续集成这实际上不可能是真的。

开发人员总能够成功地合并并在集成流中提交他们的变化，而不被其他开发人员的交付所影响。6使用持续集成，交付之间产生冲突的可能性更大。

构建和单元测试能够在开发人员的环境中迅速地和完全地运行。然而，如果一个完全的单元测试集要花一个小时运行呢？或者如果有些测试要求开发人员要首先把应用程序部署到一个Web或应用服务器环境中呢？

这就到了CruiseControl的自动化构建、测试和部署能力。要使持续集成能够进行，开发人员可以使用UCM功能快速地变基并交付到集成区域，可能要执行一些快速测试。然后，如果他们正在使用CruiseControl，他们可以与开发一起进行，知道他们的变化将在一个计划好的构建中被全面地建立和测试－－并且任何失败会被立刻报告。

实践中的持续集成

持续集成已经被证明对于小到中型规模的项目是有价值的；只要你有一个全面的单元测试验证集，你将能够获得短集成周期的好处。对于大的项目，仍然是有用的，尽管这样的工作一定会收益于一个带有多个持续集成流的基于程序的方法，每个系统或构件都一个流。

持续集成对带有主线的开发项目也运行得很好－－这些项目包括一个单一的最新代码流，最多还有维护流和一个不定流。单个最好运行具有唯一性,主干线发展工程--包括一条唯一最新的代码渠道发展,还有维护渠道和最多的补丁渠道。这是用于大多数开源开发项目的方法。但是，当你正在并行地开发多个发布版本时，使用持续集成可能会有问题。在这些环境里，分支或流趋向于长的生存期；并且如果你需要将变化集成到多个发布版本，这可能会引起更复杂的集成问题。但是，多一些额外的思考和计划，有效地使用持续集成、CruiseControl和Rational ClearCase仍然是可能的。

一个警告：在许多持续集成项目中，开发人员错误地将变更管理视作要避免的消耗，因为等待某些变更请求被分配、分析或批准会减慢开发进程。然而，开发团队如果没有一种跟踪的机制，不仅是跟踪他们的构建中的版本，而且跟踪他们首先执行这些构建的原因，就不能有效地工作。有了UCM 的基于活动的开发模型的灵活性，你可以使用CruiseControl和IBM Rational ClearCase和ClearQuest工具的组合来自动地跟踪这些原因－－或活动－－而不用严重影响开发人员的工作效率。

总结

持续集成是一种具有实效的方法，帮助你关注这句老的格言，“及早集成，和经常集成。”当正确地完成后，持续集成可以显著地增加开发人员的工作效率，部分是通过在构建中断时立即用邮件将反馈提供给团队成员。你也可以将持续集成工具用于传统开发－－例如，实施一个自动化的每夜构建过程。你所能达到的自动化水平实际上是没有限制的。一旦你有一种自动化的构建和测试方案，你就可以自动化进行基线、报告、部署，以及你的软件构建和发布生命周期中的许多其它方面。但是，要警告的是，如果你正工作在客户的一个至关重要的发布版本构建或活动环境中，你可能想要走出你的持续集成循环，进行更贴近的检查并得到更好的控制度。正如我在本文中所描述的，这是集成构建和发布构建的本质上的区别。