发布模式与分支策略

本文节选自于《持续交付2.0》一书的第八章“利于集成的分支策略”。

企业需要根据开发或维护的软件产品类型的不同，结合发布频率，并考虑自身团队成员能力和基础设施水平，如自动化测试程度、程序运行环境的管理水平、团队纪律性等，来决定适合自己的分支策略。

三种版本发布模式

版本发布的基本模式有三种。一是项目制发布模式 (Project Release Mode)，二是版本火车模式（Release Train Mode），三是城际快线模式(IntercityExpress Mode)。无论哪种发布策略，均有三个约束变量，即交付时间点（Schedule）、特性数量（Features）和交付质量（Quality），如下图所示。在投入资源不变的情况下，如果其中两个要素固定，那么就只有第三个要素存在灵活调整的空间。

例如，对发布的交付时间点和交付质量提出固定要求后，那么该版本的特性数量也就相对固定了，如下图所示。 在这三要素中，谷歌公司的Chrome团队，以及Facebook公司均选择了因定时间周期与质量标准。

1、项目制发布模式（Project Release Mode）

项目制发布模式是指在软件研发规划中，预先确定某一版本所需包含的功能特性数量，当该集合内的所有特性全部开发完成，并且达到相应的发布质量标准后，才能发布该版本。前后两次发布之间的时间间隔并没有明确的规定，而是根据新版本要求的特性集合开发完成并达到发布标准，对所需时间进行评估确定的。

这种模式是最古老的发布方式，其目标是：针对一个特定版本，在确定了版本中的特性数量和质量标准以后，再估计版本交付周期，这相当于固定了特性数量和质量要求，那么团队可能交付的时间点也就相对固定了。

项目制发布的好处在于：可以确切地知道每个版本包括哪些具体功能，有利于商业套装软件的售卖模式（卖版本拷贝和授权，收取软件维护费用，当包含有新功能的版本发行后，再向客户收取新版本的升级费用）。同时，这也符合人们的安全生产习惯，即：绝对不能把未完成的功能带到即将发布的版本中。

不足之处在于：通常项目整个交付周期较长，参与人员众多。在版本研发周期中由于某些原因导致需求变更（如增加需求、修改原有需求实现方式、或者进行需求置换）时，需要重新确定项目的交付时间，就会影响那些原本能够按期交付的需求。因为，这种项目制发布模式需要等所有需求全部实现完成后才能一起发布。

2、发布火车模式（ReleaseTrain Mode）

发布火车模式常见于大型套装分发类软件。大型传统软件企业通常有多条产品线，各产品线之间存在非常复杂的相互依赖关系。为了能够使各产品线协同发布，这些企业通常会为每条产品线都制定好每个版本的发布周期，即：每个版本都象一列火车，事先计划好什么时间点发车。

为了能够准时发布，要求所有参与到该版本开发的团队必须对齐该版本的各个开发阶段。这种严格的时间一致性要求是因为该产品线的时间变更会引起其它产品线的变更，而这些更改很可能影响共享的系统集成测试环境的分配。

在大多数情况下，由于计划和集成依赖关系，发布列车设置为季度交付窗口，但通常不会超过10个月。这种模式现在常见于智能设备制造或者大型复杂软件的开发。

当公布这种火车时间表时，发布管理团队通常与负责各产品开发的团队进行提前沟通，讨论要发布哪些内容，有时甚至需要提前几个月的时间，并将其结论发布在企业版本表中，类似于下图中LiberOffice的版本火车的时刻表。

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

制定发布计划的活动是一个非常正式和结构化的过程，需要一些格式化数据，以确保参加发布火车的团队能够对正式发布的可行性做出判断。这些数据包括：

发布详细信息（相对标识，名称，部署日期，风险级别，发布类型 - 企业，计划或投资组合）

整个生命周期中各个阶段及预定日期，如表8-2所示。

每个阶段要完成的活动和任务。

里程碑时间和质量要求。

负责管理发布火车的主要负责人。

该模式的好处在于：对于企业来说，可以通过并行多列火车的方式，将突发需求排入某一列版本火车。用户可以提前体验最新产品版本所提供的新特性，而不必影响原有生产线上正在使用的旧版本。

体验之后再决定是否将其应用于自己的生产环境上。既便已经决定将这个新版本用于自己的生产环境中，也可以等到这个新版本成熟稳定之后再这么做。

在这种模式下，如果参与团队的人数较多，沟通协调成本较高。

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

城际快线模式是指在发布策略三要素中，固定其中的时间和质量两个维度，且时间周期相对较短（如一个星期，甚至一天，或更少），针对那些在发布时间点已达到固定质量标准的特性进行一次发布。它与发布火车模式的区别在于两点：

（1）发布周期间隔较短，通常在两个星期以内；

（2）负责特性开发的团队可以自己选择搭乘哪列城际快线，而不必提前很长时间确定下来。

这种模式常见于提供互联网服务或SaaS服务的软件公司。其好处在于减少了团队及角色之间的协调成本。因为每个人都事先知道每次发布的具体时间点，所有工作任务都可以按这个时间点提前进行协调。

而且，即使某个特性没有及时赶上最近的一次版本发布，他们也确切地知道这个特性是否可以在下一次发布时间点对外发布。

例如，脸书公司（Facebook）的web网站在2013年的部署推送频率已达到每天发布2次，每周发布一次大版本。其分支发布策略如下图所示。

每个星期日从主干上拉一个发布分支，自动化测试验证通过以后，即地公司内部人员开放（在公司内访问facebook网站，会直接重定向到latest的子域名）。运行过程中如果出现缺陷，可以在主干上修复，然后分捡到(CherryPick)发布分支上。发布分支上的代码每天两次更新latest子域，对公司员工开发使用。如果版本稳定，向外部用户发布，同样是每天两次。

据报道，自2017年开始，Facebook网站的分支发布策略已经从一天发布两次的“主干开发，分支发布”模式改变为平均每天发布9到10次的“主干开发，主干发布”模式。

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

（1） 每个人都非常清楚各个时间点；

（2） 更加聚焦于生产质量。

当然，也有其不足之处，由于发布频率较高，所以未完成功能的代码也会一同发布出去，对于代码提交质量的要求较高，需要强大的质量基础设施保证。

使得这种城际快线模式，间隔多长时间发出一趟合适呢？我的建议是：在不影响用户体验、不增加成本且合规的前提下，让发布周期尽可能缩短到令你感到有些紧张的节奏。比如原来每个月发布一个版本，现在可以把两个星期做为一个目标。

分支模式与发布策略的关系

分支策略与版本发布频率之间有一定的相关性，如下图所示。通常，软件开发周期极长的“项目制”团队和软件发布频率极高的“城际快轨式”团队会使用“主干开发，主干发布”的分支策略。

而次之的团队会使用“主干开发，分支发布”的分支策略。两者之间的团队会使用“分支开发、主干发布”的分支策略。

当然，这并不是绝对的，其中会有很大的重叠部分，通常会受团队成员人数、产品架构和质量保障基础设施状况的影响。

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

城际快线模式是持续交付2.0所提倡的模式。越来越多的企业开始使用这种城际快线模式。

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

一般来说，当发布周期短到一定程度后，主干开发模式更加具有优势，因为分支开发模式的合并与验证成本会成为短周期发布的障碍。如果发布周期短于两个星期，软件团队应该毫不犹豫地转向“主干开发模式”。

篇后语：对于大规模快速建造来说，比较完善的工程方法体系的必须的。“主干开发的城际快线模式”对团队工程纪律有很高的要求，也对团队各角色协作有较高的要求。