《持续交付》译者乔梁：版本发布模式有几种？

本文转载自公众号「持续交付」，DevOps 时代社区致力于陪伴您的职业生涯，与您一起愉快的成长。

作者介绍

乔梁
《持续交付》中文版译者，腾讯高级管理顾问，“轻敏捷”方法创始人，持续交付先行者，映客、卷皮、墨迹天气等多家移动互联网公司高级管理顾问，也为魅族、上汽、平安等不同类型的公司提供组织管理咨询服务。

现在，IT媒体把DevOps炒的火热，但还是让我们来一起研究一下最基本的东西吧。因为这些最基本的东西会从根本上影响你做事的方式。

今天先谈谈软件版本发布模式。

选择版本发布策略时，通常有以下三个维度可以调整（时间、特性集和质量）。

依据三个调整项，可以总结为如下三种发布模式：

 项目制发布模式（Project Rlease Mode）

 传统版本火车模式（Release Train Mode)

 城际快线模式 （IntercityExpress Mode）

项目制发布模式是指在软件某一个版本规划中，预先确定该版本所需包含的特性集合，当该集合内的所有特性全部开发完成（通常不包含那些尚未开发完成的特性的相关代码），并且达到相应的发布质量标准后，才能发布该版本。

前后两次发布之间的时间间隔并没有明确的规定，而是根据前一版本所有特性集合开发完成并达到发布标准所需时间进行评估确定的。

明显的好处在于：可以确切地知道每个版本包括哪些具体功能，有利于商业套装软件的售卖模式（卖版本拷贝和license，收取软件维护费用，当包含有新功能的版本发行后，再向客户收取新版本的升级费用）。

同时，这也符合人们的安全生产习惯，即：不能够把未完成的功能带到即将发布的版本中，因为这会增加缺陷风险。

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

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

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

 在大多数情况下，由于计划和集成依赖关系，发布列车设置为季度交付窗口，但通常不会超过10个月。

当公布这种发布火车时间表时，发布管理团队通常提前与负责各种产品系统开发的团队（有时甚至提前几个月），并将其结论公布在企业版本表中，类似于下图（LiberOffice的版本火车的时刻表 ）。

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

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

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

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

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

2. 整个生命周期中各个阶段及预定日期，如下图（LibreOffice5.4版本火车的时间表 ）所示

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

4. 里程碑时间和质量要求

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

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

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

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

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

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

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

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

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

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

2. 每个人都感觉到特性进展；

3. 速度不断提升；

4. 更加聚焦于生产质量。

当然，也有其不足之处：

1. 未完成的代码也会一同发布出去；

2. 每个人都有紧迫感；

3. 如果频率变慢，需要更多做计划的时间

那么，这样的发布火车，间隔多长时间发出一趟合适呢？在不了解企业具体状况时，这是一个非常难回答的一个问题，但仍旧可以给出一些建议，

即：在不影响用户体验、不增加成本且合规的前提下，让发布周期尽可能缩短到令你感到有些紧张的节奏。

比如原来每个月发布一个版本，现在可以把两个星期做为一个目标。当然，这不可能轻松做到。

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

分支策略与版本发布之间有一种微妙的相关性：

1. 在时间周期较长的项目制发布模式下，研发团队采用的分支策略通常会倾向于主干开发模式

2. 在使用城际快线模式的团队中，也通常会倾向于采用主干开发模式

3. 发布周期在两者之间时，其分支策略通常会倾向于“多分支开发，主干发布”的模式（无论是特性分支也好，还是团队分支也好）

当然，这并不是绝对的，其中会有很大的重叠部分，通常会受团队成员人数和产品架构影响。 

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

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

即使在那些目前的版本发布周期较长的企业中，也常常在项目制发布模式中套用城际快线模式，即：在项目周期内加入固定时间的迭代，并要求在每个迭代结束时都能得到可交付状态的产品。

这里的可交付状态是指软件可以正常运行，且已完成的软件特性达到发布质量标准，而非可商业化发布。

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

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

很多互联网公司选择城际快线模式。如2010年之前，Facebook主站就开始使用这种城际快线模式，2012年更是达到每个工作日定时发布两次。其移动端的发版节奏也从最初的项目制发布模式改为城际快线模式。而Google的Chrome PC版本也是选择了城际快线模式 ，其Beta版本每周发布一次，而Stable版本每月发布一次。在国内公司中，2011年的百姓网也使用这种发布火车模式，每个工作日早上七点钟更新其网站。

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

如何打造城际快线模式，提升持续交付能力？

请参加我在8月份上海举办的《持续交付与DevOps精要》公开课吧~~

哈哈哈~~~

——————————————————————————

扫描下方二维码关注乔梁老师个人公众号「持续交付」

近期好文：

想更深的理解持续交付？

想更透彻的领悟 DevOps？

来 DevOpsDays 上海站吧

点击“阅读原文”，关注 DevOpsDays 上海站