Google 和腾讯点解都采用主干开发模式？

转载：本文来自微信公众号“InfoQ”（ID:infoqchina），作者：黄国峰，转载经授权发布。

1 摘要

本文介绍‌两种常用嘅代码分支模式：特性分支开发模式、主干开发模式，分别阐述‌其优缺点和适用环境；同时剖析‌ Google 和腾讯采用主干开发模式嘅背景和决策因素，捎带分享‌这 2 个巨头嘅实践，供读者喺技术选型中参考。

2 背景

按之前嘅写作思路，本文应该叫《Google 工程效能三板斧之三：主干开发》，但我改变‌主意，希望能同时提供国内互联网公司嘅实践，供读者参考，因此文章标题也随之更改。

软件开发过程度，开发人员通过版本管理工具对源码进行存储，追踪目录和文件嘅修改历史。为‌区隔唔同状态嘅源代码，会采用分支进行管理。唔同嘅软件开发模式，对应住唔同嘅分支模式。

软件业界常用嘅软件分支模式有多种，但本质上可以分为两类：

• 主干开发模式（Trunk Based Development）

• 特性分支开发模式（Feature Branch Development）

3 两种模式嘅定义及优缺点分析

特性分支开发模式

特性分支开发模式是指为一个或多个特定嘅需求 / 缺陷 / 任务创建代码分支（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（测试驱动开发），代码自动化测试覆盖率高（至少增量代码嘅自动化测试覆盖率高）；

4 点解 Google 和腾讯采用主干开发模式

互联网巨头 Google 大部分业务开发都采用主干开发模式，国内巨头腾讯也喺推行主干开发（试点业务团队大部分已经采用）。

佢哋采用主干开发嘅原因喺于对主干开发嘅优点有强烈诉求，而且有能力和资源弥补其缺点：

• 都系互联网企业，竞争激烈，因此对迭代速度要求高；

• 基础架构能力强：都可以自研强大嘅持续集成平台，Google 有自研嘅 Forge，腾讯有自研嘅蓝盾；

• 自动化测试能力强：都推行 TDD，强调开发负责质量，减少甚至取消手工测试人员（少量必要嘅手工测试转外包），自动化测试覆盖率高；

• 都有严格嘅 CR 机制确保代码质量：Google 极其严苛嘅可读性认证（Readability）喺业界已经是标杆，腾讯是国内少有正喺度采用类似实践嘅互联网企业。严格嘅代码可读性认证和根据此标准执行嘅严格代码评审制度，能有效嘅保证合入主干嘅代码质量唔会降低。

主干开发嘅最大优点是：效率和质量，而这 2 者是软件和互联网企业嘅核心诉求。主干开发嘅缺点，巨头有能力和资源来填平呢啲坑。

因此，从 ROI（Ratio of Investment）嘅角度来睇，Google 和腾讯采用主干开发实属必然。

5 美中两巨头嘅实践

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 周；

• 代码从“私有”变“公有”：通过代码评审制度，提高‌代码可读性，使代码从个人拥有（只有写代码嘅人能睇懂），变成团队拥有（成个团队都可以睇懂）；呢一点对于企业非常重要，接手过人哋代码嘅程序们都有感受；

• 代码嘅自动化测试覆盖率提升明显，为未来嘅重构构筑‌一张安全网；

6 中小企业能参考乜嘢？

中小企业应该选择特性分支开发模式，仲要是主干开发模式？根据上文，相信大家已经足以自行判断。

有啲中小企业嘅技术决策者非常认可持续集成 / 持续交付嘅理念，从而更希望采用主干开发，但对于主干开发嘅缺点（或说弥补缺点嘅成本）存喺顾虑。

对此，我有如下建议：

• 基础架构要求：可以考虑采用开源软件，如持续集成采用 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）工具可供选择。参考上述建议，并充分认识到主干开发嘅成本和困难嘅情况下，中小企业开发团队也并非唔可以考虑主干开发嘅实践。