Gerrit(基于Java编写) - CodeReview代码管控流程简要说明

AI 摘要: Gerrit是一种开放源代码的代码审查软件,通过网页界面进行代码审查和版本控制。它使用Git作为底层版本控制系统。

Gerrit,一种开放源代码的代码审查软件,使用网页界面。利用网页浏览器,同一个团队的软件开发者,可以相互审阅彼此修改后的代码,决定是否能够提交,回退或是继续修改。它使用版本控制系统Git作为底层。

1. 常规开发流程

多开发人员相互协作,各种特性分支开发,最终提交至中心仓库

2. 常规Git分支管控

2.1. 标准的GitFlow流程

2.2. GitFlow简要说明

  • Master分支:作为集成分支,包含最新功能特性;
  • Develop分支:将Feature作为功能集成分支
    • Feature分支:开发人员关注的分支,负责单独的需求功能研发使用
  • Release分支:作为预发布分支
    • 发布之前,通过Develop分支拉取而来
    • 包含版本ToDo特性功能(提前做的版本规划)
    • Release需要有发布规划v1,v2,v3….
    • Tag签发,针对测试通过的分支进行预发布 & 生产
    • Release特性同步回到Master和Develop分支
    • 代码回滚(由发布系统记录和完成)或复盘点
  • HotFix分支:针对线上生产环境的分支,拉取HotFix分支,进行补丁修复,修复后,需要同步至Master和Develop

2.3. 针对GitFlow流程补充

针对Git的使用流程,不同的企业有不同的管控方式,这里补充两类:

  1. PlanFlow:时效性低,发布计划性强,每个Release有确定的Todo清单,方便测试统一验证,适合有项目管理与功能ToDo清单的团队,可以废弃掉了Develop分支,降低分支维护成本,关注Release分支的版本特性清单
    • Master(功能集成用),保证最新特性
    • ReleaseN(并行给到多开发者,N代表并行的数),每个ReleaseN有自己的版本Todo清单,开发完成后,将ReleaseN合并到Master
    • Tag基于Master,发布基于Tag发布
    • HotFix基于Master
  2. GitFlow:时效性效率高,依赖开发人员的水平,适合敏捷型开发团队;另外,若没有自动化测试,由于高频发布,需要有CI/CD以及自动化测试的辅助,否则容易导致生产故障。由于提交、合并、发布持续进行(CI),适合功能快速集成,支持研发功能后,随时发布(同时也伴随的代码质量、缺乏严格测试导致生成问题的风险)
    • 加入有发布版本规划,每个Release有自己的ToDo项目规划
    • 开发完的Feature可以及时合并到Devlop

长期来看,若CI/CD以及自动化测试这块功能跟上,这样可以大大提升功能上线的时效性,让某个特定的功能及早面向用户!

3. 加入Gerrit代码审核流

3.1. Gerrit图示概览

用户过往直接push到代码仓库,需要先提交到Gerrit的远程分支,然后代码审核人员审核后,Gerrit会自动将代码合并中心仓库,然后在CD集成。

  1. 提交者不能直接把代码推到远程的master主线(或者其他远程分支)上去(相当于越过了gerrit了),gerrit必须依赖于一个refs/for/*的分支。
  2. 当进行commit时,必须要生成一个Change-Id,否则gerrit会报错。

普通成员的代码是被先push到gerrit服务器上,然后由代码审核人员,就是左上角的integrator在web页面进行代码的审核(review),可以单人审核,也可以邀请其他成员一同审核,当代码审核通过(approve)之后,这次代码才会被提交(submit)到代码仓库(repo)中去。

无论有新的代码提交待审核,代码审核通过或被拒绝,代码提交者(Contributor)和所有的相关代码审核人员(Integrator)都会收到邮件提醒。

gerrit还有自动测试的功能,和主线有冲突或者测试不通过的代码,是会被直接拒绝掉的,可以基于Jenkins实现该目的。

3.2. Gerrit代码审核流

主要关联对象:开发人员、代码审核人员、Gerrit在线审核、Jenkens自动化分支合并

4. 参考