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 关键代码如下:

       

       
              
              
        

              
              
        
              

      
         
       
         
    

  
        

此构建文件有以下注意事项:

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 的完整代码如下:


  
    
      
        
        
        
        
      
      
        
        
      
    
  

 

版本号管理

到此我们已经成功将 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

  
    
    
      
        
          
          
        
      
    
  
  
    
    
      
        
          
          
        
      
    
  

 

到此貌似有个问题, 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 中引入插件方可使用,具体代码如下:

	
	
	
	
    
	

	
    
			
	
	
	

 

其中, 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

 

你可能感兴趣的:(Ant,SVN,配置管理,maven,Ubuntu)