Release 分支晋级流程（RBP: Release Branch Promotion）

  • 常驻分支：main、release/*（每期一个）、临时 hotfix/*。没有长期 dev。
  • 环境：每个 PR 一个预览环境；Staging 只跟随当前 release/*；Prod 只接“已签名的 release tag”。
  • 构建哲学：构建一次（在 release 上），Staging 和 Prod 都晋级同一份产物，绝不重建。

Sprint 第 1–8 天：开发期

  • 开发分支 → PR → 合 main。
  • main 合并依赖 merge queue：单测、契约测、集成测、静态扫描、迁移脚本干跑全绿才合。
  • 每个 PR 自动起预览环境给前端/QA点验，通过就销毁。
  • 可选最小开关：全局 Kill Switch + 环境级开关两颗，够用就行。

产出：一堆通过所有检查的提交在 main，但还没承诺“本期必上”。

第 9 天：冻结日（切候选版本）

  • 从 main 切出 release/2025.08.S12（名字随你，关键是唯一）。
  • 在 release/* 上构建一次产物：镜像/包打不可变 tag（如 app:2025.08.S12-rc.1），记录 digest、SBOM，并签名。
  • 部署到 Staging，开始全链路验证（E2E、回放/影子流量、性能冒烟、迁移脚本干跑或小流量实跑）。

注意：冻结后 release/* 只收 fix 类 PR。带 refactor/deps/migration/public-api-change 标签的一律被 CI 拒收。

第 10–14 天：收敛期（只收修）

  • 需要修的 bug：

    • 方案 A（推荐）：在 main 修，打 backport:release/2025.08.S12 标签，机器人自动 cherry-pick -x 回 release/*，重跑 Staging 验证。
    • 方案 B（紧急）：直接在 release/* 修，同时 反向合回 main，保持主线干净。

  • 若发现“混了重构”的提交：在 release/* 上 git revert -m 1 <merge-commit>，重出 rc.2，继续测。主线不动。

  • DB 迁移遵循 expand/contract：

    • expand（加列/兼容写）只能在前一班或本班早期就位；
    • contract（删旧列/切流）排到下一班。冻结期不做 contract。

发版日：晋级，不重建

  • 给 release/* 当前 commit 打签名 tag：v2025.08.S12，指向已在 Staging 验证过的同一产物。
  • Prod 流水线只接受这个签名 tag，直接晋级同一 digest 到生产。
  • 打产物不可变别名：app:2025.08.S12 → 指向那个 digest。记录 SBOM、变更单、审批人，审计闭环。

Hotfix：两列车互不污染

  • 从“线上最近一次生产 tag”切 hotfix/XYZ，修完：

    1. 在 hotfix 分支构建 v2025.08.S12-p1，可先在短暂 Staging 或金丝雀验证；
    2. 晋级到生产；
    3. 回填到正在维护的 release/* 和 main。

  • 不去动任何“下一班”的 release/*。候选车和现网车各开各的。

回滚：一键退回上个版本

  • 直接把生产晋级回上一个签名 tag（同一 digest）。
  • 若需要“功能层面”止血，拉下 Kill Switch。
  • DB 回滚只在使用了可逆脚本时执行；否则依赖 expand/contract 的前向兼容性先熬过去。

权限与护栏（防作死三件套）

  • 生产流水线的部署来源只允许 release/* 的签名 tag，技术上禁止从任意分支 HEAD 部署。
  • 冻结后 release/* 的 CI Gate：仅放 type=fix 且触达面与行数低于阈值的 PR，其他一律 fail。
  • main 的合并必须经 merge queue，合并后不会自动部署到 Staging；Staging 只吃 release/*。

最小工具清单（够用即可）

  • 镜像/包签名与 SBOM：cosign/slsa + 你们的制品库。
  • Backport 机器人：现成的 backport-bot 或 GitHub Actions 模板。
  • 影子流量/回放：一条读路径回放管道；写请求在 Staging NOP。
  • 开关：自建 DB 表都行，至少有“全局关”和“按环境关”。

常见情景对照

  • “第 11 天线上爆 P1”：按 hotfix 流走，不碰下一班 release/*；发完补回。
  • “冻结后发现某 PR 混重构”：在 release/* 上 revert，另起干净 fix；main 不动。
  • “A/B 契约要成对上”：Gate 强制 A、B 都绿才放 release/*，没齐就下一班。
  • “审计要证据链”：产物 digest、签名 tag、Staging 与 Prod 的部署记录一致，截图即证。

就这么简单：主线做演化，release 做交付，产物做真相。别再把 prod 当工作台，别再让提交当发布单位。你要的是确定性，不是惊喜。