火车模型发布模式：敏捷和稳定

在说火车模型之前我们先来说说现有的版本发布模式。

参考乔梁的持续交付2.0中，从特性、时间、质量三个角度总结的三种发布模式：

• 项目制发布模式（Project Rlease Mode）
• 传统版本火车模式（Release Train Mode）
• 城际快线模式（IntercityExpress Mode）

一、项目制发布模式

项目制发布模式是指在软件某一个版本规划中，预先确定这个版本所需包含的特性集合；当版本的特性集合达到发布质量标准后，才能发布该版本，版本之间的时间间隔不确定，而是根据前一版本所有特性集合开发完成并达到发布标准所需时间进行评估确定的。

明显的好处在于：可以确切地知道每个版本包括哪些具体功能，有利于商业套装软件的售卖模式符。

其不足之处在于：通常项目整个交付周期较长，参与人员众多，需求的变更极易影响版本的交付时间。

二、火车模型发布模式

《启示录：打造用户喜爱的产品》这边说第一张就讲到了许多成熟的互联网公司都在使用火车模型发布模式。

Firefox目前正在采用的发布过程其实就是火车模型发布模式，使用一个新特性从实现并且进入mozilla-central分支到发布到用户手里只需要12-18周，并不向IE浏览器的更新以用一样要几年的时间。

如此的快速发布过程给整个项目带来了更好的敏捷性和更强的稳定性，在每个发布周期的测试和稳定阶段可以覆盖更多的用户来帮助FireFox的开发人员更早的发现和解决问题，保持在每次发布质量上的信心。

下面就要介绍下Firefox的发布流程，每个独立的发布火车（新的发布过程采用火车模型，固定的“发车”时间，特性的发布取决于该特性是否赶上最近的火车发车时间）包括6周的开发时间加上12周的稳定时间：

新的开发成果不会直接发布到Aurora和Beta分支上，这些分支需要被开发人员和社区测试人员共同测试完方可；如果发现开发中存在程序问题或者BUG，就需要先解决问题。

如上图所示，您能够看出发布周期基本上是稳定的18个星期。

Aurora和Beta分支基本上完全关注于稳定性和测试，同时，很多的工程师也在同步开始新的开发工作；所以，如果看更大的一张图表的话，下面是真正进行的过程：

在Aurora和Beta分支上经历的12周时间里，Mozilla开发社区并没有在闲着，他们会继续为后面的发布开发新的特性和bug fix。

每六个星期，他们的工作会被选择性的合并到Aurora分支，继而合并到Beta分支上；观察上面的图表，您会发现很重要的一点就是——每六个星期就会有一个新版本。

提前几个月制定发布火车的时间表，原因纯粹是让各种业务和技术部门有足够多的时间进行预计划，以便做出依赖和影响的相关评估工作。

这种模式期望通过更长时间的预计划，保障三个维度（时间、质量、特性）都能符合预期。

这种模式的好处在于：用户可以事先了解重要特性在各版本的分布，以及对应版本的发布时间，并能够提前体验到最新产品版本所提供的新特性；然后再根据体验结果，决定是否将其应用于自己的生产环境上；而且，既便决定要在自己的生产环境中使用这个版本，也可以等到这个新版本成熟稳定之后再使用。

其不足之处在于：需要提前较长时间做时间计划，而且制定发布计划的活动是一个非常正式和结构化的过程；并且需要一些格式化数据，以确保参加发布火车的团队能够对正式加入的可行性做出判断。

这些数据包括：

• 发布详细信息（相对标识、名称、部署日期、风险级别、发布类型——企业、计划或投资组合）；
• 整个生命周期中各个阶段及预定日期，如下图（LibreOffice5.4版本火车的时间表 ）所示；
• 每个阶段要完成的活动和任务；
• 里程碑时间和质量要求；
• 负责管理发布火车的主要负责人。

三、城际快线模式（Intercity Express Mode）

城际快线模式（Intercity Express Mode）是指在发布策略三要素中选择固定其中的时间和质量两个维度，且时间周期相对较短（如一个星期，甚至一天），针对那些在发布时间点前已达到固定质量标准的特性进行发布。

它与传统发布火车模式的区别在于两点：

发布周期间隔较短，通常在两个星期内；
负责特性开发的团队可以自己选择搭乘哪列城际快线，而不必提前很长时间确定下来。
这种模式常见于提供互联网服务或SaaS服务的软件公司，其好处在于减少了团队及角色之间的协调成本——因为每个人都事先知道每次发布的具体时间点，所有工作任务都可以按这个时间点提前进行协调；而且，即使某个特性没有及时赶上最近的一次版本发布，他们也确切地知道这个特性是否可以在下一次发布时间点对外发布。

比如，Facebook Web主站的发布周期是每个工作日两次发布。

这种城际快线模式的优点在于：

• 每个人都非常清楚各个时间点；
• 每个人都感觉到特性进展；
• 速度不断提升；
• 更加聚焦于生产质量。

当然，也有其不足之处：

• 未完成的代码也会一同发布出去；
• 每个人都有紧迫感；
• 如果频率变慢，需要更多做计划的时间。

那么，这样的发布火车，间隔多长时间发出一趟合适呢？

在不了解企业具体状况时，这是一个非常难回答的一个问题，但仍旧可以给出一些建议，即：在不影响用户体验、不增加成本且合规的前提下，让发布周期尽可能缩短到令你感到有些紧张的节奏；比如原来每个月发布一个版本，现在可以把两个星期做为一个目标（当然，这不可能轻松做到）。

四、分支策略与版本发布模式之间的关联关系

分支策略与版本发布之间有一种微妙的相关性，在时间周期较长的项目制发布模式下，研发团队采用的分支策略通常会倾向于主干开发模式；而在使用城际快线模式的团队中，也通常会倾向于采用主干开发模式。

而发布周期在两者之间时，其分支策略通常会倾向于“多分支开发，主干发布”的模式（无论是特性分支也好，还是团队分支也好）；当然，这并不是绝对的，其中会有很大的重叠部分，通常会受团队成员人数和产品架构影响。

项目制发布模式不会消失。毕竟每个新产品在完成第一个基本的MVP前，都需要这样一个首次启动过程，目前仍旧有很多传统IT企业采用项目制发布模式。

然而，城际快线模式越来越受到欢迎，已经有越来越多的企业 开始使用这种城际快线模式。

即使在那些目前的版本发布周期较长的企业中，也常常在项目制发布模式中套用城际快线模式，即：在项目周期内加入固定时间的迭代，并要求在每个迭代结束时都能得到可交付状态的产品——这里的可交付状态是指软件可以正常运行，且已完成的软件特性达到发布质量标准，而非可商业化发布。

一般来说，当发布周期短到一定程度后，主干开发模式更加具有优势，因为分支开发模式的合并成本会成为城际快线发布模式的障碍。

如果发布周期等于或短于两个星期，建议软件团队毫不犹豫地改进工作方式，转向“主干开发模式”。

很多互联网公司选择城际快线模式，如2010年之前，Facebook主站就开始使用这种城际快线模式；2012年更是达到每个工作日定时发布两次，其移动端的发版节奏也从最初的项目制发布模式改为城际快线模式。

而google的Chrome PC版本也是选择了城际快线模式 ，其Beta版本每周发布一次，而Stable版本每月发布一次。

在国内公司中，2011年的百姓网也使用这种发布火车模式，每个工作日早上七点钟更新其网站。

虽然项目制发布方式短期内不会消失，但是，城际快线模式可以做为软件交付团队能力的一种指示器。

参考文章：

乔梁 ：持续交付2.0

标点符：软件开发中的火车模型发布模式