摘要

本文介绍了两种罕用的代码分支模式：个性分支开发模式、骨干开发模式，别离论述了其优缺点和实用环境；同时分析了 Google 和腾讯采纳骨干开发模式的背景和决策因素，捎带分享了这 2 个巨头的实际，供读者在技术选型中参考。

背景

按之前的写作思路，本文应该叫《Google 工程效力三板斧之三：骨干开发》，但我扭转了主见，心愿能同时提供国内互联网公司的实际，供读者参考，因而文章题目也随之更改。

软件开发过程中，开发人员通过版本管理工具对源码进行存储，追踪目录和文件的批改历史。为了区隔不同状态的源代码，会采纳分支进行治理。不同的软件开发模式，对应着不同的分支模式。

软件业界罕用的软件分支模式有多种，但实质上能够分为两类：

• 骨干开发模式（Trunk Based Development）
• 个性分支开发模式（Feature Branch Development）

两种模式的定义及优缺点剖析

个性分支开发模式

个性分支开发模式是指为一个或多个特定的需要 / 缺点 / 工作创立代码分支（branch），在其上实现相应的开发（个别通过增量测试）后，把它合并（merge）到骨干 / 集成分支的开发模式。

通常这种分支生命期会继续一段时间，从几天到几周不等，极少数状况甚至以月算。

个性分支开发模式中罕用的有 Git-Flow 模式、Github-Flow 模式和 Gitlab-Flow 模式等。这些模式只有细节上的差别，以 Git-Flow 为例：

长处：

• 个性开发周期宽松：因为生命期能够较长，较大的需要个性能够在宽松的工夫内实现再合入主干；
• 分支测试的工夫宽松：因为生命期能够较长，能够有较多工夫对分支进行测试，甚至手工测试；

毛病：

• 分支治理简单：起因在于大量采纳代码分支，且起源分支和合入指标分支各异，操作简单 —— 以上图为例，能够从 master（Tag 1.0.0）拉出 hotfix 1.0.2 分支，而后合入到 develop 分支，开发阶段完结后合入到 release branches，公布后合入 master，非常复杂，很容易出错；
• 合并抵触多、解决难：分支生命期越长，意味着与骨干的代码差别越大，抵触概率越高，抵触的解决难度越大（甚至成为不可能）；
• 迭代速度慢：个性分支生命期长（数天至数周）意味着个性上线速度慢，相应的迭代速度也慢；
• 须要较多测试环境：每个个性分支都须要调配至多 1 个测试环境，且长期占用（有状态）；

实用环境：

• 对版本迭代速度要求不高
• 测试自动化水平低，或说次要靠人工测试的

骨干开发模式

骨干开发，是指开发人员间接向骨干（习惯上骨干分支通常为：trunk 或 master）提交 / 推送代码。通常，开发团队的成员 1 天至多 1 次地将代码提交到骨干分支。在达到公布条件时，从骨干拉出公布分支（通常为 release），用于公布。若发现缺点，间接在骨干上修复，并依据须要 cherry pick 到对应版本的公布分支。

流程：

长处：

• 分支模型简略高效，开发人员易于把握不容易呈现错误操作
• 防止了分支合并、抵触解决的困扰
• 随时领有可公布的版本
• 有利于继续集成和继续交付

毛病：

• 基础架构要求高：合入到骨干的代码若品质不过关将间接阻塞整个团队的开发工作，因而须要高效的继续集成平台进行把关；
• 自动化测试要求高：需有齐备单元测试代码，确保在代码合入主干前能在取得疾速和牢靠的品质反馈；
• 最好有代码评审：若代码品质要求高，须要配套代码评审（CR）机制，在代码提交到骨干时，触发 CR，通过 Peer Review 后能力正式合入；
• 最好有个性开关：骨干开发频发合入主干的状况下，个性拆分得很小，可能是半成品个性，须要配套个性开关（Feature Toggle），只有当个性整体开发完才通过灰度公布等伎俩逐渐关上；

实用环境：

• 对迭代速度要求高，心愿需要疾速交付上线
• 基础架构强，继续集成工具高效；
• 团队成员习惯 TDD（测试驱动开发），代码自动化测试覆盖率高（至多增量代码的自动化测试覆盖率高）；

为什么 Google 和腾讯采纳骨干开发模式

互联网巨头 Google 大部分业务开发都采纳骨干开发模式，国内巨头腾讯也在推广骨干开发（试点业务团队大部分曾经采纳）。

他们采纳骨干开发的起因在于对骨干开发的长处有强烈诉求，而且有能力和资源补救其毛病：

• 都是互联网企业，竞争强烈，因而对迭代速度要求高；
• 基础架构能力强：都能自研弱小的继续集成平台，Google 有自研的 Forge，腾讯有自研的蓝盾；
• 自动化测试能力强：都推广 TDD，强调开发负责品质，缩小甚至勾销手工测试人员（大量必要的手工测试转外包），自动化测试覆盖率高；
• 都有严格的 CR 机制确保代码品质：Google 极其严苛的可读性认证（Readability）在业界曾经是标杆，腾讯是国内少有正在采纳相似实际的互联网企业。严格的代码可读性认证和依据此规范执行的严格代码评审制度，能无效的保障合入主干的代码品质不会升高。

骨干开发的最大长处是：效率和品质，而这 2 者是软件和互联网企业的外围诉求。
骨干开发的毛病，巨头有能力和资源来填平这些坑。

因而，从 ROI（Ratio of Investment）的角度来看，Google 和腾讯采纳骨干开发实属必然。

美中两巨头的实际

Google 在骨干开发的实际

咱们在之前的文章提到，Google 的工程效力（也叫研发效力）核心理念只有简略的 3 条：

1. 应用单体代码仓库（参考：Google 工程效力三板斧之一：单体代码仓库）
2. 应用 Bazel 构建（参考：Google 工程效力三板斧之二：应用 Bazel 构建）
3. 骨干开发；

其中的第 3 条，就是本文所述内容。

为了保障骨干代码的品质，避免出现工程师合入到骨干的代码 break 掉骨干的状况，Google 采取了以下实际：

• 代码合入事件触发通过继续集成，确保合入到骨干的代码通过充沛且必要测试；
• 通过 Bazel 实现相干代码（指依赖变更代码的代码）的精准测试；
• 至多 2 个合资格的 reviewer（代码评审人）的 LGTM（Look Good To Me），才容许代码合入主干；
• 合资格的 reviewer 都是在 Google 外部通过 Readability（代码可读性）认证的员工；

腾讯在骨干开发的实际

腾讯某 BG 在 2018 年开始的“930 改革”后，在各试点团队推动骨干开发（注：并未全公司广泛采纳），具体的动作包含：

1. 以度量牵引：通过对个性分支）的生命期监控和预警，实现非骨干分支的生命期缩短，倒逼开发团队采纳骨干开发；
2. 投大力量对立 BG 内的继续集成工具、开发自动化测试平台；
3. 制订了 7 大编程语言的编码标准，并自研代码动态扫描工具；
4. 并参考 Google 推广代码可读性（Readability）、可测试性（Testability）认证制度；
5. 强力推广 CR（代码评审）制度，确保代码的可读性（命名、代码格调、设计、复杂度）。

成果：

• 品质晋升：代码品质从可测量的维度失去显著晋升（代码标准率、单元测试覆盖率）；
• 迭代速度晋升：试点团队的迭代周期从 4 周或 2 周晋升至 1 周；
• 代码从“公有”变“私有”：通过代码评审制度，进步了代码可读性，使代码从集体领有（只有写代码的人能看懂），变成团队领有（整个团队都能看懂）；这一点对于企业十分重要，接手过他人代码的程序们都有感触；
• 代码的自动化测试覆盖率晋升显著，为将来的重构构筑了一张安全网；

中小企业能参考什么？

中小企业应该抉择个性分支开发模式，还是骨干开发模式？依据上文，置信大家曾经足以自行判断。

有些中小企业的技术决策者十分认可继续集成 / 继续交付的理念，从而更心愿采纳骨干开发，但对于骨干开发的毛病（或说补救毛病的老本）存在顾虑。

对此，我有如下倡议：

• 基础架构要求：能够思考采纳开源软件，如继续集成采纳 Jenkins、Travis CI、Gitlab CI 等，通过简略部署能够投入使用；同时配合代码动态剖析工具（如 SonarQube、CheckStyle），确保代码根本品质过关；
• 自动化测试要求：工具上不存在阻碍，古代编程语言（如 java、go、c++）都有内建或第三方的单元测试框架；难点只在于成员的开发习惯，能够通过测试覆盖率工具，以增量覆盖率指标保障新增代码都有齐备的自动化测试，从而逐渐扭转团队的研发文化；
• 代码评审要求：开源的 Git 服务器（如 Gitlab）根本都反对 push hook，配合开源的 Gerrit 等 CR 工具，能够实现在代码推送（push）或 pull request（合入申请）时触发 1 个代码评审申请，实现评审通过后，代码才正式合入的性能；剩下的就是研发文化问题了，须要在团队外部推广代码标准、代码可读性等宣导和教育工作；
• 公布时的个性开关：如果要求不高，能够通过代码 hard code 一个常量作为个性开关；如果要求高，也有开源的个性开关（比方：unleash、piranha、flipper）工具可供选择。

参考上述倡议，并充分认识到骨干开发的老本和艰难的状况下，中小企业开发团队也并非不能够思考骨干开发的实际。

后记

本公众号（大话研发效力）上一篇文章《Google 和 Facebooke 为什么不必 Git 治理源码？》提到过，Git 的其中一大劣势是代码分支创立成本低，合入速度快（但抵触解决实质上依然十分麻烦）。
但当你看完本文，就应该明确，Git 的这个长处对于 Google、Facebook 是没有多大意义的，因为骨干开发自身不须要创立太多分支。

另外，本文提到 Google 和腾讯都极度器重代码可读性（Readability），这个词对于国内读者可能是生疏而且奇怪的，毕竟都是程序员，难道还有不可读（读不懂）的代码吗？因为篇幅问题，咱们下一篇文章再跟大家细说。