什么是持续集成？Continuous Integration, CI
它是一种软件项目管理方法，依据资产库（源码，类库等）的变更自动完成编译、测试、部署和反馈。
持续集成的背景
在没有CI的情况，开发人员进行开发，测试人员测试，最后支持人员进行部署和代码的发布。
这是一种线性的开发流程，一旦测试通不过，可能最后就没办法交付产品。
有句话说得对，目前软件开发最大的难度在于：
1 确定软件的需求
2 确定软件的剩余量
无法确定软件的需求，是因为需求随着开发的落实在不断的变化。最开始用户不知道自己想要什么，你给了他一种方案，他便在这种方案基础上想象更多，于是无论提交什么产品，都不会是用户最终想要的。
无法确定软件的剩余量，是因为我们无法像造汽车一样，看到整个开发过程。也许生于的20%工作，要花费80%的时间。
持续集成采用”水滴石穿、分而治之“的思想，既然我们不能马上交付一个可用的产品，为什么不随时提供一个可以使用的产品呢。
通过上面的结构图，就可以看到CI持续集成的基本思想。
就是程序员在向版本库中提交代码后，CI持续集成服务器自动发现或者定时发现变更，依据这些源码，重新构建产品的编译、测试、审查、部署和反馈过程。
如何做到持续集成
根据上面的思想，持续集成工具需要做到下面几个功能：
1 自动构建：要求无人值守，如果人工来操作，那就没有持续集成的必要了。
2 发现版本库的变更：通过轮询或者定时，或者程序员使用命令，处罚持续集成发现版本库的变更
3 反馈机制：在出现问题时，能及时的把问题反馈给正确的人（提交者、测试者、管理者）
4 回滚：在出现问题后，拥有回滚到可交付的能力。
5 纯净的构建环境：每一次都应该把之前的环境删除干净，让每一次构建都是一个新的构建。
6 完善的集成功能：代码的测试，审查都应该做到完善。如果单纯的利用它做持续的编译，那就是大材小用了。
利用什么工具都是其次的，关键是要注意养成持续集成的习惯，软件的开发流程以及代码的编写，都应该注意CI的风格。
比如编写具有单元测试的代码，命名符合代码审查的规范等等。
另外在持续集成的时候，还需要注意：
1 为了避免每次过多出现问题的构建，开发者在提交代码的时候，最好在本地独立的构建一次。可以自行运行构建脚本，模拟构建。
2 由于数据库与编码的分离，最好把数据库相关的DDL\DML等脚本一起放入版本库中，这样CI进行构建的时候，可以连同数据库一起重新构建。
推荐的工具资料
【1】《持续集成：软件质量改进和风险降低之道》
【2】持续集成：http://www.martinfowler.com/articles/continuousIntegration.html
【3】CI持续集成工具：
Apache Continuum: http://continuum.apache.org/
CruiseControl: http://cruisecontrol.sourceforge.net/
Hudson: http://hudson-ci.org/
Jekins: http://jenkins-ci.org/
Luntbuild: http://jenkins-ci.org/
【4】构建脚本：
Ant： http://ant.apache.org/
Maven: http://maven.apache.org/
【5】测试：
JUinit
DbUnit
Floyd
HtmlUnit
JWebUnit
SQLUnit
【6】自动化审查：
CheckStyle: http://sourceforge.net/projects/eclipse-cs/files/
JavaNCSS: http://mojo.codehaus.org/javancss-maven-plugin/
JDepend: http://www.clarkware.com/software/JDepend.html
PMD: http://pmd.sourceforge.net/
Siminan: http://www.redhillconsulting.com.au/products/simian/
【7】反馈
Jabber: http://www.jabber.org/