代码分支管理模式和应用场景

在一个有着上千开发技术人员的大型互联网公司,当研发到一定阶段,企业对CI/CD(持续集成/持续交付)的考虑会越来越重视,项目的快速上线交付能力考验着开发测试运维各个团队,但是实现CI/CD不是件容易的事情,肯定会对项目的开发上线有个规范过程,需要有个统一的应用框架,需要有规范化的部署,需要稳定可靠的基础设施,最近有对代码分支管理及其应用场景的讨论,看选择哪个可以方便CI。

两种代码分支开发模式

现在的代码分支管理一般按照上线流程成两个流派,一个是分支发布模式,还有一个是主支发布模式,下面是对两个分支模式的定义,

分支发布模式每次上线都会开出一个分支,上线的发布包从这个分支构建。

主支发布模式主支发布模式中,每次上线的发布包都会从代码主支构建。

需要说明的是,网上大家讨论比较多的gitflow流程是一种主支发布模式,其发布tag会在构建前预先提交到代码仓库,并且标记包的版本,这个和本文CI最佳实践中是有些出入,如何标记代码的tag,及其如何在CI平台中构建出包并确定包的版本,这个将在下面讨论。

分支发布流程

见如下图,

master_release4

版本1.0要上线时,会先开出一个分支R1.0,然后使用这个分支构建打包上线,上线之后分支的提交权限关闭。当发现线上有紧急bug修复时,则直接提交hotfix到分支R1.0,然后继续从分支R1.0构建打包上线。

分支R1.0和R1.1对代码提交有权限控制。

主支发布流程

见如下图,

branch_release4

版本1.0要上线时,需要合并代码到master,然后从master构建打包上线,上线之后master的提交权限关闭。当发现线上有紧急bug需要修复时,从版本1.0的commit id拉出一个hotfix分支,修复代码提交到hotfix分支,然后从此分支构建打包上线。

master和hotfix对代码提交有权限控制。

两种代码分支管理的简单比较

1. 主支发布模式中,发布主支一般固定不变,这有助于CI的打包构建,不用每次上线都要在CI job中切换分支,这是比分支发布更好的地方,在这个模式下,CI流程中可以只以主支的代码打出来包上线,然后代码合并权限和审查流程也可以较好的进行工程化控制。

2. 分支发布模式中,每次大的版本上线都有一个对应的分支,这样做有个缺点是,分支会越来越多,分支名称如果管理的好,还可以分辨出各个分支开发的功能作用,但如果管理的不好,分支可以多到让自己看不清楚哪个分支是做什么。但是,这对紧急修复是非常有帮助的,一旦知道哪个版本有问题,可以快速切换到相应分支,进行修复。

CI的版本控制

包的版本可以在很多地方确定,有些使用代码仓库管理发布包版本,有些在CI平台上控制出包的版本,有些则在上线发布平台上控制。

我觉得在CI平台上来控制包的上线版本是最恰当的时候,因为每次构建的时候,都应该是不同的包,有不同的版本,都需要经过测试才能上线。我们不能因为代码一样,构建两次的包其版本都一样,这个在后续部署测试上线环节都容易混淆。

代码的tag功能和版本控制

有些项目团队使用tag功能来确定上线包的版本,一旦有新的版本tag标记,则触发CI平台上构建打包job,获取tag来每次进行构建,但是tag有一个缺点,其版本变化都需要预先手动更改,如果CI平台对同一个tag的代码进行多次构建,这是很有可能的,这个时候如何确定版本是个问题。

一般来说由CI平台来控制包版本是推荐的做法,而不是通过代码仓库中的tag或者配置文件来控制。在软件行业,几乎没有人没有听说过maven这个项目构建工具,其默认使用项目中的pom.xml进行构建,获取依赖包,并打出一个完整的项目包,包的版本会以pom.xml中版本来定,但是有多少了解 mvn中有个version:set插件,用于在CI构建的时候动态更新pom.xml的包版本?在pom.xml等这些构建配置文档里确定包版本,提交到代码仓库,通过这个方式来确定构建时候的包版本是不可取的。maven打出的包,如果是上传到snapshot仓库,是可以覆盖上传的,但如果上传到release仓库,则必须修改每次打包的版本,这个时候一般使用mvn version:set这个插件,在CI构建的时候动态确定包的版本,而不是把包版本提交代码仓库。

然后tag该如何添加,有什么用呢?我们知道tag一般用于表示代码快照,一般的commit id是不可读的,tag我们可以做些有意义的命名,来告诉我们这份代码快照是做什么的,很多时候tag就是包的上线版本。那么上线版本什么时候打到代码仓库中去?在我们的实践中,我们是在包正式上线后,才把上线的版本打到相应的commit id上,然后如果有紧急问题需要修复上线,能够通过tag快速拉取代码,打hotfix。

应用场合

两个分支开发模式是互有优缺点,至于选择哪个更好,其实和业务场景紧密相关的,不同的业务场景需要不同代码分支管理方式,项目开发起来才会方便开发。

我们将软件应用开发下面两大类,

1) 桌面应用

一些桌面安装应用,其特点是,应用的安装包分发和版本升级都由用户在其桌面系统中控制,应用的版本基本由用户的使用市场占有率决定,开发企业很难控制应用的版本升级,完全靠用户的评价和喜好,其版本控制是趋于分散开放模式。

这些应用包括普通的windows、mac应用,还包括操作系统本身,像微软xp和win7,IE的浏览器等等,这些应用的版本,企业是很难控制的。以微软开发的XP系统为例,在微软2014年4月全面停止支持服务后,到2014年11月份StatCounter的统计数据显示Windows XP的市场份额仍然高达10.71%,和Windows 8.1的10.86%占有率几乎持平。微软公司很早就说要关闭Windows XP,但是XP的市场占有率让微软公司无可奈何,谁让XP的用户那么坚定执着。

从中可以看到,桌面应用的版本控制是分散开放的,市场上有多少版本的应用,作为软件企业需要考虑市场占有率,然后决定维护多个版本的紧急修复和补丁升级,老版本的维护工作一点都不轻松。

2) web和移动应用

现在是互联网和移动应用的时代,这个时代有着鲜明的特征,快速开发发布和迭代,其应用的版本控制和升级也是和桌面应用完全不一样。web项目的前后端版本和升级,完全是软件公司控制的,如果后台支持灰度发布,那么在灰度发布期间,一般有两个版本的应用在运行,很少有三个版本以上的同一应用同时运行。移动应用的版本升级比web应用比较慢,但还是比桌面产品好,无论是android还是ios,都有相应应用市场,不断的推动用户升级至最新版本,现在移动应用本身也在加强自动升级功能。

可以看到,web和移动应用的版本是不断向前升级的,是一种趋于内敛的版本控制。

那么,现在回到刚刚问到的问题,在什么场合,我们该用什么样的分支管理模式呢?简单的回答如下,

1)软件产品的版本升级完全由用户来决定,版本控制趋于分散开放,这个时候建议使用分支发布开发模式,大部分桌面应用就是属于这个类型。

2)软件产品的版本完全受企业控制,趋于内敛聚合,可以不断升级到最新的版本,这个时候使用主支发布的开发模式,会使项目管理和开发更加方便。web和移动应用推荐使用这个模式。

具体原因,其实就是,如果版本不能控制,各个版本的代码最好能有单独的分支管理,其紧急hotfix开发和补丁程序能够较好的独立开发,代码的hotfix合并也比较清晰易懂。如果版本完全受控制,那么我们只要负责最近发布的几个版本,而且很多时候,我们只要负责最新一个版本,这个时候即使有紧急hotfix,我们也可以把紧急fix打到主支上,然后上线,完全没有维护N多个分支(N>无穷大)的烦恼。