1. 变更门禁概述
1.1 变更门禁的定义
变更门禁（Change Gate）是 CI/CD 流水线中设置在特定阶段之间的质量检查关卡。它像一道“安全闸门”，只有当提交的代码或制品满足预设的通过条件时，门禁才会放行，允许变更进入下一阶段（如从构建进入测试，或从测试进入生产部署）。
核心思想：“不通过门禁，就不向下游流动”。变更门禁将质量左移，在早期拦截缺陷，避免有问题的代码污染后续环境或影响生产稳定性。
1.2 在 CI/CD 流水线中的作用
变更门禁在自动化交付流程中承担着质量守门人、风险控制点和流程加速器三重角色。下表总结了门禁在不同阶段的核心作用：
| 流水线阶段 | 门禁作用 | 典型检查项 |
|---|---|---|
| 代码提交 | 阻止格式混乱、含敏感信息的代码入库 | Lint 检查、Git 提交信息规范、密钥扫描 |
| 构建阶段 | 确保代码可编译、制品可生成 | 编译成功率、依赖版本锁定、制品签名 |
| 测试阶段 | 验证功能正确性与非功能性指标 | 单元测试通过率、代码覆盖率阈值、性能基线 |
| 安全扫描 | 识别漏洞与合规风险 | SAST/DAST 扫描、依赖库 CVE 检查、许可证合规 |
| 部署审批 | 人工或自动确认生产就绪状态 | 变更单关联、环境一致性校验、回滚预案 |
通过在每个关键节点设置门禁，团队可以实现：
- 质量左移：在开发早期发现并修复问题，降低修复成本。
- 风险可控：防止低质量或带漏洞的代码进入生产环境。
- 流程自动化：减少人工审核的重复劳动，加速交付节奏。
- 审计可追溯：每次门禁的通过/拒绝记录形成完整的变更审计链。
实践要点：门禁不是越多越好。过多的门禁会拖慢流水线，导致开发人员等待时间过长。建议根据团队成熟度和业务风险等级，设置 3~5 个关键门禁，并定期评估门禁的有效性。
1.3 常见变更门禁类型
根据检查维度的不同，变更门禁主要分为以下三大类：
1.3.1 代码审查门禁
代码审查（Code Review）是最传统也最有效的门禁之一。它要求每次合并请求（Merge Request / Pull Request）必须获得至少一位审查者的批准才能合入主分支。
- 人工审查：由资深开发者或架构师逐行阅读代码，关注逻辑正确性、架构合理性、可维护性。
- 自动化审查：通过静态分析工具（如 SonarQube、ESLint）自动检查代码风格、复杂度、重复率等指标。
- 混合模式：先由自动化工具做基础检查，通过后再提交人工审查，提高审查效率。
1.3.2 自动化测试门禁
自动化测试门禁是保证代码功能正确性的核心屏障。它通常包含多个测试层级：
| 测试层级 | 检查目标 | 通过标准示例 |
|---|---|---|
| 单元测试 | 验证单个函数/方法的逻辑正确性 | 通过率 100%，覆盖率 ≥ 80% |
| 集成测试 | 验证模块间交互与外部依赖 | 所有接口用例通过，无超时 |
| 端到端测试 | 模拟用户真实操作流程 | 核心业务路径全部通过 |
1.3.3 安全扫描门禁
安全扫描门禁在 DevSecOps 实践中尤为重要，它负责在代码进入生产前识别潜在的安全威胁。
- SAST（静态应用安全测试）：在不运行代码的情况下分析源代码，发现 SQL 注入、XSS、硬编码密钥等漏洞。
- DAST（动态应用安全测试）：在运行环境中模拟攻击，检测运行时安全问题。
- SCA（软件组成分析）：扫描第三方依赖库，识别已知 CVE 漏洞和许可证风险。
- 容器镜像扫描：检查 Docker 镜像中的操作系统层和应用层漏洞。
常见误区：安全扫描门禁的误报率可能较高。建议为每个扫描工具配置基线规则，将已知误报加入白名单，避免因误报阻塞正常发布流程。同时，对于高危漏洞应设置“强制阻断”，中低危漏洞可设置为“告警但不阻断”。