【测试人生】准入准出质量红线的技术设计

在应用日常开发的过程中,不论是在测试、开发联调,还是实际构建发布的时候,我们都需要一定的指标去衡量技术产物的质量,从而判断技术产物是否符合质量标准,是否能够继续发布投产,如果不符合投产标准则拦截发布。从发布过程的角度,由于一般发布过程会收口到特定的CI流水线上,因此在做这类能力的时候,通常是采用开发一个特殊的质量红线原子的方案,集成到CI流水线当中,实现发布准入准出的原子能力。

准入准出质量红线能力的开发者,通常是DevOps中台,中台提供原子能力以及配置化的能力,用户可以根据自己的业务去配置相应的指标产出与拦截规则,也可以直接套用特定的模板来快速实现准入准出的效果。本文就来讨论,这类能力要开发出来,在技术实现上,需要做怎样的考虑跟设计。

首先,针对真实业务,要用到准入准出质量红线的话,可能会考虑以下场景:

  • 日常开发提测,在代码提交MR时,通过MR的hook触发对最新代码的规范检查
    • 代码检查需要关心一系列指标,包括:代码缺陷、代码安全、编码规范、重复代码、复杂度
    • 不符合指标的情况下,显示被质量红线拦截,MR被阻止
  • 版本转测时,保证代码质量与单元测试代码覆盖率符合要求
    • 不符合指标的情况下,终止归档构件
  • 用户采用脚本等方式,自定义发布红线指标与生成过程,不符合指标的,阻止发布流程

因此,从技术实现角度上,这里可以拆解成几个维度:

  • 红线指标
    • 指标设置:数值类型、比较符号以及阈值
    • 适用节点:如bash脚本任务原子节点
    • 指标大类:内置指标、自定义指标
    • 指标业务类型:代码检查、测试、安全等
    • 开放范围:项目内适用还是全局适用
    • 指标生成方式约定
  • 红线规则
    • 引用了什么红线指标
    • 包含哪些准入准出规则
    • 拦截审批机制
      • 自动/人工审批,超时处理
      • 触发拦截后,终止CI流水线,周知相关人员
  • 执行记录
    • 拦截报告:业务、结果明细、处理人、处理结果、处理原因
    • 数据分析:各业务的拦截/逃逸率以及原因分析

从业务侧的角度,最关心的内容是【拦截报告】。作为最终输出产物,拦截报告需要有详尽的信息帮助业务决定发布内容是否符合预期。在拦截报告的实现当中,有几点细节需要体现:

  • 即时通知:拦截的通知,可以是邮件或者IM群,但一定要周知到对应的人
    • 如果存在告警,需要有不同级别的告警机制
  • 拦截原因:在哪个步骤拦截,因为什么被拦截
  • 拦截明细:拦截的指标中,具体有哪些地方报错,相关的内容跟数值指标是什么
  • 问题分析:不论指标是否通过,对于全部扫出来的问题,按照优先级划分
    • 让开发者知道哪些问题需要优先修复,防止部分指标通过但其中仍遗留严重问题的情况
  • 修复指引:需要通过什么方式,才能修复拦截的问题
    • 这一点比较重要,能够直接强化拦截指标的效力

好比说,针对代码检查场景,不同的编程语言,可能对应不同的代码检查工具,比如Clang、Coverity、ESLint这些,但即便如此,代码检查的结果都是统一的。作为开发者,需要了解到,哪里的代码出了问题,这些问题如何修复排查,以及相对于以前的报告,减少或者新增了什么问题。大多数线上问题都由变更产生,因此详细了解检查问题信息,包括与历史问题的对比,都是在拦截报告中,很需要突出的内容。

最后,准入准出质量红线的原子能力,针对红线指标、红线规则、拦截告警方面,都可以抽象固化出通用的样板间,让业务得以快速接入跟配置。这样能够显著减少落地成本,提升落地效率。

你可能感兴趣的:(测试人生,准入准出,质量红线,DevOps,CI)