3. 质量门禁基础概念：什么是质量门禁、门禁类型

质量门禁（Quality Gate）是部署流水线中的一道“自动化检查关卡”。它通过预设的规则集，在代码提交、配置变更或发布动作执行前进行校验，只有通过校验的变更才能进入下一阶段。其核心目标是：在故障发生前拦截风险，缩短故障恢复时间（MTTR）。

3.1 质量门禁的定义与作用

质量门禁可类比为高速公路上的“ETC 收费站”：车辆（变更）必须通过电子识别（自动化检查），若符合条件（门禁通过）则快速放行；若不符合（门禁失败）则被引导至检修区（回滚或修复），避免在主干道上造成拥堵（生产故障）。

3.2 门禁类型：代码门禁、配置门禁、发布门禁

根据检查对象和阶段的不同，质量门禁可分为三类。它们共同构成从开发到上线的完整防护网。

3.2.1 代码门禁（Code Gate）

代码门禁作用于开发阶段，在代码合并（Merge/Pull Request）时触发。它确保提交的代码符合团队约定的质量基线。

• 检查项示例：静态代码扫描（SonarQube）、单元测试覆盖率（≥80%）、代码风格检查（Lint）、安全漏洞扫描（SAST）。
• 阻断策略：若新增代码引入“阻断级”漏洞或测试覆盖率下降超过阈值，则禁止合并。
• MTTR 关联：将缺陷拦截在开发环境，避免流入集成测试或生产环境，从源头降低故障恢复成本。

3.2.2 配置门禁（Config Gate）

配置门禁作用于配置变更阶段，在配置项（如数据库连接串、限流阈值、特性开关）被修改时触发。它是配置发布故障快速恢复的关键防线。

• 检查项示例：配置格式校验（YAML/JSON Schema）、值范围校验（端口号 1024-65535）、依赖一致性检查（引用的服务实例是否存在）、变更影响范围分析（Diff 对比）。
• 阻断策略：若配置格式错误、值越界或引用了不存在的资源，则禁止生效。
• MTTR 关联：配置错误是生产故障的常见原因（如误将“false”写为“flase”）。配置门禁可在秒级发现此类问题，避免因配置错误导致的大规模服务中断。

3.2.3 发布门禁（Release Gate）

发布门禁作用于上线阶段，在版本发布或灰度推送前触发。它综合评估当前系统状态，决定是否允许变更进入生产环境。

• 检查项示例：生产环境健康检查（CPU/内存/错误率基线）、灰度验证结果（金丝雀发布通过率）、依赖服务可用性、变更审批状态。
• 阻断策略：若生产环境存在未恢复的告警、灰度指标异常或依赖服务不可用，则暂停发布。
• MTTR 关联：发布门禁是故障恢复的“最后一道闸门”。它确保在已知故障未解决时，不会叠加新的变更，避免故障扩散和恢复时间延长。

3.3 门禁类型对比

3.4 质量门禁在流水线中的位置

下图展示了三类门禁在典型部署流水线中的执行顺序与协作关系：

3.5 门禁规则配置示例

以下是一个配置门禁的 YAML 规则示例，用于校验数据库连接配置的合法性：

# config-gate-rules.yaml
version: "1.0"
gates:
  - name: "database-config-validator"
    type: "config"
    trigger: "on_change"
    checks:
      - field: "database.host"
        required: true
        pattern: "^[a-zA-Z0-9.-]+$"
        error_message: "数据库主机名格式错误"
      - field: "database.port"
        required: true
        range: [1024, 65535]
        error_message: "端口号必须在 1024-65535 之间"
      - field: "database.connection_timeout"
        required: false
        default: 5000
        range: [1000, 30000]
        error_message: "连接超时时间必须在 1000-30000ms 之间"
    action_on_failure: "block_and_notify"