Fork me on GitHub

一个好的持续交付流水线是怎样的?

图片

作者 | 张燎原、张裕
文章来源 | 阿里巴巴云效团队

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

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

图片

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

持续发布流水线

图片

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

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

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

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

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

一个好的流水线是怎样的?

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

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

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

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

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

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

流水线应用举例

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

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

图片

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

图片

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

图片

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

图片

右上角的“1-1-1”是我们的愿景:我们希望做到1个小时的发布前置时长,从代码提交到发布到生产1个小时完成,我们希望每天至少有1个可发布的版本,我们希望每一个应用每周至少发布1次。

“1-1-1”能够帮助我们去发现在整个集成发布过程当中存在的问题:为什么不能做到1小时的发布前置时长?由哪些原因导致的?这时就需要找到问题的关键所在,其实是给自己设定一个目标,然后再看现状。现状跟目标之间有一段距离,这个距离就是需要解决的问题。

有了基于云效的Codeup、Flow,也可以构建其他的交付模式,比如说移动APP的持续交付模式。

图片

另一个是Web应用,常见的云的服务端的发布。

图片

或者是前端,直接把相应的前端构建物发送到CDN,这些都是比较常见的发布流程。

图片

总结

  • 发布是将软件特性增量交付给最终用户的过程;
  • 软件交付需要做到准确、低成本及高效;
  • 持续部署应该:准确、可预期的部署结果;部署过程不影响线上服务;有持续可部署的软件增量;及低成本、高效地部署发布;
  • 准确地部署需要明确的待发布制品,明确的运行环境及明确的发布过程和发布策略;
  • 无服务中断的部署过程需要做到滚动式部署、部署可观测、可干预及可回滚;
  • 软件增量应该是完整的,可验证的及可独立部署发布的单元;
  • 低成本、高效的部署发布需要减少发布批量及保障发布的顺畅性
  • 持续发布流水线是规模化规范团队软件发布的有效手段,软件的发布过程应该做到可见、可控、可加速、可度量。

本文地址:https://www.6aiq.com/article/1647091802609
本文版权归作者和AIQ共有,欢迎转载,但未经作者同意必须保留此段声明,且在文章页面明显位置给出