cd容器化后如何实现持续集成与交付量资源.pdfVIP

本文由简悦SimpRead转码，原文地址

上一讲，我介绍了DevOps的概念与DevOps的一些思想。DevOps的思想可以帮助我们缩短上线周期

并且提高软件迭代速度，而CI/CD则是DevOps思想中最重要的部分。

具体来说，CI/CD是一种通过在应用开发阶段，引入自动化的来频繁地构建应用，并且向客户交付

应用的方法。它的理念是持续开发、持续部署以及持续交付，它还可以让自动化持续交付贯穿于整

个应用生命周期，使得开发和运维统一参与协同支持。

下面我们来详细了解下CI/CD。

什么是CI/CD

CI持续集成（ContinuousIntegration）

随着软件功能越来越复杂，一个大型项目要想在规定时间内顺利完成，就需要多位开发人员协同开发。

但是，如果我们每个人都负责开发自己的代码，然后集中在某一天将代码合并在一起（称为“合并

日”）。你会发现，代码可能会有很多和编译问题，而这个处理过程十分烦琐、耗时，并且需要每

一位工程师确认代码是否被覆盖，代码是否完整。这种情况显然不是我们想要看到的，这时持续集成

（CI）就可以很好地帮助我们解决这个问题。

CI持续集成要求开发人员频繁地（甚至是每天）将代码提交到共享分支中。一旦开发人员的代码被合

并，将会自动触发构建流程来构建应用，并通过触发自动化测试（单元测试或者集成测试）来验证这些

代码的提交，确保这些更改没有对应用造成影响。如果发现提交的代码在测试过程中或者构建过程中有

问题，则会马上通知研发人员确认，修改代码并重新提交。通过将以往的定期合并代码的方式，改变为

频繁提交代码并且自动构建和测试的方式，可以帮助我们及早地发现问题和解决，减少代码出错。

传统CI流程的实现十分复杂，无法做到交付，而当我们的应用容器化后，应用构建的结果就是

Docker镜像。代码检查完毕没有后合并入主分支。此时启动构建流程，构建系统会自动将我们的

应用打包成Docker镜像，并且推送到镜像仓库。

CD持续交付（ContinuousDelivery）

当我们每次完成代码的测试和构建后，我们需要将编译后的镜像快速发布到测试环境，这时我们的持续

交付就登场了。持续交付要求我们实现自动化准备测试环境、自动化测试应用、自动化代码质量，

并且自动化交付生产环境镜像。

在以前，测试环境的构建是非常耗时的，并且很难保证测试环境和研发环境的一致性。但现在，借助于

容器技术，我们可以很方便地构建出一个测试环境，并且可以保证开发和测试环境的一致性，这样不仅

可以提高测试效率，还可以提高敏捷性。

容器化后的应用交付过程是这样的，测试的环境交由QA来，当我们确定好本次上线要发布

的功能列表时，不同开发人员开发的feature分支的代码合并到release分支。然后由QA来将

构建镜像部署到测试环境，结合自动测试和人工测试、自动检测和人工记录，形成完整的测试报告，并

且把测试过程中遇到的问题交由开发人员修改，开发修改无误后再次构建测试环境进试。测试没有

问题后，自动交付生产环境的镜像到镜像仓库。

CD持续部署（ContinuousDeployment）

CD不仅有持续交付的含义，还代表持续部署。经测试无误打包完生产环境的镜像后，我们需要把镜像

部署到生产环境，持续部署是最后阶段，它作为持续交付的延伸，可以自动将生产环境的镜像发布到生

产环境中。

部署业务首先需要我们有一个资源池，实现资源自动化供给，而且有的应用还希望有自动伸缩的能力，

根据外部流量自动调整容器的副本数，而这一切在容器云中都将变得十分简单。