编者按：本文源自阿里云云效团队出品的《阿里巴巴DevOps实践指南》，扫描上方二维码或前往：https://developer.aliyun.com/topic/devops，下载完整版电子书，了解阿里十年DevOps实践经验。
为保证软件交付的质量，我们对交付物有功能和性能上的要求。这些要求体现在交付过程中产生的数据上，包括：代码评审数据、安全扫描数据、回归测试结果等。这些数据以交付物（制品）为载体。我们把这些数据称作制品的元数据。
什么是元数据?
元数据指一经产生就不会变化的数据。元数据是由系统产生，具有不可篡改和可回溯的特点，因而成为发布过程中的必要基础数据。
元数据为何重要?
为说明元数据的重要性，先举个例子。阿里中台应用在架构上依赖很多业务团队的二方包，这些二方包质量往往难以把控。那怎么来解决呢?
一种改进方法就是从单个应用维度，到应用依赖树维度更”全景”更”立体”展示数据。以代码评审为例，在中台应用的制品中，包含很多业务团队开发的二方包。而在评审中台应用时，只会看到 pom 文件中的二方包的版本号变了，看不到具体的代码变化。对于评审者，需要看到这些版本号背后的代码变化，以及与这些代码变化相关的信息，如相关的需求、有没有通过代码检测、单元测试结果等。
一个应用运行时的依赖大部分在构建时就决定了。运行时问题很多是由依赖引起的。让构建依赖(树)产生新价值，从而实现风险左移。
元数据主要有哪些?
除了在构建阶段取到的依赖树，我们还有其它数据，如测试产生的质量数据，安全扫描产生的安全数据。这些数据我们都会存放到"元数据中心"，再通过"管控策略中心"，利用这些数据对交付过程做自动化的卡点。这一流程通常包括可见、可控、可信三个阶段。
- "可见"是给用户展现元数据中心的数据，给用户透出交付过程的风险与瓶颈。
- "可控"是给用户根据看到的问题后，再设置规则来实现自动化检测与门禁。
- "可信"则是结合"合规安全扫描服务"与"制品仓库"能力，完成数据与规则的融合，实现交付安全。
从可见到可控，再到可信，最后达到提升交付效率的目标。与此同时，元数据与规则不断演进，慢慢沉淀成知识库，成为公司最重要的资产之一。
以元数据为基础实现可信发布
上图展示了可信发布的架构，可以看到可信发布以元数据为中心，基于制品，持续生产和消费元数据，配合各类自动化的门禁规则，做到持续、可靠、安全地发布。
元数据分为两类：包本身的元数据、包的血缘关系数据。
包本身的元数据
包本身的元数据包括包的基本信息，如：构建信息、质量数据、安全扫描数据等。除了这些基本信息外，还包括通过元数据协议写入的三方数据。
元数据详情
评分体系
一个制品，如一本书或一部电影一样，可以评分。以二方库 jar 包为例，评分可以指导 jar 包的"使用方"引用最佳质量版本的 jar 包。
评分包括：1. 系统评分，2. 用户评分。评分是针对制品的某个版本的。
其中，系统评分满分 10 分，主要根据以下几点来判断：
- 是否符合代码规约，每有一条不满足就扣一分;
- 是否符合核心指标，每有一条不满足就扣一分;
- 是否通过官方平台发布，如不是，直接扣分；
- 是否有安全漏洞，如有，则扣分；
- 运行时的动态指标，如启动耗时，启动时内存消耗等；
- 业务测试用例指标，如单元测试覆盖率/成功率；
- 被引用数，一定时间段被越多的应用使用，会加分。
用户评分是开发者对这个制品的评价，某些制品系统评分很高，但是接口设计不合理，依赖多，使用方可以给较低的用户评分，推动制品的持续改进。
血缘关系的元数据
一个大制品，是由多个小制品组成的。制品与制品存在依赖与组合等多种关系。制品的血缘关系，也就是制品的依赖数，评分高的依赖版本会被推荐使用。
自动推荐版本升级
元数据如何有效使用?
元数据除了在交付流程中用于各节点的准入与准出外，还可以帮助进行制品治理。制品治理基于元数据的“洞察”和“态势”两大能力。
- 洞察：告诉团队主管如何治理，帮助团队主管找到哪些制品，或哪些自己的子团队需要优先治理。
- 态势：经过治理后，制品质量的趋势是什么样的，帮助团队主管看治理力度与治理效果。
以 jar 包(二方包)治理为例。
洞察
二方包核心指标包括：依赖深度，依赖总数，版本总数。团队主管可以在"洞察报表"中选择自己的团队，找到最需要优化的二方包，进行针对性重点优化。
如何选择"三高"对象
重点治理对象一般是"三高"对象，即依赖深度等级过高，依赖总数等级过高，版本总数等级过高的二方包。如下图中，"com.taod:feent"是典型的三高对象，需要优先，重点治理。
发现三高制品
如何找到"元凶"
因依赖深度，依赖总数是对 GA 最后一个 release 版本且有被应用依赖的二方包，所以要选择符合这条件的二方包版本，如下图:
确定"元凶"
接下来，我们查看"依赖树详情"，再分析，因为有可能自己的二方包也是因为引用了一个"三高"二方包，而导致自己"三高"的，在"依赖树详情"中，就可以找到它，而它可能就是"元凶"。
在找到"元凶"后，一般这样处理:
- 联系"元凶"二方包的负责同学，进行优化。
- 先去掉它的一些没使用到的间接依赖。
态势
态势报表主要体现以下两个方面:
- 如对制品没治理，那包括风险等质量问题会如何恶化?
- 如对制品进行了治理，那治理的效果如何。如效果不好，则再引申出是治理的方法有问题，还是治理的力度不够?
态势分析
元数据在持续交付流程中的应用
我们会根据历史出现过的故障，及安全、测试质量等要求，对一次发布中的制品及它的依赖进行扫描。并基于制品的元数据分析，将发布的风险进行分类，并提示用户如何修复。
流程中风险提示
风险详情
风险等级
风险按照严重等级分为高危、中危和低危，其中高危和中危需要重点关注。等级定义如下：
高危
- 本地发布的 snapshot 更新
- release 版本号降低
- 新增的 release 包有依赖 snapshot 包含有 x86 的 so 的 jar 包用于非 x86 的服务器上
中危
- 新增相同 ga，不同 version 的依赖
- 新增了 snapshot
- 前后二个版本代码删除过多
风险检测流程
首先会在"正式发布"时卡最后一道关，然后基于风险修复成本，将风险检测尽可能提前。
最后一道关卡
小结
从基于代码的交付到基于制品的交付，其核心区别在于制品是完整和不可变的。这样基于制品及其元数据构建的持续交付体系，可以做到可信发布，极大地提升发布效率、降低发布风险。
免费下载《阿里巴巴DevOps实践指南》
阿里巴巴合伙人和业界多位大佬力荐、何勉、陈鑫等17位阿里资深技术专家联袂出品、阿里十年DevOps经验沉淀总结、阿里巴巴DevOps落地实践一本通。
前往：https://developer.aliyun.com/topic/devops，下载完整版电子书。
