持续集成的解决方案

本文由《持续集成实践》一书总结而来。

一、持续集成

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 的主要特点：

• 易安装；易配置；易使用；易扩展；
• 支持分布式构建、文件跟踪等；
• …

优点太多了~