主干开发TBD——定义篇

一、主干开发是什么?
说到开发过程,一切的源头都是从分支模式开始的。国内目前大部分公司采用的还是特性分支的开发模式,包括git-flow和github-flow等。而国外大厂却早已达成共识,用的都是主干开发。同样,主干开发也有一些变种,常见的有三种。纯粹的主干开发,带feature分支的主干开发和gitlab-flow。
那么主干开发到底是什么呢,以纯粹的主干开发为例,整个仓库中只有master和release两个分支。所有rd本地开发的代码在经过code review后,都合并到master上。在发版时,从master合并到release上,经过一系列自动化测试和手动测试后,上线。

二、为什么使用主干开发?
一般的回答:世界上最大的五家IT公司FAANG中,除了苹果外,使用的无一例外是主干开发。再加上ThoughtWorks和Martin Fowler的个人背书,难道不值得一试?值得一提的是,Facebook和Google都是全公司共用同一个代码仓。
以Facebook为例,主干开发+持续发布使得Facebook自动每小时自动发布一次全站,无需人工干预。
我们知道,Margin Flower是《重构》和《领域特定语言》等计算机名著的作者,敏捷宣言12元老之一,统一了控制反转和依赖注入这两个名词的用法,将敏捷和持续集成变成全世界风靡的开发模式的大佬之一,他的背书,也是很强力的。
我的回答:敏捷开发+主干开发模式+充足的单测集测+持续集成,威力无比。
在后续的文章中,我们会一一解释上述的每一项。他们结合在一起会产生1+1远远大于二的效果。

三、主干开发与特性分支模式的比较?

模式 优点 缺点 总结
主干开发模式 "1、最适用CI/CD 2、无需切换分支3、可以容纳大型团队共同做一个项目" "1、必须引入feature toggle,对开发要求非常高2、master的质量很可能不高,导致上线崩溃" 优点招招制敌,缺点招招致命。如果能发挥出优点又避开缺点,绝对是最强的开发模式
分支开发模式 "1、能保证master分支的质量:只要不把没验证好的功能合并,就不会出问题2、不同人的工作不会干扰" "1、分支时间长了非常难merge。不是一般的难。2、与CI/CD有一定冲突,很难治理。业内很少有公司有优秀的治理方案。" 入门门槛低,比较简单实用。带来的缺点是上限低,与CI/CD的冲突很难弥补。

四、持续集成与主干开发
持续集成应该是近年来最没有争议的开发实践之一,即使再传统的公司,也正在向持续集成靠拢。先简单看看持续集成的定义。

持续集成是一种软件开发实践,即团队开发成员经常集成他们的工作,通常每个成员每天至少集成一次,也就意味着每天可能会发生多次集成。每次集成都通过自动化的构建(包括编译,发布,自动化测试)来验证,从而尽早地发现集成错误。

我们看一下,每天至少一次,对于特性分支开发是很难达到的。也是因为如此,敏捷和持续集成的推动人ThoughtWorks在全公司大规模的使用主干开发。

五、不想上线的功能怎么办
自然而然的,很多人会问,用分支可以让固定功能的分支不合并到master,从而不用上线。如果是主干开发怎样才能做到呢?这是个好问题。解决方案就是大名鼎鼎的feature toggle,请继续看下篇。

六、一点思考
与国内的大多数公司不同,国外的头部公司特别喜欢全公司公用一个仓库,他们在分支模式和开发模式上与我们大相径庭。在我刚毕业的时候,也觉得git flow特别牛,直到最近经历了几年的主干开发,才知道在一个高效的敏捷团队中,使用主干开发简直就是一种享受,灵活高效。同时,主干开发与分支开发也没有优劣之分,只能说不同的场景有不同的偏好。

七、参考
https://www.duyidong.com/2017/10/29/trunk-base-development/
https://netflixtechblog.com/deploying-the-netflix-api-79b6176cc3f0 (本文Netflix明确提出目标是只有master分支)
http://www.ruanyifeng.com/blog/2016/07/google-monolithic-source-repository.html (很老的文章,介绍Google使用的主干开发和统一代码仓)

发表评论

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