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

最新推荐文章于 2024-09-18 17:04:07 发布

糖醋鼻子

最新推荐文章于 2024-09-18 17:04:07 发布

阅读量1.7k

点赞数

分类专栏：持续集成文章标签： maven ant thoughtworks 任务持续集成系统 build

本文链接：https://blog.csdn.net/zhmnsw/article/details/4588947

版权

持续集成专栏收录该内容

5 篇文章 0 订阅

订阅专栏

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

*******************

-->

<arg line=" ${m2.target} -Dpversion=${build.version}

"/>

</exec>

<loadfile property="run-info"

srcFile="${infofile}"/>

<not>

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

<jobs>

<tasks>

</tasks>

</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>

</target>

<!--

*******************

刷新版本号

*******************

-->

</java>

</target>

Cruise setup ：

<jobs>

<tasks>

</tasks>

</job>

</jobs>

</stage>

<jobs>

<tasks>

</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 。