quality-gate

Quality Gate

Reference sources: SonarQube Quality Gate, DORA "Accelerate" Change Failure Rate, Google "Software Engineering at Google" Continuous Delivery, Microsoft Azure DevOps Quality Gates.

Applicable Scenarios

Final decision before version release
CI/CD pipeline automated gates
Phased quality assessment (weekly / per iteration)
"Fast track" decision for emergency fixes
Release rules defined jointly with DevOps

Core Principles

1. 门禁必须是明文标准
   不是"看心情"放行

Gates are divided into blocking vs warning Blocking = must be stopped if not compliant Warning = compliant but needs attention
Gates must be automatable Relying on human memory = omissions are inevitable
Gates can evolve Evaluate and adjust in every retrospective
Gates cannot be too strict Too strict = never able to release Too loose = equivalent to none
Emergency channel is clear Under what circumstances bypass is allowed, and who can approve


## 三层门禁结构

### 1. 提交门禁（Pre-Commit / Pre-Push）

```text
触发：git commit / push 时

检查：
  □ 代码格式（Prettier / Black）
  □ Lint（ESLint / Pylint）
  □ 单元测试通过
  □ 类型检查（TypeScript / mypy）
  □ 安全扫描（密钥泄漏）

阻断：失败必须修复才能提交
人工：偶尔 --no-verify（不推荐）

2. CI Gate (Pull Request / Merge Request)

触发：PR / MR 创建或更新

检查：
  □ 单元测试 100% 通过
  □ 集成测试 100% 通过
  □ Smoke 套件通过
  □ 代码覆盖率 ≥ X%
  □ 静态扫描无 Critical
  □ 依赖安全扫描无高危
  □ Code Review 通过（≥ 1 人）

阻断：失败不能合并
警告：覆盖率下降 / 性能退化轻微

3. Release Gate (Pre-Production)

触发：准备上线

检查（必过）：
  □ 必测用例 100% 通过
  □ S0 / S1 Bug = 0
  □ Sanity 套件通过
  □ 性能 SLO 达标
  □ UAT 通过
  □ 安全审计通过
  □ 监控告警就绪
  □ 回滚方案就绪
  □ 灰度策略明确
  □ 已知问题清单业务方知悉

阻断：任一未达不放行
紧急通道：CTO + PM + SRE 三方签字

Gate Standard Template

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%"

Emergency Fix Gate (Hotfix Gate)

不能用常规门禁的场景：
  - 生产事故修复
  - 安全漏洞紧急补丁
  - 影响重大业务的紧急功能

简化门禁：
  □ 修复用例 100% 通过
  □ 受影响模块 Sanity 通过
  □ 已审视影响范围
  □ 回滚方案就绪
  □ 灰度发布（先 5% 再 100%）

签字要求：
  □ Tech Lead
  □ QA Lead
  □ SRE
  □ PM（业务影响评估）

后续要求：
  □ 24 小时内补完整测试
  □ 7 天内复盘

Gate Metrics (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 周

Gate Data Automation

集成项：
  - 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

Gate Evolution Strategy

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

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

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

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

Workflow

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

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

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

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

5. 团队培训
   - 门禁规则
   - 修复指南

Quality Self-Check

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

Common Pitfalls

Gates rely on human memory— omissions are inevitable
Gates are too strict— developers bypass them
Gates are too loose— equivalent to none
No emergency channel— online incidents cannot be fixed quickly
Emergency channel has no sign-off process— bypassed every day
Gates do not evolve— standards from 3 years ago are still in use today
No effectiveness evaluation— how many false problems were blocked and how many real problems were missed is unknown
Gate failure messages are unclear— no idea how to fix
Gate rules are scattered in multiple places— configuration drift
Not linked to DORA— quality evolution cannot be quantified

Supporting Templates

templates/quality-gate-template.md — Three-layer gate definition + YAML configuration + emergency channel process + DORA tracking + evolution roadmap

Collaboration with Other Skills

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

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

About this skill

Applicable Scenarios

Core Principles

2. CI Gate (Pull Request / Merge Request)

3. Release Gate (Pre-Production)

Gate Standard Template

Emergency Fix Gate (Hotfix Gate)

Gate Metrics (DORA)

Gate Data Automation

Gate Evolution Strategy

Workflow

Quality Self-Check

Common Pitfalls

Supporting Templates

Collaboration with Other Skills