开发者学堂课程【ALPD 云架构师系列：云原生 DevOps 36计-阿里云云效出品：云原生时代的软件持续交付实践】学习笔记，与课程紧密连接，让用户快速学习知识。
课程地址：https://developer.aliyun.com/learning/course/772/detail/13495
云原生时代的软件持续交付实践
内容介绍：
一、什么是持续交付实践
二、持续、快速、高质量、低风险发布的要求
三、基于云和云原生技术的持续交互实践
四、标准化的产业链
五、持续交付流水线
六、可信发布
七、享受持续交付的红利
八、总结
一，什么是持续交付实践
持续交付是业务快速响应的的基础
持续交付，就是持续地交付 ( Continuous Delivery is Deliver Continuously )
持续—分散均匀的，而不是集中批量的
快速—过程快速即时的
高质量—过程要有质量保证
低风险—安全、合规、可信
持续交付是为了业务快速响应而产生的，也就是说持续交付是业务快速响应的的基础。从字面意义上来讲就是持续的交付。
持续交付怎么理解？
首先，持续交付是持续的，不是一个一个波峰而是均匀的。也就是每一次都是分散的过去，不会是突然一个很高的波峰集中批量发过去，然后停下之后又来一个波峰。持续交付是快速的，整个交付的过程很快，整个交付的频率很高。要做到持续交付，就要能够保证质量。
所以持续交付，一定要做到高质量，为了保证这个高质量，整个过程都需要有一个质量保证。整个交付，又必须是低风险的，尤其在现在的互联网环境下，风险无处不在，整个研发的全链路，中间会有各种各样的安全风险，而且基本都出现过。
那在持续交付过程中，怎么去解决低风险的问题？要做到安全合规，并且可信。
二，持续、快速、高质量、低风险发布的要求
有了持续交付任务，该怎么做到持续交付呢？
要做到持续、快速、高质量、低风险，但是分别要做到什么样才能是我们认为的持续、快速、高质量、低风险呢？
第一个是持续。发布力度要很小，如果力度很大，基本上很难做到持续，同时频率要高，这样高频的小力度发布，才能把线拉匀。
第二个是快速。首先就是工序是很短的，也就是每一个阶段，比如测试、发布、开发，整个阶段都是很短的，这样才能够做到快速的反馈，快速的响应。同时就是工序和工序之间工序和其他流程之间的等待很短。比如我们不需要等一个联调或者一个协同发布，这种情况会变得尽可能的少，这样才能做到快速。就是反馈很快，比如当提交代码之后，会在两分钟之内接收到其中存在的问题，需要另外修复，然后在一分钟之内修复完了之后很快又接受到修复成功的信息，就像这样的一个非常快速的反馈。
第三个是高质量，首先这个质量是能够看得见的，可以知道现在这个软件质量是什么样的。有时候衡量做的如何，就要看质量，所以可见质量非常重要。高质量软件的可靠性要高。另外一个是缺陷要少，就是整个软件要按照预期的设计是会有很多简单的缺陷的。最后是故障，每次软件故障，可能带来的不仅仅是客户的损失，也是整个软件团队的一个损失，因为会损失很多客户的机会，也就会损失很多的业务资产。
第四个就是低风险，首先就是要知道软件的风险，所以第一最重要的点就是可观测，能够知道这个软件当前是什么样子的。然后整个软件的发布是可控的。第三个问题是可以回溯的。如果真的出现了发布问题或者软件发生了故障，能够回溯整个问题的来源的：从哪里开始？从哪里引入？能够回溯起来。最后一个就是系统可回滚的，如果真的无法解决或者没法快速解决，能够快速把它回滚掉，以避免造成更大的风险。
持续交付只有满足了这四个方面，才能做到持续。他们基本上是缺一不可的。
三，基于云和云原生技术的持续交互实践
三方面，首先一个是希望基础设施可以做到不可变，有了这些东西之后要发布一个完整的端到端的链路。就是需要建立一个持续交互的流水线，它一定程度上是把整个软件交互的一个过程全部完整的串接在一起。中间不能是连不上的，否则就不叫流水线。另外一个就是发布是安全可信的，比如把质量合规，安全，包括业务规则相应的一些事情都放在这里，会发现其实相应的一些测试，无论是分层还是其他的一些测试方式，因为它在整个软件交互的整个过程里，那就可以认为在整个软件交互的过程，是为了不断让你的制品（制品就是产生出来，最后要交付的交付的东西）的质量越来越高。所以把整个过程分成三款，一个就是不改变基础设施。另外一个持续交互流水线，还有安全可信，那么在这个基础上，就可以做很多事情，比如说架构的一些管控，服务的一些治理。包括变更流程收敛一致性。还有人的安全管控跟面向终态运维的一些方式，都可以在这里完成。
四，标准化的产业链
如上图的这本书，叫做集装箱改变世界，这本书讲述的是，五六十年前的码头上的场景跟现在是不一样的，当时码头运货是一个一个的货运站，就一列货车到达之后，会有人去把货车上的东西卸下来，堆到货运站的货场上，所以比如有那种黄沙、水泥、水果等散装的货物，干这些活的人非常辛苦。当时的码头工人也是这个样子，因为以前构造比较老的船，摆货也是个问题，所以在当时怎么运货是很痛苦的。但是后来，有人发明了集装箱，就是一个固定尺寸的，一个铁箱子。但是集装箱做了一个标准化的，有了集装箱之后，嗯，所有的吊车、运输、储藏，如何在穿上装运，以及船的尺寸都是根据集装箱来去设计的，这样可以让集装箱在船上吊装非常方便。同时因为不需要码头工人手工把货物运出来，所以有了集装箱之后，把集装箱吊上来，然后拉走即可，这样它就形成了一个完整的一个产业链，就是基于集装箱的一个产业链。这样的后果就是它带来了整个货运成本的降低95%。就是旧集装箱以及它所带来的一整套的产业链的升级所带来的后果就是整个货运成本降低百分95%。所以在几十年前，人们认为跨国生产是不合算的，因为成本太高，但是现在就非常便宜了。做这个事情会带来一个后果，就是整个经济全球化就有了基础，因为我们可以把订单发送到全世界各个地方。
举个例子，软件以前的情况是什么样的，知道以前的那个开发语言构建，方式是各种各样，但是它的打包方式是不一样的，那么运营方式也不一样，整个管理方式也会不一样。所以就像用原来老的方式运货一样，卸货的时候要知道现在是什么货。如果卸错了，比如卸水果的时候像卸沙子一样，往外扔，那水果可能就坏了，这样就会很难受。
那么当有容器之后，其实就是在有容器之前，就有很多种运维工具，部署工具，也做了很多尝试，但是都不太成功。为什么呢？因为容器做了一个标准化。然后有容器之后，基于容器又做了比如像 K8S 这样的，就是把整个分发做了然后，整个的去部署运维。那个体系做了整个运行的环境，又基于它有各种各样的云原生的数据库，云原生的消息中介，云原生的整个的一些标准就出来了。然后就会发现就像以前集装箱带来的改变一样，整个的研发体系的基础部分就标准化了。就可以用相同的方式去对待，不同方式写的程序。这个就降低了大量的成本。所以因为它不可变，消除了不一致带来的不确定性。第二个，可以减少不一致的风险，这个风险很难预估。例如：你向一个 java 程序里面运行程序。大部分是对的，但是在某些情况下会出现异常，而这个异常的原因是因为java程序里面它包了一个 SO 这个 SO 依赖一个 library 的版本，刚好运行环境里面，这个版本有一点差别，这个差异刚好让这个程序运行产生异常。这种情况下就会发现这个风险非常难排查，而且这个风险带的后果很严重。第三个，维护成本降低，因为很多东西都由底层的东西标准化了。
标准化的后果：就是标准化会带来什么？第一个就是整个的部署简化。第二个就是整个的环境维护成本降低。第三个就是整个工具链的开发和学习成本降低了。所以这个就是不可变基础设施给我们的非常大的一个技术红利。
五，持续交付流水线
持续交付流水线，上图是一条非常典型的一条流水线。整个流水线简化来看，从代码提交到合并，会做构建，生成一个制品。生成制品之后会做接口测试，会做功能验证如果这些都通过了，会进入到一个类生产环境去做部署和验收工作，如果都完成了之后，就可以部署了生产环境了。流水线是整个串起来的一个过程，也就是中间不会产生断头，它是要一层一层往后走的，而且不会跳过。有了流水线之后，整个的理想情况是假如我 git push 一下。如果代码质量很好。自动化率很高，那么整个事情都是完全可以自动搞定的。比如可能在两分钟或者一小时之后告诉我上线成功了。
然后不是随便去建一个流水线它就可以达到目的，因为流水线是有一定的要求的。
1.可描述
流水线应该是一个可描述的东西，就流水线本身是一个研发模式的一个具象化的一个表达，通过流水线可以描述这个研发模式。第二，流水线保证了发布流程的一致性，也就是流水线的每次发布是一样的，没有任何的区别。第三个，这个最佳实践可以快速的复制。比如说在一个公司里面，不同的团队的研发实践差别非常大有时候哪怕是挨着的两个团队，它们的差别非常大，因为它们都是靠文档去做的，而文档里面的东西是靠人去掌握的，这个东西的学习成本和它的掌握程度是很不一样的。但是流水线可以让它快速的复制。
2、可观测
整个流水线应该是可观测的，这个可观测意味着整个开发发布过程是可以看到的。不仅仅是当前的，发布过程和开发过程都是可以看到的，历史的发布过程，开发过程也是可以看到的，每一次的发布经过了怎么样的阶段，每个阶段是什么结果，都应该是可以看到的。有了这个之后就可以知道整个流程是什么样子，整个流程的质量是什么样子，中间哪个节点有可能是出现问题的。第二个是整个发布过程是要有保障的。就是整个流水线中间有很多的验证节点，很多的接口测试，很多的预发的验收。那这些节点带来的成本都都不小，但是它的目的是为了保证最后的发布上线是一个成功的，稳定的。所以在这个可观的前提下，整个发布过程就有了一个保障。
3、自动化
整个流水线应该是自动化的，意思就是不应该或者尽量减少人工在这里面的干预程度。比如流水线，应该是完整的串起来的，而不应该是分成好几段的。因为当分成好几段的时候，每一段之间的衔接是靠人的，一旦靠人，那么中间的等待时，以及它的协同的成本就会比较高，就会带来各种各样的一个风险，所以应该做到整个发布过程是完全自动化的，完全自动化意味着从代码提交过到最后上线是完全的有一个流水线牵动的。当然中间可能有些布置需要人去做验收或者测试，但是这只是一个工序，完成之后，就可以保证成功了，或者通过这个工序就可以自动的往下进行，所以整个过程是一个自动化的过程。同时整个流程，是一个由工具来落地的，就是说不是通过写在文档里，每一个部分都是一个描述，到了这部分通知你干什么了，接下来回来后再去做什么。这个是不行的，整个东西应该是通过工具串起来的。
六，可信发布
降低发布风险：防止缺陷带来业务损失；降低发布心智负担。
获得质量反馈：让质量看得见、提升发布信心；快速获得反馈、提升开发效率。
可信发布就是一个代码，一个配置或者一个依赖性的一个变化。其实都会引发最后制品的一个改变。那这个制品的改变会经过一系列的一个过程，比如说流水线，经过一系列的流水线，一定系列的节点，这个节点中间有很多需要去验证和关注的点和管控的点。比如会有代码审查、测试验证，代码评审，有发布的管控，中间会有很多的规则，会关注很多的检测项，比如代码质量和验证，安全等。然后这些规则加上这些检测项，最终会给我们一个反馈，说名这次发布是不是可信的？如果它是有问题的，那就不应该发布。如果不是，那就可以往下进行。
那作为可信发布来讲呢？
首先，它是能够降低整个发布的风险，防止整个缺陷带来的业务损失，更重要的是降低发布带来的心智负担。比如不敢发布。希望能够通过这个去获得一个质量的反馈，让质量是能够看得见的。就有当一个发布信息能够快速的获得反馈，这样当这个反馈足够快速的时候，整个开发效率就会比较高。因为可以及时的去反馈，及时的去修复。
七，享受持续交付的红利
认为做好持续交互，可以带来很多的红利。
1、消除对个人的依赖
比如其实可以消除对个人的一些依赖。比如我们常说的可见可控，然后可度量可加速，我们希望所有东西都是可见的。
2、降低团队之间的损耗
另外一个就是降低团队之间的损耗。流程一致了，所有的东西，版本也是一致的。
例如：有一家公司，他们的发布是直接从个人电脑发布的，这样就不知道今天在生产环境跑的版本来自于哪一个电脑，尤其是当出现故障的时候，也不知道当时是哪一个版本。
3、降低测试成本，提升质量
降低测试成本，测试要做测试，自动化，需要投入人力来去做一些测试自动化的维护。这样就会提高成本，但是只有自动化的设施，它可以不断的重复的来去运行，而手工测试的它的重复成本是特别高的，因为机器是廉价的，如果把测试和质量保证的方式集成在整个持续集成发布的一个流水线上，那其实很容易降低这个成本。对在做工程的来说，可以去做一些相应的工具或者方式方法，去快速的去做一些问题的定位排查，尤其现在架构下出现问题，就可以知道是哪个服务的问题，那如果有很清晰很方便的定位排查手段，也是可以提升整个成本的。
4、降低发布风险
最后就是降低发布的风险，如果版本是可以回溯跟追溯，而且版本一致性比较好。那么对于发布的风险也相对来说会有很好的一些控制。而且也可以根据跑出来的这些可信的规则引擎来去做相应的判断确定哪一个版本应该发到哪里去，包括发布的一些策略，也会做定义。
八、总结
1、2个挑战1个机遇
2、持续产品交付是响应业务的关键
3、持续交付能力是持续产品交付的基础
4、持续交付是持续交付，即持续、快速、高质量、低风险地发布
5、持续交付必须从三个方面落实：不可变基础设施、持续发布流水线及安全可信发布
