介绍
持续集成是一种软件开发实践。开发人员频繁地集成各自的工作，一般至少一天一次。
每次的集成都被自动构建，测试，发现其中的问题。这样，可以迅速的解决开发过程中的很多问题，而不是等到软件开发完成之后。而软件的质量，可以在很大程度上由一次次的自动化测试得到保障。
下面介绍以下本人团队中目前的持续集成实现。
持续集成，首要的就是选择持续集成服务器。
目前比较成熟的持续集成服务器很多，例如CruiseControl，Continuum，Luntbuild…
我这边采用的是Jenkins(An extendable open source continuous integration server)
除了CI Server 外，我们还用到了svn，maven,ant,jira，fisheye。
下面详细介绍一下我们项目的实施情况。
大致情况:
源码管理方式
主干
分支1
测试分支
开发分支
分支2
测试分支
开发分支
项目有个主干。新需求开分支进行开发。容许并行需求开发。(多分枝情况)
开发分支需要建立持续集成任务，按天集成；
测试分支在完成整体开发，或者大里程碑开发后集成测试。
分支测试完成后，需要同步回主干。同步回主干前又需要先同步主干的更新
项目情况：1)需要出基础包+增量包。且增量包的文件需要核对。
2)需要出前后台包，前后台包文件有所不同
3) 需要处理升级脚本
故决定采用ant 来控制打包流程，调用maven执行项目的编译，测试工作。
开发
Jira 与 eclipse 集成。每次开发任务都关联Jira任务(bug/改进/…)。
开发人员发起code review 请求。 Review人员每次都可以在jira上找到任务对应的文件内容修改。
自动化测试
Jenkins每天跑构造任务，自动测试，生成测试报告。分发问题给各开发人员。(email/jira)
开发分支每天打包编译/发布/自动化测试，checkstyle
测试分支阶段性打包
部署环境/配置文件
部署环境涉及 SIT，UAT，生成. 软硬件部署形式都有点不同。Ant部署脚本+项目配置文件
具体流程：
1. 任务建立阶段
2. 开发阶段
2.1 开发环境：
采用Eclipse集成Jira 插件的形式，把开发与Jira任务更紧密结合起来。
(Mylyn + atlassianConnector 本文不做具体介绍)
当开发人员开始某个任务时，首先激活该任务。之后所做的所有修改，都会自动关联到该任务。
当开发完成时，提交代码，在Svn message 中加入Jira 任务ID(其实插件会自动加入该信息，开发人员不删除即可).
这样，当在Jira 上查看问题时，就可以查看到svn log(Jira需要安装svn plugin)。
任务及对应的代码自动关联。如有需要， reviewer 可以很方便的查看代码。
2.2 持续集成:
2.2.1 配置自动集成所有资源 (Jenkins 源码管理)
每次新的任务下来都会建立对应的开发分支。
1.2.2 按照国际惯例，开发最少1天集成1次。设定每天6点自动打包
1.2.3 执行具体的构建工作
构建工作很简单。
由于项目文件目录遵循了maven规范，跑check style，unit test 等只需要执行 maven site 任务就行了。
Maven 测试结束后，跑了个后续的部署脚本，把测试报告文件发布到内部的应用服务器。
其实一开始还有计划是把测试报告的内容按我们自定的负责人规则自动发布的jira上，但后来却不了了之。
感觉这个想法，，，还是不错的。
其实Jenkins的配置还是很简单，清晰的。
大多数任务都仅需配置个一下资源，Jenkins要跑的任务(例如maven脚本，或者ant脚本…)，任务之间的前后关系。
3. 测试(SIT,UAT,…)
测试环节因部署环境的不同，涉及到增量包，升级脚本及配置文件修改。
这些都主要是在ant脚本中完成。因此实现效果就是先执行maven编译，之后ant在maven编译结果的基础上，处理各种具体需求。在遇到这种特别需求时，ant还是很给力的。不过ant脚本写复杂之后，由于整个脚本是流程化的，测试起来还是很麻烦的。因此ant脚本的传参，变量定义，调用方式都是值得慢慢斟酌的。
抛开ant脚本，整体Jenkins任务却是依旧简单，清晰。
4. 交付
