质量门禁是什么
在流水线关键节点设置必须通过的检查（测试、扫描、依赖与评审），未通过就中止后续阶段，把问题拦在发布之前。常见位置：合并前、制品晋级前、生产发布前。判定依据是测试结果、扫描报告与评审状态；失败行为是阻断流水线并通知责任人。核心原则：门禁的目标是降低变更风险，不是增加流程数量；每条门禁都应写清失败后的处理人与时限，否则门禁会退化成所有人的背景噪音。
基本信息
| 作用 | 在阶段之间设置通行条件 |
|---|---|
| 常见位置 | 合并前、制品晋级前、生产发布前 |
| 判定依据 | 测试结果、扫描报告、评审状态 |
| 失败行为 | 阻断流水线并通知责任人 |
| 设计原则 | 每条门禁有明确处理人与时限 |
典型使用场景
- 合并门：主干保护要求测试与评审通过才允许合并。
- 晋级门：制品从预发晋级生产前核对验证证据。
- 安全门：高危漏洞与密钥泄露检出即拦截。
- 覆盖率门：核心模块覆盖率低于阈值不放行。
- 人工门：生产发布前的审批与变更单核对。
- 门禁复盘：定期统计拦截与误报情况，不合适的阈值要调整而不是无视。
GitLab 串联检查后发布
GitLab 串联检查后发布
deploy-prod:
stage: deploy
script: ./deploy.sh
needs: ["unit-test", "security-scan"] # 检查未完成不进入发布
rules:
- if: '$CI_COMMIT_BRANCH == "main"'
when: manual门禁的目标是降低变更风险，不是增加流程数量；每条门禁都应写清失败后的处理人与时限。
全部门禁都堆在发布前会让修复成本放大：能在合入前拦的问题不要留到发布前，反馈越早越便宜。
给例外留明路：明确紧急修复通道与补偿动作，避免团队在压力下悄悄绕过整套门禁。