发布冻结是什么
发布冻结指发布前的短暂窗口内，发布分支只接受阻断级修复，其他改动继续走主干常规流程。目的是把「发布候选」与「新开发」隔离开，降低发布期引入回归的概率，同时不让整个团队停摆——冻结针对发布分支，主干照常开发。
基本信息
| 目的 | 降低发布期引入回归的概率 |
|---|---|
| 范围 | 仅发布分支；主干开发照常 |
| 例外 | 阻断级缺陷修复，走加急评审 |
| 解除 | 发布完成并打标签后 |
| 窗口 | 以天计，尽量短 |
典型使用场景
- 版本发布前一到两天进入冻结，集中回归。
- 客户端提交商店审核前锁定候选版本。
- 合规或审计场景：发布版本必须与验收版本一致。
- 线上事故后的补丁版本：小范围冻结，快速发布。
- 大促或关键节点前：暂停非必要变更。
冻结规则示意
冻结规则示意
# 冻结开始：release/x.y 已切出并进入候选状态
# 冻结期仅接受：阻断级缺陷修复（加急评审 + 回归测试通过才放行）
# 其余改动：正常走主干，等待下一班发布
# 解除：vX.Y.Z 发布完成并打标签冻结期改动分级
| 改动类型 | 是否放行 | 处置 |
|---|---|---|
| 阻断缺陷修复 | 放行 | 加急评审加回归 |
| 普通功能 | 不放行 | 顺延下一版本 |
| 文案与配置 | 原则上不放行 | 特殊放行需负责人确认 |
| 交付管道修复 | 放行 | 仅影响构建发布链路 |
冻结规则要写清楚哪些改动可以例外、由谁裁决，否则执行时全靠临场解释。窗口要短：以天计，过长会积压改动。冻结期内发布分支的每次提交要有准入记录：谁放行、依据什么，方便事后追溯与复盘。解除冻结后立刻打标签固定发布点。