CruiseControl入门简介

CruiseControl是一种持续集成过程的框架，包括了邮件通知，ant和各种源码控制工具的插件。并提供了web接口，用于查看当前和以前的创建的结果。下面将用CC来代表CruiseControl。

首先来安装运行一个CC自带的示例:

1.  CC下载

下载地址：http://cruisecontrol.sourceforge.net/

2.  CC安装成功后，目录结构如下

CC目录下面有一个apache-ant-1.7.0的目录，是CC所集成Ant程序。artifacts里面放了项目生成JAR文件，ect是CC内置的Jetty服务器的配置文件。lib里放了CC引用的一些库。log文件夹不用说，是CC的操作日志，在Project文件夹中，我们可以放入我们要集成的项目。Webapp文件夹是Jetty应用程序的文件夹。

3.  启动CC

双击安装目录下的cruisecontrol.bat文件，就会启动CC。CC用Jetty用为服务器，端口为8080，如果想要修改端口，可以修改etc/jetty.xml文件。

4.  CC默认的配置文件config.xml

在config.xml里，CC会每隔300秒构建一次projects文件夹下的connectfour项目。

<cruisecontrol>  <project name="connectfour">    <listeners>      <currentbuildstatus listenerfile="logs/${project.name}/status.txt"/>    </listeners>    <bootstrappers>      <antbootstrapper anthome="apache-ant-1.7.0" buildfile="projects/${project.name}/build.xml" target="clean" />    </bootstrappers>    <modificationset quietperiod="30">      <!-- touch any file in connectfour project to trigger a build -->      <filesystem folder="projects/${project.name}"/>    </modificationset>    <schedule interval="300">      <ant anthome="apache-ant-1.7.0" buildfile="projects/${project.name}/build.xml"/>    </schedule>    <log>      <merge dir="projects/${project.name}/target/test-results"/>    </log>    <publishers>      <onsuccess>        <artifacts publisherdest="artifacts/${project.name}" file="projects/${project.name}/target/${project.name}.jar"/>      </onsuccess>    </publishers>  </project></cruisecontrol>

5.  CC构建结果

我们可以通过http://localhost:8080/cruisecontrol/testresults/connectfour来查看CC的构建结果，如下图。

6.  CC帮助文档

我们可以通过http://localhost:8080/documentation/overview.html来查看CC的详细帮助文档。

接下来我们有必要研究一下CC的框架， 这对我们了解 CC 的设计原理和 CC对持续集成的支持程度很有帮助。通过前面对CC的演示，我们看看CC持续集成的几个要点。

持续集成的要点：

1.  单一代码源：CC 通过相应的插件支持对 CVS,VSS （Visual SourceSafe） ,ClearCase等各类版本控制软件的源码库的访问。

2.  自动化创建脚本：CC通过BuildLoop支持自动化创建，并通过 CC 插件支持 ant，maven 等创建工具。CC对创建的支持实际上是通过一个代理（proxy）来完成的，你可以选择 Ant,Maven这些流行的创建工具。

3.  自测试的代码：间接通过 ant 等自动化创建工具来支持对自测试的调用，但是这取决于项目自身是否提供自测试代码，CC 只是通过 ant 等工具激活对测试代码的调用。

4.  主创建：间接通过 ant 等自动化创建工具支持，要求相应的ant或者maven脚本提供了主创建任务。

5.  检入代码：属于版本控制的范畴，要求开发人员自己检入代码。

CC设计思想是one-size-fits-all，也就是CC是由一个很精小（但是很强大）的核心（Build Loop）以及一些外部插件组成，这给使用者提供了很大的扩展空间，使用者可以根据需要扩展 CC的功能（提供新的插件），而且CC是开源项目，你还可以查看源码并修改CC提供的插件。 CC提供了不同类型的插件：bootstrapper， modificationset， publisher 以及listener等。CC 的配置是围绕这些插件展开的，下面对这些插件进行一个简单的介绍：

1.  bootstrapper：在CC进行创建之前运行，是创建前的准备工作

2.  modificationset：查看源码自上一次Build之后是否被修改过

3.  publisher：用于发布创建的结果，可以通过email的方式通知开发人员。

4.  listener：用于处理一些项目有关的事件（CC2.2之后提供的新的功能）。

CC的配置文件用于build loop，默认文件名为config.xml，该文件的Builder插件部分会引用相应的build文件，如ant的build文件。关于CC配置文件的各配置项参数的详细资料，请参考官方文档： http://cruisecontrol.sourceforge.net/main/configxml.html。这里只讨论配置文件中常用的各元素之间的关系。 主配置文件config.xml的根元素是<cruisecontrol>，该元素很简单，没有什么需要配置的属性。<cruisecontrol>下支持三种元素，如下：

<cruisecontrol>  <system/>  <plugin/>  <project/></cruisecontrol> 

在这只讨论<project>元素，其他两个元素在常规的场合可以不用，目前CC支持多个项目（multiproject）， 因此可以有多个并行的<project>元素。在<project>元素下面都是跟 CC 插件有关的配置项，结构如下：

<cruisecontrol>  <project>  <plugin/>  <dateformat/>  <labelincrementer/>  <listeners/>  <bootstrappers/>  <modificationset/>  <schedule/>  <log/>  <publishers/>  </project></cruisecontrol>

下面对其中几个常用的元素的意义和用法进行详细的讲解。

1. <bootstrappers>

<bootstrappers>的子元素就是Bootstrapper插件的配置信息，<bootstrappers>在创建之前运行，这个前面我们已经讲过了，<bootstrappers>下面的每一个子元素都是相互独立的，因此可以同时配置有多个bootstrapper。

CC提供的bootstrapper包括了两个种类，一种用于向其他插件提供项目当前创建的状态，还有一种是从某个源码控制系统更新本地文件，其中最常用到的bootstrapper是<currentbuildstatusbootstrapper>和<svnbootstrappers>如果读者使用Visual SourceSafe或者 ClearCase，那么这里应该分别使用<vssbootstrappers>或<clearcasebootstrappers>）。

前者<currentbuildstatusbootstrapper>指定了状态文件的位置，主要是用来访问项目当前创建的状态，CC的<currentbuildstatuspublisher>会将创建的状态写入这个文件。顺带讲一下<currentbuildstatusftpbootstrapper> ，其作用跟<currentbuildstatusbootstrapper>完全一样，不同的是状态文件保存在一个FTP上。

后者<svnbootstrapper>的作用有点难理解，因为我们每次项目的创建都应该基于最新的代码，因此在创建之前就要获得最新的项目文件，如果你使用的是ant，这个工作是由ant的buildfile来完成的，如果这个buildfile本身在创建开始之前发生了变化，我们是不是应该先更新这个buildfile，然后才通过buildfile来对项目进行创建呢？<svnbootstrapper>就是为从源码控制系统更新buildfile文件而设计的。

 <bootstrappers>应用举例：

<bootstrappers>   <svnbootstrapper localworkingcopy="projects/${project.name}" /></bootstrappers>

2. <modificationset>

<modificationset>包括了SourceControl 插件的配置信息，用于检查各个源码控制系统中是否发生变化，<schedule>会用到这里面的配置信息，如果检测到变化，会触发创建过程。

<modificationset>的属性 quietperiod（单位为秒）定义了一个时间值。如果CC检查到了变化，会自检查到变化的源码控制系统的最后一次 check in 的时间开始等待，等待的时间由quietperiod决定，等待结束之后才触发创建（build）过程，主要是防止有人在check in的过 程当中就触发创建过程（可能check in只做了一半, 这个时候触发创建显然是不正确的）。

下面给一个svn的例子：

<modificationset quietperiod="30">  <svn localworkingcopy="projects/${project.name}"/></modificationset>

3. <schedule>

 <schedule >指定了创建的时间间隔，新的版本已经支持定义某个具体时间触发创建，这个新的特征是为了满足Nightly build 的需要。

<schedule>定时驱动<modificationset>，如果检测到变化，就执行所指定的builder的任务。 例子：

<schedule interval="300">  <ant anthome="apache-ant-1.7.0" buildfile="projects/${project.name}/build.xml" target="make"/></schedule> 

4. <log>

<log >指定项目日志保存的地点，主要是合并项目创建过程 junit 测试结果的报表文件(xml)。<log>的用法很简单，通常是指定CC的合并日志的目录就可以了，例如：

<log>    <merge dir="projects/${project.name}/target/test-results"/></log> 

5. <publishers>

<publishers>的子元素包括了Publisher插件的配置信息在build loop结束之后将运行 Publishers，无论 build 是成功还是失败，都会运行publisher，发布build的结果。

<publishers>下面最常用的publisher插件是<currentbuildstatuspublisher>， <email>和<artifactspublisher>。

<currentbuildstatuspublisher>的主要作用是用来显示build loop的结果，包括了编译信息，JUnit测试结果信息，以及谁做了变更的信息。该插件和<currentstatusbootstrapper>插件访问的文件是同一个文件。

而<email>主要是用来通知使用者。最常用的用法是根据不同的结果发送到不同的邮件列表，如每次build，无论成功失败都发送给某个邮件列表，还有失败的时候才发送的邮件列表。

<artifactspublisher>用于对创建过程中产生的人工制品进行发布。当CC启动ant build时，ant是作为独立的java进程被调用的，ant的关键文件为build.xml。

参考资料：

http://wenku.baidu.com/view/3adee161caaedd3383c4d359.html

http://wenku.baidu.com/view/4630d4d233d4b14e852468bd.html