发布列车是什么
发布列车以固定节奏组织跨团队发布：各团队按共同时刻表合并、集成与稳定，发布窗口稳定之后，特性按就绪度上车，未就绪的顺延下一班而不阻塞列车。它的核心收益是把临时协调变成固定节拍，让集成与回归有确定的窗口。前提是技术基础可靠：自动化测试与发布流水线不成熟时，稳定期会被不断挤压，固定节奏只是名义上的。
基本信息
| 节奏 | 固定发布周期，长度按团队实际与业务窗口确定 |
|---|---|
| 稳定期 | 发布前预留集成与回归窗口，期间冻结非必要变更 |
| 上车规则 | 未就绪特性顺延下一班，不因个别特性推迟整体发布 |
| 度量 | 按期发布率、发布后缺陷数、回滚次数与恢复时长 |
| 前提条件 | 自动化测试覆盖与可重复的发布流水线 |
典型使用场景
- 多团队共同交付同一产品，需要统一的发布窗口减少临时协调
- 发布频繁失败或回滚，需要用固定节奏换取稳定期集中验证
- 业务方需要可预期的上线时间，用固定列车替代随时发布
- 跨团队集成问题在临近上线才发现，需要提前的集成检查窗口
- 对外服务有窗口限制（如业务高峰期禁发），需要据此设定列车时刻
列车运行要点
列车运行要点
确定节奏：按业务窗口与团队能力设定固定周期，避免频繁变更
就绪评估：发布前逐特性确认完成定义与集成状态
稳定期：冻结非必要变更，集中做回归与缺陷修复
上车规则：未就绪顺延，禁止为单个特性推迟整列
发布复盘：统计缺陷与回滚原因，作为下轮改进输入列车运行检查
| 检查项 | 频率 | 关注点 |
|---|---|---|
| 就绪度评估 | 每次发布前逐特性确认 | 是否满足完成定义与集成要求 |
| 集成健康 | 稳定期内持续检查 | 主干是否始终可发布 |
| 回滚预案 | 发布前确认 | 失败时的恢复步骤与授权 |
| 发布复盘 | 每次发布后 | 缺陷与回滚原因是否被记录并改进 |
固定节奏的前提是自动化测试与发布流水线可靠：手动环节多时，稳定期会被不断挤压，最终演变为为赶窗口而降低验证标准。