立即登录 编者按：火车班次不是随便排的，背后是长时间的调度和协调。有意思的是，这种"按时发车、准点到站"的思路，被软件行业借用了过去。
本文聊聊三种软件发布模式。先理清现在常见的做法，再看"火车模型"是怎么运作的，以及它的一种变体——城际快线模式。
项目制发布：什么都定好了再出门
这是最传统的做法。项目启动前，先把这版要做哪些功能全部列清楚，等所有功能都开发测试完毕、达到质量标准，再打包发布。两版之间隔多久？说不准，得看上一版全部做完要多久。
好处是清清楚楚——销售可以跟客户拍胸脯说"这版包含ABC功能"，卖套装软件尤其合适。坏处也明显：周期拉得太长，参与的人多，中间需求一变，整个时间表就乱套。
火车模型发布：赶不上这趟，等下趟
《启示录：打造用户喜爱的产品》里提到，不少成熟互联网公司用这个模式。Mozilla的Firefox是个典型例子。
Firefox的做法是固定发车时间：新功能想上线？先看能不能赶上最近的列车。从代码合入主干到用户手中，大约12到18周。每个周期拆成6周开发加12周稳定期——Aurora和Beta分支专门用来打磨稳定性，开发人员和社区测试者一起找问题、修Bug。与此同时，主干上的开发不会停，每六周选一批成熟的功能合并到Aurora，再进Beta。
为什么要提前几个月把发布时间表定死？主要是让各业务和技术部门有充足时间评估依赖关系和影响面。用户也能提前知道什么时候有什么新功能，想尝鲜的可以早点体验，求稳的也可以等版本成熟再上。
这种模式对计划性要求很高。发布团队需要收集一堆格式化的信息：版本标识、部署日期、风险等级、生命周期各阶段的任务和里程碑、质量门槛、负责人是谁……LibreOffice 5.4的火车时刻表就是这么一张密密麻麻的表格。
城际快线模式：班次更密、上车更灵活
火车模型的进化版。同样是固定时间发车，但间隔大幅缩短——一周甚至一天。质量门槛不变，到点就发，发的是已经达标的功能。
和传统火车模型比，两个关键区别：一是周期短得多，通常两周以内；二是团队不用提前很久占座，想好了随时上车。Facebook主站曾经每个工作日发两次，就是这种打法。
优势很实在：时间透明，进度看得见，节奏逼着人提速，质量意识也更强。代价是未完成的代码可能硬着头皮发，人人神经紧绷，一旦频率掉下来，重新规划反而更费时间。
间隔到底设多短？这得看企业具体情况。一个粗略的原则：不影响用户体验、不增加成本、不违规的前提下，尽量缩短，短到让你微微有点紧张。比如原来每月一发，试试两周？当然，真做起来没那么容易。
分支策略怎么配？
发布模式和代码分支策略其实是挂钩的。
项目制发布，通常用主干开发模式。城际快线模式也倾向主干开发——发布周期短到这份上，多分支合并的成本扛不住。周期介于两者之间的，往往用多分支开发、主干发布（按特性或按团队分都可以），不过这也得看团队规模和产品架构。
项目制发布不会消失。新产品从0到1、MVP还没成型的时候，传统的首次发布流程依然需要它。但城际快线模式确实越来越主流，不少长周期项目也会在里面插入固定时长的迭代，每轮结束都要求产出"可交付"的版本——能跑通，已完成的功能达标，未必商业发布。
再补充一点：当发布周期短到一定程度，主干开发的优势会放大。分支合并的代价在城际快线模式下几乎无法忍受。如果周期等于或短于两周，建议果断转向主干开发。
2010年前后，不少互联网公司已经这么干了。Facebook主站是其中之一，2012年做到工作日每天发两次，移动端也从项目制转向城际快线。Google Chrome PC版走同样的路，Beta每周一发，Stable每月一发。国内也有先例，2011年人民网就是每个工作日早上七点更新网站。
项目制发布不会消亡，但城际快线模式正在成为衡量软件交付能力的一个标尺。编者按：火车班次从来不是随便排的，背后是漫长的调度与协调。有意思的是，这种"按时发车、准点到站"的思路，后来被软件行业学了去。
这篇文章想聊的是三种软件发布模式。我们先看看现在常见的做法，再讲讲"火车模型"怎么运作，以及它的一种变体——城际快线模式。
项目制发布：什么都定好了再出门
这是最传统的路子。项目启动前，先把这版要做哪些功能列得明明白白，等全部开发测试完毕、质量达标了，再打包发布。两版之间隔多久？说不准，得看上一版什么时候能全做完。
好处是清清楚楚——销售可以跟客户拍胸脯说"这版包含ABC功能"，卖套装软件尤其合适。坏处也很明显：周期拖得太长，参与的人多，中间需求一变，整个时间表就乱套了。
火车模型发布：赶不上这趟，等下趟
《启示录：打造用户喜爱的产品》里提到过，不少成熟互联网公司都在用这种模式。Mozilla的Firefox是个典型例子。
Firefox的做法是固定发车时间。新功能想上线？先看能不能赶上最近的列车。从代码合入主干到用户手中，大约12到18周。每个周期拆成6周开发加12周稳定期——Aurora和Beta分支专门用来打磨稳定性，开发人员和社区测试者一起找问题、修Bug。与此同时，主干上的开发不会停，每六周选一批成熟的功能合并到Aurora，再进Beta。
为什么要提前几个月把发布时间表定死？主要是让各业务和技术部门有充足时间评估依赖关系和影响面。用户也能提前知道什么时候有什么新功能，想尝鲜的可以早点体验，求稳的也可以等版本成熟再上。
这种模式对计划性要求很高。发布团队需要收集一堆格式化的信息：版本标识、部署日期、风险等级、生命周期各阶段的任务和里程碑、质量门槛、负责人是谁……LibreOffice 5.4的火车时刻表就是这么一张密密麻麻的表格。
城际快线模式：班次更密、上车更灵活
这是火车模型的进化版。同样是固定时间发车，但间隔大幅缩短到一周甚至一天。质量门槛不变，到点就发，只发已经达标的功能。
和传统火车模型相比，关键区别有两个：一是周期短得多，通常两周以内；二是团队不用提前很久占座，想好了随时上车。Facebook主站曾经每个工作日发两次，就是这种打法。
优势很实在：时间透明，进度看得见，节奏逼着人提速，质量意识也更强。代价是未完成的代码可能硬着头皮发，人人神经紧绷，一旦频率掉下来，重新规划反而更费时间。
间隔到底设多短？这得看企业具体情况。一个粗略的原则是：不影响用户体验、不增加成本、不违规的前提下，尽量缩短，短到让你微微有点紧张。比如原来每月一发，试试两周？当然，真做起来没那么容易。
分支策略怎么配？
发布模式和代码分支策略其实是挂钩的。
项目制发布通常用主干开发模式。城际快线模式也倾向主干开发——发布周期短到这份上，多分支合并的成本根本扛不住。周期介于两者之间的，往往用多分支开发、主干发布（按特性或按团队分都可以），不过这也得看团队规模和产品架构。
项目制发布不会消失。新产品从0到1、MVP还没成型的时候，传统的首次发布流程依然需要它。但城际快线模式确实越来越主流，不少长周期项目也会在里面插入固定时长的迭代，每轮结束都要求产出"可交付"的版本——能跑通，已完成的功能达标，未必商业发布。
当发布周期短到一定程度，主干开发的优势会进一步放大。分支合并的代价在城际快线模式下几乎无法忍受。如果周期等于或短于两周，建议果断转向主干开发。
2010年前后，不少互联网公司已经这么干了。Facebook主站是其中之一，2012年做到工作日每天发两次，移动端也从项目制转向城际快线。Google Chrome PC版走同样的路，Beta每周一发，Stable每月一发。国内也有先例，2011年人民网就是每个工作日早上七点更新网站。
项目制发布不会消亡，但城际快线模式正在成为衡量软件交付能力的一个标尺。