一个好的持续交付流水线是怎样的（ | 研发效能提升36计）阿里云云原生云计算持续交付

文章图片

策划&编辑｜雅纯
上一讲我们讲了持续部署的4个目标：准确可预期的部署结果、部署过程不影响线上服务、有可持续部署的软件增量、低成本和高效地部署发布，并分析了如何做到。
可是，有了好的持续部署实践，如何才能规模化落地呢？

文章图片

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

如上图所示，我们可以看到，从最早拉取代码、构建、验证、部署，整个过程是一个逐级递进的过程。如果代码发生变化，或配置发生变化，或代码依赖发生变化，流水线将会被重新触发。从拉取代码开始，直至流程执行完成或中断。我们会按照构建的配置来构建制品，将制品保存到制品仓库，产生构建产物，接下来我们会基于构建产物做验证，验证通过就可以进入部署，部署成功就意味着这个特性已经被成功发到了线上的运行环境中。
在图中我们增加了几个部分，包括研发管理平台、配置中心、监控中心、运维发布平台。
在最简化的流水线里面我们看不到这些，但是在大家的实际工作当中会存在这几个概念：

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

这样，我们通过流水线跟我们现有的研发系统就形成了有机的整合，以达到高效发布的目的。
一个好的流水线是怎样的既然流水线是如此重要的载体，一个好的流水线应该是什么样的呢？
首先，流水线应该是可描述的，流水线可以像一幅画或者一项工作那样被具象化出来。特别重要的是流水线可以具象化表达研发模式，通过流水线保证发布流程的一致性。基于流水线可以把实践快速复制，如应用同一条流水线的模板就可以应用同一个实践。
第二，流水线应该是可观测的。整个发布过程发到哪、发了什么、中间有什么问题、成功还是失败，是可观测的，并且这个观测是和监控打通的，这样就可以保证发布过程有保障。
第三，整个过程是自动化的。比如构建完不需要到验证阶段再手动触发，整个过程是自动流转的。流程应该建立在工具的基础上，不依赖人，这就是自动化。
以从右到左、面向终态的思维来看，我们的终态是有一个稳定可预期的系统，为此需要找到一个稳定可预期的软件的制品版本，达到一致性的环境，再去进行部署。
部署的时候要符合上一讲所说的4个原则。无论是持续集成、持续测试，无非是要获取确定的软件制品，然后按照4个原则部署上去，所有的这些能力和活动都是为了最终的目标来服务的。
流水线应用举例我们结合例子来看一下确定持续交付流水线的整个过程。
首先是模板。我们会在团队或者是公司层面有一些最佳实践的模板，比如说有
JAVA后端应用的流水线模板，流程上从代码扫描开始，执行测试，然后是构建和部署。有了这个模板之后，可以在团队内所有JAVA后端应用间复用。

文章图片

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

文章图片

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

文章图片

下面是我们基于云效做的DevOps方案大图。云效包含完整的DevOps研发工具链。以需求的角度，在任务看板里面拿到相应的开发任务就可以开始开发，提交代码，然后在代码层面做检测和安全扫描，接着执行构建，集成，验证，最后上线。

文章图片

右上角的“1-1-1”是我们的愿景：我们希望做到1个小时的发布前置时长，从代码提交到发布到生产1个小时完成，我们希望每天至少有1个可发布的版本，我们希望每一个应用每周至少发布1次。
“1-1-1”能够帮助我们去发现在整个集成发布过程当中存在的问题：为什么不能做到1小时的发布前置时长？由哪些原因导致的？这时就需要找到问题的关键所在，其实是给自己设定一个目标，然后再看现状。现状跟目标之间有一段距离，这个距离就是需要解决的问题。
【一个好的持续交付流水线是怎样的（ | 研发效能提升36计）】有了基于云效的Codeup、Flow，也可以构建其他的交付模式，比如说移动APP的持续交付模式。