Git Flow分支策略与Azure DevOps相关功能简介

By | 2019年3月23日

想了很久,还是写这么一篇文章来总结一下有关分支策略和DevOps的一些内容吧。其实,DevOps相关的内容并不是我的工作范围,不过对于敏捷开发、DevOps、项目管理等等这一系列的与开发过程相关的内容,我还是有些经验的,也就抽时间跟大家分享一下吧。

Git Flow应该是很多基于Git分布式版本控制系统的项目所实践的一种开发流程,当然,很多人对于Github非常熟悉,甚至平时工作就是基于Github的。在此我也就不多介绍Git以及Github的概念了,只需要知道Github是基于Git的一个服务供应商,目前已被微软收购。Git Flow就是由Vincent Driessen基于Git这一版本控制系统所总结出来的一套可行的、能够满足很多项目开发需求(注意:不是大多数项目)的敏捷开发流程,英语水平好的朋友可以参考阅读Vincent的原文:《A successful Git branching model》。

Git Flow

Git Flow通常会用在有具体的release发布的概念的项目上,简言之就是类似于以前能够给客户提供安装包的项目,对于SaaS项目,Git Flow还是太重了,而且不同环境、多租户的部署策略也与Git Flow有一些差别。因此,团队还是应该根据自己的实际情况来选择合理的开发流程,这里所介绍的内容也是仅供参考。下图(来自《A successful Git branching model》一文)展示了Git Flow的整个流程,在这里,我会对这个流程做一个详细的介绍。

git-model@2x

master分支

master分支始终保持了最近一次发布(release)的代码,通常情况下,通过tag的方式来标记每一次release。在Github中,每创建一次release,就可以基于某个分支(branch)创建一个tag。在tag被创建后,分支是可以删除的。因此,我觉得在上面的模型中,维护一个master分支并不是必需的。所以,有些团队为了直观,会将develop分支作为默认分支,甚至删除master分支。但我觉得删不删除也都无所谓,直接将master分支作为开发分支(也就是合并develop和master的职责)也是可以的。

develop分支与feature分支

develop分支(或者master分支),是项目开发的主要分支,它包含了项目的最新代码,开发和测试团队都会基于develop分支进行工作。每当有新的功能需要开发时,都会从develop分支分出一个feature分支。从实践的角度:

  • 上图中分主体功能的feature分支(Major feature for next release)以及后续版本的feature分支(Feature for future release),实际上,出现后续版本的feature分支的可能性不会太大,由于采用敏捷开发,团队通常不会做三个月以上的项目计划,因为没有意义,没有人能够确保三个月之内不会有功能需求的变更、backlog的调整以及市场对于项目本身的影响,因此,相对而言,近期的版本发布目标应该是比较明确的,长远的计划反倒显得意义不大。不过,也有可能会让团队的部分成员提前进入下一版本的研发,但由于敏捷开发和微服务理念的引入,一般敏捷团队也不会特别庞大,所以,这样的活动也不太会频繁发生。当然,还是应该依据项目实际情况而定,如果真有部分成员提前进入下一版本开发的需要,那就按上图中所描述的流程进行即可,不会有什么大问题
  • 多个feature并存的可能性还是很大的,团队的不同成员会工作在不同的feature分支上,当每个feature完成之后,都会合并到develop分支。合并过程可能会出现代码冲突
  • 每个成员是直接将代码提交到feature分支,还是自己再基于feature分支创建自己的工作分支?这取决于团队的代码审核(Code Review)流程,如果团队有严格的代码审核流程,开发人员应该在进行开发工作之前,基于feature分支创建自己的工作分支。开发完成后,将代码push到远程,然后提交Pull Request(PR)并邀请团队进行Code Review,Review通过,再将代码合并到feature分支,代码合并之后,将自己的工作分支删掉即可。如果代码审核流程不严格,那么直接将代码push到feature分支也是可以的,这需要团队成员建立起互信机制,并且有高度自治(Self-organize)的能力。这里有两点可以多写几句,首先不要觉得重复创建、删除分支会带来很大压力,Git的分支是非常轻量的,需要的时候就创建,不需要就删除,非常方便;其次,很多持续集成系统,对于多分支的开发流程以及Pull Request/Code Review流程都有完美的支持,Azure DevOps的这部分功能使用起来也是非常方便,之后我会详细介绍
  • 持续集成系统会从各feature分支上拉取代码进行编译,然后自动化部署到开发环境进行冒烟测试(Smoke Test),便于开发人员尽早验证已开发的功能。如果验证通过,开发团队可以将feature分支合并到develop分支,并删除feature分支,然后进行下一个feature的开发
  • 持续集成系统会从develop分支上拉取代码进行编译,然后自动化部署到测试环境供测试团队(QA)进行测试,最后给Product Owner或者其他Stakeholders做演示的环境,也是从develop分支出来的

release分支

当所有计划好的feature都完成之后,团队会基于develop分支创建release分支,此时:

  • 持续集成系统会基于release分支产生新的构建,构建结果称为Beta构建(Beta Builds)
  • 测试团队(QA)基于Beta构建进行回归测试(Regression Testing)
  • release分支不接受任何新的功能增加
  • 开发团队在release分支上进行Bug修复,同样,修复Bug时是否需要创建自己的代码分支,取决于团队自己的决定
  • 当质量达标,团队验收之后,进入release流程,此时,基于release分支创建release tag,同时将release分支合并回develop分支,以将release分支中的bug修复带入develop分支。在建完release tag并将代码合并回develop分支后,可将release分支删除。上图中没有体现这一步
  • 上图中展示的是将release分支合并到master分支,然后在master分支上建release tag,这样做是不妥的,因为合并到master分支的代码并没有经过测试,所以release tag不能建立在master分支上

hotfix分支

在某个版本发布之后,有可能会得到用户的反馈,有些是功能性的,有些则是影响用户使用的问题。对于功能性的反馈,可以与用户商量,或者团队自己决定,是准备在下一个版本中加入,还是基于用户现在的版本为用户专门定制。如果是后续版本再支持,则遵照上述feature分支的策略即可,但如果是基于用户现在使用的版本进行定制,则需要走Hotfix的流程

  • Hotfix分支从已经release的tag创建,找到已有的tag,然后基于tag新建Hotfix分支即可
  • Hotfix分支的工作流程可以参考develop分支
  • Hotfix开发完成并检验通过之后,基于Hotfix分支创建tag,标记为某一个Hotfix
  • 根据当前所修复的问题是针对该特定用户的(比如在界面上增加用户公司的名称与logo),还是针对所有用户的(比如某个bug的修复),以此决定是否需要将改动合并到develop分支
  • 删除Hotfix分支

从上面的流程可以看出,除了develop分支(或者master分支)为长期存在的分支之外,其它的分支都为辅助分支,在工作完成之后可以立即删除。为了满足代码评审(Code Review)而创建的开发人员自己的分支,一般都是即用即删。

以上就是Git Flow的整个流程,应该是已经介绍的比较细致了。在平时的工作和自学中,我都是以Github作为代码托管平台的,因此,本文的内容仍然是以Github为基础,包括接下来有关Azure DevOps Pipeline的介绍,也是与Github进行集成的。

Azure DevOps中Git Flow相关功能介绍

在上面的介绍中,不止一次提到持续集成系统,比如,当有代码签入feature分支或者develop分支时,持续集成(Continuous Integration,CI)系统会自动进行编译,然后触发持续发布(Continuous Delivery,CD)系统完成自动化部署。这些CI/CD系统所执行的自动化任务,需要人为地反复定义并触发吗?其实并不需要。现在流行的持续集成系统基本都已成熟,比如Jenkins,它的Pipeline功能直接支持Multi-Branch,每当有新的分支创建,或者代码签入,都会触发Jenkins创建新的Job,并触发相应的CI任务。Azure DevOps在这部分也做得非常好,而且它是云端服务,简单易用,对于开源项目是完全免费的。

首先,当你在Github中新建了一个repo,并且在Azure DevOps中配置了一个Project,使其从Github拉取代码时,你会发现,Github repo的Webhook里已经自动为你加上Azure DevOps所需的Webhooks:

image

不用管它,我们设想两个场景:

  1. 当开发人员准备向feature分支合并代码时
  2. 当feature分支出现代码签入时

下面看看,如何在Azure DevOps中进行配置,以实现上述两个场景。在这个实验中,我的Github Repo有三个分支:

  • master:暂时没用到
  • dev:开发主线,保持了最新代码
  • features/a1:功能代号为a1的开发分支

目前团队都在集中开发features/a1功能,由于团队选择较为严格的Code Review流程,因此,开发人员在进行自己工作之前,都是从features/a1创建自己的工作分支,比如就叫features/a1-daxnet吧,以便在代码签入features/a1分支的时候,能够产生Pull Request并申请代码审查。工作分支的名称可以自己决定,但团队需要达成共识,因为这个名称之后会被Azure DevOps用到。

现在,进入Github Repo的Settings页,在Branches设置页面中,在Branch protection rules设置下,新建一个规则(Rule),在Branch name pattern中,输入features/a1(也可以使用规则来定义一组分支),然后,勾选Require status check to pass before merging:

image

注:如需Code Review,则还需要勾选Require pull request reviews before merging,在这里就不演示了。然后,回到Azure DevOps,针对Github Repo创建CI,在CI的Trigger选项中,启用Continuous integration,以保证每当有代码签入指定的分支,就会触发持续集成。在Branch filters中,添加features/*分支,表示以features作为开头字符的所有分支,都需要进行持续集成,确保编译通过:

image

启用Pull request validation,在Branch filters中,添加features/a1,表示当有Pull Request需要合并到features/a1分支时,也需要进行持续集成,以确保编译通过。注意,目前我们不涉及Repo被Fork的情况,所以我们不勾选Forks选项:

image

OK,基本设置就是这样,非常简单。接下来,我们开始开发新的功能。首先,在Github页面基于features/a1,创建分支:features/a1-daxnet:

image

刚刚创建完新的分支,Azure DevOps就已经开始工作了,可以看到,Build Pipeline已经完成了新分支的编译:

image

下面,我要开始修改代码了,在代码修改完成本地编译通过之后,我将代码提交到features/a1-daxnet分支:

image

再次查看Azure DevOps的Build Pipeline,可以看到,CI已经开始帮我们编译新的代码提交了:

image

OK,再次不管它,现在,我希望将代码合并到features/a1分支,于是,我到Github上创建Pull Request,此时Github会提示,代码校验还在进行中,并等待Azure DevOps的编译结果:

image

回到Azure DevOps,可以看到,Build Pipeline正在进行Pull Request编译:

image

等待编译成功后,开发者就可以将代码合并到features/a1分支了。当然,这里我没有强制要求必须要等代码编译成功才能合并分支,因此,即使是编译没有完成,上图中的Merge pull request的按钮也是可用的。

总结

本文首先介绍了Git Flow分支策略,并结合了实际应用介绍了Git Flow的详细步骤,然后基于Azure DevOps介绍了在实际应用中,Azure DevOps Build Pipeline对Git Flow的支持。本文所介绍的内容并不能完全适用于所有的软件项目,尤其是SaaS项目,所以在开发过程中,团队还是应该根据自己的实际需求来定制自己的开发流程,在保证软件质量的前提下,提高开发体验和团队生产力,探索寻求适合自己的实践流程。

(总访问量:1,002;当日访问量:1)

发表回复

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

此站点使用Akismet来减少垃圾评论。了解我们如何处理您的评论数据