什么是班车模式？

本文主要是介绍什么是班车模式？，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！

导读

今天给大家介绍下Google的Release Train Model（俗称火车发版模型）。大家知道，在公司初创的时候，产品技术人数比较少，版本发布的流程也比较简单，速度也非常快，只需要那么一两个技术骨干把控好代码质量就基本上不会出现太多的问题。

而如果公司进入快速发展阶段，产品技术人员迅速扩展，产品需求迭代的种类和规模都成倍增加的情况下，之前依赖于个别人的套路可能就会玩不转了，因为此时产品、开发已经划分多条线，沟通成本已经变得很高，稍不注意就会出现问题，导致线上问题不断。这也就是为什么我们经常会感觉很多创业公司“乱”的原因之一。

当然还有很多其他原因会导致创业公司让人感觉混乱，这里不是我们要讨论的重点，在本篇文章中，我们主要讨论如何让产品迭代更加高效有序的Release Train流程。

Release Train的基本思想

Releae Train简单来说就是一种软件发布的形式和计划。不同业务线可以根据发布的独立性来制定自己的Release Train。以一个互联网App的发布为例，假设固定每两周发布一个版本（或者叫发一趟车可能比较形象），那么针对App中不同的功能需求，参与各方包括产品经理、技术（涉及前后端）、QA都需要提前互相沟通好自己的需求和内容，并在规定的时间内完成相应的步骤，如果没有问题能赶上车就正式跟车，如果存在某些问题那么就要及时下车，以免影响其他需求的上线和产品的正常迭代。

一句话就是“车是按照时间发的，能赶上火车的就一起走，赶不上火车的，就只能等待下一班车了！”，通过这种发布形式确保产品的持续迭代。如何协调好产品、技术、QA等参与方，以及制定合理的时间节点，是确保Release Trian流程能够正常运转的关键。

发车时间轴

如果按照每两周一个版本的迭代速度，为了确保每趟车都能够顺利发车，在Release Trian流程上就需要有严格的计划。

在这个时间轴中，很多工作其实是需要提前做的，在正式上车之前PM需要组织需求评审、开发人员需要根据需求进行功能开发。此时该需求的开发代码处于功能开发分支上（具体关于开发代码分支管理的内容可以在后面进行讨论），如果功能开发完毕，准备搭乘本躺车，就需要严格按照图中的时间轴运转。

在每周四需要TPM或项目经理组织召开Cut Meeting会议，及时Cut掉无法按照正常节奏上车的需求或功能。一旦Cut Meeting后，剩下的功能和需求就需要全力确保进度，各需求开发负责人需要在周五前完成代码自测并合并至本次发布代码版本中，如果无法完成的需要自觉周末加班，确保最晚周日20:00钱完成本次Release所有功能的提测。

代码分支管理

在整个Release Trian流程中，在一个版本的发布流程中，可能会涉及多个开发人员同时并行进行开发，如何确保代码不冲突就需要对代码分支进行合理的管理。

为了更好的适配整个Release Trian流程，需要对代码分支进行有效地命名，对于需要Release的代码分支，统一用release/1.1.x 这样的方式命名，并需要约定相应的权限。

这里介绍两种主要代码发布流程：

（一）、新功能开发&Release

这是主要的代码开发流程，当一名开发人员开始开发一个新功能时，需要从master上拉取一个分支前缀命名为feature/<feature-name>的开发代码分支，并在该分支上完成自己的功能开发及自测工作。

如果该功能需要跟上某躺车，进入一个Release Train流程，则需要根据流程中的时间节点，在完成代码自测后联系相应的release master，这是的release master是指负责负责本躺车涉及的所有公共代码工程合并的技术人员。当准备开始一次Release Train时Release Master会从master代码分支中拉取分支前缀为release/1.0.x这样的发布分支。

之后，功能开发人员提出从feature分支到release分支的Merge Request，并将assignee指向release master或者所属项目的owner。release master或者项目owner进行code review，当code review通过后，接受Merge Request。

至此就完成了流程中各端代码的Merge工作，如果没有问题就正式将release分支代码提请QA测试。最后，在完成正式线上发布后再将release分支代码合并至master分支，本次release train完成！

流程示意图如下：

（二）、线上问题紧急修复（Hotfix）

如果线上发现紧急Bug，需要针对线上版本代码进行紧急修复的话，需要相应问题责任开发从master拉取前缀名为hotfix/<hotfix-name>的修复分支，当完成代码bug修复工作并自测完成后，向线上运行的release版本代码发起Merge Request，与正常流程一样需要相关的人员进行code review，完成后由release master接受合并，release分支提请QA测试，完成后上线。最后将此次hotfix所产生的代码，再次从release分支合并到master分支，以便下一次的Release Train流程。

流程示意图如下：