版权声明：原创不易，未经作者允许请勿随意转载！因个人能力和精力有限，难免有疏漏和不足之处，欢迎指正，谢谢~ https://blog.csdn.net/lijing742180/article/details/88428645
本文由《持续集成实践》一书总结而来。
一、持续集成
1、什么是持续集成？
持续集成，即 Continuous integration，简称「CI」，是极限编程中的一种软件开发实践。
它通过自动化的构建（包括编译、发布和自动化测试）实现不间断的进行集成工作，从而尽快地发现集成错误。
- 持续：不间断的，每日多次进行；
- 集成：代码和代码之间的集成，软件各个过程的集成（开发、部署、测试等）；
持续集成的主要目的：
- 一是“频繁集成”
- 二是“反映代码质量”
2、持续集成的核心价值
持续集成的价值有很多，在我看来，最核心的价值有三方面：
- 尽早发现缺陷，尽快解决缺陷，减少风险；
- 构建常用功能，集成自动化测试，减少重复劳动；
- 把所有看似散乱的工作有机的形成一个整体，明确定义阶段性交出物，将职责的定义清晰化。
二、持续集成方案
最初，我们的代码不多，自动化脚本也比较简单，在一台机器上运行所有的测试也仅需要几分钟，构建套件的运行顺序一般是：CheckStyle -> Compile -> UnitTest -> FunctionTest -> Report。
后面随着代码量和测试脚本越来越多，每次集成的时间越来越长，甚至可能达到几个小时，这时持续集成给我们带来的更多就是痛苦了。
1、阶段化持续集成
一般来说，测试代码越多，越能够正确反映代码的质量，但是越 多的测试代码也意味着更长的运行时间，更慢的反馈速度。
因此，我们不得不在“反馈时间”与“判断质量准确性”两者之间找到一种平衡，于是有了“阶段化持续集成”。
阶段化持续集成：
- 即为不同的构建测试套件（即构建计划），建立不同的持续集成循环周期；
- 由于单元测试运行时间短，反馈较快，所以可以频繁进行；
- 而功能测试、性能测试的时间比较长，占用资源比较多，所以适当减少集成次数，但一定要保证其周期性运行；
- 重复任务较多，仍存在一定的资源浪费，定位问题困难。
2、过程式构建
过程化构建：
- 将每一个步骤单元化，并顺序执行。
- 将构建与测试分离以节省时间，这也是其与阶段性集成的不同之处。
- 去除了重复步骤，提供了持续的信息反馈，反映了整个过程。
- 后续单元在执行时，需要依赖前面单元产生的产物，更有效的利用资源，但管理复杂性较高。
3、管道式持续集成
管道式（pipeline）持续集成方案，是目前企业级持续集成的常用解决方案。
- 形式上与过程式构建类似，但是思想不一样；
- 所有的过程单元都运行在同一管道的上下文中，即各单元所使用 的原材料都是完全相同的，即代码基线相同；
- 当持续集成服务器发现有新的代码时，会创建新的一个管道，所有的过程单元都在这一个管道中运行，而每个单元产生的产物也在该管道中有效。
- 综合了阶段式和过程式的优点。
当团队人数大于 100 人、没有专门的配置管理员等情况下，一定要好好规划持续集成方案，而不能简单的装起来就用，否则会导致工作流程越来越混乱。
三、持续集成工具
从敏捷开发提出至今，陆续出现了很多优秀的持续集成工具，这里说一下主要的几款：
CruiseControl：开源免费，由ThoughtWorks开发的，早期比较流行。Hudson：最初由 Sun 开发并开源，很快超越CruiseControl，但是后来被 Oracle 收购了，变成收费了。gitlab-ci：专门为 gitlab 提供的持续集成工具，从 gitlab 8.0 版本开始默认集成了 gitlab-ci，但是很多用户反应构建比较慢。Jenkins：前身即 Hudson，由之前的核心开发人员维护，开源免费，功能强大，插件丰富，是目前企业的首选工具。
Jenkins 的主要特点：
- 易安装；易配置；易使用；易扩展；
- 支持分布式构建、文件跟踪等；
- …
优点太多了~