如何基于制品元数据提升交付效率 | 阿里巴巴 DevOps 实践指南

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

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

什么是元数据?

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

元数据为何重要?

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

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

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

元数据主要有哪些?

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

• "可见"是给用户展现元数据中心的数据，给用户透出交付过程的风险与瓶颈。

• "可控"是给用户根据看到的问题后，再设置规则来实现自动化检测与门禁。

• "可信"则是结合"合规安全扫描服务"与"制品仓库"能力，完成数据与规则的融合，实现交付安全。

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

以元数据为基础实现可信发布

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

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

包本身的元数据

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

元数据详情

评分体系

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

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

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

1. 是否符合代码规约，每有一条不满足就扣一分;

2. 是否符合核心指标，每有一条不满足就扣一分;

3. 是否通过官方平台发布，如不是，直接扣分；

4. 是否有安全漏洞，如有，则扣分；

5. 运行时的动态指标，如启动耗时，启动时内存消耗等；

6. 业务测试用例指标，如单元测试覆盖率/成功率；

7. 被引用数，一定时间段被越多的应用使用，会加分。

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

血缘关系的元数据

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

自动推荐版本升级

元数据如何有效使用?

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

• 洞察：告诉团队主管如何治理，帮助团队主管找到哪些制品，或哪些自己的子团队需要优先治理。

• 态势：经过治理后，制品质量的趋势是什么样的，帮助团队主管看治理力度与治理效果。

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

洞察

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

如何选择"三高"对象

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

发现三高制品

如何找到"元凶"

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

确定"元凶"

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

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

1. 联系"元凶"二方包的负责同学，进行优化。

2. 先去掉它的一些没使用到的间接依赖。

态势

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

1. 如对制品没治理，那包括风险等质量问题会如何恶化?

2. 如对制品进行了治理，那治理的效果如何。如效果不好，则再引申出是治理的方法有问题，还是治理的力度不够?

态势分析

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

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

流程中风险提示

风险等级

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

高危

• 本地发布的 snapshot 更新

• release 版本号降低

• 新增的 release 包有依赖 snapshot  包含有 x86 的 so 的 jar 包用于非 x86 的服务器上

中危

• 新增相同 ga，不同 version 的依赖

• 新增了 snapshot

• 前后二个版本代码删除过多

风险检测流程

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

最后一道关卡

小结

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

【关于云效】

云效，云原生时代一站式BizDevOps平台支持公共云、专有云和混合云多种部署形态，通过云原生新技术和研发新模式，助力创新创业和数字化转型企业快速实现研发敏捷和组织敏捷，打造“双敏”组织，实现 10 倍效能提升。

立即体验