共计 3261 个字符，预计需要花费 9 分钟才能阅读完成。
简介：全线专栏《研发效力晋升 36 计_继续交付篇》上线啦！本专栏将通过 10-20 篇文章，零碎分享云原生时代，企业如何落地继续交付。本文是该专栏的第 2 篇。什么是真正的继续交付？
编者按：全线专栏《研发效力晋升 36 计_继续交付篇》上线啦！本专栏将通过 10-20 篇文章，零碎分享云原生时代，企业如何落地继续交付。本文是该专栏的第 2 篇。
什么是真正的继续交付？
首先，咱们先看一下什么是继续交付。咱们认为，继续交付至多应该蕴含这 4 点：
● 继续：顾名思义，是平均的、扩散的。具体来说是要：
粒度小：继续公布的粒度肯定要很小，大了便很难做到“继续”。
频率高：公布频率要十分高。
● 疾速：继续交付中整个的交付过程是很快的，交付频率也是很高的。要做到疾速须要。
工序短：在测试、公布、开发等各个阶段中都要做到“短”。这样能力做到疾速地反馈、疾速地响应。
期待少：工序和工序之间、工序和其余流程之间的期待应做到“少”。
反馈快：提交代码后，应在尽短时间内反馈此次提交的问题，应尽快修复问题再尽快失去又一次的修复反馈。
● 高质量：继续交付是要可能保证质量的，肯定要做到高质量。高质量须要保障：
品质可见性：判断做得好不好，首先咱们要看到它，所以可见性是十分重要的。
缺点少：软件应是依照预期设计去运行的，而不是有很多潜在的缺点在外面。
故障少：每次软件故障带来的不仅仅是客户的损失，也是软件团队的损失。很多客户机会、业务资产会因为故障太多而白白损失掉。
● 低危险：在当初的互联网环境下，危险无处不在，所以咱们要做到平安、合规且可信。
软件可观测：要晓得软件的危险，最重要的一点就是可观测，晓得软件以后是什么样子的。
公布可控：咱们后续会专门讲到。
问题可回溯：如果呈现了公布问题或软件故障，咱们可能回溯整个问题的起源。从哪开始、从哪个中央引入的，都须要能回溯起来。
零碎可回滚：如果有问题真的解决不了或没法疾速解决，咱们须要可能疾速把它回滚掉，以防止造成更大的危险。
以上是继续交付的 4 个关键点，只有满足了继续、疾速、高质量、低危险这 4 点才是实现了继续交付。这 4 点是缺一不可的。粒度小、频率高，是疾速的前提。相应地，只有品质高了，危险才可能低一些。
问题是：如何做到呢？
基于云和云原生技术的继续交付
咱们认为，云原生时代，要实现继续交付须要做到这 3 点：不可变基础设施、继续交付流水线、平安可信公布。
1、不可变基础设施
有一本书叫做《集装箱扭转世界》。这本书讲述了集装箱的创造让本来系统涣散的货物运输体系变成以集装箱为单位，并由此带来了整个货运老本的 95% 的升高。
如果咱们看软件交付，以往咱们的开发语言构建形式是各种各样的，程序的打包、运行、治理形式也都不一样，这些不同使得咱们的软件交付面临着很大的危险。
在容器呈现之前，大家在运维工具、部署工具上做了很多尝试，然而都不太胜利，整体也不如容器风行。其起因便是容器做的就像集装箱做的事件——标准化。
基于容器咱们又做了 K8S，做了容器的散发和整个部署运维体系，运行的环境也做掉了。在此基础上，诞生了各种各样的云原生的数据库、云原生的中间件。这样云原生的整体规范就进去了。就像集装箱带来的扭转一样，研发体系实现了标准化，由此咱们便能够以雷同的形式去看待不同技术栈写出的程序。
整体来看，不可变基础设施的利用为咱们带来了以下几点“红利”：
（1）打消了不统一带来的不确定性：以前一个程序换了一个环境可能就跑不动了，其中的问题便是底层呈现了不统一带来的 bug。
（2）缩小不统一的危险：危险很难预估。像一个 Java 程序外面，你大部分跑的是对的，然而在某些状况下，它会出现异常，小版本的差别会产生更多异样的危险。这种状况下你会发现危险是十分难排查的，而且危险带的结果很重大。
（3）缩小保护老本：因为很多底层的货色被标准化了，就不必咱们去做了。比方 K8S 就做了很多这样的事件。
（4）部署简化了：都是同样一套货色，就像集装箱一样，运输就是了。
（5）环境保护老本升高了：广泛应用标准化后便不须要有太多的累赘，只有遵循这个规范就行。
（6）工具的开发和学习老本的升高了。
不可变基础设施带给咱们十分大的技术红利，咱们生态越来越残缺。只是这时，咱们原来的习惯、思维或者工作形式都要发生变化。
2、继续交付流水线
继续交付流水线肯定水平上是把咱们的整个软件交付的过程残缺地串接在一起。
上图展现的是一个十分典型的流水线：从代码提交到合并、构建、生成一个制品、接口测试、性能验证、类生产环境部署验证到最终验收、上线。
这个流水线是一个残缺的过程。没有间断、没有跳过，是一层层往后走的。
有了这个流水线之后，如果代码品质很好、自动化率很高，整体就会主动地在很短的工夫内告知咱们上线胜利。这是一个十分美好的体验，晦涩而省力。
要想达到下面晦涩的体验，咱们对流水线是有要求的，具体来说有如下几点：
（1）可描述性
流水线是研发模式的具象化表白：流水线应该是一个可形容的货色。研发模式其实是通过流水线或其余一些伎俩形容进去的。
公布流程的一致性：有了流水线之后，每次的公布流程都是一样的。
最佳实际可疾速复制：在一个公司里，不同团队的研发实际差异往往十分大，因为很多货色是在口口相传或者是文档里的，不同的人对其中内容有不同的把握、解读形式。然而流水线能够实现疾速的复制。把流程用文章写进去不如让它落实在流水线中成果好。
（2）可观测性
开发、公布过程可见：在流水线中，不仅仅是以后的公布、开发过程是能够看到的，历史公布过程、开发过程也是能够看到的。每一次的公布通过了哪些阶段、每个阶段是什么后果，都是能够看到的。如此便能够晓得整个流程是什么样子，整个流程的品质是什么样子，两头哪个节点有可能呈现问题。
公布过程有保障：整个流水线中咱们看到有很多的验证节点、接口测试、预发验收。所有这些节点的老本都不小，然而它们却能保障最初公布上线的后果是胜利的、稳固的。如此，有了流水线的使用，整个公布过程就有了保障。
（3）自动化
自动化顾名思义就是尽量减少人工在过程中的干涉。若每一次阶段间的连接是靠人工实现的，它两头的期待时长以及它的协同老本就会比拟高，会带来各种各样的危险，所以咱们应该做到整个公布过程是齐全自动化的。从代码提交到最初上线，全过程是齐全由流水线牵动的。即便两头有些步骤须要人去做验收或者测试，然而这也只是一个工序。这个工序完了之后执行人点个确定，说我验收胜利了，之后就会主动地往下发。因而，整个过程是一个自动化的过程。
3、平安可信公布
在软件交付中，一个代码、配置，甚至是一个依赖的变动，都会引发制品的扭转。制品的扭转会通过流水线的一系列节点。这些节点两头有很多须要去验证、关注和管控的点，例如代码审查、测试验证、评审、公布管控；也会有很多的规定、检测项，例如代码品质合规、平安检测。
这些规定加上这些检测项，会最终造成一个反馈，表明这次公布是不是可信的。如果反馈有问题，那就不应该公布，如果反馈没有问题那便能够持续往下走。
作为平安可信公布来讲，首先它要可能升高公布的危险，避免缺点带来的业务损失。更重要的是升高公布的心智累赘，不会不敢公布。
同时，通过平安可信公布咱们能够取得品质的反馈，让品质是看得见的。让咱们能做到及时反馈、及时修复，整个开发效率就会变高。
享受继续交付的红利
继续交付能够带来很多的益处，例如：
（1）打消对集体的依赖：所有的信息都是共享的，可见、可控、可度量、可减速
（2）升高团队之间的损耗：流程统一，所有版本统一，呈现故障时更好解决。
（3）升高测试老本、晋升品质：自动化的测试是能够回归的，能够一直地运行的，也能够反复的，老本远低于手工测试。在微服务架构下如果呈现问题，也能够更清晰、不便地定位。
（4）升高公布危险：版本能够回溯，一致性也比拟好，因此公布危险也会很好地被管制。另外，有了可信公布的反对，整体的公布成功率也会更有保障。
接下来咱们将从：不可变基础设施、继续交付流水线、平安可信公布 3 个层面，逐个深刻，通过系列文章，为大家一一解说。
原文链接
本文为阿里云原创内容，未经容许不得转载。
