2. 质量门禁基础
2.1 质量门禁的定义与核心概念
质量门禁（Quality Gate）是嵌入在 CI/CD 流水线中的自动化检查点，用于在软件交付的特定阶段对制品或环境进行预定义的、可量化的质量评估。只有通过门禁检查的变更才能进入下一阶段，否则将被阻断或标记为风险。
门禁的本质是“契约”——开发、测试、运维三方共同认可的质量基线。它从“事后发现”转向“事前阻断”，将质量左移，降低修复成本。
关键特征：
- 自动化：无需人工干预，由流水线自动触发并执行检查脚本或调用质量平台 API。
- 可量化：所有检查项必须有明确的阈值（如：代码覆盖率 ≥ 80%，漏洞数 = 0）。
- 阻断性：失败的门禁会中止流水线，阻止低质量代码进入生产环境。
- 可追溯：每次门禁结果均记录在案，形成质量审计日志。
2.2 门禁在 CI/CD 流水线中的位置
质量门禁通常部署在流水线的关键转换节点上。根据交付阶段的不同，门禁可分为三类：提交门禁、集成门禁、发布门禁。下表展示了它们的位置与职责差异：
| 门禁类型 | 流水线阶段 | 检查对象 | 典型检查项 | 阻断策略 |
|---|---|---|---|---|
| 提交门禁 | 代码提交 → 构建前 | 代码变更（Commit） | 代码规范、静态扫描、单元测试通过率 | 阻断合并请求（MR/PR） |
| 集成门禁 | 构建 → 制品归档 | 构建产物（Artifact） | 构建成功率、依赖漏洞、制品签名校验 | 阻止制品进入制品库 |
| 发布门禁 | 制品 → 部署环境 | 部署包 + 环境配置 | 容量水位、性能基线、安全合规、配置漂移 | 阻止发布到目标环境 |
容量水位发布准入属于发布门禁的范畴。 它检查目标集群的 CPU、内存、磁盘、连接数等资源水位是否在安全阈值内，防止因发布导致系统过载。
2.3 门禁在流水线中的作用
质量门禁在 CI/CD 流水线中承担以下四个核心作用：
- 风险前置：在代码提交阶段即发现缺陷，避免缺陷流入集成测试或生产环境，降低修复成本（缺陷修复成本随阶段指数级增长）。
- 自动化决策：替代人工审核的“点头/摇头”环节，基于数据驱动发布决策，提升交付效率。
- 质量基线固化：将团队的质量共识转化为可执行的检查脚本，防止因人员流动或项目压力导致质量标准下降。
- 审计与回溯：每次门禁结果形成不可篡改的日志，为事故复盘、合规审计提供客观证据。
2.4 门禁在流水线中的集成架构
下图展示了一个典型的 CI/CD 流水线中，质量门禁的部署位置与数据流向：
2.5 门禁检查的典型数据流
质量门禁在执行时，通常遵循以下数据流：
- 触发：流水线运行到门禁节点，调用门禁服务 API。
- 采集：门禁服务从质量平台（如 SonarQube、Prometheus、CMDB）拉取当前制品或环境的度量数据。
- 评估：将采集数据与预配置的阈值进行对比，生成通过/失败/警告结果。
- 反馈：将结果写回流水线上下文，并记录到审计日志。
- 决策：流水线根据结果决定继续执行或中止。
常见误区：门禁不是越多越好。过多的门禁会增加流水线耗时，降低交付效率。建议遵循“最小必要原则”——只阻断那些一旦违反就会导致生产事故或严重质量问题的检查项。对于非关键项，可以使用“警告但不阻断”模式。
2.6 门禁与发布策略的协同
质量门禁并非孤立存在，它需要与发布策略协同工作。下表展示了不同发布策略下门禁的配置差异：
| 发布策略 | 门禁检查重点 | 阻断粒度 | 典型场景 |
|---|---|---|---|
| 蓝绿部署 | 新环境容量水位、健康检查 | 环境级别 | 全量切换，要求新集群完全就绪 |
| 灰度发布 | 灰度实例的容量水位、错误率 | 实例级别 | 逐步放量，要求每个批次通过门禁 |
| 金丝雀发布 | 金丝雀实例的容量水位、延迟、错误率 | 实例级别 | 小比例验证，要求金丝雀实例稳定 |
| 滚动更新 | 每批次更新后的集群整体容量水位 | 批次级别 | 逐个替换，要求每批次后集群水位不超限 |