持续集成，持续交付和持续部署是人们谈论现代开发实践时常提到的几个概念，三者究竟是什么，又有何联系和区别呢？我们翻译了以下这篇文章来探讨这些问题。

第一次开始学习持续集成和持续交付的时候，想必很多人都多多少少有一些疑惑。别着急，在理解这些术语之前，我们首先需要知道一个概念———流水线（pipeline）。

在软件开发领域，流水线就是一系列流程的序列，例如按照顺序一个接着一个执行的过程或者指令。有的时候，上一步的输出即是下一步的输入。

在详述每个连续性流程的细节之前，我们可以先来看一看组成流水线的步骤：

首先，将在本地进行的代码更改提交并推送到中央仓库中；接下来，通过一个自动系统将其检出，该系统将项目构建为我们的浏览器可以理解的代码段；然后针对代码进行测试以确保我们的更改没有任何中断，最后部署到用户可以使用的最终环境。

这些步骤实质上构成了持续集成/持续部署的核心，并且一起构成了软件开发的流程。既然已经知道了流水线是什么，我们接下来谈谈本文的重点。

持续集成

顾名思义，持续集成（Continuous integration，简称 CI）是指每次对代码库进行更改时都运行集成测试。每当提交更改并将其推送到代码仓库时，持续集成系统都会重建分支，并运行所有相关的测试用例，以验证新更改不会破坏现有应用程序的运行。然而要实施持续集成，必须满足一些先决条件。

条件是什么

为了使应用程序做好持续集成的准备，需要事先采取一些措施。最显而易见的是如果没有构建系统或测试要运行，则无法构建和测试应用程序。尽管看起来可能要花费额外的精力（特别是在代码没有进行过任何测试的情况下），持续集成可以带来很多好处。例如，自动化单元和集成测试能够在 bug 进入生产环境之前就捕获它们，这样一来更少的 bug 会被交付到生产中。事实上，防止一个潜在 bug 进入生产阶段的有效措施就是用一个测试用例覆盖它们，以确保它们不会导致产品回滚。除此之外，由于持续集成可以在短短几分钟内运行数百个测试用例，花费在手动测试上的时间也将大大减少，这意味着测试人员可以专注于更重要的改进而不是耗费大量精力在反复测试现有功能上。

为了进一步开发和拓展持续集成机制以实现更高的自动化程度，我们引进了持续交付这一理念。

持续交付

持续交付（Continuous delivery，简称 CD）是持续集成的扩展。从本质上讲，这意味着每次代码更改通过测试时都要对其进行重新部署。这不仅自动化了构建和测试阶段，而且还自动化了大部分发布过程，运维人员只要点一下按钮就可以部署应用程序。

和持续集成相比，持续交付的好处是什么？

有了持续交付，由于在构建和测试应用程序后大部分步骤已经自动化，部署的复杂性得以降低。开发团队可以加快迭代速度并部署更小的更改，从而减少引入生产 bug 的可能性。通过持续交付，我们可以更轻松地定位 bug并将其修复。

持续部署

持续交付是持续集成的扩展，而部署则建立在交付之上。与持续交付相比，持续部署（Continuous deployment，简称 CD）更进一步，因为它可以自动将代码更改部署到生产中而无需人工干预。这也意味着为了避免出现回滚和其他问题，您的测试包必须是一流的，因为它决定了您的发布过程。

在持续交付的基础上，项目团队将获取更快的部署速度，因为每项更改都可以进行自动处理，代码合并后几分钟就能够在生产环境中看到本地开发的功能；另一方面，代码发布的风险也能够进一步降低，因为您应该尽可能进行小批量部署，这样的话在出现任何问题时更容易排除故障。通过所有这些连续性环节，最终用户将体验到应用程序中的持续改进，而不是时不时看到重大版本的变化。

最后，为了可视化整个过程以及这三个概念之间的核心区别，以下这张流程图可以加深您的印象。

参考文章：https://zhuanlan.zhihu.com/p/103554905