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
关键代码如下：
|
</exec>
srcFile="${infofile}"/>
<echo message="${run-info}"/>
<!–
<contains string="${run-info}" substring="BUILD
</not>
</condition>
<fail unless="run-success"
message="${run-info}"/> |
此构建文件有以下注意事项：
–>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 target="deploy -Dscmurl=http://xxxxxx/xxxx/xxxx
</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
：
|
|
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
</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
</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 |
返回结果：
|
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 #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
中引入插件方可使用，具体代码如下：
|
<!–
<copy srcUrl="${scm.srcurl}"
destUrl="${scm.desturl}" |
其中，
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
Cruise自V1.3之后，在免费版中支持无限多个本地agent(即与Cruise Server安装在同一台机器上)。
Cruise is very useful for Agile development.