做到这 4 点，才是真正的持续交付| 研发效能提升 36 计

者按：全线专栏《研发效能提升 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 个层面，逐一深入， 通过系列文章，为大家一一讲解。

也欢迎在评论区与作者互动，说出你想听到的内容～

点击下方链接立即体验云效持续交付流水线 Flow。

https://www.aliyun.com/product/yunxiao/flow?channel=yy_rccb_36