一 持续集成是什么
持续集成是一种软件开发实践，即团队开发成员经常集成他们的工作，通过每个成员每天至少集成一次，也就意味着每天可能会发生多次集成。每次集成都通过自动化的构建（包括编译，发布，自动化测试）来验证，从而尽早地发现集成错误。
对于很多软件项目来说，开发人员虽然可以做到在提交代码后对代码进行自动化的单元测试， 但基本上没人会在试运行环境中去启动并使用它。这样便可能会发生一些潜在的问题。比如当开发结束后需要留出很长时间去集成，这个阶段往往会很费时间，最糟糕的是没人知道这将会花费多长时间才能完成集成。
所以我们应该尽早去做持续集成，而持续集成的目的就是让软件一直处于可工作的状态。
二 实现持续集成
1、准备工作
- 版本控制：任何项目都应该使用版本控制
- 自动化构建
- 团队意识
2、一个基本的持续集成系统
- 查看一下是否有构建正在运行，如果有的话，等它完事，如果它失败了，就和团队的其他人把他一起修复，然后再提交代码
- 一旦构建完成且测试完全通过，就从版本控制库中将该版本的代码更新到自己的开发环境上
- 在自己的开发机上执行构建脚本，运行测试，以确保在你机器上的所有代码都正常工作
- 如果本地构建成功，提交代码
- 然后等待你这次提交的构建结果
- 如果失败了，停下手中的活，修复问题，转到步骤3
- 如果成功，开始下个任务
三 持续集成的前提条件
1、频繁提交
2、创建全面的自动化测试套件
自动化测试的套件包括：
- 单元测试：用来测试应用程序中某些小单元的行为（方法、函数...），通常不需要启动整个应用程序，也不需要连接数据库、文件系统或网络。
- 组件测试：用于测试应用程序中几个组件的行为。它也不需要启动整个应用程序，但有可能需要连接数据库、访问文件系统或其它外部系统或接口。
- 验收测试：用来验证应用程序是否满足厌恶需要所定应的验收条件，包括应用程序提供的功能，以及其它特定需求。一般会将整个应用程序运行于类生产环境的运作方式。
3、保持较短的构建和测试过程
4、管理开发工作区
当开发人员开始工作的时候，应该总是从一个已知正确的状态开始。
四 应该遵守的实践
- 构建失败之后不要提交新代码
- 提交前在本地运行所有的提交测试，或者让持续集成服务器完成此事
- 等提交测试通过之后再继续工作
- 回家之前，构建必须处于成功状态
- 时刻准备着回滚到前一个版本
- 按照持续集成的流程，前一个版本肯定是没有问题的
- 在回滚之前规定一个修复时间
- 不要将失败的测试注释掉
- 为自己的导致的问题负责
- 测试驱动开发
