要提高团队代码质量,就要这么用Git进行版本控制!

2021-06-30 - kblog

大家都比较清楚,互联网产品要能够快速响应市场变化,要面对频繁的需求变更,要用廉价的成本快速试错,这样才能不断的完善和优化产品。

Git是一个开源的分布式版本控制系统,可以有效、高速的处理从很小到非常大的项目版本管理。非常适合做互联网产品的代码版本管理。

一个团队如何如何使用git进行版本管理,如何使用git进行多人的代码写作?如何解决产品开发过程中的提出来的版本控制的问题?就是我要表达的意思。

团队如何进行版本管理呢?

第一,GitServer的选型和安装

我选用了GitLab作为GitServer。GitLab是一个开源的版本管理系统,实现一个自托管的Git项目仓库,可通过Web界面进行访问公开的或者私人项目。它拥有与Github类似的功能,能够浏览源代码,管理缺陷和注释等,还有一个功能,它能够实现分支的在线合并申请,分支可以进行保护等权限的控制。

第二,版本号定义规范

约定版本号规范,每个模块的版本号约定为三位<main>.<feature>.<hotfix>,根据大的基线设定<main>主要版本号,根据当前版本设定<feature>次版本号,<hotfix>默认为0,当有bug修改后才更新这个版本号。每次产品人员定义好产品功能后,每次变更<feature>版本号即可。

第三,创建固定分支

每创建一个项目,分别创建dev、test、release、master四个固定分支。

dev分支用来研发人员进行自测和模块间联调使用的,用来部署到研发环境的,开发人员对该分支有pull和push权限。

test分支是测试人员进行测试的代码分支,是部署到测试环境的代码分支,研发人员联调完自测完成后,提交feature分支合并申请到test分支,由管理员负责代码review并进行代码合并,该分支是受保护分支,开发人员对该分支有pull权限。

release分支是在test分支测试完成后,由研发人员提交test分支合并申请到release分支,release代码分支是用来部署到预生产环境的,由管理员进行代码合并。

master分支是最终上线的代码分支,测试人员在预生产环境测试通过后,由研发人员提交release代码分支合并申请到master分支,master分支是要部署到生产环境的,master上线完成后打对应版本的tag标签。

第四,临时分支

feature分支,每次定义产品一个完整的基线版本就生成一个feature_{版本号}分支,上线完成后删除该分支,所有的人创建一个属于自己的分支,每个人自测完成后,发起自己分支合并到feature分支,然后将feature分支合并到dev分支。

hotfix分支,每次bug修复创建一个hotfix_{版本号}分支,生产环境出现bug后,需要马上修改时,确定好版本号,从继承master分支创建hotfix分支。

第五,正常上线流程

1)管理员创建固定的分支dev、test、release和master版本,根据产品人员确定的功能确定当前版本的版本号,并继承master分支创建feature分支。

2)每个研发人员拉取feature分支,并创建个人本地分支。

3)研发人员进行编码,自测完成后合并本地分支合并到feature分支,并将feature分支合并到dev分支部署到研发环境进行模块间联调。

4)研发人员联调通过以后,向管理员发起feature分支合并到test分支的申请,由管理员review代码后完成合并,并部署到测试环境。

5)测试人员在测试环境进行测试,发现bug并登记,由研发人员进行修改,重新从第3步开始重复执行。

6)测试人员测试通过以后,由研发人员发起从test分支向release分支合并申请,由管理员完成合并,并部署到预生产环境。

7)测试人员测试预生产环境测试通过后,由研发人员发起从release分支向master分支的合并申请,有管理员完成合并,并在master分支上打版本标签,并部署到生产环境。

8)测试人员验证生产环境通过后,上线完成,如果生产环境验证不通过,马上回滚到master上一次的版本代码。

第六,线上从来不缺bug,如何处理线上紧急Bug呢?

1)研发人员从继承master分支创建一个hotfix分支。

2)研发人员检出hotfix分支,自测通过后提交并申请分支合并到release分支,由管理审核通过后完成合并,并部署到预生产环境。

3)由测试人员对预生产环境进行测试,测试通过后,由研发人员发起从release分支合并到master分支的申请,由管理员审核通过后完成合并,并在master分支上打版本标签,并部署到生产环境。

4)测试人员验证生产环境通过后,上线完成,如果生产环境验证不通过,马上回滚到master上一次的版本代码。

以上就是我使用GitLab进行版本管理的实际使用过程,大家有什么想法可以关注我的公众号(xtech100)一起讨论。

- END -

896

微服务中消息总线架构设计应用1

微服务中消息总线架构设计应用1

当一个O2O电商系统到达一定规模之后,就需要考虑系统的可扩展性、松耦合和组件化。一般采用的都是基于时下比较流行SpringCloud和Dubbo的分布式的微服务的架构模式,虽然模块间能够独立部署了,但是模块间的还是强依赖关系,每次改动都需要重新发版上线,产品迭代速度又快,使用分布式的消息总线设计就可以解决这些问题。

如何使用SpringCloud进行灰度发布?

灰度发布是指在黑与白之间,能够平滑过渡的一种发布方式。在其上可以进行A/B testing,即让一部分用户继续用产品特性A,一部分用户开始用产品特性B,如果用户对B没有什么反对意见,那么逐步扩大范围,把所有用户都迁移到B上面来。灰度发布可以保证整体系统的稳定,在初始灰度的时候就可以发现、调整问题,以保证其影响度。本文主要讲解了使用SpringCloud进行灰度发布。