合前合后怎么分工
合前做快速、确定性高的检查（Lint、单测、依赖评审）；合后做耗时与依赖部署环境的检查（端到端、性能、DAST），结果回流到发布决策。原则是反馈速度与确定性优先放合前——合前的目标是快速给评审可信信号；合后失败按 broken build 流程优先修复，否则主干长期不健康，发布质量无从谈起。
基本信息
| 合前 | 分钟级：Lint、单测、构建、依赖与密钥扫描 |
|---|---|
| 合后 | 更耗时：集成与端到端、性能、DAST、制品签名 |
| 原则 | 反馈速度与确定性优先放在合前 |
| 衔接 | 合后失败按 broken build 流程优先修复 |
| 时长预算 | 合前控制在分钟级，超出的移到合后 |
典型使用场景
- 评审加速：快速信号让评审人尽早介入
- 成本控制：重测试合并后只跑一次
- 安全分工：密钥扫描合前拦，DAST 合后跑
- 质量回流：合后结果计入发布门禁
- 主干健康：合后失败高优先级修复
- 分层演进：先并行观察，再迁移测试项
阶段分工示意
阶段分工示意
stages:
- fast-checks # 合前：lint 与单测，分钟级反馈
- build
- post-merge # 合后：e2e、性能、DAST，独立流水线触发分工对照
| 维度 | 合前 | 合后 |
|---|---|---|
| 目标 | 快速可信信号 | 深度验证与发布决策 |
| 时长 | 分钟级 | 十分钟到小时级 |
| 内容 | Lint、单测、扫描 | 集成、性能、DAST |
| 失败处理 | 阻塞合入 | 进入优先修复队列 |
| 资源 | 每次提交 | 合并后或定期 |
合后检查长期失败等价于主干长期不健康：应给出明确的修复优先级。
测试项搬家有依据：跑得慢且需要部署环境的检查属于合后。
两类检查都要有失败出口：合前阻塞合入，合后回到修复队列。
过渡与观察
- 开关过渡：不稳定检查先设为非阻塞，稳定后再转阻塞
合并队列配合：合前检查接入队列，批量验证按序推进等待统一入口。
两类检查的时长与失败率分开统计，优化方向才有数据依据。