暑期实习期间，所在的技术中台—效能研发团队规划设计并结合公司开源协同实现符合DevOps理念的研发工具平台，实现研发过程自动化、标准化；
实习期间对DevOps的理解一直懵懵懂懂，最近观看了阿里专家带你玩转容器云原生DevOps公开课开始系统的学习DevOps，所以根据学习视频整理出以下学习笔记希望分享给更多对此感兴趣的同学～
课程大纲如下图所示，会陆续进行更新：

一、DevOps、微服务和容器服务

随着微服务云原生框架容器技术的兴起，越来越多的企业开始对 DevOps 技术产生浓厚的兴趣。希望通过 DevOps 技术进行企业经济开发转型，提高交付效率，通过自动化降低交付成本。
本课程主要是通过介绍 DevOps 相关的一些交付理念、常用的工具、最佳实践的流程以及在云环境中的集成等多个角度，为大家打开通往 DevOps 的大门。

1. DevOps入门

1. 概念定义

维基百科定义：DevOps 即 Development(开发) 和 Operations(运维)，它是一种重视软件开发人员和运维技术人员之间沟通合作的文化、运动或惯例。透过自动化 “软件交付” 和 “架构变更” 的流程，来是的构建、测试、发布软件能够更快更频繁更可靠

通俗的来理解，DevOps 就是一系列做法和工具，可以使运维团队和软件开发团队之间的流程实现自动化。随着敏捷软件开发日趋流行，持续集成 (CI) 和持续交付 (CD) 已经成为该领域一个理想的解决方案。

什么是 CI/CD 呢？如下图所示：

• 持续集成CI：代码编写完成后，后续的构建、测试、合并到代码仓库这一系列操作持续自动化完成
• 持续交付CD：自动化的将代码打包成镜像然后发布到镜像仓库中

在 CI/CD 工作流中，每次集成都通过自动化构建来验证，包括编码、发布和测试，从而帮助开发者提前发现集成错误，团队也可以快速、安全、可靠地将内部软件交付到生产环境。

也就形成了如下的闭环：

一句话来说：DevOps 就是只要代码发生变更，通过一系列的自动化流程，就能在线上的云平台看到代码变更后的效果，减少了开发人员和运维人员之间大量工作，全部交给自动化链路来完成。也就是就是自动化的进行代码编写、构建、分析、测试、合并代码库、构建打包成镜像、部署、线上运维分析这一闭环

2. 历史背景

DevOps的概念最早在2007年提出：

DevOps 其实就是在这个时候产生的，它主要就是来融合这个开发和测试之间的工作。那为什么2007年就已经有DevOps 的概念，直到2018年才渐渐的被人们认可、接受和采纳呢？

答案是要完成 DevOps 倡导的理念，不止是一个技术问题，更多的是一个流程、管理、乃至公司架构的问题。要想让团队之间的消息流转更顺畅，就需要更多的自动化流程、系统以及规范。而 DevOps 的发展正式随着越来越多的企业互联网化转型、IT转型，越来越多DevOps工具与交付模型的诞生而兴起。

对比以前传统应用的交付模式如上图所示：每个步骤紧紧有条，表面上看着庞然有序，但也存在着弊端，比如非常一个简单的小需求也必须走完整的一个庞大的流程才能上线，这就会导致产品的迭代速度变得缓慢，冰鞋流程中出现问题也不能快速的进行溯源，会导致错误不能得到及时的解决。

而现如今，我们有越来越多的交付场景，比如app、网站以及各种各样的服务，且迭代速度越来越快，正常一个产品新版本的推出都是一周一次的频率及以上。我们面对的是一个越来越复杂和快速的交付场景，在这种场景下，传统的应用交付方式已经无法满足我们的需求。为了面对日益复杂的场景，越来越多的企业开始互联网化转型、IT转型，DevOps也就逐渐兴起，越来越多DevOps工具与交付模型的也逐渐诞生

下图是当今DevOps的元素周期表，其中每一个元素都代表在DevOps中可能涉及到的工具，其中很多工具都被各大公司开始使用，这些软件工具的兴起也从反面促进了DevOps流程在大型企业中的落地

因此，引入 DevOps 后的交付模型是怎么样的呢？

传统的DevOps应用交互模型如下所示：

当今更过的是标准容器DevOps交互模型，如下所示：相比传统应用交互只是在中间产物方面多了一个从持续集成系统中到镜像仓库，以及一个分发镜像的流程

3. DevOps的目标

以上工作流看上去很酷炫很高级，但这真的适合我们吗？是否我们也需要迁移类似一个自己的 DevOps 工作流来汇集 DevOps 所带来的优势。此时就遇到了DevOps 领域中著名的“大象问题”，有的人认为有长牙齿的就是大象，有人认为有粗大腿的就是大象，有人认为有长鼻子的就是大象，有人说有大肚子的就是大象， 有人说有长尾巴的就是大象

但实际上，每个人说的都对，但都只注重于大象的一个部分。但这样的话如果从以上纬度来看大象再进行组装的时候就会下图所示现象：就是一个不伦不类的玩物，完全没有惠及到整体的优势，从而造成企业做DevOps转型时的困难。

所以为了很好的完成一个DevOps工作流，首先要知道DevOps的核心概念和它要解决的问题。

DevOps的目标就是上图所示：流程化、标准化、自动化、质量提升。以此来减少脱节，降低人力消耗，提高效率，避免返工。总结来讲就是提高质量，减少时间，那该如何实现呢？

传统的瀑布流开发模型是一个前驱性的过程，是消息在瀑布流中逐步轮转的过程，只有完成了前一步才能进行下一步，这其中导致时间浪费的主要因素就是等待：等待基础架构、等待应用部署、等待其他团队、等待审核…

DevOps 解决该问题的方式如上图右边所示，宏观来看就是测试员首先建立一个defect缺陷报告，然后开发者去fix defect，最终测试员再重新测试，如果没有问题就上线。而两者中间的所有过程都是通过 DevOps 工具链自动化完成的，因此 DevOps 的理念就是将原先的等待的时间消除掉，交由自动化完成，节省了大量时间也保证了质量。

4. 无脑DevOps吗？

我们接下来看四个公司转型DevOps的实例：

对比上面两个案例，可以看到，我们应该挑选适合自己的DevOps方案，选择合适工具来适配自己的开发流程，而不是以一套拿来的主义的方式来进行实现。

5. 总结

DevOps 是为了解决 “时间” 和 “质量” 而产生的一种交付文化、流程、交付方式等等的统称，DevOps期望通过消除 “等待” 与 “浪费” 的方式实现更快速、更高质量的交付。

DevOps 不仅仅是简单的自动化流程，更多的是开发方式、开发流程的变革，但是由于团队架构、工具生态、技术架构等等的因素

2. 微服务入门

虽然 DevOps 的理论提出了很长时间，但是一直难以有范式的操作流程可以供大家参考，更多的是在某些特定的场景或者交付流程中实现了部分的最佳实践。那么为什么这两年越来越多的公司开始重新将关注点放到了DevOps上？正是因为微服务的引入，接下来我们来介绍微服务：

1. 微服务的历史

上图所示就是一个简单的微服务架构模型，业务形态分为移动app和web端，移动app通过api网关的方式调用后端的service服务，后端有三个微服务Account Service、Inventory Service、Shipping Service 相互独立，也有各自的数据库操作DB对象；web端通过前台的StorefrontWebApp来组合后台的service api实现上层应用逻辑。

2. 微服务的特性

1. 服务组件化。就每一个组件都会有完整的一个生命周期，它包含自己的这个API，可以独立存在。就如刚才看到的简单微服务架构示例图所示，不论是Account Service 还是Shipping Sservice，它都包含自己的API并且通过网关方式进行暴露，然后每一个服务都包含一个DB，且这个DB是独立存在的。
2. 微服务是按照业务来去组织团队。每一个微服务都是一个完整的生态，它包含了一个业务逻辑以及对应的业务边界。比如说Account Service服务，它包含的就是所有和账号相关的业务操作及账号的业务边界。不同的业务是不相互耦合的。所以根据功能的独立性，企业会将这个功能分配给独立的团队去负责。
3. 每一个微服务以产品化为目的去推进演进。既然已经把对应功能模块分给了一个团队，模块的负责人就要以产品的思维来去考虑这个模块的以后的演进方向。
4. 服务通过使用定义良好的API（智能端点）和简单协议如基于HTTP 的REST协议（哑管道）相互通信。
5. 微服务采用去中心化的治理方式。就是根据不同业务的不同特点来选择合适的开发语言和框架。比如说后台的API Service，可能比较倾向于选择 Golang 来去实现。但如果是一个前台逻辑服务，我可能会使用Node JS来去实现。
6. 去中心化来管理数据。不同的模块使用的是不同的数据库、或是不同的表，不会出现这个相互调用的场景，以此来降低组件数据间的耦合。
7. 基础设施的自动化。也就是是自动化部署和自动化交付。
8. 容错设计。在分布式系统里面有一个概念叫做网络是不可信的，而在微服务的设计里面，也有一个说法叫做组件是不可信的。对于失败的状态，其实是要有一些降级的处理的，比如类似像 spring cloud 这种微服务框架里面就提供了类似垄断器的这样的一种机制。
9. 演进式的设计。我们已经将每个微服务的组件划分的十分细了，而且它包含了相应的业务边界。所以每一个组件未来可能涉及到哪些功能，需要预留出哪些接口，以什么样的方式设计你的API，其实是演进式设计的一种。

3. 微服务案例

我们先来看一个传统应用进行微服务的一个案例。以下是一个打车软件的示例图，业务功能面向移动客户端(乘客端和司机端)以及web端。以前它是一个非常大型的一个单体系统，数据存储是在mysql 里面进行存储的，对外暴露了一个restful api，前台有外部UI，然后对于一些三方接入系统，有各种各样的适配器来进行实现。而这个大的单体系统里边有非常多的一个业务逻辑在里边，耦合了非常多的这个子的模块和系统。

这个系统其实看起来非常复杂，而且一旦出现了问题之后，其实是影响了所有的对外的移动端、web端以及三方系统。 后来该公司对这个系统做了微服务转型，将原系统进行了一个微服务化的拆分。那么是如何从一个传统的架构转换成一个微服务的一个框架的呢？

首先我们先来看他的乘客端和司机端是通过API网管调用了 passenger、driver、trip 三个web service。然后这三个 service 又调用了底层的billing、payments、notification 这三个对外暴露的restful API。也就是说它将原本的一个单体系统拆分成了六个业务相关的service，并通过六个service 和 API网关对外提供了完整的一个功能。而上层又通过了这个 passenger web UI 和 driven web UI 包装了底层的这些服务，实现web端的一个访问。这就是一个很典型的一个传统应用微服务化的一个方式。

上图右侧的是scale cube，就是微服务的扩展立方体，它讲述了一个应用进行扩展的三种方式：

• 第一种方式就是按照不同的类型进行扩展，比如说我可以将一个系统切分成很多不同的部分，然后进行扩展。
• 第二种方式是切分成很多相同的部分进行扩展，比如说我会把一些东西归纳成同一个类型，然后进行扩展，
• 第三种方式是直接不切分，直接拷贝进行扩展，就是完整的水平扩展。

对于微服务来讲，其实它是第一种方式，就是它将那一个大的系统切分成不同功能的子模块。然后再从这个子模块的方式进行扩展。这个其实是微服务的一个扩展方式。

刚才我们提到的这个passenger、driver 和 trip 这三个service，其实它是一个自包含的形态，每一个部分其包含了一个 database 的 adapter，然后这个 adapter 底下会有自己的一个数据存储的部分，可能是同一个库的不同表，或者干脆就是不同的数据库。但是他们之间是没有数据之间的一个相互依赖的。而对于每一个相应的service，都可以通过水平扩展的方式来实现一个业务的一个扩展。就类似像右边这张图，前面是一个 load balancer，后边是不同的容器，用来均衡发到 web 服务器的请求量，均衡负载，提高系统性能。

4. 微服务的优点

1. 它将一个大型的单体系统拆分成了多个微服务，可以解决这个应用复杂性的问题，每一个微服务都可以更好的切分业务边界。
2. 每一个模块都有专门的团队和人员负责，可以选择最合适的技术进行实现，使得这个架构演进变得更简单，降低了历史的技术债务。比如说有一天我觉得某模块原本的框架设计的不是很好，可以迅速的用很小的成本来重写到这个小模块，而不影响整个的一个系统。
3. 微服务之间并不相互影响和依赖，降低了这个系统的耦合度，可以独立升级。我们可以在任何时间升级系统里面的一个组件，而不会对这个系统产生非常巨大的一个影响。
4. 微服务切分之后都是独立部署的，可以根据业务特征动态的调整。这个其实是很常见的微服务的使用场景，因为对于不同的时间点，可能你的系统的压力会出现在不同的地方。比如说如果是双11的时候，那可能我的订单系统是压力最大的；而在平时的时候，我可能是前台的这个缓存的这个部分压力是最大的。所以可以针对不同的场景，不同的时间来去扩缩容我不同的这个业务的子的微服务的系统。这个其实也是微服务的一个优势。

5. 微服务的缺点

微服务并不是十全十美的，微服务的很多优点，同时也是它的缺点：

1. 一是比如说我将一个大型的系统拆分成微服务，那涉及到你的系统是会有一些分布式的一个改造，带来了固然的一个技术成本。
2. 二是更清晰的一个边界划分，也使得标准化变得越来越困难，比如说的 API 的代码部分既实用了golang 也是用了node.JS，这会使得我们很多以前使用的一些公共的框架或类库没有办法在跨语言的场景进行使用。所以很多微服务的改造实际上是依赖于一些上层的框架进行规约的。比如说 Spring Cloud 来进行规约 Java 的这个微服务的一个开发方式，或者是在容器里面也有 Service Mesh 来解决微服务的接入层的部分，或者是类似像Kong、TYK 的网关也是类似解决API接入的这种场景。
3. 三是单体应用内部的通信成本远远低于微服务组件之间的网络通信，这是一个性能的问题，但是对于一个非常大型的系统来讲，这种性能问题相对来讲可以的忽略，但对于一些特别是实时系统来讲，这个成本还是挺高的。
4. 四是说管理多个组件或者是组件拓扑成为了微服务系统的头等要务。上述打车软件例子里边，我们将一个大型的单体系统切分成了六个子服务，表面上看并没有很大的成本，但是如果我们有数十个这样的大单体系统的话，那可能会拆分成了成百上千个微服务，这个时候对于微服务的管理来讲实际上是一个挑战。
5. 五是数据库的设计和业务规划成为了这个微服务的一个难点。也就是说你要想设计出一个完全符合微服务理念以及范式的架构的话其实是一个很大的挑战，对于开发者提出了更多的难点，所以微服务的问题在于：它的架构方式对于开发者来讲要求比较高、管理与集成的自动化程度要求比较高、标准化的成本比较高。

6. 与DevOps的关联

第一节里提到了DevOps 的一些概念以及 DevOps 很难落地的原因，DevOps 发展起来的另一部分原因其实也是微服务的兴起。微服务完美的匹配了DevOps 的一些理念，而且微服务的概念可以弥补 DevOps 的一些缺失：

1. 第一是因为将大型的应用拆分成了微服务可以更加清晰每个模块的责任边界，变相引导了一个交付流程的变革，其实也是填补了这个 DevOps 里面缺乏流程变革的一个点。
2. 第二是清晰的边界、独立的部署，可以提供更快的迭代和交付流程自动化的一个可能。因为如果你是一个非常大的一个单体系统的话，任何的一个变更可能会要走一个非常庞大繁琐的交付流程，甚至构建的一个时间也是令人难以忍受的。但是如果有很清晰的边界、很小的一个代码体积，你就可以很快的进行迭代与交付。所以微服务也从侧面降低了DevOps 的交付成本。
3. 第三是越小的一个业务边界，可以使实现的复杂性降低，提高交付的质量。我们刚才也提到了 DevOps 关注的是 “时间” 和 “质量” 两个问题。你的这个边界越窄，所包含的范围越小，出错的可能性也就越小，相应的质量会变得越高。

所以微服务把很多 DevOps 里边的缺失进行了弥补。用中国的一句古话来讲，微服务与 DevOps 的结合就是首先分而治之，然后再通过 DevOps 进行连续集成，便可以实现快速交付。

所以微服务可以说从概念上完美的匹配了DevOps 的一些缺陷，并且可以和 DevOps 进行完美的一个结合。

3. 容器入门

前文我们了解了DevOps和微服务的相关概念，我们提高微服务的概念很好的解决了DevOps的不足并且推进了DevOps的发展，而微服务的缺点其实可以从容器的方式来去解决，因而很多人说容器定义了一种新的交互方式。

下图上是从2015年到2016年的一个调查的报告图。可以看到从15年到16年 DevOps 的采用比例逐渐在提升，而且和容器相结合的 DevOps 越来越被很多的企业所采纳，那这是为什么呢？

1. 什么是容器

首先我们先来讲一下什么是容器。容器简单的来讲是一种虚拟化的方式，如下图所示中的 Docker 就是容器的一种实现方式。

上图左半边部分是我们传统的虚拟化方式：在最底层的硬件服务上会跑着类似 Hypervisor 这样的管理程序，然后之上会有一个完整的虚拟化操作系统与其相应的 Banaries 和 Libraries，最上层便是 Application。

而容器虚拟化和传统虚拟化相比，其实是在虚拟化这一层做的很轻。在 Hypervisor 之上并没有 Guest OS 这一层，而是通过操作系统的标准接口来实现或模拟系统调用，从而降低了这个虚拟化的一个成本。可以简单的理解，Docker 是一种轻量级的虚拟化，它和标准的虚拟化的一个差别就在于对于虚拟化的这个损耗上面。

2. Docker简介

到底什么是Docker呢？

Docker 是一个开源的一个应用容器引擎，它可以让开发者打包自己的一个应用，以及将这个依赖包放到一个可移植的一个容器里边，然后发布到任何一个流行的一个linux 的机器上(现在 Docker 公司也支持了windows 容器，也可以实现虚拟化)。容器是完全使用沙箱机制，相互之间不会留有任何的一个接口。

Docker 里面有几个重要的概念：

1. 第一个就是 DockerFile，就是 Docker 的配置文件，它是用来生成 Docker image；
2. Docker image 是我们所谓的交付的最小单元，比如一个 Java 应用实际上交付的时候，并不是交付应用代码本身，而是使用了容器技术，通过 DockerFile 将应用打包生成 Docker image。而这个打包了我们应用代码的 Docker image 实际上是在容器交付里的最小单元。
3. 第三个是 Docker 的命令与 API，它定义了一些命令和接口，支持三方系统的一个集成。比如说现在比较流行的类似像 kubernets 容器编排系统，实际上就是和 Docker 的 API 打交道，就是封装了一些 API 以及上层的子系统来实现了容器编排的功能，实现了类似一些 pass 、sass 平台一些场景。

3. Docker改变交付流程

Docker 到底是怎么改变了交付流程的呢？主要从以下三面进行分析：

1️⃣ DockerFile 标准化了交付环境

DockerFile 是一条条指令组成的一个配置文件。例如上图所示，这个 DockerFile 实际上用于打包生成 nginx 镜像，它首先 from 一个 untuntu 的基础镜像，然后 run了一些命令安装一些软件以及依赖环境，然后变更的一些配置，接下来挂载了一个存储目录，然后设置了一些 command，最终暴露了一些端口。

和我们传统交付流程里面相比，DockerFile 将我们以前需要在虚拟机里安装很多的基础组件、环境依赖，代码部署等操作完整打包好变成了一个可交付的一个单元 Docker image。也就是标准化了一个交付环境，最终我们交付的就是一个 Docker image

2️⃣ 编排模版标准化了交付内容和拓扑关系

上图例子里是一个 Docker Swarm 编排模板。这个模板里边分为两部分：上面是web，下面是DB，其实可以理解成它是一个应用的拓扑。其中 web 里边使用了相应的 docker image，然后声明了一些环境变量，设置了一些重启策略以及这个拓扑关系的 links，然后又打了一些 label；在DB里边同样也是使用了镜像、环境变量、重启策略和label。其实这个文件就定义了一个带有DB的web服务的应用拓扑，以及相应使用的交付的最小单元 Docker image，编排模板其实就是标准化的交付内容和突破关系。

3️⃣ Docker 命令与 API 定义了交付流程与动作

Docker 本身自己有很多的命令，这写命令也会暴露成相应的API。这些命令其实和我们标准的一些运维动作是非常相似的，所以 Docker 的命令和 API 定义了这个交付的流程以及后续的运维动作。

4. Docker解决了微服务的缺点

1. 第一就是容器带来了是标准化交付，DockerFile 已经可意将微服务中的这个语言和框架的复杂性进行了一个封装。对于不同采用不同语言不同开发框架开发的微服务于DockerFile 来讲，都能够把这些东西封装成一个Docker image，然后通过标准的 docker run/start/rmi 等命令来进行生命周期的一个管理，也就是将微服务里边的很多的复杂性进行封装。
2. 然后第二是 Docker image 将交付的最小单元进行的定义，降低了这个交付的一个复杂性。传统的这个微服务里边不同的语言会有不同的交互方式，比如说 Java 的应用构建时会用maven build，测试的时候采用maven test，然后最终部署的时候，我可能会在这个最终的环境上就部署很多启动脚本，然后再通过这个tomcat 的启动脚本再启动这个应用。而对于node JS 应用我可能就会用这个 npm run/start 来启动应用。所以对于很多不同框架或者是不同的版本的应用，对于微服务来讲，持续交付起来是很复杂很困难的。但是当这些操作封装进一个 Docker image 的时候，启动一个应用就是 docker run，删除一个应用就是docker rmi，重启一个应用就是docker restart，也就是将交付的动作进行了封装，降低了交付的一个复杂性。
3. 第三是 Docker 提供了各种各样的 API 以及上层编排系统解决了多个微服务之间管理的关系，以及拓扑关系的维护。
4. 第四是越来越丰富的容器生态，使得微服务不止从这个交付而且从框架级别进行了一个支持。我们可以看到类似在容器里边的 Service Mesh 或者是类似 Linkerd 的等接入层的框架都可以和我们自己的代码进行一些整合来降低我们使用微服务而带来一些技术成本。

5. 容器交付的难点与解决方案

容器交付能够解决微服务中的一些问题。这个容器交付有没有难点或者问题呢？其实是有的：

1. 一是使用容器了之后，它有比较高的一个学习成本和技术成本，对于团队来讲是一个不小的开销。
2. 二是容器的架构和现有的系统集成存在一些困难，特别是在发布系统和监控系统上面。
3. 三是容器的交付流程改变了现有的交付方式，引入了更多的步骤和成本。以前交付代码的时候，只需要提供代码仓库，但现在可能需要提供一个构建好的 Docker image，也就是增加了更多的流程。

那么怎么解决上述容器的一些缺点呢？

其实反过来了，这些问题可以通过 Devops 的一些工具来去实现，Devops 可以将容器交付流程进行自动化来降低交付成本，而剩下的问题可以交给阿里云的容器服务

阿里云的容器服务是怎么注意这个容器交付的呢？首先在集群调度管理、网络存储、监控日志等等维度，会有云原生的实现和开源方案的一个集成；对于微服务架构和持续交付上面，也有系统的集成能力以及开源方案的一个集成；对于编程模型上面，也提供了常见的一个编程模型框架的最佳事件。

6. 服务、容器、DevOps交付链

经过上文所述，我们了解到 Devops 的一些弊端其实是由微服务进行解决的，而微服务的一些问题，又有容器进行了弥补，而容器的问题又通过 Devops 工具的方式进行了一个整合。所以从这个角度来讲，他们三者进行了一个完整的融合。

从 Devops 的概念来讲，微服务实际上可以对等到 Devops 的内功部分，而容器其实可以对等到这个 Devops 的招式的部分。那为什么说微服务是内功呢？因为微服务本身其实它只是一种架构设计的一个理念，通过这种理念可以帮助 Devops 来实现业务流程的改造、人员的划分、架构设计以及质量保障。而容器本身其实就是一个工具，它可以在这个自动化和工具的角度来成为这个 Devops 的招式，也就是说微服务和容器进行整合，并且依托于 Devops 的一个理念，可以实现一条比较完整的交付链。

7. 持续交付链路实例

一个非常简单的容器交付链的流程大概如下所示：首先在本地进行代码开发，当代码需要变更的时候，可以提交到代码仓库，然后在阿里云的镜像服务里边会有web hook 的一个通知，自动去拉取这个代码仓库中代码，进行镜像的一个构建，而这个镜像所需要 DockerFile 已经在本地开发时和代码一起提交到代码仓库了，当这个镜像构建完成后，可以在阿里云容器服务的一个集群里面配置一个web hook，这个web hook 就可以做到一个容器应用的重新部署。

如此流程，从代码提交到镜像部署到应用拉起，就变成了一个非常自然非常简单的操作流程。这就是是一个最简单的一个持续交付链路。但是我们可以看到，在这条链路里面它可以很快的帮你完成一个交付流程的变更，其实这是 Devops 里边最重要的节省时间。那么质量保证是怎么来实现呢？质量保证分为两个部分，一个部分是代码质量的保证，另一部分是交付质量的保证。在这张图里边，我们并没有过多的体现代码质量是怎么保证，但是我们体现了这个这个交付质量是怎么保证的，因为每一个流程里边没有人员的介入，所有的地方都是通过自动化流程来进行交付的，所以无形降低了人员引入带来的交付出错的可能性，所以提高了这个交付流程的一个质量。

在后续的一些课程里面，我们会来讲解怎么去构建一个更复杂的一个交互系统，带有各种各样测试、质量保证和报告等等。可以以这种方式来进行一个完整的一个持续交付

然后这里有一个实例 AliyunContainerService/DevOps: 阿里云容器服务持续交付 (github.com) 是阿里云容器服务里边的一些 Devops 案例，然后包括我们团队之前写过的一些文章，然后包括有一些手把手的一些教程，可以帮助大家更好的来体验