CruiseControl简介:
CruiseControl 是 CI 服务器的老者，诞生已是多年，在许多方面， CruiseControl 服务器已经成为持续集成实践的同义词。而现在， CruiseControl 已发展成为一个家族式系统，包括 CruiseControl.java 、 CruiseControl.net 、 CruiseControl.ruby 等适应不同语言环境的实现，其强大的插件和扩展能力也是诸多同类系统无法比你的。而在这里，我只介绍该家族的本家 CruiseControl.java ，即 CruiseControl 。
[img]
[/img]
从上图可以看出，CC主要包括了三个组件：
A、Build Loop组件：主要负责根据外部的xml配置，定时、周期性的根据外部SCM的状态启动构建任务，并将构建结果通过Email/IM/RSS等方式通知到相应的客户端。
B、JSP的报告组件：提供了一个web页面供我们查看构建结果以及每次构建发布的工件。
C、Dashboard组件：提供了一个可视化的界面，让我们可以清楚的看到各个项目的构建状态 。
工具的官方网站：http://cruisecontrol.sourceforge.net/
持续集成(CI)其实是由一系列的最佳实践所构成：
.源代码的版本控制和管理
- 自动化构建
- 自动化测试
- 代码审查
- 自动发行和部署
- 持续反馈
使用持续集成的作用：
持续集成（CI）是一种实践，可以让团队在持续的基础 上收到反馈并进行改进，不必等到开发周期后期才寻找和修复缺陷。诸如 CruiseControl 之类的检查工具是在后台运行的，它们轮询版本控制存储库，从中寻找更改之处。当发现某一更改时，这类工具就会通过 Ant 执行预定义的构建脚本。持续检查借助持续集成的实践得以改进。
持续集成周期包括以下几个步骤：
1. 持续集成服务器不断从版本控制服务器上检查代码状态，看代码是否有更新。
2. 如果发现代码有最新的提交，那么就从版本控制服务器下载最新的代码。
3. 等代码完全更新以后，调用自动化编译脚本，进行代码编译。
4. 运行所有的自动化测试。
5. 进行代码分析。
6. 产生可执行的软件，能够提供给测试人员进行测试。
CI的概念:
在没有应用持续集成之前，传统的开发模式是项目一开始就划分模块，然后等所有的代码都
开发完成之后再集成到一起进行测试，随着软件技术的发展，各种软件方法百花齐放，软件
规模也在扩大，软件需求越来越复杂，软件已经不能简单地通过划分模块的方式来开发，需
要项目内部互相合作，划 分模块这种传统的模式的弊端也越来越明显，由于很多 bug在项目
的早期就存在，到最后集成的时候才发现问题，开发者需要在集成阶段花费大量的时间来寻
找 bug 的根源，加上软件的复杂性，问题的根源很难定位，甚至出现不得不调整底层架构的
情况，在这个阶段的除虫会议（bug meetings）特别多，会议的内容基本上都是讨论 bug 是
怎么产生的，最后往往发展成为不同模块的负责人互相推诿责任。
持续集成最大的优点是可以避免这种传统模式在集成阶段的除虫会议。持 续集成主张项目的
开发人员频繁的将他们对源码的修改提交(check in)到一个单一的源码库，并 验证这些改变是
否对项目带来了破坏，持续集成包括以下几大要点：
1 访问单一源码库，将所有的源代码保存在单一的地点（源码控制系统）， 让所有人都能
从这里获取最新的源代码（以及以前的版本）。
2 支持自动化创建脚本，使 创建过程完全自动化，让任何人都可以只输入一条命令就完成
系统的创建。
3 测试完全自动化，要求开发人员提供自测试的代码，让 任何人都可以只输入一条命令就
运行一套完整的系统测试。
4 提供主创建，让任何人都可以只输入一条命令就可以开始主创建。
5 提倡开发人员频繁的提交（check in）修改过的代码。
持续集成的关键是完全的自动化，读取源代码、编译、连接、测试，整个创建过程都应该自
动完成。对于一次成功的创建，要求在这个自动化过程中的每一步都不能出错，而最重要的
一步是测试，只有最后通过测试的创建才是成功的创建。
在持续集成里面创建不再只是传统的编译和连接那么简单，创建还应该包括自测试，自测试
的代码是开发人员提交源码的时候同时提交的，是针对源码的单元测试（源自 XP 的实践），
将所有的这些自测试代码整合到一起形成测试集，在 所有的最新的源码通过编译和连接之后
还必须通过这个测试集的测试才算是成功的创建。这 种测试的主要目的是为了验证创建的正
确性，M cConnell称之为“冒烟测试”，在 持续集成里面，这 叫做集成验收测试Build Verify Test，
简称 BVT。BVT 测试是质量的基础，QA 小组不会感受到 BVT 的存在，他们只针对成功的
创建进行测试（如功能测试）。
BVT 测试应该尽量的详尽，详尽的测试才能发现更多的问题，而由此得到的反馈结果也更
有参考意义，测试应该全部执行完毕，这样得到的反馈结果才是完整的，而不是遇到错误就
放弃测试过程。
持续集成和日创建相比还有以下特点：
1 持续集成强调了集成频率，和日创建相比，持续集成显得更加频繁，目前推荐的最佳实
践是每一个小时就集成一次。
2 持续集成强调及时反馈，日创建的目的是得到一个可以使用的稳定的发布版本，而持续
集成强调的是集成失败之后向开发人员提供快速的反馈，当 然成功创建的结果也是得到
稳定的版本。
3 日创建并没有强调开发人员提交（check in）源码的频率，而持续集成鼓励并支持开发
人员尽快的提交对源码的修改并得到尽快的反馈。
从上面列出的续集成和日创建相比的特点来看，很明显，“ 频率”和“反馈”这两个词出现
的特别多，持 续集成有一个与直觉相悖的基本要点，那 就是“ 经常性的集成比偶尔集成要好”。
Martin Fowler 认为对于持续集成来说，集成越频繁，效果越好 ，如果你的集成不是经常进
行的（少于每天一次），那么集成就是一件痛苦的事情，如果集成偶尔才进行一次（一周甚
至一个月）， 等到集成阶段发现bug，然后找原因解决bug，会耗费你大量的时间与精力，而
且这种方式有点象传统的集成模式，这违背了持续集成的初衷。
根据 Martin Fowler 的观点，项目 bug 的增加和时间并不是线性增长的关系，而是和时间的
平方成正比，两次集成间隔的时间越长，bug 增加的数量越超过你的预期，解决 bug 付出的
工作量也越大，而你越觉得付出的工作量越大，你就越想推迟到以后去集成，企图到最后一
次性解决问题，结果 bug 产生的就更多，导致下一次集成的工作量更大，你越感觉到集成的
痛苦，就越将集成的时间推后，最后形成恶性循环。
因此如果集成的结果是让你感到痛苦，也许就说明你应该更频繁地进行集成。频繁的集成和
及时的反馈鞭策着项目小组积极的面对问题，而 不是将问题推到最后来解决，如 果方法正确，
更频繁的集成应该能减少你的痛苦，让你节约大量时间。
因为持续集成最终是通过测试来验证创建，所以你会发现对于持续集成的频率的要求跟
Kent Beck 提出的测试驱动的开发方法里面测试第一的理念完全一致。
需要注意的是从项目的一开始就引入持续集成可以尽早的发现 bug，但是并不代表持续集成
可以帮你你抓到所有的 bug。持续集成的排错能力取决于测试技术，众所周知，无法证明已
经经过测试的代码就已经找到了所有的错误。
前面列举了持续集成这么多优点，但是创建一个持续集成的环境技术上是比较复杂的，也需
要一定的时间，关键是在于持续集成可以“及时”抓到足够多的 bug，从根本上消除传统模
式的弊端，这就已经值回它的开销了
二：CruiseControl持续集成环境的配置安装
第一步：
A、从上面的官方网站下载最新的稳定版本，当前最新的稳定版本为2.8.4
B、下载JAVA安装包
第二步：解压下载的工具包（由于CC是绿色版的，所以解压即可不需安装），并在你的环境变量中增加两个环境变量
A、JAVA_HOME设置为你的JAVA安装目录
B、设置ANT_HOME为CC解压目录下的apache-ant-1.7.0目录，并且将“你的下载目录\cruisecontrol-bin-2.8.4\apache-ant-1.7.0\bin”加入你的path路径中
这样我们就可以在命令行直接调试ant脚本）
第三步：直接运行CC解压目录下的cruisecontrol.bat即可 修改访问端口在cruisecontrol.bat倒数第三行
修改参数:-webport 8080
第四步：在你的浏览器地址栏输入：http://localhost:8080/dashboard/tab/dashboard ，如果出现下面的界面表示安装成功
第三：如何搭建自己的构建项目
第一步：熟悉CC的目录结构
在上面粉红色的方框中，我们大部分时间只需要配置一下文件即可：
1、confile.xml文件 -------所有项目的信息配置，包含了你的SCM以及发布信息等等
2、cruisecontrol.bat -------启动CC工具
3、apache-ant-1.7.0文件夹 -----这里存放了ant工具所有内容，包括lib
4、artifacts文件夹 -----存放了每次构建发布的工件，以项目进行区分
5、etc文件夹 -----存放了工具的配置，包括jetty容器、数据库连接配置等
6、lib文件夹 -----存放了所有CC依赖的lib库
7、log文件夹 -----存放了所有日志信息
8、projects文件夹 ------存放了你的构建项目的描述信息，构建自己的项目需要在这里面配置
9、webapps文件夹 ------存放了CC的WEB部署，如果你想定制自己的界面，就需要在这里配置，如上图的TestAnalusis的Tab就是我定制的一个页面
第二步：熟悉总的项目文件的配置config.xml
第三步：熟悉每个项目的Build.xml的编译控制
CI相关资料网站:
部署自动化:http://www.ibm.com/developerworks/cn/java/j-ap02109/
Ci服务器搭建:http://www.cnblogs.com/kenkofox/archive/2010/10/13/1850600.html
WEBLOGIC自动化部署:http://edocs.weblogicfans.net/wls/docs92/programming/index.html
CC整合插件:http://confluence.public.thoughtworks.org/display/CC/Home
CI中文PDF：http://www.xiaxin.net/blog/OpenDoc-CruiseControl.pdf
CC的CONFIG文件属性说明：http://cruisecontrol.sourceforge.net/main/configxml.html#starteam