continuous integration (CI) is the practice of merging all developer working copies to a shared mainline several times a day.
持续集成的含义是：频繁的（一天多次的）将所有开发者的工作合并到主干上。持续集成是一种软件开发实践，即团队开发成员更加频繁的集成他们的工作，通常每个成员每天至少集成一次。每次集成都通过自动化的构建（包括自动编译，自动生成部署包、自动发布测试环境，自动化测试) 来验证，从而尽快地发现集成错误。
一般的软件开发过程：
1. 开发人员：进行编码 (实现新需求 / 修复 bug)
2. 开发人员：将新的代码在本地编译，并完成单元测试
3. 开发人员：将代码提交到代码仓库
4. 集成测试人员：将代码从代码仓库拉取下来
5. 集成测试人员：将代码进行编译和打包，生成部署包
6. 集成测试人员：将部署包发布到集成测试环境
7. 集成测试人员：执行集成测试，并将 bug 反馈给开发人员，循环执行 1-6 步，直到集成测试通过。
8.UAT 测试人员：将部署包发布到 UAT 测试环境
9.UAT 测试人员：开展测试工作，并将 bug 反馈给开发人员，巡回执行 1-7 步，直到 UAT 测试通过。
10. 运维人员：发布生产环境。
在该过程中，开发阶段只有单元测试，那么新开发的代码与已有代码的集成问题，不同开发人员新提交的代码之间的集成问题，以及系统级别的功能问题，都需要到交付前的集成测试阶段才能够被发现，甚至要等到 UAT 测试阶段才被发现，在急于修复这些问题的时候又有可能引入新的问题，最终可能会导致延迟发布生产环境。如此，修复缺陷往往花费很大的成本。所以，缺陷越早的被发现，修复成本越低，能在单元测试发现的就不要推迟到集成测试阶段，能在集成测试阶段发现的问题，就不要遗留到 UAT 测试阶段。
基于上述两点，我们需要考虑到把集成测试阶段的工作前移。相关软件功能可以分批交付给测试，早开发完的早交付，而不是积累到最后一次性交付。但是，我们还可以做得更好，可以期望每天做一次集成测试，甚至每个开发人员每次提交代码都执行一次集成测试，这就是持续集成。
持续集成的好处：
1. 问题被尽早修复，提高软件交付质量。
利用持续集成，开发人员更加频繁的将新代码和其他的代码进行集成，并做相应的测试。如果出现问题，开发人员马上就会被通知到，问题会第一时间被修复。这样一来，无论是交付给 UAT 验收测试的软件版本，还是最终交付给生产环境的版本，质量都得到保障，也降低了因质量问题而延迟上线的风险。
2. 将重复过程自动化，提高效率并降低成本。
在传统软件开发过程中，开发代码的每次集成，都要手工重复做一遍拉取代码、代码编译打包、发布测试环境、执行测试等步骤，这些步骤非常繁琐，非常耗费时间精力，正因为如此，代码集成无法做的太频繁。通过自动化的持续集成可以将这些重复的动作都变成自动化的，无需太多人工干预，让项目人员的时间更多的投入到更有创造性、更高价值的事情上，同时也可以实现更高频率的集成，从而提高代码质量。
3. 实施自动化测试，提升测试效果
在未实施持续集成的情况下，做自动化测试相对比较困难，因为大量 bug 被遗留到集成测试和 UAT 测试阶段，使得测试人员疲于发现大量 bug，并开展后续的跟踪和验证工作，往往没有精力去编写和维护自动化测试脚本。实施持续集成之后，如果大量 bug 在开发前期就能被消灭，测试人员能够腾出精力去实施自动化测试。实施自动化测试之后，测试人员进一步从大量的回归测试中解放出来，去设计和执行更具创造性的手工测试，从而将系统测试的更加充分。
4. 提供项目度量指标，增强项目的可见性。
多数时候，当项目最终的交付出现问题，我们无法清晰的知道问题到底是出在项目的哪个具体环节，这是因为我们没有真实或最新的项目过程数据做支持。通常，项目成员可以通过手工收集相关数据，但是这增加了负担，也很耗时。持续集成在这方面可以发挥积极的作用：一方面，持续集成可以为项目构建状态和品质指标提供及时的信息，例如功能完成度、缺陷率、测试覆盖率等指标；另一方面，由于经常集成，我们可以看到一些趋势，如构建成功或失败、总体品质以及其它的项目信息，这有助于我们评估项目过程，开展持续改进工作。
5. 建立团队对开发产品的信心
持续集成可以建立开发团队对开发产品的信心，因为他们清楚的知道每一次构建的结果，他们知道他们对软件的改动造成了哪些影响，结果怎么样。
持续集成的核心思想是切分任务，缩短每次迭代的间隔（对应的是细小任务，同时也是对应的细小时间），然后持续集成的必要条件是要用自动化的方式替代那些重复的劳动，测试，部署，分析等。
