SuperAPI AI 工具集
合作ENAI 行业资讯收藏
Skill 广场quality-gate

quality-gate

测试与质量

查看项目

更新于 10-16 10:25

技能介绍

质量门禁（Quality Gate）用于上线放行决策，以及阻断不达标交付。适用于版本发布前的门禁、CI/CD 自动门禁、阶段性质量评估，以及紧急修复的“快速通道”决策。该技能参考 SonarQube Quality Gate、DORA《Accelerate》的变更失败率（Change Failure Rate）、Google《Software Engineering at Google》的持续交付、Microsoft Azure DevOps Quality Gates。

核心原则

门禁必须是明文标准，不是“看心情”放行。门禁分阻断与警告：阻断表示不达标必拦，警告表示达标但要关注。门禁要可自动化，靠人工记忆必有遗漏；门禁可演进，每次复盘评估调整；门禁不能过严，过严会导致永远放不出去，过松等于没有。紧急通道要明确，规定什么情况能 bypass，谁能批准。

三层门禁结构

  1. 提交门禁（Pre-Commit / Pre-Push）：触发于 git commit / push 时，检查代码格式（Prettier / Black）、Lint（ESLint / Pylint）、单元测试通过、类型检查（TypeScript / mypy）、安全扫描（密钥泄漏）。失败必须修复才能提交，偶尔可用 --no-verify（不推荐）。

  2. CI 门禁（Pull Request / Merge Request）：触发于 PR / MR 创建或更新，检查单元测试 100% 通过、集成测试 100% 通过、Smoke 套件通过、代码覆盖率 ≥ X%、静态扫描无 Critical、依赖安全扫描无高危、Code Review 通过（≥ 1 人）。失败不能合并；覆盖率下降或性能退化轻微时警告。

  3. 发布门禁（Pre-Production）：触发于准备上线，检查（必过）必测用例 100% 通过、S0 / S1 Bug = 0、Sanity 套件通过、性能 SLO 达标、UAT 通过、安全审计通过、监控告警就绪、回滚方案就绪、灰度策略明确、已知问题清单业务方知悉。任一未达不放行；紧急通道需 CTO + PM + SRE 三方签字。

门禁标准模板

quality_gates: commit: blocking: - lint_pass: required - unit_tests: 100% - type_check: required - secret_scan: clean

merge: blocking: - unit_tests: 100% - integration_tests: 100% - smoke_tests: 100% - code_coverage_diff: "≥ -2%" # 不能降太多 - security_scan: no_critical - code_review_count: ≥ 1 warning: - code_coverage_absolute: "< 80%" - performance_regression: "> 5%"

release: blocking: - must_pass_tests: 100% - critical_bugs: 0 - high_bugs: 0 - sanity_suite: pass - perf_p99: "< SLO" - perf_error_rate: "< 0.1%" - uat: approved - rollback_plan: ready - monitoring: configured - canary_plan: defined warning: - medium_bugs: "> 5" - perf_regression_vs_baseline: "> 10%"

紧急修复门禁（Hotfix Gate）

适用于不能用常规门禁的场景：生产事故修复、安全漏洞紧急补丁、影响重大业务的紧急功能。简化门禁包括：修复用例 100% 通过、受影响模块 Sanity 通过、已审视影响范围、回滚方案就绪、灰度发布（先 5% 再 100%）。签字要求包括 Tech Lead、QA Lead、SRE、PM（业务影响评估）。后续要求包括 24 小时内补完整测试、7 天内复盘。

门禁度量（DORA）

  1. 部署频率（Deployment Frequency）：高效团队每天多次，中等每周到每月，低效每月到每季度。

  2. 变更前置时间（Lead Time for Changes）：高效 < 1 天，中等 1 周 ~ 1 月，低效 > 1 月。

  3. 变更失败率（Change Failure Rate）：高效 0~15%，中等 16~30%，低效 > 30%，目标 < 15%。

  4. 平均恢复时间（MTTR）：高效 < 1 小时，中等 1 天 ~ 1 周，低效 > 1 周。

门禁数据自动化

集成项包括 GitHub Actions / GitLab CI / Jenkins、SonarQube（代码质量）、Snyk / Dependabot（依赖安全）、Allure / TestRail（测试结果）、Datadog / Prometheus（性能监控）。门禁脚本示例（GitHub Actions）：

release-gate: runs-on: ubuntu-latest steps: - name: Check Critical Bugs run: | critical=$(curl ...jira API... | jq '.issues | length') if [ "$critical" -gt 0 ]; then echo "::error::Critical bugs found: $critical" exit 1 fi

  - name: Check Test Coverage
    run: |
      coverage=$(cat coverage.json | jq '.total')
      if [ $(echo "$coverage < 80" | bc) -eq 1 ]; then
        echo "::warning::Coverage below 80%"
      fi
  
  - name: Check Performance
    run: |
      ./scripts/check-perf-slo.sh

门禁演进策略

  1. 起步阶段（项目早期）：简单门禁，单元测试 + Lint，阻断少、警告多。

  2. 成熟阶段（功能稳定）：增加集成测试 + Smoke，增加性能基线 + 覆盖率。

  3. 规模阶段（多团队 / 多服务）：增加契约测试 + 安全扫描，自动化所有门禁。

  4. 卓越阶段：增加 Chaos / 混沌工程门禁，DORA 高效区间，变更失败率 < 5%。

工作流程

  1. 与团队定义门禁标准，由 PM / Dev / QA / SRE 共同制定，写入 quality-gate.yml。

  2. 实现自动化检查，集成到 CI/CD，失败有清晰错误信息。

  3. 监控门禁触发率：多少次合并被拦、多少次紧急通道、多少次 bypass。

  4. 复盘门禁有效性：漏放多少 Bug、误拦多少（误判率），调整阈值。

  5. 团队培训：门禁规则、修复指南。

质量自检

□ 三层门禁明确（Commit / CI / Release） □ 阻断规则清晰 □ 警告规则清晰 □ 数据自动化收集 □ 门禁失败有清晰错误信息 □ 紧急通道有签字流程 □ 门禁规则进版本控制 □ 复盘机制定期评估 □ DORA 指标跟踪 □ 团队达成共识

常见坑

门禁靠人工记忆必有遗漏；门禁过严，开发绕过去；门禁过松，等于没有；没有紧急通道，线上事故没法快速修；紧急通道没签字流程，天天 bypass；门禁不演进，3 年前的标准用到现在；不做有效性评估，拦了多少假问题、漏了多少真问题不知道；门禁失败信息不清晰，不知道怎么修；门禁规则散在多个地方，配置漂移；不与 DORA 关联，没法量化质量演进。

配套模板

templates/quality-gate-template.md — 三层门禁定义 + YAML 配置 + 紧急通道流程 + DORA 跟踪 + 演进路线。

与其他 skill 的协作

上游：test-strategy → 退出条件作为门禁基础；test-report → 报告数据作为门禁判断；risk-based-testing → 风险等级作为门禁阈值；performance-testing → SLO 作为门禁；acceptance-testing → UAT 通过作为门禁。

下游：DevOps 工作流 → 集成到 CI/CD；SRE 工作流 → 监控 / 告警就绪；项目经理工作流 → 里程碑门禁。