团队项目分支及部署管理

1.分支管理

1.1 分支划分

development :这个分支是我们是我们的主开发分支,包含所有要发布到下一个staging的代码,这个主要合并与其他分支,比如Feature分支。

staging :测试环境的稳定分支,测试环境基于该分支构建,为保护分支,由gitlab项目维护将需要发布的分支逐个合并进来。

master :生产环境的稳定分支,生产环境基于该分支构建。仅用来发布新版本,除了从staging或生产环境Bug修复hotfix分支进行merge,不接受任何其它修改。

1.2 创建分支

平时开发工作中,会根据需要由开发人员创建三类临时分支:

功能( feature )分支:为了开发某个特定功能,从development分支上面分出来的。开发完成后,要merge到development分支。功能分支的命名,可以采用feature-的形式命名(为任务单号)

Bug修复( fixbug )分支:为了修复某个bug,从常设分支上面分出来的。修复完成后,再merge到对应的分支。Bug修复分支的命名,可以采用fixbug-的形式命名(为bug单号)

热修复( hotfix )分支:当我们在Production发现新的Bug时候,我们需要创建一个Hotfix, 完成Hotfix后,我们合并回Master、staging和Develop分支,所以Hotfix的改动会进入下一个Release

2.流程规范

2.1 正常开发流程

1.从development分支切出一个新分支,根据是功能还是bug,命名为feature-* 或 fixbug-*。

2.开发者完成开发,提交分支到远程仓库。

3.开发者发起merge请求(可在gitlab页面“New merge request”),将新分支请求merge到development分支,并提醒code reviewer进行review

4.code reviewer对代码review之后,若无问题,则接受merge请求,新分支merge到development分支,同时可删除新建分支;若有问题,则不能进行merge,可close该请求,同时通知开发者在新分支上进行相应调整。调整完后提交代码重复review流程。

5.转测时,直接从当前development分支merge到staging分支,重新构建测试环境完成转测。

6.测试完成后,从staging分支merge到master分支,基于master分支构建生产环境完成上线。并对master分支打tag,tag名视各个环境而定。

流程示意图如下:

图片描述

2.2 并行开发测试环境Bug修复流程

并行开发(即前一个版本已经转测但未上线,后一个版本又已在开发中并部分合并到了development分支)过程中,转测后测试环境发现的bug需要修复,但是development分支此时又有新内容且该部分内容目前不计划转测,可以staging切出一个bug修复分支。完成之后需要同时merge到staging分支与development分支。merge时参考“正常开发流程”。

流程示意图如下:

图片描述

« »

发表评论

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

昵称 *