Cruise 简介
Cruise 是 ThoughtWorks 推出的持续集成系统，它秉承了 CruiseControl 的优秀品质，同时加入了管线阶段、分布式集成等特性，让整个自动化环境更加合理智能。
当然，对于该系统更详细的介绍，各位可参考 ThoughtWorks 工程师 tony1130 的博客： http://blog.csdn.net/tony1130 。
安装
Cruise 的安装非常简单，只需要在其官网： http://studios.thoughtworks.com/cruise-release-management ，下载最新版本的安装文件，并在对应的系统上安装即可。
Cruise 运行环境分为 server 和 agent 两部分，前者是持续集成管控系统，后者则是具体运行 job （即任务）的任务节点系统，两者是一对多关系，即一个 server 可以同时管理多个 agent （可通过网络进行分布式管理）。
Cruise 为小型团队提供免费版，此版本的 server 和agent只能运行在同一主机上，agent不限数量 ，不过对于小团队来说已经足够了。
运行
Cruise 的 server 和 agent 安装完毕后会自动成为系统级服务， server 会自动寻找 agent 并进行管理。
默认打开 http://localhost:8153 即可看到 server 的主界面，如图：
管线概念
与 CruiseControl 单个工程的概念不同， Cruise 使用了管线、阶段、 job 分级的方式来管理集成。
所谓管线（ pipeline ），就是 CruiseControl 中的一个工程，它指向一个版本控制系统（ SCM ）工程库，并监测其中的变更。
一个管线会分多个串行的阶段（ stage ），即按顺序执行的阶段，每个阶段执行完毕，下一个阶段才能执行。
为了支持分布式集成，每个阶段又可以分为多个任务（ job ），任务之间是并行的，可以分发给相应的 agent 独立执行，但必须所有任务全部通过之后，该阶段才能通过。
每个任务是由多个自动化脚本组成，可以是 ant 、 maven… 也可以是命令行工具。
下图中显示了 build 、 test 、 deploy 、 candidate 、 release 五个阶段：
配置
Cruise 的配置是基于 XML 的，我们可以使用它提供的管理界面，创建一个简单的 pipeline ，当然也可以直接编辑配置文件，获得更大的灵活性，下图为配置文件编辑界面：
ANT 和 Maven2 双剑合璧
Cruise 的任务（ job ）是通过调用自动化脚本完成的，它本身并不具备实际的逻辑执行能力，而提到自动化脚本，我们自然会想到 ANT 以及 maven2 两大自动化构建工具。
ANT 被称为万金油一点不为过，它除了提供丰富的插件之外，还能够自由与命令行工具结合，这就使得它几乎适用于任何自动化环境，它应该是我们用于管理软件发布最常用的工具了。详细资料请参考： http://ant.apache.org/ 或《 ant 权威指南》
Maven2 是自动化构建工具的后起之秀，它更注重于软件生命周期的管理，其内部定义了一整套的从构建、测试到部署发布的 goal （ goal 表示了软件生命周期的一个阶段，类似于 Cruise 的 stage ）用于模板化管理。详细资料请参考： http://blog.csdn.net/wind5shy/archive/2007/10/18/1830826.aspx
一般来说，我们只需要选择一种工具就可以方便的管理我们的软件生命周期，但是一种工具必然有其利弊： ANT 虽然灵活强大，但它的脚本比较复杂，且不能自动管理依赖； Maven2 定义了一套现成的模板和具有很好的依赖管理功能，但它不能自己定义 goal ，且无法从文件中读取属性定义，其灵活程度大打折扣。
那既然如此，将两个工具的优势结合到一起，不就可以扬长避短了吗？哈哈，说干就干。
由 ANT 定义阶段和读取文件中的属性参数（还好 Maven2 支持命令行参数），之后将软件生命周期的工作交给 Maven2 来执行。
其 build.xml 关键代码如下：
| ******************* 启动 maven ******************* --> <target name="maven-run"> <exec executable="${m2.path}" output="${infofile}" dir="."> <arg line=" ${m2.target} -Dpversion=${build.version} "/> </exec> <!-- 判断运行是否成功 --> <loadfile property="run-info" srcFile="${infofile}"/> <echo message="${run-info}"/> <condition property="run-success"> <!-- 没有关键字 "BUILD FAILURE" 即为成功 --> <not> <contains string="${run-info}" substring="BUILD FAILURE"/> </not> </condition> <fail unless="run-success" message="${run-info}"/> </target> |
此构建文件有以下注意事项：
1、 ANT 没有集成 Maven2 的调用任务插件，因此应该使用 exec 命令，但 exec 命令必须使用绝对路径调用程序，那么当任务运行在不同环境的 agent 上时，就无法使用统一的绝对路径（比如 windows 和 linux 的路径格式无法兼容），所以，在此使用了 ${m2.target} 变量来表示 Maven2 所在的绝对路径，该变量从系统的环境变量中读取。
2、 使用 -D 向 Maven2 传递参数时，尽量避开内置属性名称
3、 Maven2 执行完毕之后如成功则打印 BUILD SUCCESSFUL ，而 ANT 也会返回这样的关键字（此关键字常被作为构建成功的条件），那么为了让其不扰乱程序集成系统的判断，就必须使用 BUILD FAILURE 关键字来判断（即只要存在此关键字就代表构建过程失败）。
把这个 target 作为子 target ，就可以复用在多个 ANT 阶段中了。
最后，在 Cruise 中配置 ANT 任务，就完成了整个持续集成环境的搭建。其一个 stage 的完整代码如下：
| <stage name="deploy"> <jobs> <job name="ubuntu_deploy"> <tasks> <!-- 清理构建环境 --> <exec command="mvn" args="clean" /> <!-- 调用 ANT 脚本，执行自动化任务 --> <ant target="deploy -Dscmurl=http://xxxxxx/xxxx/xxxx -Dscm.username=xx -Dscm.password=xx" /> </tasks> <artifacts> <!-- 将打包文件归档到服务器 --> <artifact src="target/*.war" /> </artifacts> </job> </jobs> </stage> |
版本号管理
到此我们已经成功将 Cruise 、 ANT 、 Maven2 连接在一起，能够自动进行软件的集成和发布，但是似乎还有一个重复性的工作没有纳入到自动化环境中（重复浪费是自动化理念无法忍受的事情，所以 … ）。
一般的，我们习惯使用 4 段版本号方式来标识软件，即 x.y.z.p ， x 代表产品号， y 代表发布号， z 代表修正号， p 代表构建号（即构建次数），而我们内部管理的里程碑还有一个修订号，以方便跟踪版本库的代码，那么一般的版本号会是这种形式： 1.0.22 .342-r1232 。
我们会在每次提交代码的时候让版本库中的 revision 号加 1 ，每次构建完毕会让构建号加 1 ；每个相对稳定的候选版本则需要提取交给 QA 组测试，测试通过之后发布给用户，且修正号加 1 ；而对于功能性的变更，则需要发布号加 1 ；一个新的产品版本会让产品号加 1 。
那么对于版本号的管理似乎也是一个劳心费神的工作，料想我们不会每次在做版本变更的时候都去 check in 你的配置文件，那样的话，浪费时间不说，还很容易出错。
那既然这样，我们完全可以把工作交给持续集成环境来做，当然产品号一般是分支的号码，只需要手动管理即可，我们使用持续集成环境管理修订号、构建号、修正号、发布号。
Cruise 提供了版本库修订号 CRUISE_REVISION 和构建次数 CRUISE_PIPELINE_LABEL 两个参数，修订号和构建号搞定了；而其又为 stage 的执行提供了手动功能，那样的话我们就可以创建两个手动 stage ，每当需要发布的时候，手动运行相应的 stage ，让版本号自动变更。具体方法如下：
修订号和构建号由 CRUISE_REVISION 和 CRUISE_PIPELINE_LABEL 两个参数提供，在 ANT 中引用即可。
创建两个手动的 stage ，一个命名为 candidate ，用于发布一个修正版（即仅修正号增加）；一个命名为 release ，用于发布一个发布版（发布号增加，修正号归零）。
ANT 脚本中增加对应的两个 target ，用于刷新版本号和调用 Maven2 的 package 任务。
具体配置代码如下：
Build.xml ：
| <!— 修正版本 --> <target name="candidate" depends="init"> <property name="build.type" value="candidate"/> <antcall target="refresh"/> <property file="${versionfile}"/> <property name="build.version" value="${product.number}.${release.number}.${candidate.number}.${build.number}-RC"/> <property name="m2.target" value="package -DskipTests"/> <antcall target="maven-run"/> <antcall target="tag"/> </target> <!-- 发布版本 --> <target name="release" depends="init"> <property name="build.type" value="release"/> <antcall target="refresh"/> <property file="${versionfile}"/> <property name="build.version" value="${product.number}.${release.number}.${candidate.number}.${build.number}-release"/> <property name="m2.target" value="package -DskipTests"/> <antcall target="maven-run"/> <antcall target="tag"/> </target> <!-- ＝＝＝＝＝＝＝＝＝＝＝＝子过程＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝ --> <!-- ******************* 刷新版本号 ******************* --> <target name="refresh"> <java jar="${buildnumber.path}" fork="true"> <arg value="${versionfile}"/> <arg value="${build.type}"/> </java> </target> |
Cruise setup ：
| <stage name="candidate"> <approval type="manual" /> <jobs> <job name="ubuntu_candidate"> <tasks> <exec command="mvn" args="clean" /> <ant target="candidate -Dscmurl=http:// xxx/xxx/xxx -Dscm.username= xxx -Dscm.password=xxx" /> </tasks> </job> </jobs> </stage> <stage name="release"> <approval type="manual" /> <jobs> <job name="ubuntu_release"> <tasks> <exec command="mvn" args="clean" /> <ant target="release -Dscmurl=http:// xxx/xxx/xxx -Dscm.username= xxx -Dscm.password=xxx" /> </tasks> </job> </jobs> </stage> |
到此貌似有个问题， ANT 只有一个 build.number 的机制，即在一个文件中记录任务执行的次数，但是这个参数无法被重命名，所以在导入到执行环境时，只能保留一个参数值，无法做到多级的版本自增逻辑。
而 Cruise 和 Maven2 都没有此机制，看来，只能自己动手丰衣足食了。
抄起吃饭的家伙，花了一顿饭功夫搞定了个小小的 jar 包―― buildnumber ，专门用于多级版本号管理，既然 ANT 原生支持 java ，那么用它刷新版本号就易如反掌了，其实，这就是 build.xml 中名为 refresh 的子过程。
Buildnumber 从命令行读取参数，第一个为版本号存储的文件，这是一个标准的 properties 文本文件，默认是运行目录下的 version.properties ，如果文件不存在，则自动创建，初始号码均为 0 ；第二个是需要变更的版本号，支持 build （构建号）、 candidate （修正号）、 release （发布号）、 product （产品号），默认是 build 。
命令行（ buildnumber 需要在 classpath 中）：
| java –jar buildnumber.jar my.properties release |
返回结果：
| update successful! new version is product.number: 0 release.number: 1 candidate.number: 0 build.number: 0 |
my.properties ：
| #Auto generate by BuildNumber, don't edit it. #Thu Sep 24 15:14:43 CST 2009 build.number=0 product.number=0 candidate.number=0 release.number=1 |
将此文件放到一个不会被轻易变更的目录，并用系统环境变量引入 ANT （例子中使用了 VERSION_REPO 环境变量），就可以让 ANT 具备分级版本号自增功能啦，每执行一次 refresh ，那么指定的 build.type 对应的版本号就会自增。
自动 Tag
通常，对于代码的管理是基于 SCM 版本库的，所以，每次发布都在 SCM 中创建标记（ tag ）也是用于跟踪代码的一个重要工作。
当然，对于 ANT 来说，自动打 tag 那是小菜一碟，只需要调用 svn 插件的 copy 命令即可。
svn 的 ANT 插件没有集成在标准包中，所以需要自行下载，并解压至 ANT_HOME/lib 中，并在 build.xml 中引入插件方可使用，具体代码如下：
| <!-- ******************* 在 svn 上打 tag ******************* --> <target name="tag"> <property name="scm.srcurl" value="${scmurl}/trunk"/> <property name="scm.desturl" value="${scmurl}/tags/${build.version}"/> <!-- 引入 svn 插件 --> <taskdef name="svn" classname="org.tigris.subversion.svnant.SvnTask" /> <svn username="${scm.username}" password="${scm.password}"> <copy srcUrl="${scm.srcurl}" destUrl="${scm.desturl}" message="Tag created by cruise on ${TODAY}" /> </svn> <echo message="new tag is ${build.version}"/> <echo message="success create tag at ${scm.desturl}"/> </target> |
其中， scmurl 、 scm.username 、 scm.password 等变量是由 Cruise 的 exec 标签传入的参数。
这样就可以在每次 deploy 、 candidate 、 release 之后，在 SCM 上创建 tag 了。
附
示例完整的 Cruise 配置、 build.xml 、 pom.xml ： http://download.qihangsoft.net/cruise_config.zip
buildnumber 及其源码： http://download.qihangsoft.net/BuildNumber.zip
Maven2 完全使用手册： http://blog.csdn.net/wind5shy/archive/2007/10/18/1830826.aspx
ANT 入门教程： http://www.java3z.com/cwbwebhome/article/article2/2764.html?id=1271
tony1130 博客： http://blog.csdn.net/tony1130