开发者学堂课程【ALPD 云架构师系列-云原生 DevOps36计：云原生时代的软件持续交付实践（一）】学习笔记，与课程紧密联系，让用户快速学习知识。
课程地址：https://developer.aliyun.com/learning/course/82/detail/1265
云原生时代的软件持续交付实践（一）
内容介绍：
一、持续交付的特点
二、如何做到持续交付
三、基于云和云原生技术的持续交付实践
四、持续交付流水线
五、可信发布
六、持续交付的红利
七、小结
一、持续交付的特点
云原生大时代软件的对交付实践应该的运用。
持续交付，从任何角度讲，其实是为了那个业务快速响应而产生的，持续交付是一个业务快速响应的基础。从字面意义上来讲就是持续的交付。
首先它是一个持续的，而不是一个一个的波峰，是均匀的；然后每一次都是分散的过去，而不是说我可能突然以波峰形势集中批量发过去；同时，持续交付还意味着它是快速的，整个的交付过程是很快的，交付频率很高的；交付，不是发上去然后再撤回来，交付要能够保证质量。所以说持续交付首先它要一定要做到高质量。
除了高质量以外，整个过程也需要质量保证；交付必须是低风险的，尤其是在现在的联网环境下，风险无处不在的。后面会有当年就专门聊安全的话题，你会发现其实整个研发的全链路中间都存在各种各样的安全风险，而且都报出来过。在交付过程中如何解决低风险的问题，即要做到安全合规、可信合规。大家可以肯定很有体感，尤其是最近因为中美各种各样的事情，合规问题越来越重要的。安全、可信同样是非常关键的一个内容。
二、如何做到持续交付
整个持续交付的要求包括：持续、快速、高质量、低风险，这样四块。
1. 持续
（1）发布力度一定要是很小。如果力度很大，基本上很难做到持续：如果一个大批量一发过来，可能整个涉及的时间就几天，这样是不行的。
（2）频率要非常高。这样的话，使用高频的小力度发布，才能够把一条线拉匀了。
2.快速
（1）首先工序是很淡短的。每一个阶段，比如说测试、发布、开发等整个阶段都是很短的。这样的话才能够做到快速的一个反馈和响应。
（2）工序和工序之间、工序和其他流程之间的等待少。比如不会去等一个联调要等一个协同发布。只有这种等待的情况变得尽可能的少，才能够到快速。
（3）反馈要快。比如提交代码之后，在两分钟之内会告诉我，这次的提交又遇到了一个什么样的问题，必须尽快修复它，然后在一分钟之内修复完了之后，马上提示修改成功了，即非常快速的反馈。
2. 高质量
（1）质量可见性。质量是要能够看得见的，要知道现在这个软件质量是什么样子。很多时候衡量我们做的好不好，首先要满足要能够看到它。所以可见性是非常重要的。
（2）软件的可靠性高。比如刚说提及的99.99%，如果乘以十次方，已经变得很低了，它的功能非常高了。为了做到很高的可靠性，阿里每年双11都是为这个做了很多努力。
（3）缺陷要少。整个软件是要按照预期的设计去运行，而不是有很多潜在的缺陷存在。
（4）故障要。软件故障每次可能带来的不仅仅是客户的一个损失，也是软件团队的损失。这会导致很多的客户的机会、很多的业务资产就损失掉了。
4.低风险
（1）最重要的是要可观测。要知道这软件当前是什么样子的。
（2）软件发布可控的。后面专门聊发布的时候，会详细谈这个发布可控这个问题。
（3）可回溯。如果真的出现了发布问题，或者说软件的某个故障，是要能够回溯这整个问题的来源的，比如从哪开始、从哪个地方引入的，这些都需要能够回复起来。
（4）回滚。如果真的解决不了，或者没法快速解决，把它回滚掉，以避免说造成更大的一个风险。
持续、快速、高质量、低风险，这是我们认为做持续交付需要做到的四个方面。就是只有满足这四个方面，才能做到持续交付。基本上这四方面是缺一不可的，有很多时候力度小、频率高，是基于快速的做持续的前提，而且相对来说只有质量高的风险才会低一些。
如何做到持续交付？
有一位上海的小伙伴说：现在很多时候都是云原生架构，降低了中小企业的成本和复杂度。大部分基础工作都是被项目平台接管了，可以谈谈从事工程效能的未来的方向吗？
我觉得这里其实是说，做效能工作的、或者说做这些事情，很多时候我们会发现其实要去做到这些地方，是有特别多的机会去做。有很多非常现实的问题。刚刚那位同学也说，现在云原生平台把很多事情都做完了，可能原来需要做很多底层，但现在事情就不用做了。但是现在的微服务，整个的体系数量完全跟原来不一样，所以在上层的服务治理的需求还在，而且发布的质量、发布的风险这些问题都是非常现实要去解决的。就从这个角度来说，我们不会去因为站在课程的体系，觉得要去做到交付实现只要从三方面去做就可以了，太多其他的内容也没有必要的。
三、基于云和云原生技术的持续交付实践
基础。我们希望基础设施可以做到不可变，有了这些东西，刚才提到的要发布的一个链路，要端到端完整，需要建立一个持续交互的流水线。持续交付流水线一定程度上是把整个软件交付的过程全部串进去，是完整的串联起来的。此外，不能说把他分成两段，而且中间是连不上的，这个就不叫流水。
安全核心的发布。像质量合规安全、包括业务规则上的事情都包含在这里。相应的一些测试，包括无论是分层，还是其他的测试方式，因为它是在整个软件交付的过程里，所以我们认为在整个软件交付的过程里是要不断让进行自评。自评就是产生出来你最后要交付的东西。自评的质量在软件交付的过程中越来越高。按张刚老师以前说的，它是价值增值的活动，把整个价值增值的活动所有的串起来，越到后面价值越高。
所以说在整个过程里，我们把它分成三块：顾客面基础设施、协调或者缺陷、安全科技化。
在这个基础上，可以去做很多的事情：比如说像架构的管控、服务的治理，包括变更流程这种一次性的过程。类似安全管控、面向综合的这些应用类型方式，在这里都可以去做。阿里也对云原生做出了相应的一些实践，包括在做相应的技术探索；一些产品的工具等。未来我们可以在这方面做一些更详细的交流。
每一块里头具体是什么，为什么要去做到这个边界，要做到一个什么样的标志，我们平常会聊一下这块。
一本书叫做集装箱改变世界，这本书说了在五六十年前的故事。我经常看到他们货运站很忙的样子：一列货车到了之后，有人去把货车上东西都卸下来，同时两边调整一下，把这些货又运到当时货运车的货场上。所以会发现其中什么样东西都有，比如说有黄沙，是散的；水泥，承包的；还有水果那种装箱的，每个东西都不一样。所以干这个活的人非常辛苦，他们都是整个身体都是那种非常强壮，但是会很累。当时码头工也是这个样子，因为一个船过来船的那个构造，老式的整个船的船舱里面摆着货物，运货是很痛苦的。
后来就有人发明了集装箱这个东西：集装箱其实看起来很简单，就是一个箱子，一个固定尺寸的一个铁箱子。但是集装箱的箱子就是做了一个标准化的事情。首先有集装箱之后，同时产生了吊车、运输、储藏和船上的研发。
整个船该怎么装，船的尺寸都是根据集装箱来去设计的，所以我可以让这个集装箱在船上吊装非常方便。同时码头的工人不需要去手工的把里面各种各样的货运出来。因为像沙子和水果是完全不同的东西，运输方式是非常非常难的，所以有了集装箱之后就不用管了，只需要把集装箱吊上来再拉走就可以了。
所以它形成了一个完整的产业链，就是基于集装箱的一个标准产业链，这样的话带来什么后果：整个货运成本的降低95%。就是集装箱以及它所带来的这些那个一套的产业链的升级，所带来的后果就是整个货运成本降低95%，因为在几十年前跨国的那个生产是不划算的，因为成本太高了。但是现在非常便宜，那就可以做这个事情。整个经济全球化就有这个基础，因为可以把这个订单送到到全世界各个地方。
再来看这个问题，就是说我们软件以前的情况什么样的。以前的开发语言构建方式是各种各样的，比如说一个 iPhone 程序，打的是一个大包；另外一个是要编译成一个安全式文件的，可能还有诸如 PHP 等各种各样的程序，它的打包方式都不一样、它的运营方式也不一样，整个管理方式都不一样。
所以就像我们原来在老的方式下去运货一样的，卸货的时候得知道卸的什么货。如果卸错了，比如说卸水果的时候，要像卸沙子一样往下扔，就可能会扔坏了，所以这是一个非常现实的问题。那么当有容器这个问题起来之后，在容器之前，还有很多运维工具、部署工具，都做了很多尝试，但是都不太成功，因为容器做了就像我们那个集装箱做的一样事情，它做了标准化。
然后有了容器之后，基于容器，又把分发做了，然后把整个的部署运维的体系做了以及运行的环境。
1. 各种各样云原生的数据库、消息，中介语言性的一些标准就出来了，就像那个集装箱带来的改变一样，整个的研发体系的基础部分就标准化了。用相同的方式去对待，不管是用 Python 写的程序，还是勾写的程序，还是用 loss 写的程序，都完全是一样的，着降低了我们大量的成本。
首先因为它不可变，带来的影响就是消除了不一致带来的不确定性。相信很多人以前可能经历过这样的，或者现在也经历过这样的。
2. 减少不一致的风险，这个风险很难预估。之前遇到过一个 bug 就是像 Java 程序，里面大部分数据是是对的，但是在某些情况下出现了异常，异常的原因是因为它 Java 程序里面包了一个 so，这个 so 依赖一个 library 的版本，刚好硬环境里的版本是有一点差别，这个小版本的差异导致行为是有异常的。这种情况下会发现风险非常难排查，而且风险带来后果很严重。
3.维护成本降低了。就刚刚那个同学说的就是说我现在实现云原生了，运维的成本比原来低的很多。很多事情不需要运维再去做了。确实是这样，因为无论什么都会有底层的东西，包括标准化。标准化使用使整个部署简化了，都是用同样一套东西，就像集装箱一样，吊起来反正都那么大，都往上丢，直接就就运走了。
环境维护成本的降低了，因为是集装箱，而且是标准化的，所以不需要有太多的薪酬负担，只要遵照这个标准，放到既定的位置上就行了。因为只有一种形态了，整个工具链的开发、学习成本就相应的降低了。所以不可变基础设施，带给我们的非常大的技术红利。
目前，生态越来越完整，整个成本、研发的成本也在降低。但是这个地方，对大家也是一个挑战：原来的习惯，原来的思维方式或者工作方式也发生了变化。
因为可能用原来的方式再去套在线上面就会产生一些问题，比如说容器可能就是默认他是虚拟的，尽量用。那很多东西就不再是一个集装箱了，还是集装箱里塞了一些沙子。另外，比如说还是把自己当做码头工人的话，那就意味着也要做一些变革，你的脑子要去改一下，比如我能不能成为是货车司机、或者吊车司机。
四、持续交付流水线
这是一个非常典型的流水线。如果简化来看，大概就是从代码提交到合并；然后上去之后会做构建以生成一个制品；之后会做接口测试，会做功能验证。如果这些都通过了，会进入到一个类生产环境去做部署和验证、验收。完成以上步骤就可以上线了，部署到市场环境里。流水线它是一整个串起来的一个一个的过程，就是中间不会说产生断头的概念，是一层一层往后走的，而且是不会跳过的。有了这个流水线之后，可以看出理想的情况是什么样的。如果这个代码质量很好，自动化率很高，整个事情都是完全可以自动搞定的，它就会自动在两分钟之后或者说一小时之后告诉我成功了。
这个是一个非常美妙的体验，因为我的工作不会打扰我，然后会直接告诉我发布完成了。但是流水线不是说像云校一样，建一个流水线，它就可以达到这个目的的。
1. 流水线需要能够可表述：
（1）研发模式的具象化表达。流水线是一个可描述的东西，它本身是一个研发模式的具象化的表达。研发模式的展现，我们是通过流水线或者其他一些手段来把它描述出来的。
（2）发布流程一致性。流水线保证了发布流程的一致性。当拥有流水线之后，每次发布要是一样的，流程是一样的，没有任何的区别。
（3）最佳实践可快速复制。很多时候我们会发现，在一个公司里面不同团队的研发实践差别非常的大，很多东西是口口相传或者说文档里的。当在文档里的时候，在一家几十人的公司，哪怕是挨着的两个团队，在发布这个事情上面，它的差别都非常大，因为他们都是靠文档去做的，文档里面的东西是靠人去掌握的。学习成本和掌握程度是不一样的。
刚好有人提到 ducument的这件事情，其实对于流水线，你可以认为它就是拉一个ducument的问题，把这个流程用文章描写出来，还不如直接落在工具里头，让他活在那里。即不是落在纸上需要人去维护的东西，而是它就天然在运行，天天在启动的一个东西
2.流水线需要能够可观测：
（1）开发、发布过程可见。整个开发发布过程是可以看到的，不仅仅是当前的开发过程可以看到；历史的发布过程、开发过程也是可以看到的。每一次的发布经过了怎么样的阶段；每个阶段是什么结果，我都应该是可以看到的。有了这个之后，我可以知道我整个的流程是什么样子、整个流程的质量是什么样子，中间哪个节点是有可能出现问题的
（2）发布过程有保障。发布过程保障意味着在整个流水线里，我们看到了有很多的验证节点、很多的接口测试、很多的预发的验收。所有这些节点它带来的成本都不小，但是它的目的是为了保证最后发布上线是成功的、是稳定的，所以在这个可观测前提下，整个发布过程就有了一个保障。
3.流水线需要能够自动化：
（1）发布过程自动化。自动化就是不应该，或者尽量减少人工在这的干预程度。比如说一直在提的流水线应该是完整的串起来的，而不应该是分成好几段的。
当你分成好几段的时候，每一段之间的衔接是靠人的，一旦靠人的时候，中间的等待市场以及协同的成本就会比较高，会带来各种各样的一个风险。所以我们应该做到整个发布过程是完全的自动化。完全自动化意味着从代码提交，或者某个事件开始，到最后上线，是完全有流水线牵动的。中间有可能有些布置需要人去做验收，或者做测试，但是这只是一个工序，工序完成之后点个确定，保证说成功了，就会可以自动的往下发。所以整个过程是自动化的。
（2）流程通过工具落地。而不是通过写在文档里，或者说每一个部分都是描述，通知要干什么了，才去干一下；接下来回来再去做什么，这样是不行的。整个东西应该是通过工具串起来的，这个工具可能包括很多。
