• 提交：持续集成第一步就是开发人员将代码进行提交并推送到代码仓库，比如git、svn。
• 测试（第一轮）：代码仓库对commit操作配置了钩子（回调），只要提交代码，就会跑自动化测试。
• 构建：通过了第一轮测试，代码就可以合并到主干，就算可以交付了，交付后，先进行构建，再进入第二轮测试，所谓构建，就是将源代码转换为可以运行的实际代码，比如.java变.class。
• 测试（第二轮）：构建完成后，就要进行第二轮测试，如果第一轮涵盖所有测试内容，这个流程就可以忽略，但是此时构建、和第一轮测试的先后顺序要交换，先构建再进行第一轮测试。
• 部署：过了第二轮测试，当前代码就是一个可以直接部署的版本（artifact）。将这个版本的所有文件打包（tar filename.tar * ）存档，发到生产服务器。
• 回滚：一旦当前版本发生问题，就要回滚到上一个版本的构建结果。最简单的做法就是修改一下符号链接，指向上一个版本的目录。

持续集成的组成因素：

• 一个自动构建的过程，从代码检出，编译构建，运行测试，结果记录，测试统计，等都是自动完成，无需人工干预。
• 一个代码存储库，版本库，比如 Git、Svn。
• 一个持续集成服务器，比如Jenkins就是一个配置简单和使用方便的持续集成服务器。
  

1. 降低风险，由于持续集成不断去构建、编译、测试，可以早期就发现问题，所以修复代价就小一点。
2. 对系统进行健康持续检查，减少发布风险带来的问题。
3. 减少重复性工作。
4. 持续部署，提供可部署单元包。
5. 持续交付可供使用的版本。
6. 增强团队信心。

持续部署已经包含在持续集成里面，持续部署的前提就是持续集成。