阿里巴巴DevOps实践指南(十八)| 基于制品元数据提升交付效率

阿里巴巴DevOps实践指南(十八)| 基于制品元数据提升交付效率

编者按:本文源自阿里云云效团队出品的《阿里巴巴DevOps实践指南》,扫描上方二维码或前往:https://developer.aliyun.com/topic/devops,下载完整版电子书,了解阿里十年DevOps实践经验。

为保证软件交付的质量,我们对交付物有功能和性能上的要求。这些要求体现在交付过程中产生的数据上,包括:代码评审数据、安全扫描数据、回归测试结果等。这些数据以交付物(制品)为载体。我们把这些数据称作制品的元数据。

什么是元数据?

元数据指一经产生就不会变化的数据。元数据是由系统产生,具有不可篡改和可回溯的特点,因而成为发布过程中的必要基础数据。

元数据为何重要?

为说明元数据的重要性,先举个例子。阿里中台应用在架构上依赖很多业务团队的二方包,这些二方包质量往往难以把控。那怎么来解决呢?

一种改进方法就是从单个应用维度,到应用依赖树维度更”全景”更”立体”展示数据。以代码评审为例,在中台应用的制品中,包含很多业务团队开发的二方包。而在评审中台应用时,只会看到 pom 文件中的二方包的版本号变了,看不到具体的代码变化。对于评审者,需要看到这些版本号背后的代码变化,以及与这些代码变化相关的信息,如相关的需求、有没有通过代码检测、单元测试结果等。

一个应用运行时的依赖大部分在构建时就决定了。运行时问题很多是由依赖引起的。让构建依赖(树)产生新价值,从而实现风险左移。

元数据主要有哪些?

除了在构建阶段取到的依赖树,我们还有其它数据,如测试产生的质量数据,安全扫描产生的安全数据。这些数据我们都会存放到"元数据中心",再通过"管控策略中心",利用这些数据对交付过程做自动化的卡点。这一流程通常包括可见、可控、可信三个阶段。

  • "可见"是给用户展现元数据中心的数据,给用户透出交付过程的风险与瓶颈。
  • "可控"是给用户根据看到的问题后,再设置规则来实现自动化检测与门禁。
  • "可信"则是结合"合规安全扫描服务"与"制品仓库"能力,完成数据与规则的融合,实现交付安全。

从可见到可控,再到可信,最后达到提升交付效率的目标。与此同时,元数据与规则不断演进,慢慢沉淀成知识库,成为公司最重要的资产之一。

阿里巴巴DevOps实践指南(十八)| 基于制品元数据提升交付效率
以元数据为基础实现可信发布

上图展示了可信发布的架构,可以看到可信发布以元数据为中心,基于制品,持续生产和消费元数据,配合各类自动化的门禁规则,做到持续、可靠、安全地发布。

元数据分为两类:包本身的元数据、包的血缘关系数据。

包本身的元数据

包本身的元数据包括包的基本信息,如:构建信息、质量数据、安全扫描数据等。除了这些基本信息外,还包括通过元数据协议写入的三方数据。

阿里巴巴DevOps实践指南(十八)| 基于制品元数据提升交付效率
元数据详情

评分体系

一个制品,如一本书或一部电影一样,可以评分。以二方库 jar 包为例,评分可以指导 jar 包的"使用方"引用最佳质量版本的 jar 包。

评分包括:1. 系统评分,2. 用户评分。评分是针对制品的某个版本的。

其中,系统评分满分 10 分,主要根据以下几点来判断:

  1. 是否符合代码规约,每有一条不满足就扣一分;
  2. 是否符合核心指标,每有一条不满足就扣一分;
  3. 是否通过官方平台发布,如不是,直接扣分;
  4. 是否有安全漏洞,如有,则扣分;
  5. 运行时的动态指标,如启动耗时,启动时内存消耗等;
  6. 业务测试用例指标,如单元测试覆盖率/成功率;
  7. 被引用数,一定时间段被越多的应用使用,会加分。

用户评分是开发者对这个制品的评价,某些制品系统评分很高,但是接口设计不合理,依赖多,使用方可以给较低的用户评分,推动制品的持续改进。

血缘关系的元数据

一个大制品,是由多个小制品组成的。制品与制品存在依赖与组合等多种关系。制品的血缘关系,也就是制品的依赖数,评分高的依赖版本会被推荐使用。

阿里巴巴DevOps实践指南(十八)| 基于制品元数据提升交付效率
自动推荐版本升级

元数据如何有效使用?

元数据除了在交付流程中用于各节点的准入与准出外,还可以帮助进行制品治理。制品治理基于元数据的“洞察”和“态势”两大能力。

  • 洞察:告诉团队主管如何治理,帮助团队主管找到哪些制品,或哪些自己的子团队需要优先治理。
  • 态势:经过治理后,制品质量的趋势是什么样的,帮助团队主管看治理力度与治理效果。

以 jar 包(二方包)治理为例。

洞察

二方包核心指标包括:依赖深度,依赖总数,版本总数。团队主管可以在"洞察报表"中选择自己的团队,找到最需要优化的二方包,进行针对性重点优化。

如何选择"三高"对象

重点治理对象一般是"三高"对象,即依赖深度等级过高,依赖总数等级过高,版本总数等级过高的二方包。如下图中,"com.taod:feent"是典型的三高对象,需要优先,重点治理。

阿里巴巴DevOps实践指南(十八)| 基于制品元数据提升交付效率
发现三高制品

如何找到"元凶"

因依赖深度,依赖总数是对 GA 最后一个 release 版本且有被应用依赖的二方包,所以要选择符合这条件的二方包版本,如下图:

阿里巴巴DevOps实践指南(十八)| 基于制品元数据提升交付效率
确定"元凶"

接下来,我们查看"依赖树详情",再分析,因为有可能自己的二方包也是因为引用了一个"三高"二方包,而导致自己"三高"的,在"依赖树详情"中,就可以找到它,而它可能就是"元凶"。

在找到"元凶"后,一般这样处理:

  1. 联系"元凶"二方包的负责同学,进行优化。
  2. 先去掉它的一些没使用到的间接依赖。

态势

态势报表主要体现以下两个方面:

  1. 如对制品没治理,那包括风险等质量问题会如何恶化?
  2. 如对制品进行了治理,那治理的效果如何。如效果不好,则再引申出是治理的方法有问题,还是治理的力度不够?

阿里巴巴DevOps实践指南(十八)| 基于制品元数据提升交付效率
态势分析

元数据在持续交付流程中的应用

我们会根据历史出现过的故障,及安全、测试质量等要求,对一次发布中的制品及它的依赖进行扫描。并基于制品的元数据分析,将发布的风险进行分类,并提示用户如何修复。

阿里巴巴DevOps实践指南(十八)| 基于制品元数据提升交付效率
流程中风险提示

阿里巴巴DevOps实践指南(十八)| 基于制品元数据提升交付效率
风险详情

风险等级

风险按照严重等级分为高危、中危和低危,其中高危和中危需要重点关注。等级定义如下:

高危

  • 本地发布的 snapshot 更新
  • release 版本号降低
  • 新增的 release 包有依赖 snapshot  包含有 x86 的 so 的 jar 包用于非 x86 的服务器上

中危

  • 新增相同 ga,不同 version 的依赖
  • 新增了 snapshot
  • 前后二个版本代码删除过多

风险检测流程

首先会在"正式发布"时卡最后一道关,然后基于风险修复成本,将风险检测尽可能提前。

阿里巴巴DevOps实践指南(十八)| 基于制品元数据提升交付效率
最后一道关卡

小结

从基于代码的交付到基于制品的交付,其核心区别在于制品是完整和不可变的。这样基于制品及其元数据构建的持续交付体系,可以做到可信发布,极大地提升发布效率、降低发布风险。

免费下载《阿里巴巴DevOps实践指南》

阿里巴巴合伙人和业界多位大佬力荐、何勉、陈鑫等17位阿里资深技术专家联袂出品、阿里十年DevOps经验沉淀总结、阿里巴巴DevOps落地实践一本通。

前往:https://developer.aliyun.com/topic/devops,下载完整版电子书。

阿里巴巴DevOps实践指南(十八)| 基于制品元数据提升交付效率

上一篇:阿里巴巴DevOps实践指南(十九)| 监管控一体化运维


下一篇:阿里云生态合作伙伴优秀案例:大山深处的网约车