首页
学习
活动
专区
工具
TVP
发布
精选内容/技术社群/优惠产品,尽在小程序
立即前往

【DevOps实践】企业应用场景众多,怎样选择合适的代码分支模型?

常见的Git类代码分支模型有Git flow、Github flow、Gitlab flow、TBD等,企业可根据其业务、团队、管控等多方因素,选用其中一种或多种代码分支模型,随着DevOps工具的引入,在不降低代码质量管控力度的同时可有效提升代码管控效率,代码分支模型的应用可更加灵活自主。

常见代码分支模型

高效的持续交付体系,必定需要一个合适的代码分支模型。分支模型有利于规范开发团队遵循统一的规则执行功能开发、问题修复、分支合并、版本迭代及发布等操作,合适的繁殖策略可以使团队合作变得平滑顺畅,项目有序向前推进。因此,企业的研发团队通常需要慎重地选择代码分支策略应用。

代码分支从大模型的原则上分为三类,一类是主干开发分支发布,一类是分支开发主干发布,还有一类是主干开发主干发布。这些原则的沉淀,一方面是由于代码管理工具的历史发展所导致,另一个方面也受业务发布的时效诉求和管理诉求所影响。

常用代码分支模型

根据开源社区网站OpenHub的统计,使用Git管理代码的项目逐年快速增加,如今Git在代码管理领域已经占据主导地位。基于Git模式的代码管理已经成为绝对主流,基于Git的常见的代码分支模型有Git flow、Github flow、Gitlab flow、TBD flow等,不同的分支模型及优缺点分别如下:

1.Git flow

Git flow是由Vincent Driessen于2010 年提出的代码分支管理模型,但是不要被名字欺骗了,git-flow并不是Git社区官方推荐的工作流。

Git flow存在两个长期的独立分支:主分支master和开发分支develop,主分支用于版本发布,主分支的每个版本都是质量稳定和功能齐全的发布版。开发分支用于日常开发工作,存放最新的开发版代码。当开发分支的代码达到稳定状态并可以发布版本时,代码需要被合并到 master 分支,然后标记上对应的版本标签(tag)。

如果需要开发新的功能或者解决代码中的问题,则创建辅助分支来解决问题,辅助分支常用于:功能开发(Feature),版本发布(Release),问题修复(Hotfix)等,在辅助分支上的工作完成后,辅助分支将被删除。

优点:在于流程清晰,分支管理严格,适用于发布周期比较长的“版本发布”,发布周期可能是几周,几个月,甚至更长时间。

缺点:由于保持两个长期分支同步的开销较大,所以Git flow并不适用于快速的“持续发布”。

2.GitHub flow

GitHub flow是由Scott Chacon于2011年提出的代码分支管理模型,这是GitHub官方推荐的开发流程,以快速部署为目标,目前大部分开源项目都遵循这一流程。 Github flow最大的特点是只有一个长期分支,即主分支master,且主分支始终保持可发布状态。从master上创建新分支进行功能开发、问题修复等,这些分支通过pull request将代码合并到master。

为了保证主分支的代码质量,master的权限只开放给一部分人。Pull request是请求别人pull你的代码库(repository),也就是把开发分支的代码经过代码评审并通过测试后,让有权限的管理员合并回master。

不过在实际情况中,代码评审不可能检查出提交的代码中的所有问题,所以对于每次提交的代码进行自动化测试,主分支代码的自动化部署尤其重要,自动化测试能在产品部署前及时发现一部分问题,如果产品部署之后发现严重问题,自动化部署可以在最短时间内把产品回滚到上一个版本。

优点:在于流程简单灵活,不需要考虑及管理太多的分支,适用于需要快速集成及“持续发布”的项目,这类项目可能需要每天发布一个版本,甚至一天发布多个版本。

缺点:对于应用场景比较复杂的情况,例如:多个环境下的产品部署,多个版本的发布或问题修复,只有一个master便会显得力不从心。

3.Gitlab flow

GitLab flow是由GitLab 的 CEO Sytse Sijbrandij 于 2014 年正式发布的代码分支管理模型,属于GitHub flow的演进版本,与GitHub相同之处是也存在一个长期主分支mater,从master上创建新分支进行功能开发、问题修复等,结束后合并回master。

与GitHub不同之处是GitLab flow又考虑多环境部署等现实因素,增加production产品分支用于在不同的环境下部署产品,或者从master的稳定版本创建release发布分支用于发布软件。 如果在产品分支或者发布分支发现问题,就从对应版本分支创建修复分支,修复完成之后,GitLab flow遵循 “上游优先” 的合并策略,也就是将代码先合并到 master,再合并到下游的production或release分支。

和Github flow类似,master的修改权限只开放给部分人,开发分支的工作完成后,代码通过merge request(类似于GitHub flow中的pull request)请求有权限的管理员把代码合并(merge)回主分支。

4.TBD flow

TBD (Trunk-based Development) flow是由Paul Hammant于2013年提出的模型, TBD flow最大的特点是所有开发都基于主干trunk,不再有长期的开发分支,要求所有的提交尽快回到主干,这样可以共享最新的代码,并且能尽可能地减少合并冲突。如果需要发布版本,可以基于trunk直接生成新的分支用于发布。

TBD flow没有pull或者push request,要求开发人员尽快把代码提交到主干分支,但是TBD flow缺乏严格的流程来保证每一份提交代码的质量,如果一些项目开发人员众多且水平不一,同时工作在主分支上可能会在产品发布时才发现不可预知的问题,所以TBD flow更适用于需要快速迭代的产品,如果在主干分支上发现问题,可以快速进行修复再合并回主干分支。

分支模型应用分析

企业中,由于业务场景的不同,不同团队对于代码分支模型的应用也会有所不同,通常来说,会由对代码管控的强/弱程度、应用发布的高低频率为主要考虑因素来决定团队的代码分支模型。

场景1:强管控、低发布

该类型的开发常见于大型项目或者传统瀑布模式。比如,在众多大型企业中仍在执行的按季发布的方式。这一类型的场景,对于源代码的提交、源代码合并往往需要执行严格的人工Code Review,从而会有明显的多分支特征。基于该类场景,可采用Git flow的分支模型,有利于实现对源代码的强管控。

场景2:强管控、高发布

该类型的开发常见于直接面向客户的互联网项目,比如互联网金融、移动App等,由于业务的重要性,需要进行源代码更新的强管控,同时,又由于业务具有互联网属性,所以,需要经常性的发布。该场景下可选用Gitlab flow,既可以满足高频发布,又可以实现针对任一历史版本的修复。

场景3:弱管控、高发布

该类型的开发也常见于直接面向客户的互联网项目,和场景2的业务所不同的是,该场景下的业务的重要性较弱,比如一些娱乐性的产品。

该场景的弱管控是指减少人工code review,取而代之的是采用源代码扫描工具进行检测,以工具检测自动化在代码提交前完成相关质量检测。基于该前提,可采用Github flow、Gitlab flow、TBD等分支模型,尤其是在团队成熟度高的情况下,可优先考虑TBD模型,将发布频率提升至极限。

场景4:弱管控、低发布

该类场景为理论场景,如现实工作中存在该场景,可采用Git flow模型。

总结

在选择分支模型中,除了业务要求对代码管控的强弱以及业务的发布频率外,往往还会遇到业务需求是否要发布、团队成熟度、研发过程自动化工具支撑程度等问题影响。

随着DevOps在企业中的普及,以产品化为思路的持续交付模型在各企业内先后建立,借助DevOps平台自动化的能力,企业可将提交检测、合并检测等工作常态化,用自动化的代码检测方式替代人工Code review,降低人工成本的同时,提升交付效率。

同时,企业可根据自身的业务特征基于上述代码分支模型,规约企业特有的分支模型,其核心思想是在满足业务、管理、效率、质量、安全的多方诉求。

  • 发表于:
  • 原文链接https://kuaibao.qq.com/s/20201112A087F100?refer=cp_1026
  • 腾讯「腾讯云开发者社区」是腾讯内容开放平台帐号(企鹅号)传播渠道之一,根据《腾讯内容开放平台服务协议》转载发布内容。
  • 如有侵权,请联系 cloudcommunity@tencent.com 删除。

扫码

添加站长 进交流群

领取专属 10元无门槛券

私享最新 技术干货

扫码加入开发者社群
领券