摘要
本文介绍了两种罕用的代码分支模式:个性分支开发模式、骨干开发模式,别离论述了其优缺点和实用环境;同时分析了 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),这个词对于国内读者可能是生疏而且奇怪的,毕竟都是程序员,难道还有不可读(读不懂)的代码吗?因为篇幅问题,咱们下一篇文章再跟大家细说。