在解释这三个概念之前，先举个例子。

譬如说，你开了一家公司，雇了很多码农在一起写代码。

• 你说，要用 Gitlab 做代码管理。当一个码农在自己的开发机上写好代码之后，要合并到主分支里，他首先要发起一个 Merge Request（MR），这会在一个特定服务器上触发一次对他提交的代码的检查，包括代码格式检查、依赖关系检查以及单元测试等一系列检查，等通过了全部检查，他就可以将代码合并到主分支，否则他需要按照错误提示进行修改，然后发起新一轮的检查。然后呢，每天晚上 10 点会有一个定时任务从主分支上拿最新的代码，进行编译打包，最后将打包好的程序推送到一个服务器上保存，这个服务器叫做 Artifact Repository。

• 你又说，要每天将当天打包好的程序部署到测试环境上。也就是说，一个码农晚上 10 点之前提交了代码，那他第二天就可以在测试环境上看到自己新提交的代码的效果了。

• 你还说，每一个月要在生产环境上部署一个稳定的发布版本。

以上三段内容是一个软件从开发到部署的流程的简单描述，也分别对应持续集成、持续交付以及持续部署。

1、持续集成（Continuous Integration）

在传统软件开发过程中，集成通常发生在每个人都完成了各自的工作之后。在项目尾声阶段，通常集成还要痛苦的花费数周或者数月的时间来完成。持续集成是一个将集成提前至开发周期的早期阶段的实践方式，让构建、测试和集成代码更经常反复地发生。

持续集成就是把多个码农写的代码集成到同一个分支，然后经过编译、测试、打包之后将程序保存到 Artifact Repository 里。

image

2、持续交付（Continuous Delivery）

持续交付就是定时地、自动地从 Artifact Repository 将最新的程序部署到测试环境里。

image.png

3、持续部署（Continuous Deployment）

持续部署就是定时地、自动地将过去一个稳定的发布版本部署到生产环境里。

image.png

很明显，集成、交付和部署是软件开发到发布流程中的不同阶段。那所谓的持续是相对于过去的流程提出的。过去的流程是所有人写好代码之后再进行合并，然后再进行测试，最后再发布。这种流程会把风险堆到软件发布前的最后阶段。那持续的概念就是，做一点就马上递交给下一个流程，这样能够尽早地发现并解决问题。

补充，持续交付和持续部署是不是相同的概念，一直有争议。不过我认为，只要在你们的团队内部达成一致就可以了，不用太纠结于是不是同一个概念。