一个好的持续交付流水线是怎样的？ | 研发效能提升 36 计

作者：阿里云云效

2022 年 3 月 03 日
本文字数：2482 字
阅读完需：约 8 分钟

策划 &编辑｜雅纯

上一讲我们讲了持续部署的 4 个目标：准确可预期的部署结果、部署过程不影响线上服务、有可持续部署的软件增量、低成本和高效地部署发布，并分析了如何做到。

可是，有了好的持续部署实践，如何才能规模化落地呢？

承载实践最好的方式就是工具。持续部署过程的最好载体就是流水线，因为持续部署本身就是一个逐级递进的流水线。

持续发布流水线

如上图所示，我们可以看到，从最早拉取代码、构建、验证、部署，整个过程是一个逐级递进的过程。如果代码发生变化，或配置发生变化，或代码依赖发生变化，流水线将会被重新触发。从拉取代码开始，直至流程执行完成或中断。我们会按照构建的配置来构建制品，将制品保存到制品仓库，产生构建产物，接下来我们会基于构建产物做验证，验证通过就可以进入部署，部署成功就意味着这个特性已经被成功发到了线上的运行环境中。

在图中我们增加了几个部分，包括研发管理平台、配置中心、监控中心、运维发布平台。

在最简化的流水线里面我们看不到这些，但是在大家的实际工作当中会存在这几个概念：

我们在执行流水线的时候，会跟研发管理平台做交互，比如是否有统一的构建规则；在整个公司的层面或者是部门的层面是否有统一的约束，比如代码的检测标准，可能是公司统一的，这些都会在研发管理平台维护。
配置中心是管理服务的特性开关和动态配置等，配置中心的配置是需要下发给运行中的服务的。
流水线的发布过程和监控中心打通，监控数据的变化，反过来会影响发布，所以整个流水线和监控需要做集成。这个集成可以通过人，但是更好的方式是通过工具链。
部署策略一般沉淀在运维同学的脑子里，或者是运维平台的工具里，这些策略要被应用到流水线上，部署过程当中流水线和运维发布平台有非常强的耦合。
另一个很重要的点，我们在运维平台上有很多安全策略和敏感信息，这些是不可以，或者是不能承载在流水线或者代码中的，需要通过运维发布平台做管控。

这样，我们通过流水线跟我们现有的研发系统就形成了有机的整合，以达到高效发布的目的。

一个好的流水线是怎样的

既然流水线是如此重要的载体，一个好的流水线应该是什么样的呢？

首先，流水线应该是可描述的，流水线可以像一幅画或者一项工作那样被具象化出来。特别重要的是流水线可以具象化表达研发模式，通过流水线保证发布流程的一致性。基于流水线可以把实践快速复制，如应用同一条流水线的模板就可以应用同一个实践。

第二，流水线应该是可观测的。整个发布过程发到哪、发了什么、中间有什么问题、成功还是失败，是可观测的，并且这个观测是和监控打通的，这样就可以保证发布过程有保障。

第三，整个过程是自动化的。比如构建完不需要到验证阶段再手动触发，整个过程是自动流转的。流程应该建立在工具的基础上，不依赖人，这就是自动化。

以从右到左、面向终态的思维来看，我们的终态是有一个稳定可预期的系统，为此需要找到一个稳定可预期的软件的制品版本，达到一致性的环境，再去进行部署。

部署的时候要符合上一讲所说的 4 个原则。无论是持续集成、持续测试，无非是要获取确定的软件制品，然后按照 4 个原则部署上去，所有的这些能力和活动都是为了最终的目标来服务的。

流水线应用举例

我们结合例子来看一下确定持续交付流水线的整个过程。

首先是模板。我们会在团队或者是公司层面有一些最佳实践的模板，比如说有 JAVA 后端应用的流水线模板，流程上从代码扫描开始，执行测试，然后是构建和部署。有了这个模板之后，可以在团队内所有 JAVA 后端应用间复用。

第二是团队统一管控和能力复用，比如统一定义某些环境变量，在运行中注入 Secret 或者账号信息，这些不希望在代码中明文存储，但是我们会通过工具注入下去。假设把 devops.test.local 作为我们自己的研发管理平台，我们可以通过类似上图的方式与之集成，我们也可以在平台里定义敏感信息，或者维护公共变量，然后在每一个流水线的步骤里面引用，达到全局复用的效果。

其次，流水线是具备观测性的。我们可以知道当下流水线的情况，最新的一次运行是否完成、有没有连续失败的情况等。从流水线视角可以看到一个 feature 从开发、集成到发布的整个阶段是什么样的，中间是否存在问题。比如图中的流水线从开发完到集成之间有很长时间的等待，这里可能存在阻塞，可以下钻进行进一步分析。