3. 质量门禁核心指标：代码质量、测试覆盖率、安全扫描、构建成功率
质量门禁是发布准入的第一道防线，其核心在于通过一组可量化、可自动判定的指标，对每一次代码变更进行“健康体检”。只有所有核心指标均达到预设阈值，流水线才允许进入下一阶段。本章详细拆解四项关键指标的定义、度量方式与常见陷阱。
3.1 指标全景与门禁决策逻辑
质量门禁并非单一指标的“一票否决”，而是多维度综合评估。下图展示了核心指标在门禁决策中的协作关系：
3.2 代码质量指标
代码质量是软件健康的“基因”。门禁系统通常关注以下子指标：
| 指标名称 | 典型工具 | 推荐阈值 | 说明 |
|---|---|---|---|
| 代码异味 (Code Smells) | SonarQube | 新增异味 = 0 | 不允许引入新的设计缺陷或反模式 |
| 重复代码率 | SonarQube / PMD | < 3% | 超过阈值需重构，避免维护成本激增 |
| 圈复杂度 | SonarQube / Lizard | 单函数 ≤ 15 | 过高复杂度意味着难以测试和维护 |
| 技术债务比率 | SonarQube | < 5% | 修复成本占开发总工时的比例 |
实践建议： 代码质量门禁应区分“新增代码”与“存量代码”。建议对新增代码执行零容忍策略（新增异味=0），对存量代码设定逐步降低的目标，避免一次性阻断所有历史遗留问题。
3.3 测试覆盖率指标
测试覆盖率衡量代码被自动化测试执行的程度。门禁中通常关注两个维度：
- 行覆盖率 (Line Coverage)： 被执行的代码行数占总行数的百分比。推荐阈值：单元测试 ≥ 80%，集成测试 ≥ 60%。
- 分支覆盖率 (Branch Coverage)： 被执行的逻辑分支（if/else、switch）占总分支数的百分比。推荐阈值：≥ 75%。分支覆盖率比行覆盖率更能反映测试的充分性。
常见误区： 单纯追求高覆盖率可能导致“测试泡沫”——大量断言空洞的测试代码。门禁应同时要求覆盖率达标且测试数量与代码复杂度匹配，避免为凑数字而写无效测试。
3.4 安全扫描指标
安全扫描是发布前的“安检门”，主要包含两类扫描：
| 扫描类型 | 检测对象 | 典型工具 | 门禁规则 |
|---|---|---|---|
| SAST（静态应用安全测试） | 源代码 | Fortify / Checkmarx / Semgrep | 阻断所有 Critical / High 级别漏洞 |
| SCA（软件组成分析） | 第三方依赖 | Black Duck / Snyk / OWASP Dependency-Check | 阻断已知 CVE 且 CVSS ≥ 7.0 的依赖 |
| 密钥泄露检测 | 硬编码密钥 / | GitLeaks / TruffleHog | 零容忍，发现即阻断 |
注意： SCA 扫描可能产生大量“误报”或“低危”告警。建议门禁只阻断高危及以上漏洞，中低危告警进入缺陷跟踪系统，由安全团队定期评估，避免因噪声过多导致开发者对门禁产生抵触。
3.5 构建成功率指标
构建成功率是门禁的“入场券”——如果代码无法通过编译或打包，其他指标无需检查。关键考量点：
- 构建通过率： 门禁要求最近一次构建必须 100% 成功。失败原因包括编译错误、依赖缺失、资源文件冲突等。
- 构建时长： 虽然不直接阻断，但建议设置超时阈值（如 30 分钟）。超长构建会阻塞流水线，影响交付效率。
- 增量构建 vs 全量构建： 门禁阶段建议使用增量构建以加速反馈，但发布前需触发一次全量构建确保无遗漏。
3.6 指标联动与门禁策略
单一指标存在局限性，实际生产环境需要组合策略：
| 场景 | 门禁策略 | 示例 |
|---|---|---|
| 紧急热修复 | 放宽代码质量阈值，但安全扫描不降级 | 允许技术债务比率临时升至 10%，但高危漏洞必须修复 |
| 新项目启动 | 严格全指标，培养质量文化 | 覆盖率要求 85%，圈复杂度 ≤ 10 |
| 遗留系统改造 | 增量指标 + 存量趋势监控 | 新增代码覆盖率 ≥ 80%，存量覆盖率每月提升 2% |
核心原则： 门禁指标不是“死数字”，而是质量契约。每个团队应根据自身业务风险、技术栈和交付节奏，与 QA、安全、开发三方共同商定阈值，并定期回顾调整。门禁的最终目标是“防止坏代码上线”，而非“阻止代码上线”。