Google 和腾讯为什么都采用主干开发模式？
本文介绍了两种常用的代码分支模式：特性分支开发模式、主干开发模式，分别阐述了其优缺点和适用环境；同时剖析了 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 有自研的 Forge，腾讯有自研的蓝盾；
自动化测试能力强：都推行 TDD，强调开发负责质量，减少甚至取消手工测试人员（少量必要的手工测试转外包），自动化测试覆盖率高；
都有严格的 CR 机制确保代码质量：Google 极其严苛的可读性认证（Readability）在业界已经是标杆，腾讯是国内少有正在采用类似实践的互联网企业。严格的代码可读性认证和根据此标准执行的严格代码评审制度，能有效的保证合入主干的代码质量不会降低。
主干开发的最大优点是：效率和质量，而这 2 者是软件和互联网企业的核心诉求。主干开发的缺点，巨头有能力和资源来填平这些坑。
因此，从 ROI（Ratio of Investment）的角度来看，Google 和腾讯采用主干开发实属必然。
我们在之前的文章提到，Google 的工程效能（也叫研发效能）核心理念只有简单的 3 条：
使用单体代码仓库（参考：Google 工程效能三板斧之一：单体代码仓库）
使用 Bazel 构建（参考：Google 工程效能三板斧之二：使用 Bazel 构建）
主干开发；
其中的第 3 条，就是本文所述内容。
为了保证主干代码的质量，避免出现工程师合入到主干的代码 break 掉主干的情况，Google 采取了以下实践：
代码合入事件触发通过持续集成，确保合入到主干的代码经过充分且必要测试；
通过 Bazel 实现相关代码（指依赖变更代码的代码）的精准测试；
至少 2 个合资格的 reviewer （代码评审人）的 LGTM（Look Good To Me），才允许代码合入主干；
合资格的 reviewer 都是在 Google 内部通过 Readability （代码可读性）认证的员工；
腾讯某 BG 在 2018 年开始的“930 变革”后，在各试点团队推动主干开发（注：并未全公司普遍采用），具体的举措包括：
以度量牵引：通过对特性分支）的生命期监控和预警，实现非主干分支的生命期缩短，倒逼开发团队采用主干开发；
投大力气统一 BG 内的持续集成工具、开发自动化测试平台；
制定了 7 大编程语言的编码规范，并自研代码静态扫描工具；
并参考 Google 推行代码可读性（Readability）、可测试性（Testability）认证制度；
强力推行 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）工具可供选择。参考上述建议，并充分认识到主干开发的成本和困难的情况下，中小企业开发团队也并非不可以考虑主干开发的实践。
点个在看少个 bug 👇