Cruise+ANT+maven2搭建持续集成环境

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

 

标签:
文章分类 FK Coding
2 条评论在 “Cruise+ANT+maven2搭建持续集成环境” 上
  1. tony1130 说道:

    Cruise自V1.3之后,在免费版中支持无限多个本地agent(即与Cruise Server安装在同一台机器上)。

  2. lieberstraum 说道:

    Cruise is very useful for Agile development.

lieberstraum 进行回复 取消回复

电子邮件地址不会被公开。 必填项已用 * 标注

*

您可以使用这些 HTML 标签和属性: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

点赞
如果您觉得很赞,我将非常乐意接受虚拟币的捐赠,以示您对我的肯定。

比特币钱包地址:
1PqpqA8FyH3NbfCrbcRd1YxQk3LEsSEYDV
莱特币钱包地址:
LRTdmovGGVEHCKWz7JdL9aiB7VZkuNycJf
站点勋章
网站统计