3. 质量门禁基础
3.1 什么是质量门禁
质量门禁（Quality Gate）是软件交付流水线中预设的一组自动化检查规则集合。当代码或制品通过某个阶段时，门禁会依据预定义的阈值对关键质量指标进行判定，只有全部检查通过，流水线才能继续向下游推进。门禁的本质是“卡口”——它将主观的“代码质量不错”转化为客观的“指标数值是否在允许范围内”。
核心定义：质量门禁 = 检查规则 + 阈值 + 触发时机 + 阻断/告警动作。它确保只有满足最低质量标准的变更才能进入生产环境或下一阶段。
在误差预算（Error Budget）与数据一致性治理场景中，质量门禁承担着双重角色：
- 技术角色：阻止因配置错误或数据质量劣化导致的SLO（服务等级目标）违规。
- 治理角色：强制台账数据（如误差预算消耗、门禁阈值记录）在流水线各环节保持一致，避免人工核对。
3.2 门禁在CI/CD流水线中的位置
质量门禁并非孤立存在，它嵌入在CI/CD流水线的关键节点中。下图展示了门禁在典型流水线中的部署位置及其与误差预算台账的交互关系。
从图中可以看出，质量门禁通常部署在以下关键位置：
| 门禁位置 | 阶段 | 检查重点 | 与误差预算的关系 |
|---|---|---|---|
| 门禁 #1 | 代码提交后、构建前 | 代码规范、单元测试覆盖率、静态分析 | 验证变更是否引入新的技术债务，间接影响未来误差预算 |
| 门禁 #2 | 集成测试后、部署预发前 | 制品签名、依赖漏洞、配置一致性 | 检查配置项是否与台账中的阈值定义一致 |
| 门禁 #3 | 预发验证后、生产发布前 | 预发环境SLO达成率、误差预算消耗率 | 直接判定当前误差预算是否允许发布 |
3.3 门禁的典型触发条件
质量门禁的触发条件决定了“何时执行检查”。根据触发方式的不同，可分为以下三类：
设计原则：触发条件应覆盖所有可能引入质量风险的变更入口，同时避免过度触发导致流水线阻塞。推荐采用“事件驱动 + 定时补充”的组合策略。
3.3.1 事件驱动型触发
由CI/CD流水线中的特定事件自动触发，是最常见的模式：
- 代码推送（Push）：开发分支或主分支有新的commit提交时触发门禁检查。
- 合并请求（Merge Request / Pull Request）：创建或更新MR/PR时触发，通常作为预合并检查。
- 标签创建（Tag）：创建版本标签（如v1.2.3）时触发，常用于发布前的最终门禁。
- 人工审批通过：某些高风险变更需要人工确认后，门禁才执行后续检查。
3.3.2 定时触发
按照固定时间周期执行门禁检查，用于发现渐进式质量劣化：
- 每日基线检查：每天凌晨对主分支执行一次全量门禁，生成质量报告。
- 每周SLO审计：每周对误差预算台账进行一致性校验，确保门禁阈值与SLO定义匹配。
- 月末结算触发：在误差预算重置周期（如每月1日）前，强制触发一次全量门禁，冻结当月数据。
3.3.3 条件组合触发
将多个条件通过逻辑运算组合，实现更精细的控制：
| 组合条件 | 逻辑表达式 | 典型场景 |
|---|---|---|
| 主分支推送 + 非文档变更 | branch == "main" AND file_path != "docs/*" |
仅对主分支的代码变更执行门禁，跳过文档更新 |
| MR创建 + 目标分支为release | event == "mr_created" AND target_branch == "release/*" |
只有向发布分支提MR时才触发部署前门禁 |
| 定时触发 + 误差预算消耗率 > 70% | schedule == "0 6 * * *" AND error_budget_consumption > 0.7 |
当误差预算消耗超过70%时，每日早晨额外触发一次门禁检查 |
下图展示了三种触发条件在流水线中的协作关系：
常见误区：不要将所有门禁都设置为“每次提交都触发”。高频触发会显著增加流水线耗时，且对误差预算台账产生大量写入压力。建议将全量检查放在定时触发中，事件驱动只做增量检查。
3.4 门禁与误差预算台账的数据一致性要求
在误差预算治理场景中，质量门禁的阈值配置必须与台账记录保持严格一致。以下是需要对齐的关键字段：
| 台账字段 | 门禁配置字段 | 一致性要求 | 校验方式 |
|---|---|---|---|
| SLO目标值（如99.9%） | 门禁阈值上限 | 完全相等 | 每次门禁触发时读取台账最新值 |
| 误差预算总量 | 门禁消耗率分母 | 完全相等 | 定时审计脚本比对 |
| 当前消耗量 | 门禁判定依据 | 实时同步（延迟 < 1分钟） | 门禁执行时调用台账API |
| 门禁阻断阈值（如消耗 > 80% 阻断） | 门禁规则参数 | 完全相等 | 变更审批时强制同步 |