背景

目前，互联网产品呈现出高频优化迭代的趋势，需求方希望尽早地看到结果，并给予及时反馈，所以技术团队需要用“小步快跑”的姿势来做产品，尽早地交付新版本。基于以上背景，美团用户端研发平台适时地推行了单周发版的迭代策略。单周版本迭代的优点可以概括为三个方面：更快地验证产品创意能否符合预期，更灵活地上线节奏，更早地修复线上Bug。

首先说一下美团平台的发版策略，主要变更点是由之前的每四周发一版改为每周都有发版。具体比照如下：

• （旧）三周迭代指的是2周开发+1周半测试，依赖固定的排期和测试时间，假如错过排期，则需要等待至少20天方可跟着下个版本迭代发布，线上验证产品效果的时间偏长。具体示例形容如下：

image

• （新）单周版本迭代指一周一发版，单周迭代版本排期、测试不再依赖固定时间节点，需求开发并测试完成，即可以搭乘最近一周的发版“小火车”，跟版发布直接上线。对于一般需求而言，这将会大大缩短迭代时间。

业务方研发人员的痛点

在之前按月发版的迭代节奏下，基本上所有的需求都属于串行开发，每个版本的开发流程比较固定。从“评审-开发-提测-灰度-上线”各个环节都处于一个固定的时间点来顺序执行，开发人力资源的协调方式也相对简单。全面推进单周发版之后，并不能把所有需求压缩到5天之内开发完成，而是会存在大量的并行开发的场景，之前的固定时间节点一律被打破，由固定周期变成了动态化调配，这给业务方的需求管理和研发人员人力管理都带来了指数式复杂度的提升。一旦进入并行开发，需求之间会产生冲突和依赖关系，版本代码也会随之产生冲突和依赖，这也大大提高了开发过程中的分支管理成本，如何规范化管理分支，降低分支冲突，把控代码质量，是本文接下来要探讨的重点。

下面形容了几种典型的单周发版带来的问题：

• 业务需求开发周期不固定，会存在大量的多版本、多需求并行开发。平台只提供了单周发版的基础策略，每5天发一版，业务方完成需求就可搭车发版。

对于各业务方来说，需求开发往往并不是都能在5天内完成，一般需求在5~10天左右，在之前串行发版模式下这个问题其实也存在，但并不突出，在单周发版的前提下，都要面临跨版本开发，意味着多个版本多个需求会同步并行开发，这给业务方的分支管理带来了极大的挑战。

• 业务方架构复杂，仓库依赖多，单周发版分支创立合并维护成本大。

交通业务线涉及火车票、国内机票、国际机票多条业务线，代码仓库除了业务线的独立仓库，还有交通首页，交通公共仓库，RN仓库等多个仓库，Android端6个Git仓库，iOS端5个仓库，RN5个仓库，共计16个Git仓库。

多仓库频繁发版分支代码存在安全风险，容易漏合代码，冲掉线上代码。

image

• 业务线自身的公共基础库需求变动频繁。也需要具有单周发版的能力。

例如交通公共基础仓库，承载了很多交通业务线的UI功能组件，这些公共组件的业务变化频繁，公共基础仓库变化的同时，可能会对使用组件的业务产生影响，需要同步的更新发版。美团平台的策略是公共服务组件每四个小版本统一更新一次，但对业务方自身组件这种策略限制较大，还是需要公共组件也要具有随时发版的能力。

单周发版分支管了解决方案

针对上面提出的问题，交通用户端团队通过技术培训、流程优化、关键点检测、自动化解决等方式保证分支代码的安全。技术培训主要是增强技术人员分支管理的基本知识，Git的正确使用方法，这里不做过多形容。本文主要探讨关键点检测，以及如何进行自动化的分支管理。

在实施单周发版之前，业务方代码仓库只有两个分支，Develop分支，即开发分支；Stage分支，即发版分支；开发流程基本在串行开发模式，每个版本10天开发，8天测试，而后进入下一版本的开发。

image

这种方式只能适用于节奏固定的长周期开发方式，对于多版本并行开发来说，有点力不从心，显然已经不能承载当前更灵活的发版节奏。

针对这些问题，我们推出了如下分支管理结构。总的来说，就是废除之前作为开发分支的Develop分支，建立对应的Release发版分支，每个版本打包从Release分支直接打包；同时Stage分支不再承担打包职责，而是作为一个主干分支实时同步所有已发布上线的功能，Stage分支更像一个“母体”，孵化出Release分支和其它Feature分支；当Release分支测试通过、并且发版上线之后，再合入到Stage分支，此时所有正在开发中的其它分支都需要同步Stage分支的最新代码，保证下一个即将发布的版本的功能代码的完整性。

image

上面的流程形容可能有些复杂，下面是简化的流程图，每个版本都有自己的生命周期：

image

1. 从Stage创立一个Release分支；
2. 进入开发阶段；
3. 假如Stage分支有变化，同步Stage分支；
4. 打包测试；
5. 测试通过，发布线上；
6. 发布线上之后，合回Stage分支。

为了适应单周发版，新的开发流程也引入了很多新的挑战。例如下图所示的一个Branch分支中涉及的六个关键点：创立分支、合入主干、主干变化通知、Merge主干变化、检测主干同步、未同步阻拦，除了这些还要考虑多仓库同步操作的问题，还有热修复版本的管理方式的问题。是否把这些关键节点正当的规范和把控起来，是我们当前应对多分支并行开发的主要难点：

image

如何更高效的处理这些问题呢？结合我们当前使用的工具：Git + Atlassian Stash 代码仓库管理工具；Jenkins Build打包工具；大象（美团内部通讯工具）内网通信工具。目前这三个开发工具已经非常成熟、稳固，并且接口丰富易于扩展，我们需要配合当前单周发版的分支管理模式，利用这些工具来进行扩开展发，正所谓“要站在巨人的肩膀上”。

1. 创立分支Release分支如何创立，何时创立，分支命名规范定义如何束缚？

创立Release分支，本质上是从Stage新建一个分支，当前提前一个周期创立新的发版分支，例如在10.1.1版本Release后，创立10.1.3版本的分支，此时10.1.2版本处于开发测试阶段。业务方所有的分支命名和平台的分支命名保持一致，采用Release/x.x.x的格式，但同时需要更新成为即将发布的Release版本号，例如10.1.3。

现在交通业务线多达十几个仓库，每个仓库每周都要操作一次需要耗费大量人力。之前每个分支的创立都是通过Stash或者者手工创立，能不能自动化批解决的创立呢？答案是一定的。对此，我们采用了Jenkins的方式，需要建立一个Jenkins Job, 基本原理就是通过命令行的方式进行Branch的创立，而后通过Job管理，批解决建立所有仓库的Release分支，这样就收敛了Branch的创立，即采用统一的命名规范，并且同时更新版本号。这就处理了创立分支的难点，实现了自动化创立分支，并且实现了规范化命名。

2. 如何知道Stage分支有变化，变化后需要做什么，不做会怎么？

一个好的开发习惯，就是每天写码之前都同步主分支，但是还是需要一个机制来确保同步。这里做了三个措施来确保各个分支和Stage是保持同步的：一个通知，一个警告，一次阻拦。这三个步骤处理主干变化通知、检测主干同步、未同步阻拦的问题。

一个通知：具体路径如下，建立了一个内部推送公众账号和一个Jenkins监听Job，当所有交通业务仓库Stage分支有代码改动，通知所有对应的开发人员，该仓库有代码变化，请及时合入。

一次警告：本地开发过程中，每次提交代码到远端仓库时，会触发一个Stage分支代码同步检测的脚本，假如发现未同步，会通过内部通讯系统通知提交者存在未同步主分支问题。但这里目前并不做强制阻拦，保证分支代码开发的整体流畅性。

最终阻拦：在开发分支打包的过程中强制阻拦，最终功能代码上线还是需要打包操作。在打包操作时统一收口，因为之前打包也是在Jenkins上来完成的，这里我们也是通过在打包Jenkins上接入了分支合并检测的插件，这样每次打包时会再次检测和主分支的同步情况。假如发现未同步则打包失败，确保每次发版都包含当前线上已有代码的功能，防止新版本丢失功能。

3. 如何合并分支，如何保证漏合？

和上面提到的第一个如何创立分支的问题相似，通过Jenkins Job来进行批量操作，可以一键创立所有分支的Pull Request；在每个版本发版之前，统一进行一次打包，合入美团的主分支，防止多个仓库有漏合的情况。

4. 公共基础库版本策略？

公共基础和业务分支保持同样的策略，通过批解决脚本同时建立分支，合并分支，监听分支变化，需要注意的是，每次版本更新，公共基础库也需要同步的打包，并且强制业务库更新。不然，假如基础仓库存在接口变动，有的业务更新了，有的业务没更新，最终会导致无法合入主分支，进而无法打出App包。

5. 热修复的版本管理策略？

热修复的确是一种非常规的解决方式。从准则上来讲，热修复需要在对应的Release分支上进行修改，而后把修改合入Stage分支，同时需要同步到其它正在开发的分支。实际的解决需要根据具体情况来分析，能否需要对线上多个版本热修复。假如多版本都要修复就不能再合入Stage分支，否则会导致Stage分支冲突，假如把Stage分支合入需要热修复的其它分支，会把线受骗前最新代码带入历史旧版本，会导致版本兼容性问题。最终执行起来可能还是对热修复版本进行单独解决，不肯定要进行Stage主分支的同步，热修复的版本管理成本会比较高，更多的需要人工介入。

未来展望

目前整体的分支发版流程已经基本完成，现在已经稳固运行了10个小版本，同时没有出现由于分支管理问题而引发的线上问题。

不过，当前整体流程的自动化程度还有待提高，每周需要人工去触发，很多代码合并过程中的冲突问题还需要人工去处理。未来我们希望能够自动化地根据平台的版本号自动创立分支，并且对于少量简单的冲突问题拥有自动化的解决能力。随着单周发版的不断成熟，未来对于持续交付能力也将不断提升，发版节奏可以不限于单周，一周两版或者是更快的发版节奏也成为一种新的可能。

作者详情

• 王坤，美团用户端开发工程师，2016年加入美团，目前主要负责大交通业务的用户端架构、版本管理及相关工作。