软件发布模式是软件开发过程中的核心议题，不同企业会根据自身业务特点、技术能力和团队规模选择不同的发布策略。本文要介绍的，是三种主流的发布模式——项目制发布、火车模型发布和城际快线发布模式。

项目制发布是最传统的一种方式。团队在版本规划阶段就确定好本版本要交付的功能清单，只有当所有功能都达到发布质量标准了，新版本才会正式发布。这种模式最明显的特征是版本之间的时间间隔不确定，完全取决于功能集的准备情况。



对需求方来说，项目制发布有个很大的好处：能精确知道每个版本包含哪些功能。这对商业套装软件的销售策略特别有利。销售团队可以基于明确的功能列表来推广产品、给客户做承诺，客户的预期管理也变得更可控。

但缺点也很明显。整个交付周期比较长，参与的人多，需求一旦变化就很容易打乱既定的发布计划。市场环境变了或者客户提出新需求时，协调各方资源、调整发布节奏就成了巨大的挑战。

火车模型发布这个名字很形象——像火车时刻表一样有固定的发布时间表。很多成熟的互联网公司都用这种策略，Mozilla Firefox就是典型例子。它的发布过程严格遵循火车模型：开发新功能并进入mozilla-central向用户发布分支，需要12到18周；而IE浏览器有些版本好几年都不向用户推送更新。

Firefox的发布周期比较稳定，大约18周，其中6周用来开发，12周用来稳定。新的开发成果不会直接发布到Aurora和Beta分支，而是需要经过开发人员和社区测试人员的共同验证。开发过程中如果发现问题，得先解决才能继续推进。



这种模式的核心优势在于可预测性。发布火车的时间表提前好几个月就定好了，各业务和技术部门有充足的时间做依赖评估和影响分析。用户也能提前知道每个版本有哪些重要特性、什么时候发布，这样就能更好地规划自己的产品升级节奏。即使想在生产环境里用新版本，也可以等它完全成熟稳定之后再部署。

火车模型的缺点同样不容忽视。提前很长时间制定时间计划，整个过程就会变得非常正式和结构化，需要大量格式化的数据来支持决策。这些数据包括发布的详细信息、相对标识、名称、部署日期、风险等级、发布类型，还有整个生命周期各个阶段和预定日期的详细规划。



城际快线模式完全是另一种思路。它根据发布时间点前已达到固定质量标准的功能来选择发布内容，时间周期相对较短，通常可以压缩到一周甚至一天。这种模式在互联网服务或SaaS公司中非常常见。

城际快线模式和传统火车模型的核心差异在于发布周期间隔更短，一般不超过两周。负责功能开发的团队可以选择乘坐哪一班“城际快线”，不用提前很长时间确定计划。这种模式大大降低了团队和角色之间的协调成本，因为每个人都知道每次发布的具体时间点，所有任务都能提前协调。即使某个功能没赶上最新版本，团队也清楚它是否能在下次发布时间点发布。

Facebook就是典型的例子，它的主站发布周期达到每个工作日两次。这种高频率发布带来了一些独特的好处：每个人都清楚每个时间点该做什么，能感受到功能的持续进步，团队速度不断提高，也更注重生产质量。

当然，城际快线模式也有挑战。未完成的代码可能会被一起发布，团队成员始终处于紧迫感中。如果发布频率变慢，就需要投入更多时间进行规划。

至于发布火车间隔多长时间合适，这个问题很难有统一答案，但可以给出一个基本原则：在不影响用户体验、不增加成本和合规压力的前提下，尽可能缩短发布周期。比如目前如果是每月发布一个版本，就可以把目标设为两周发布一次。

分支策略和版本发布模式之间存在微妙的关联。在项目制发布模式下，研发团队通常采用主干开发模式；而在使用城际快线模式的团队中，也倾向于主干开发。当发布周期介于两者之间时，分支策略通常会偏向多分支开发模式。

项目制发布模式并不会完全消失。在新产品完成第一个基本产品MVP之前，很多传统的首次发布过程仍然需要这种模式。不过城际快线模式正变得越来越流行，越来越多的企业开始采用这种模式。即使在当前版本发布周期较长的企业中，也经常在项目制发布模式中加入固定时间的迭代，要求在每个迭代结束时交付可用的产品。

当发布周期短到两周或更短时，主干开发模式更具优势。因为分支开发模式的合并成本会成为城际快线发布模式的障碍。

其实不少互联网公司在2010年之前就选择了城际快线模式。Facebook主站开始使用这种模式后，2012年每个工作日定期发布两次，移动端的发布节奏也从最初的项目制发布转变为城际快线模式。Google的Chrome PC版本也选择了城际快线模式，Beta版本每周发布一次，稳定版本每月发布一次。在国内，2011年人民网也采用了这种发布火车模式，每个工作日早上7点更新网站。

虽然项目制发布不会在短时间内消失，但城际快线模式可以作为衡量软件交付团队能力的一个重要指标。它反映了团队的协作效率、技术成熟度和市场响应能力，是现代软件工程追求快速迭代、持续交付理念的具体体现。