找回密码
 立即注册

QQ登录

只需一步,快速开始

搜索
查看: 557265|回复: 0

Google和腾讯为什么都采用主干开发模式?

[复制链接]

该用户从未签到

发表于 2021-5-13 05:36:48 | 显示全部楼层 |阅读模式

您需要 登录 才可以下载或查看,没有账号?立即注册

×
作者 | 黄国峰责编 | 欧阳姝黎

摘要
本文介绍了两种常用的代码分支模式:特性分支开发模式、主干开发模式,分别阐述了其优缺点和适用环境;同时剖析了 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条:
使用单体代码仓库(参考: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)工具可供选择。
参考上述建议,并充分认识到主干开发的成本和困难的情况下,中小企业开发团队也并非不可以考虑主干开发的实践。

后记
)上一篇文章《Google 和 Facebooke 为什么不用 Git 管理源码?》提到过,Git 的其中一大优势是代码分支创建成本低,合入速度快(但冲突处理本质上仍然非常麻烦)。但当你看完本文,就应该明白,Git 的这个优点对于 Google、Facebook 是没有多大意义的,因为主干开发本身不需要创建太多分支。
另外,本文提到 Google 和腾讯都极度重视代码可读性(Readability),这个词对于国内读者可能是陌生而且奇怪的,毕竟都是程序员,难道还有不可读(读不懂)的代码吗?由于篇幅问题,我们下一篇文章再跟大家细说。

IBM 能靠 2nm 芯片翻身吗?拼多多否认对极兔快递“政策倾斜”;86版西游记“红孩儿”成中科院博士;AirTag遭破解 | 极客头条从头开发一个 RPC 是种怎样的体验?
回复

使用道具 举报

网站地图|页面地图|文字地图|Archiver|手机版|小黑屋|找资源 |网站地图

GMT+8, 2024-11-26 22:29

Powered by Discuz! X3.5

© 2001-2024 Discuz! Team.

快速回复 返回顶部 返回列表