一、持续集成（Continuous Integration）

Continuous Integration：持续集成，简称CI，是软件开发周期的一种实践，把代码仓库（Gitlab或者Github）、构建工具（如Jenkins）和测试工具（SonarQube）集成在一起，频繁的将代码合并到主干然后自动进行构建和测试。简单来说持续集成就是一个监控版本控制系统中代码变化的工具，当发生变化是可以自动编译和测试以及执行后续自定义动作。

简化的含义为：频繁的（一天多次的）将所有开发者的工作合并到主干上。

以图例说明：

从图例上来看流程，分为3个步骤：

1. 首先，开发人员提交代码到 Source Repository （源代码仓库）。
2. 然后，通过 git hook 等触发 CI Server（持续集成服务器）的相关功能。执行 编译 -> 测试 -> 输出结果 等。
3. 最后，向开发人员反馈结果的 report。

可以看出，持续集成的 核心 在于 确保新增的代码能够与原先代码正确的集成。与后续要介绍的持续交付以及持续部署，其最主要的差别也就在于其目标不同。

🙂 持续集成的优势

和我们一直在使用的 阶段集成（完成一个阶段的开发后执行代码的集成） 相比， 持续集成 的策略能够为我们带来哪些好处呢？

• 易于定位错误：每一次的代码集成都需要执行相关的测试工作，持续集成频繁的集成次数天然的将复杂的代码逻辑切割为了小块，也就使得每一次测试中遇到的错误能够更加容易的被定位。
• 易于控制开发流程：更为细致的工作提交也就意味着更容易判断当前的工作进度，这对于管理者规划开发流程而言提供了一个有效的参考，同时也为开发人员省下了汇报工作的时间。
• 易于CodeReview：对于大块工作的切分自然也有助于做 CodeReview。
• 易于减少不必要的工作：build 以及 test 过程的自动化可以为你节约一大票的时间，从而投入到有价值的工作中去。

二、持续交付（Continuous Delivery）

Continuous Delivery：持续交付，简称CD，是在CI的基础进行了扩展，在CI环节完成了软件构建和测试工作并形成了新的版本，那么接下来就要进行交付，而这里的交付并不是交付到生产环境，而是类生产环境（STAGING），我们可以理解为灰度环境或者预发环境，进而接受部分真实流量的测试。如果没有问题的话则通过手动的方式部署到生产环境。

简化的含义为：一种能够使得软件在较短的循环中可靠的发布的软件工程方法。

与持续集成相比，持续交付的侧重点在于 交付，其核心对象不在于代码，而在于可交付的产物。

由于持续集成仅仅针对于新旧代码的集成过程执行了一定的测试，其变动到持续交付后还需要一些额外的流程。

以图例说明：

可以看到，与 持续集成 相比较，持续交付 添加了 Test -> Staging -> Production 的流程，也就是为新增的代码添加了一个保证： 确保新增的代码在生产环境中是可用的 。

在这一增加的流程中，Test 环节不仅仅包含基本的单元测试，还需要延伸到更为复杂的功能测试以及集成测试等。

在这里，Staging 指的是 类生产环境 ，其尽可能的对真实的网络拓扑、数据库数据以及硬件设备等资源进行模拟，从而为测试人员反馈代码在生成环境中的可能表现。

流程中每一个环节的执行结果都会对开发人员进行反馈，每一个出现的错误都会导致版本的回滚。当测试完毕确认无误之后，将由相关人员对其进行 手动部署到生产环境。

三、持续部署（Continuous Deployment）

Continuous Deployment：持续部署，简称CD，它是在持续交付的基础上打通最后一公里的工作，就是把手动部署到生产环境的方式升级为自动部署。看下图和上图在最后部署到生产环境中的区别。

简化的含义为：通过自动化部署的手段将软件功能频繁的进行交付。

与持续交付以及持续集成相比，持续部署强调了通过 automated deployment 的手段，对新的软件功能进行集成。

以图例说明：

可以看到，同 持续交付 相比 持续集成 的区别体现在对 Production 的自动化。

从开发人员提交代码到编译、测试、部署的全流程不需要人工的干预，完全通过自动化的方式执行。

这一策略加快了代码提交到功能上线的速度，保证新的功能能够第一时间部署到生产环境并被使用。

四、总结

持续集成、持续交付和持续部署其目的是减少代码改动到投入生产的所需时间，提早发现风险、减少QA的测试时长、减少运维的人工干预。整体上是一个提效的过程。