摘要

本文介绍了两种常用的代码分支模式:特性分支开发模式、主干开发模式,分别阐述了其优缺点和适用环境;同时剖析了 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)工具可供选择。

参考上述建议,并充分认识到主干开发的成本和困难的情况下,中小企业开发团队也并非不可以考虑主干开发的实践。

余下全文(1/3)

本文最初发表在微信公众号,文章内容属作者个人观点,不代表本站立场。

分享这篇文章:

请关注我们:

发表评论

邮箱地址不会被公开。 必填项已用*标注