首页/开发/Git 与协作速查/发布列车节奏

发布列车节奏

固定节奏发车:到点验收通过的改动随车发布,未就绪的顺延下一班;计划性强、协调成本可控。

Git 与协作速查开发更新于 2026-10-13

发布列车是什么

发布列车指固定节奏发车:到发布窗口时,把验收通过的改动带上发布分支发布;没就绪的自动顺延下一班,不为个别改动晚点。核心价值是把「什么时候发布」与「哪些改动能赶上」解耦——评审与测试有明确截止点,协调成本可预期。

基本信息

机制固定时间点切发布分支并发布
上榜条件到点前验收通过的改动
顺延规则未就绪的改动下移到下一班,不阻塞整列车
配套发布分支 + 标签 + 验收清单
适用多团队共享同一产品的合并发布

典型使用场景

  • 多团队共用一个产品:谁赶上算谁,节奏公开可预期。
  • 需要联合发布或外部审核:时间点由外部约束决定,内部只能对齐。
  • 测试资源有限:按车次集中安排回归,避免随到随测。
  • 小改动密集:集中上车发布,摊薄每次发布的协调成本。
  • 运维窗口固定:发布与值守、回滚演练绑定同一节奏。

节奏示意

节奏示意
# 周一:从主干切出 release/x.y(冻结口径见发布冻结)
# 周内:只有验收通过的修复进车,其余顺延下一班
# 周四:发布并打标签 vX.Y.Z
# 周五:复盘数据(回归来源、晚点原因)
# 下周一:开启下一班车

车次要素

要素要求常见做法
发车时间固定且公开每周或双周一次
上榜截止早于发车并留测试窗口截止后只收阻断修复
验收标准可自动核验流水线全绿加验收单
顺延规则未就绪不阻塞整列车大改动拆分后等下班车
列车与发布分支、标签配合使用,让评审与测试有明确截止点。列车频率要与验证能力匹配,过密会把测试压缩成形式,过疏则积压改动。

易错点

  • 上榜规则模糊:到点未验收的改动得到例外放行,整列车为个别改动晚点;把「到点未验收一律顺延」写成硬规则。
  • 列车过密,测试时间被压到只剩冒烟;用最近几次发布引入的回归数量来校准频率。
  • 总是差一点的改动长期挤不上车,累积成大爆炸版本;安排专人跟踪顺延队列并拆分大改动。
  • 直接从主干发车而不切发布分支,发布期间主干继续合并会污染候选版本;到点先切分支再进入冻结口径。

数据来源与参考

  • GitLab 官方文档:发布流程实践
  • DORA 研究报告(dora.dev)
​‌‌​​‌​​​‌‌​‌‌‌‌​‌‌​​​‌‌​‌‌‌​​‌‌​​‌​‌‌‌​​‌‌‌​​​‌​‌‌​‌​​‌​‌‌‌​​​‌​‌‌​‌​​‌​‌‌​​​‌‌​‌‌‌​‌​​​‌‌​‌‌‌‌​​‌​‌‌‌​​‌‌​​​‌‌​‌‌​‌‌‌‌​‌‌​‌‌​‌