1.5 统一代码分支策略
想必大家看到这里，应该迫不及待地想看代码质量提升项目如何运转了。但就在这个时候，我们发现一个非常棘手的问题，若这个问题不解决，很难让各团队进行有效配合，更难对各指标采用同一个评估标准。
既然可视化平台展现了各团队的指标数据，这就意味着开启了团队间的比较；既然我们把这些指标和趋势图搬到了代码质量委员会上，就要确保这些指标是准确的。否则，效能团队肯定会遭到质疑，进而导致项目推进受阻。
所以，先不着急，在运转项目前，我们先把这些影响指标数据准确性的因素找出来，然后和所有团队达成一致意见，按照统一的标准行事。这是很重要的。
1.5.1 往往简单的问题最复杂
基于当前现状，我们在做代码质量指标计算时，遇到如下问题。
1）技术团队有4个部署环境，分别是开发环境、测试环境、预生产环境和生产环境，多环境将导致分支策略和指标统计规则的复杂度增加。
我们想度量部署到各环境中的代码质量，因各团队使用的触发分支不一致，而无法使用统一的指标统计规则。若针对不同环境和团队设置不同的分支策略，可视化度量平台设计成本就会增加。所以，触发分支策略和各环境相对应很重要。
2）各团队的分支开发模式不一致，导致指标计算方式比较复杂。
比较常见的3种分支开发模式为主干开发、分支发布，分支开发、主干发布，主干开发、主干发布。统一分支开发模式很重要。图1-12所示为分支开发、主干发布模式。若采用这种分支开发模式，我们只需设置在分支代码合并到主干时触发指标计算即可。
图1-12 分支开发、主干发布模式
3）各团队分支工作流使用不统一，导致部署在不同环境中的代码指标重复计算多次。
技术团队使用的代码管理工具是Git。基于Git使用最广泛的分支工作流有Git Flow、GitHub Flow、GitLab Flow。其中，GitLab Flow是一个基于环境分支属性的工作流程（适用于为不同的部署环境创建不同分支的项目，所有的代码都要在不同环境中测试通过），如图1-13所示。其中，master、test、pre-prod、production这4个分支分别为主干分支、测试分支、预生产分支和生产分支。若采用这种工作流，我们可能只需在触发测试分支部署到测试环境时计算指标；在部署到其他环境，构建流水线时，无须再重复计算相关指标，因为此代码已经在测试环境中验证过。
图1-13 GitLab Flow工作流
我们原本计划随意选择一个工作流，然后找各技术部门负责人做评审，尽早达成统一；但当我们在小范围内调研时，结果大吃一惊：80%研发人员投了反对票。我们不得不停止此事的推进，还需要再深入了解他们的业务场景和痛点。
经过如上分析不难看出，若使用标准的工作流，各分支采用统一的命名规范，并为每个分支名赋予一定的意义，同时将相应的触发分支绑定到不同环境，这样看似能把所有问题都解决。但实际上，由于各研发人员在不同的文化环境下养成的研发习惯不同，这种代码分支策略很难实行。
先看一下在实际的代码管理过程中，我们经常遇到什么问题。
❑ 合并后的代码若其中一个分支出现问题，需要回滚所有分支的代码。
❑ 线上版本出现Bug，若此时需要快速发布，得及时清理出一个满足线上发布的“纯净”版本。
❑ 紧急需求插入，导致上线计划调整，部分已经合并的分支功能需要摘出来延后上线。
基于这些现状，有的团队比如前端团队就很难接受Git工作流。前端团队是一个技术团队各部门共用的强职能团队，它们需要对接所有的后端研发团队。在代码管理过程中，如它们每天都会遇到以上问题。若使用Git工作流，它们每天可能需要花费很长时间在分支开发和分支发布的沟通协调上。这对于它们来说就是一场噩梦。
我们将代码分支规范、分支开发模式以及分支工作流问题归结为代码分支策略问题。这件事看起来简单，但我们来回折腾了一个月才与技术团队达成一致意见。接下来就让我们针对代码分支策略的不统一问题给出解决方案吧！
1.5.2 适合自己的才是最重要的
这期间的几周，我们每天都辗转反侧，若这个事情不能达成一致意见，代码质量提升还如何推进？改进期间，我们采用的临时策略是：只固定采集develop分支触发构建的代码，develop分支默认对应开发环境的构建和部署，其他都不限制，先让工作开展下去，再想后续如何统一策略。
读到这里大家可能会想为什么选择develop分支？因为对于研发人员来说，他们的编码和调试活动除了在本地进行外，还需要在开发环境进行频繁构建和部署来验证问题。
我们结合调研信息，想了一天一夜，终于想清楚了他们的痛点（研发的要求），并给出解决方案和策略，如表1-1所示。
表1-1 研发人员的要求和我们的要求
GitLab平台针对项目分支做如下检查。（以下数值和限制不一定适合所有团队，思路供参考。）
（1）项目分支命名规范检查
源码库只接收符合如下项目分支命名规范的分支。
1）所有分支名称中只能包含（0-9|A-Z|a-z|-.），不可出现中文或特殊字符，各变量都统一保持小写；
2）版本号：A.B.C（AB产品定义，C研发定义，都必须是数字），例：V1.2.333；
3）master：主分支；
4）develop：开发分支；
5）develop-1：测试分支；
6）hotfix：修复Bug分支，hotfix-yyyyMMdd-{版本号}；
7）feature功能分支：feature-yyyyMMdd-{版本号}；
8）release版本分支：release-[v]{版本号}-{release内容描述}；
9）tag分支：release*分支打标签，全大写或全小写的项目名称格式为-[tag|TAG]-[v]{版本号}。
各分支来源可按照Git Flow规范获取，比如hotfix-*分支来源于master分支。
（2）限制项目远端分支总数
1）远端release-*分支总数不多于5；
2）远端hotfix-*分支总数不多于5；
3）远端feature-*分支总数，需小于等于团队写权限人数（忽略继承Git组中的写权限成员），feature分支总数小于10不做检查；
4）项目分支总数需小于“项目写权限人数+21”（21=1个master分支+5个release分支+5个hotfix分支+10个feature分支）。
（3）限制触发分支和环境绑定
1）生产环境：在master或者release-*分支上打标签；
2）预生产环境：绑定release-*分支；
3）测试环境：绑定develop-1分支；
4）开发环境：绑定develop分支。
同时，一些特殊分支有如下限制。
1）配置develop和develop-1分支为保护分支；
2）只允许hotfix-*分支合并到develop、release-*分支。当合并到release-*分支时，需校验提交的代码已经合并到develop和develop-1分支，否则合并失败；
3）只允许feature-*分支合并到develop和release-*分支。当合并到release-*分支时，需校验提交的代码同步合并到develop和develop-1分支，否则合并失败。
分支若不符合规范，控制台会提示错误并终止远端代码合并，此时不会触发流水线执行。检查效果示例如图1-14所示。
图1-14 项目分支规范检查效果示例
在和研发团队达成一致意见后，之前的问题都已得到解决。
1）部署到各环境中的代码质量都可以进行指标度量，特别是开发环境中对应的代码质量。（若平台已经实现了一次打包、多次部署功能，部署到后续环境的代码质量已经在开发环境度量过了，无须重复度量。）
2）代码质量指标的统计方式已经统一（比如平台采集所有项目的develop分支代码进行质量分析等），意味着各团队的代码质量指标可以在同一个平台进行对比、查看和分析。
3）并行开发分支冲突以及分层部署验证（所有的代码都要在各环境中测试通过）问题，我们将在第3章讲述解决方案，不过也需要基于统一的代码分支策略。
经过一个月的苦战，我们不仅解决了指标度量问题，也解决了技术团队代码分支策略问题，提升了与研发团队的沟通协作效率，同时增进了与研发团队的信任。
此时，效能团队规模达到5人，已处在人强马未壮阶段。
接下来，让我们一起把项目运转起来吧！