CI(Continuous Integration)具体实施方式依赖于项目的开发流程，而CI以自身的一些特点（如，自动化，快速，周期性，定时性等）在敏捷的开发流程(如scrum)中似乎更能体现其价值。本文便是建立在这样的一个项目基础之上的。
项目背景：
- 敏捷的开发流程，3到4周为一个sprint，正常的提交是以sprint为周期的，不排除因其它原因而要求3天内提交。
- 项目多分支——mainline，sandbox，release x...
- mainline为每个sprint的提交分支
- sandbox为开发分支，是开发人员的workspace，会不定时将代码同步至mainline分支
- release为发布分支，是项目发布包到产品测试环境源代码分支。在此分支上只允许bug的修复，并要求同步至mainline分支
- 开发团队多小组（如功能A组，功能B组），每一个小组可以有自己的sandbox分支。
- 开发语言为Java，因此在编译时并没有去考虑编译的性能，直接是全编译。（注：有项目可以考虑使用增量编译的方式）
在这样的项目背景下，针对mainline和release分支都创建了自动化的Job，每个Job的过程大概可以分为以下几个步骤：
- 源代码同步
- 编译
- 单元测试
- 打包部署至测试环境
- 集成测试
- 发布包
流程中会收集每个环节的报告：
- unittest report
- code coverage
- function test report
这些报告将发布到web服务器上，并以邮件的形式将报告的URL通知给相关人员。
此外若最后编译的包也发布成功，那么邮件体中也会包含如下内容：
- 当前版本与上个版本相比的changlist
- 新包的版本号
- 包的发布地址
这样方便测试人员进行后续的人工验证。