驾驭敏捷交付：发布火车、巴士和出租车

一次发布过程中，涉及到几个系统/组件？

隐含的，这个发布涉及到几个团队/部门？

另外，发布频率怎么样，间隔多久发布一次？

根据不同的回答，形成了发布模式。笔者整理了一下，可能有Realse Traing/Bus/Taxi三种模式。

坐好了，开车喽。

发布火车（Release Train）

Release Train是一种敏捷实践，旨在通过定期的、可预测的发布来增强软件交付的流程。这一概念最初源自于敏捷方法论，特别是持续集成和持续交付的理念。在Scaled Agile Framework（SAFe）中，Agile Release Train（ART）被定义为一个长期的团队集合，负责在价值流中逐步开发、交付和经常性地运营一个或多个解决方案。

发布火车通常具有比较大的系统/需求规模：涉及多个系统和较多的需求。它通常用于大型组织或复杂的项目，需要协调不同团队和组件的发布，是一种典型的批次作业。不同于互联网/在线产品团第，在产品型团队中，也可能将某个系统的不同版本打包形成一列发布火车。

固定发布周期是Release Train（发布火车）模式中的一个核心概念，它要求软件的发布按照一个预定的时间表进行。以下是固定发布周期中涉及的几个关键事项：

1.发布内容计划（买票）：

o在每个发布周期开始之前，团队需要规划将要包含在发布中的特性、功能和错误修复。这个过程可以比作是“买票上车”，即团队成员需要在这个时间点之前确定哪些工作项会包含在即将到来的发布中。

2.发布冻结（停止售票）：

o版本冻结是指在发布周期的某个特定时间点，决定不再添加新的特性或功能到当前的发布中。这个时间点之后，所有的工作都集中在完成已经规划的内容，并准备发布。这确保了发布的内容是已知的，并且可以进行适当的测试和准备。发布冻结与版本冻结不同，开发人员可以继续提交开发或者修复缺陷的代码。

3.特性下车（改签）：

o如果某个特性或功能在版本冻结之后还未完成，或者发现它会影响发布质量，可能需要将其推迟到下一个发布周期。这就像是“改签”到下一班车。团队需要决定是匆忙完成这个特性以赶上当前的发布，还是将其推迟以保证发布质量。

4.版本发布（发车）：

o发布火车发车是指按照计划发布软件的新版本。这个时间点是固定的，所有团队成员都清楚何时需要完成工作。发布之后，团队可以收集反馈，为下一个发布周期做准备。

发布巴士（Release Bus）

在花了较多笔墨介绍发布火车后，如果把相同的概念进行一下缩减，我们可以得到一个更经济、快捷、高效的交付模式，也就是发布巴士。

1.系统/需求规模：可能涉及单个系统的多个需求或者多个系统但需求相对有限。相比火车，巴士可能在规模上更小或更灵活。

2.发布频次：可能有一定的时间表，但相比火车，巴士可能提供更多的灵活性，允许在特定的时间点或条件下进行发布。

发布的士（Release Taxi）

类似的，再进一步缩小，就可以得到发布的士。

1.系统/需求规模：通常针对单个系统或服务的单个需求。它提供了高度的灵活性，允许快速响应市场变化或用户需求。

2.发布频次：非常灵活，可以根据需求随时进行发布，不依赖于固定的时间表。

每种模式都有其优势和局限性，选择哪种模式取决于项目的特点、团队的技术能力以及对市场响应速度的需求。

从现实情况来看，监管要求高、系统间耦合度高的企业中，通常会倾向于采用发布火车的模式。而互联网公司更多倾向于发布巴士以及的士的模式。

对照表

以下是根据Release Train（发布火车）、Release Bus（发布巴士）和Release Taxi（发布出租车）三种模式的特点，从团队、系统、需求等几个维度进行的比较：

本文借助于Kimi撰写。