手机输入法多支线管理介绍

【背景】

搜狗输入法主线版本的迭代速度慢，大概1~1.5月/大版本，版本迭代速度已经跟不上项目需求，对比其他产品（抖音2个月5个版本，快手1个月4个版本等等）迭代速度确实需要改进。

【问题分析】

我们对整个项目流程的各个环节进行了梳理，希望能发现导致版本慢的一些原因。问题抽象汇总如下：

问题汇总为两个大的维度： ①项目流程有不规范的地方，存在内耗，导致时间和人员浪费； ②整体项目流程确实存在不灵活，不能满足需求、版本快速迭代、临时变更的痛点。

【解决方案】

1.【优化】对存在问题的流程进行改进优化；（这部分主要的解决方案就是推进《开发提测流程》、《产品验收流程》、《设计走查流程》等相关流程，不多做介绍，在我们的流程规范系列文章里都有。） 2.【创新】对当前的项目迭代方式进行改革，实施多支线并行开发、并行测试、多版本上线（简称多支线管理）。

【多支线管理介绍】

1.总的原则： ①形成需求池； ②每个需求一条支线； ③多条支线并行开发、并行测试； ④到规定上线时间点，评估多条支线状态，是否满足合并为一条支线上线的标准； ⑤合并代码，把已完成测试的需求合并到主线并发布。 用一张图来体现和之前只有一条支线时的变化：

2.多支线代码建立分支、代码合并示意图 在多支线管理的过程中，拉支线/建立分支，测试完毕后合并到主线这两步尤为重要。在此以一张图来说明：

简单做一下介绍： ①当8.27正式版发布后，根据优先级评估，从需求池里取四个需求拉四条开发支线：语音变声、视频皮肤、互金相关功能、斗图插件化框架，任意一条支线开发完毕后进进入测试阶段； ②在8.28第一轮灰度时间点时，测试进行风险和进度评估，得到结论：语音变声、视频皮肤、互金相关功能测试完毕无质量问题，合并到主线发布（上图中红线）；斗图插件化框架存在质量问题，不进行合并，仍然处于开发和测试阶段； ③发布8.28三轮灰度及8.28正式版 ④当8.28正式版发布后，根据优先级评估，从需求池里再取三个需求：8.29新功能1、8.29新功能2、8.29新功能3，拉三条支线重复上述1,2,3环节。 注意，此时，斗图插件框架支线完成测试并通过评估无质量问题，合并到8.29一并发布。 ⑤依此往复。

【效果评估】

1.需求灵活度/迭代速度/实验包灵活度提高： 强的需求变更/老板临时插入需求/实验包观察线上效果等需求通过新拉支线完成临时上线，目前可实现1个大版本/月，1~3个小版本。 2.抗风险能力提高： 制度上避免了第三方资源不到位、开发提测delay、需求变更、开发实现变更、测试delay可能导致的主线delay；delay的支线顺移到后续支线合并上线。

【细节补充】

1.每个版本的支线合并到主支线的时机？ --小灰前5天，如果支线经评估无风险&测试完毕，合入trunk支线。 2.线上bug如何修复合并？比如8.27正式版发版后发现有问题，则基于8.27正式版的新支线怎么处理？ --8.27正式版是稳定版本，如果有问题，在主支线上修改bug，会自动Merge到分支线中。 3.如何进行多支线的评测/稳定性？ --模块测试负责人各自负责自己模块的评测/稳定性，小灰前5天分支合并，开发利用2天时间解决冲突，3天进行集成测试（测试新模块间影响&主线整体评测&老模块回归）。 4.集成测试做什么？ --支线新功能主路径回归，已知严重Bug回归，已上线的老功能checklist回归，主要解决代码合并后可能产成的bug。

【待后续完善】

1.多支线管理对代码灵活Merge的要求较高，当前SVN的Merge功能还不够完善，后续会考虑把代码迁移到Git； 2.测试环节的自动化覆盖度不足，整体测试效率还有提升的空间。