在应用日常开发的过程中，不论是在测试、开发联调，还是实际构建发布的时候，我们都需要一定的指标去衡量技术产物的质量，从而判断技术产物是否符合质量标准，是否能够继续发布投产，如果不符合投产标准则拦截发布。从发布过程的角度，由于一般发布过程会收口到特定的CI流水线上，因此在做这类能力的时候，通常是采用开发一个特殊的质量红线原子的方案，集成到CI流水线当中，实现发布准入准出的原子能力。
准入准出质量红线能力的开发者，通常是DevOps中台，中台提供原子能力以及配置化的能力，用户可以根据自己的业务去配置相应的指标产出与拦截规则，也可以直接套用特定的模板来快速实现准入准出的效果。本文就来讨论，这类能力要开发出来，在技术实现上，需要做怎样的考虑跟设计。
首先，针对真实业务，要用到准入准出质量红线的话，可能会考虑以下场景：
- 日常开发提测，在代码提交MR时，通过MR的hook触发对最新代码的规范检查
- 代码检查需要关心一系列指标，包括：代码缺陷、代码安全、编码规范、重复代码、复杂度
- 不符合指标的情况下，显示被质量红线拦截，MR被阻止
- 版本转测时，保证代码质量与单元测试代码覆盖率符合要求
- 不符合指标的情况下，终止归档构件
- 用户采用脚本等方式，自定义发布红线指标与生成过程，不符合指标的，阻止发布流程
因此，从技术实现角度上，这里可以拆解成几个维度：
- 红线指标
- 指标设置：数值类型、比较符号以及阈值
- 适用节点：如bash脚本任务原子节点
- 指标大类：内置指标、自定义指标
- 指标业务类型：代码检查、测试、安全等
- 开放范围：项目内适用还是全局适用
- 指标生成方式约定
- 红线规则
- 引用了什么红线指标
- 包含哪些准入准出规则
- 拦截审批机制
- 自动/人工审批，超时处理
- 触发拦截后，终止CI流水线，周知相关人员
- 执行记录
- 拦截报告：业务、结果明细、处理人、处理结果、处理原因
- 数据分析：各业务的拦截/逃逸率以及原因分析
从业务侧的角度，最关心的内容是【拦截报告】。作为最终输出产物，拦截报告需要有详尽的信息帮助业务决定发布内容是否符合预期。在拦截报告的实现当中，有几点细节需要体现：
- 即时通知：拦截的通知，可以是邮件或者IM群，但一定要周知到对应的人
- 如果存在告警，需要有不同级别的告警机制
- 拦截原因：在哪个步骤拦截，因为什么被拦截
- 拦截明细：拦截的指标中，具体有哪些地方报错，相关的内容跟数值指标是什么
- 问题分析：不论指标是否通过，对于全部扫出来的问题，按照优先级划分
- 让开发者知道哪些问题需要优先修复，防止部分指标通过但其中仍遗留严重问题的情况
- 修复指引：需要通过什么方式，才能修复拦截的问题
- 这一点比较重要，能够直接强化拦截指标的效力
好比说，针对代码检查场景，不同的编程语言，可能对应不同的代码检查工具，比如Clang、Coverity、ESLint这些，但即便如此，代码检查的结果都是统一的。作为开发者，需要了解到，哪里的代码出了问题，这些问题如何修复排查，以及相对于以前的报告，减少或者新增了什么问题。大多数线上问题都由变更产生，因此详细了解检查问题信息，包括与历史问题的对比，都是在拦截报告中，很需要突出的内容。
最后，准入准出质量红线的原子能力，针对红线指标、红线规则、拦截告警方面，都可以抽象固化出通用的样板间，让业务得以快速接入跟配置。这样能够显著减少落地成本，提升落地效率。