4 种常见分支模式解析及优劣对比 | 研发效能提升 36 计
策划 &编辑|雅纯
团队研发的本质
我们曾经接触到一家企业,它一开始只有 8 个人,那个时候每个月都可以发一两个版本出去,客户都可以用到,因为他们是做医院的信息管理 HIS 系统。他们觉得做得还不错。后来团队发展比较快,规模到了 80 人左右,却半年没发一个版本。这导致实施团队没脸见客户,因为客户说半年前提的需求怎么还发不出来。
这个时候悖论就来了:我们以为团队规模越大,研发效率就会越高,可以做越多的东西,但是我们发现团队规模大到一定程度,整个研发效率是会下降的,甚至降得非常快。
站在团队的角度来说,因为人多,协作越来越慢,协作的成本也越来越高。我们发现团队的研发模式,人越多越会有问题,因为冲突更多,等待更多。这里冲突是指代码集成发布过程中的冲突,而等待也是集成和开发过程中代码彼此的等待。
以下是两个具体的场景。
假设有两个程序员 A 和 B 一起工作,A 一开始每次提交都把工作逐渐成功提交到线上去,然后 B 提交了一个版本,导致编译失败了。这时,A 就无法提交,因为提交就会挂,要等待 B 修复问题才能提交,这时 A 的提交和 B 的工作就产生了冲突。
第二种情况,多个分支往同一个分支合并,FeatureA 先合进主干,FeatureB 晚了一点结果发现无法合并,因为基线不一样了,这时候必须先解决掉代码冲突才能合进去。
如上图,假设现在有 3 个人,A、B 和测试 C,每个人的点代表它做的任务,比如 A 一直在做自己的事情,每完成一个事情就开始做下一个事情,做完第三个事情的时候他觉得需要去找 B 联调一下,就给 B 发了一个 ping,但是 B 有自己的节奏,在忙他自己的任务,所以并未马上响应 A 的请求。他发现有一个任务可以提测了,他就告诉了 C,C 发现有问题就马上 Pong 了回去,但是这时 B 在忙另外一个任务,没有响应。C 发现 B 无响应,又发了一次 Pong,这时 B 看到了 A 和 C 的消息,他先处理了 A 的事情,给 A 回复了一个 Pong 的消息。
我们发现,程序员和程序员,测试人员和开发人员之间,在整个的开发协作中其实是异步的、延迟协作的过程。每个人并不是收到一个请求就马上回复,马上协作,往往都是有自己的步调和自己的动作,可能会产生延迟。所以当产品更复杂,协作更多,团队更复杂,团队的人多了以后,协作成本就会快速上升。
在这样一个异步的、延迟协作的过程中,程序员面对日常开发的工作,需要有一套相应的研发模式,来保证在协作过程中能够持续地把信息同步掉,并快速地响应掉。
软件交付过程,本质是开发者围绕代码库的协作过程。无论是产品代码、配置、环境和发布流程,都可以通过代码来描述,并保存到代码库里。
因此,研发模式的目的就是约束我们在围绕代码库工作时的行为,本质是一种围绕代码库的行为约束。
研发模式我们狭义地理解为分支模式,包含一系列的行为约束,比如分支类型及其标识、分支的生命周期、Commit 在分支间的流转方式,以及流转的约束条件,还有分支和代码之间的对应关系等。接下来我们会一一探讨。
研发模式是一系列研发行为的约束,目标是避免冲突、减少等待。在协作的过程中,人多了之后带来的最大的问题就是冲突变多、等待变多,所以好的研发模式应该尽可能的避免冲突,尽可能的减少等待。
首先看一下研发模式和研发行为之间的对应关系。
这些研发行为和代码库行为有一个 Mapping(映射)关系。开始新的特性开发时,我们会创建一个新的特性分支。做一次代码的提交集成,其实就是一次 Commit 和 Push,完成之后进入集成验证,就做了一次分支的 Merge。
同样地,集成完进入待发布也是在做 Merge,而完成发布意味着打一个 Tag。代码库里的操作记录了我们的研发行为,所以研发行为和代码库的操作可以做到一一映射。
要避免冲突,唯一的方法是大家彼此隔离,分开就没有冲突。在代码库里面,很多时候通过分支的方式,来做工作之间的隔离,避免冲突。
要减少等待,而等待是信息不同步造成的,尽可能地做到信息同步,就不用等待。在代码里面的等待,是代码之间基线的同步,比如说频繁地提交。所以其实分支是用来避免冲突和做工作隔离,而频繁地提交合并是为了做信息同步,减少等待。
Q:如果是一个人做软件开发,用什么样的分支模式?一个人会不会有冲突?
一个人做软件开发的时候是不会有冲突的,一个人工作的时候不需要很多分支,一个分支就足够。一个人做开发,也不用等待信息,因此可以一条主干走到底。但是如果人数扩张到 10 人、100 人,彼此之间就会有工作的隔离,彼此之间也会存在着冲突,也存在着等待。所以在这个过程中,随着协作的人数越来越多,分支的模式会不断地发生变化。
4 种常见分支模式解析
主干开发
团队人很少(比如 1~2 个人)的时候,最常见的研发模式是 Trunk—BasedDevelopment,也叫主干开发方式。
主干开发方式一条主干分支走到底,开发的过程中不会有太多的冲突,要求代码持续集成到主干上去,所以在开发过程中不需要做相应工作的隔离。开发的过程中,所有的开发者在主干上面频繁地提交,频繁地集成。这种分支模式下,唯一的分叉出现在发布的时候,为了能够把发布版本隔离出来,有了发布分支。
这种模式下,不需要做分支隔离,信息同步通过持续频繁地提交来保证。在人数比较少,并且整个工程能力比较强的时候,这是我们推荐的研发模式。
但是当参与开发的人数越来越多时,主干开发的冲突几率就大大增加了,对工程能力的要求也越来越高。
所以说主干开发不是万能药,主干上的人越多,代码提交的冲突机率就越大,而且解决冲突的风险也越大。如果两个人的时候,即便有冲突我知道只是和另外一个人有冲突,如果是 10 个人,这中间就会产生很多的问题。
另外在主干开发里面,要保持信息地同步,需要做频繁持续地提交,而且每次提交的力度要很小,这针对有一些特性来说,可能只做了一半,这时需要将它提交上去,需要通过特性开关等方式来进行隔离。比如说这个是还未完成的特性,提前把它的开关制成 Off,再做相应的提交,但是特性开关本质上也是一个分支。
特性开关只是用代码的形式拉了一个分支,但是这个分支只有打开的时候才能跑到,本质上还是一个分支。如果特性开关比较多,它在一定程度上会把代码变得很脆弱,维护起来比较麻烦。
主干开发当很多人同时参与时,代码冲突的机率很大,而且特性开发的时候也有很多的风险,大家彼此之间需要隔离。
Git-Flow
Git—Flow 的基本原则是需要什么分支就给什么分支,任何事都有很明确的分支。比如说要集成,就有 develop 分支,要开发就有 feature 分支,要发布有 release 分支,每个都是不同的分支。每种类型的分支都有确定的用途。
比如说 feature 分支,是很多个 feature 并行开发的时候用来去做工作隔离,避免彼此之间有冲突。而 release 分支是用来做发布的隔离,使得发布之间不会有冲突。
我们发现这种模式很好地做了隔离,但是在信息同步的过程中,它需要基于 develop 频繁地集成去做同步,并且在各个分支中间做相应的 cherry-pick 或者是 rebase 这样的方式来做的。
这个时候,我们就会发现分支太多,而且一个 commit 从 feature 开发到最终发布要经历好几个分支,其中分支的流转和 merge 规则非常麻烦。
所以 Git—Flow 也不是仙丹,过多的分支增加了分支管理的复杂度。还有如果 Feature 分支的生命周期特别长,它的合并耗时也会变得很长。而且 Develop 分支和 Master 分支同时存在,好像 Develop 分支的意义不是特别大。另外区分 Feature 分支和 hotfix 好像意义也不是特别大。
所以 Git—Flow 虽然增加了很多的分支,让各种工作尽可能地隔离开来,但是它信息同步是很麻烦的,而且它管理这些分支的难度也特别大。
GitHub-Flow
GitHub 引入了一个分支模式叫 GitHub—Flow,明显比 Git—Flow 简单很多。没有 Develop,没有 hotfix,也没有 Release,当需要开发的时候拉一个 Feature 分支,开发完就合并 Master 做发布。
这个过程中,它的隔离只发生在开发过程中,它的信息同步通过持续地往 Master 去做集成,和频繁从 Master 里面 Pull 代码来实现。它的发布过程是基于主干 Master 分支做的,因此没有在发布的过程中做相应地隔离。
这时候又会带来一个问题,就是 Master 分支需要做持续集成,这个分支既是集成的地方也是发布的地方。一旦集成后出现问题,它会把所有的工作堵塞掉,无法发布也无法合并。
所以 GitHub—Flow 很简单,可以做相应地隔离,但是如果说本身基础设施或工程能力比较弱,它会限制你集成和发布的频率。
GitLab-Flow
GitLab—Flow 和 GitHub—Flow 区别是在发布过程中有了 Pre-production 分支和 Production 分支,基于开发、集成和发布过程中不同的环境分配了相应的分支。
完成集成以后是在 Master 分支上,下面一步将会切换到预发分支上。对应 Commit 的版本已经达到了预发的条件,在预发上做完验证以后再将其同步到 Production 分支,说明它已经达到了发布的条件,所以它是逐级 Promotion(晋级)的过程。逐步从集成的环境 Promotion 到预发环境,再 Promotion 到生产环境。
我们简单地介绍了一些常见的分支模式,下面我们再来比较一下他们之间的优劣。
常见分支模式优劣对比
TBD 分支少,实施简单,做起来不需要太多的理解成本。但是它对团队协作的成熟度和纪律都有很高的要求,一旦有人不遵守纪律,那主干就会成为你的梦魇,这时就很难很好地去做持续地集成和发布了。一旦它出现问题,所有人都被 Block,这是主干方式的优缺点。
Git—Flow 特性之间可以并行开发,规则很完善,每个分支的职责特别明确,再大的团队协作基本上也不会有太多的问题,但是它分支太多,规则太复杂,而且分支生命周期长,合并冲突会比较频繁。尤其是 Develop,Master 是长期存在的。
对于 GitHub—Flow,Git—Flow 能支持的基本上它也能支持,但是这里面有一个问题,它的集成只有在 Master 分支去做,因此对集成纪律有很高的要求,而且集成和发布在一个分支上,一旦集成分支中断,无论是集成还是发布都会被中断。
Gitlab—Flow 也是并行开发,但是开发分支还是会有生命周期长的问题,有合并冲突的风险。另外,发布分支之间是有耦合的,比如说 Prodution 和 Pre—Prodution 之间,是基于 Promotion 来耦合,所以彼此之间也是一种中断阻塞的方式,而且很多的开发分支,Prodution 和 Pre—Prodution,也增加了分支管理的复杂性。
因此,我们发现没有哪个分支模式是绝对好的,也没有哪个是绝对差的。
对于分支有一个简单的原则,即控制分支数目,小批量频繁集成。控制分支的数目也就是做到工作隔离,但是又增加太多管理成本。而小批量频繁集成可以加速信息同步。
所以一个简单的原则就是,从最大化生产力和最小化风险的角度,尽可能地控制分支的数目和小批量频繁集成。
最大化生产力:所有人工作在公共区域内。除了一条长期的,不被中断的开发主干外,没有任何分支。也并无其他规则,代码的提交过程相当简单。但是,每一次的代码提交,都有可能破坏整个项目的集成,进而导致项目进度的中断。
最小化风险:所有人都工作自己的分支上。每个人的工作是相互独立的,没人可以打断其他人的工作,这样,减少了开发被打断的风险。但是,这种做法却增加了额外的流程负担,同时,协作变得非常困难,所有人都不得不谨小慎微地合并自己的代码,即便是整个系统中非常小的一部分,也是如此。
那么怎么设计或选择适合自己的分支模式?下一篇文章,我们将继续分享,不同的团队如何选择适合自己的研发模式。
点击下方链接,立即体验云效流水线 Flow
https://www.aliyun.com/product/yunxiao/flow?channel=yy_rccb_36
版权声明: 本文为 InfoQ 作者【阿里云云效】的原创文章。
原文链接:【http://xie.infoq.cn/article/ae54d4e912dca81d24ee840bf】。文章转载请联系作者。
评论