转转客户端持续集成--分支管理

背 景

互联网产品需要快速迭代，需求方希望尽早地看到结果，得到用户反馈，所以需要技术团队用“小步快跑”的方式来做产品，尽早地交付新版本。过去转转客户端团队是手工管理分支。存在以下问题:

1. 很难将分支和需求关联起来
2. 提测阶段，需要人为沟通功能分支是否合并测试
3. 分支之间代码领先落后不清楚，需要人为判断

针对以上问题，beetle平台与app组的鲁班系统一起，管理了从需求版本分支拉取、编译、提测，灰度一整套流程。今天主要分享一下beetle在多分支管理方面的经验。

开发分支模型

原来的项目版本分支都是手动拉取，现在统一托管为beetle处理。大致流程如下：

• 首先从master分支上拉取一个release分支作为版本分支
• 然后从一个版本分支拉取多个功能分支方便多开发人员协同开发，防止多人在单个分支上进行开发时修改代码影响其他人
• 版本分支打包上线后如果发现有bug则会在版本分支上拉出一个hotfix分支进行开发
• bug修复后由RD&QA同学判断hotfix的代码是否合并到master，因为有的bug是在老版本的代码基础上进行修改的，如果合入master则可能引起冲突

具体分支管理如下图:

整个流程如下：

1. 从master创建一个release分支
2. 进入开发阶段
3. 如果master分支有变化，同步master分支
4. 打包自测
5. 提测 自动打包并检测版本分支是否落后关联的功能分支，检测到落后情况会进行微信通知
6. 测试通过，开始灰度
7. 灰度完成，上线成功，合回master分支

新问题 新方案

app是转转最后一个接入beetle的工程类型，上文介绍的开发分支模型与原来的还有所不同（以前的分支开发模型大家可参考beetle平台百天记）。

新的开发流程也带来了一些新的挑战。例如一个branch分支从开发到上线中涉及的一些关键问题：

• 创建版本分支及其功能子分支
• master变化通知
• merge master
• 检测版本分支与功能子分支领先落后情况
• 子分支领先版本分支时的提醒
• 版本分支的未同步master拦截
• 热修复hotfix分支的管理方式

我们能否把这些关键节点进行合理的规范和把控，是当前应对多版本分支并行和版本分支的多子分支并行开发的主要难点。

1、版本分支及功能子分支如何创建，何时创建，分支命名规范定义如何约束？

• 版本分支，本质上是从master新建一个分支，只不过用户会在beetle平台新建分支方便管理版本分支在创建时关联的需求和版本号。业务方所有的分支命名由beetle统一管理，命名格式为（工程名-分支类型-仓库id-第几次创建的分支）如zzbeetle-feature-1444-90，这样就收敛了branch的创建，即采用统一的命名规范，实现了自动化创建分支。
• 功能子分支，是从版本分支上创建，子分支与版本分支的关系由beetle管理，这样方便检测分支与分支之间的落后领先情况。

2、如何知道master分支和功能子分支有变化，变化后需要做什么，不做会怎样？

• 页面提示：用户每次进入分支操作页面beetle都会检测版本分支与master分支和它的功能子分支的领先落后情况并在页面显示，用户可以选择合并master分支或者功能分支的代码
• 关键节点提示: 用户在提测时再次检测如果有子分支领先主分支则会给RD&QA同学发企业微信提醒
• app开发流程现阶段不强制用户必须合并master(其他流程是强制性的)，主要因为app的版本管理成本比较高。开发阶段强制合并会影响当前的开发测试效率，在后续阶段强制检测。

3、热修复的版本管理策略

哪个版本出现bug则以它作为父分支拉取hotfix分支，在修复完成后由RD&QA同学决定是否将hotfix分支的代码合入master，因为如果合并可能会出现代码冲突，或者出现版本兼容性的问题。

后续规划

目前app的发版流程已经基本完成，但还有不足之处。app的公共组件库尚未接入beetle，如果基础仓库存在接口变动，beetle无法感知。后续计划将公共组件库版本也纳入beetle管理，进一步减少手工操作，优化自动化管理能力，提高研发效率。如果大家有想法建议，请留言，欢迎讨论。