3. 发布门禁概念：门禁的定义、门禁在CI/CD中的位置、常见门禁类型

发布门禁（Release Gate）是部署流水线中预设的自动化质量关卡。每一道门禁代表一个必须通过的验证条件，只有所有门禁均判定为“通过”，制品才能进入下一阶段或最终发布到生产环境。门禁机制将人工审批的“事后检查”转变为自动化的“事前阻断”，是保障蓝绿发布安全性的核心手段。

3.1 门禁的定义与核心要素

门禁本质上是一个布尔判定点：输入当前制品的质量数据，输出“通过”或“阻断”的决策。一个完整的门禁定义包含以下要素：

3.2 门禁在CI/CD中的位置

门禁并非均匀分布在流水线各处，而是集中在制品晋升的关键决策点。下图展示了标准 CI/CD 流水线中门禁的典型部署位置：

从图中可以看出，门禁分布在三个主要阶段：

• CI 阶段（G1-G3）：代码提交后、镜像构建前，主要检查代码质量和单元测试覆盖率，确保进入制品库的代码是健康的。
• CD 阶段（G4-G6）：镜像构建完成后、部署到预发环境前后，执行安全扫描和集成测试门禁，阻断存在漏洞或功能异常的制品。
• 生产发布阶段（G7-G8）：蓝绿切换前和灰度验证后，执行性能基线对比和业务可用性门禁，确保新版本不会引发生产事故。

3.3 常见门禁类型

根据验证目标的不同，发布门禁可分为三大类。下表对比了各类门禁的核心关注点、常用工具和典型阈值：

3.4 代码质量门禁详解

代码质量门禁是流水线中最早触发的门禁，通常在单元测试阶段之后执行。其核心目标是确保新提交的代码不会降低整体代码库的健康度。常见的检查维度包括：

• 代码覆盖率：行覆盖率、分支覆盖率、方法覆盖率。低于阈值则阻断。
• 代码异味：重复代码块、过长方法、过深嵌套。超过阈值则告警。
• 静态分析：空指针引用、资源未关闭、类型转换异常等潜在缺陷。
• 编码规范：命名规则、缩进风格、注释规范。违反规则数超过阈值则阻断。

# sonar-project.properties 关键配置
sonar.qualitygate.wait=true
sonar.qualitygate.timeout=300
# 自定义质量阈：覆盖率 >= 80%，且新增代码覆盖率 >= 85%
sonar.coverage.exclusions=**/test/**/*.java
sonar.java.coveragePlugin=jacoco

3.5 安全扫描门禁详解

安全扫描门禁在镜像构建完成后、部署到预发环境前执行，是防止漏洞进入生产环境的最后一道防线。主要扫描对象包括：

• 容器镜像：扫描操作系统包（如 apt、yum）和应用依赖（如 npm、pip）中的已知 CVE 漏洞。
• 密钥泄露：检查代码仓库和镜像层中是否包含 AWS 密钥、数据库密码等敏感信息。
• 许可证合规：检测依赖库的许可证类型，避免 GPL 等传染性许可证进入商业产品。

安全门禁的典型执行流程如下：

1. 从镜像仓库拉取待发布镜像。
2. 使用 Trivy 执行全量漏洞扫描，生成 JSON 格式报告。
3. 解析报告，提取高危和严重漏洞数量。
4. 与预设阈值比较：若高危漏洞 > 0，则阻断流水线并发送告警。
5. 若通过，将镜像标记为“已安全扫描”并允许进入预发环境。

3.6 性能基线门禁详解

性能基线门禁是蓝绿发布场景中最重要的门禁类型。它通过对比新版本（绿环境）与当前生产版本（蓝环境）的性能指标，判断新版本是否满足性能要求。其核心机制包括：

• 基线建立：在生产环境持续采集蓝环境的性能指标（如 P99 延迟、吞吐量、CPU 使用率），形成动态基线。
• 对比策略：在绿环境执行相同负载的压测，将结果与基线进行统计对比（如 t 检验、百分比偏差）。
• 门禁判定：若绿环境性能劣化超过阈值（如 P99 延迟上升 > 10%），则阻断蓝绿切换。

以下 SVG 图展示了性能基线门禁的判定逻辑：

3.7 门禁的移植适配要点

在将标准门禁模板移植到目标环境时，需要关注以下适配点：

• 工具链替换：如果目标环境无法使用 SonarQube，需替换为等效工具（如 CodeClimate、Codacy），并重新定义门禁规则。
• 阈值校准：不同业务场景的阈值差异很大。金融场景要求“高危漏洞=0”，而内部工具类应用可适当放宽。
• 超时配置：安全扫描在大型镜像上可能耗时较长，需根据镜像大小调整超时时间，避免因超时导致误阻断。
• 门禁降级：在紧急发布场景下，应支持手动跳过或降级门禁（如将“阻断”降级为“告警”），但需记录审计日志。