持续集成, 持续交付和持续部署区别

原文链接

如上图所示，持续集成、持续交付和持续部署就像是方向相同的向量，但是大小不同。他们都有相同的目标：使我们的软件开发和发布流程更快更稳健。

这三个概念的主要差异在于采用自动化的程度。但是刚接触这些的人就很容易被混淆，不理解他们之间的关系，实际上，他们更像是包含关系而不是互斥关系。

持续集成（CI）

开发者可能最先接触到的就是持续集成，对于开发者而言，就是每天多次地向中心仓库合并代码更新。而持续集成要做的就是，在每次的代码合并之后自动触发构建和测试。

根据语言不同，可能先要编译代码，在现在的环境下然后可能还要考虑构建docker镜像，然后，自动测试验证特定的代码单元、UI行为、应用程序性能、API可靠性等等。这些通常都认为是 “构建”阶段的事。

CI充当一个安全网罩，让开发人员在接触到用户之前就防止许多问题。因此，开发人员交付代码时更有信心，但不一定更快——部署过程可能仍然是手动的、冗长的，而且容易出错。

开发人员所能做的最好的初始投资就是确保他们的自动化测试套件足够全面和稳定，这样他们就可以放心地将每一个通过测试的CI构建部署到测试环境，以及以后的生产环境中，而不需要长时间的手工QA(质量保证)过程。

第二件需要注意的事情是CI速度: 开发人员必须在10分钟内得到CI结果，否则由于缺乏焦点和频繁的上下文切换，他们的生产力会下降。优化CI时间的一个简单方法是在一个强大的平台上并行运行测试。

从持续交付（CD）到持续部署

持续交付(CD)是整个软件发布过程的自动化实践。这个想法是做CI的同时，自动化地准备和追踪产品发布。预期的结果是，任何拥有足够特权的人都可以在任何时候通过一次或几次点击就可以完成产品新版本的部署。通过消除几乎所有的手工任务，让开发人员变得更加高效。

持续交付过程通常包括至少一个手工步骤，即确认和启动部署到生产环境。在具有多个依赖项的复杂系统中，持续交付pipeline可能包括额外的步骤，这些步骤可以是手动的，也可以是自动的。

持续部署是在持续交付的基础上，将源代码的每次变更都自动部署到生产环境中，整个过程不再需要开发人员的确认。开发人员只需要检查来自队友的pull请求并将其合并到主分支。这时，一个CI/CD服务接管了运行所有测试并将代码部署到生产环境中的任务，同时要让团队知晓每个重要事件的结果。

当然，持续部署可能更需要一个强大的监控系统、团队的随时待命和快速恢复能力作为坚强后盾。