本文仅供参考,下面是系统开发过程中的常用环境.
| 简称 | 全称 |
|---|---|
| DEV | Development environment |
| FAT | Feature Acceptance Test environment |
| UAT | User Acceptance Test environment |
| PRE | Multivariate Testing |
| PRO | Production environment |
pro环境：生产环境,面向外部用户的环境,连接上互联网即可访问的正式环境。
pre环境：灰度环境,外部用户可以访问,但是服务器配置相对低,其它和生产一样。
uat 环境：用户验收测试环境,用于生产环境下的软件测试者测试使用。
fat环境：测试环境,外部用户无法访问,专门给测试人员使用的,版本相对稳定。
dev环境：开发环境,外部用户无法访问,开发人员使用,版本变动很大。
接下来，针对不同的环境来设计分支。
| 分支 | 名称 | 环境 | 可访问 |
|---|---|---|---|
| master | 主分支 | PRO | 是 |
| release | 灰度分支 | PRE | 是 |
| hotfix | 紧急修复分支 | DEV | 否 |
| test | 预上线分支 | UAT | 是 |
| dev | 测试分支 | FAT | 是 |
| feature | 需求开发分支 | DEV | 否 |
master分支
master 为主分支，用于部署到正式环境(PRO),一般由 release 或 hotfix 分支合并,任何情况下不允许直接在 master 分支上修改代码。
release分支
release为预上线分支,用于部署到灰度环境(PRE),始终保持与 master 分支一致,一般由 dev 或 hotfix 分支合并,不建议直接在 release 分支上直接修改代码。如果在 release 分支测试出问题,需要回归验证 dev 分支看否存在此问题。
hotfix 分支
hotfix 为紧急修复分支,命名规则为 hotfix- 开头。当线上出现紧急问题需要马上修复时,需要基于 release 或 master 分支创建 hotfix 分支,修复完成后,再合并到 release 或 dev 分支,一旦修复上线,便将其删除。
test 分支
test 为uat测试分支,dev联调测试通过后,告知相应测试人员并发送提测邮件,将dev分支合并到test分支,告知测试人员,进行测试验收。
dev 分支
dev 为测试分支,用于部署到测试环境(FAT)始终保持最新完成以及 bug 修复后的代码,可根据需求大小程度确定是由 feature 分支合并,还是直接在上面开发。一定是满足测试的代码才能往上面合并或提交。
feature 分支
feature 为需求开发分支,命名规则为 feature- 开头,一旦该需求上线,便将其删除。
紧急修复正式环境 Bug
需求在测试环节未测试出 Bug,上线运行一段时候后出现了 Bug,需要紧急修复的。我个人理解紧急修复的意思是没时间验证测试环境了,但还是建议验证下预上线环境。
如果 release 分支存在未测试完毕的需求,就基于 master 创建 hotfix-xxx 分支,修复完毕后发布到 master 验证,验证完毕后,将 master 代码合并到 release 和 dev 分支,同时删掉 hotfix-xxx 分支。
如果 release 分支不存在未测试完毕的需求,但 dev 分支存在未测试完毕的需求,就基于 release 创建 hotfix-xxx 分支,修复完毕后发布到 release 验证,后面流程与上线流程一致,验证完毕后,将 master 代码合并到 develop 分支,同时删掉 hotfix-xxx 分支。
如果 release 和 dev 分支都不存在未测试完毕的需求, 就直接在 develop 分支上修复完毕后,发布到 release 验证,后面流程与上线流程一致。
commit格式规范
commit -m “<type>(<scope>):<subject>”
格式说明：
type：用于说明本次commit的类别，只允许使用下面7个标识
feat:新功能（feature）
fix:修补bug
docs:文档（documentation）
style:格式（不影响代码运行的变动）
refactor:重构（即不是新增功能，也不是修改bug的代码变动）
test:增加测试
chore:构建过程或者辅助工具的变动
Scope: 可选参数
用于说明commit的影响范围，比如数据层、控制层、视图层等，视项目不同而不同
Subject: 是commit目的的简短描述，不超过50字符
以动词开头,第一个字母小写结果不加（.）
例如：feat:新增退费挽单跟进报表
分支管理规范
参与角色：开发、组长、测试、产品、运维
角色Gitlab中的职责：
开发：根据自己所做的功能，在本地创建feat分支
组长：根据排期创建dev[版本号]、pre[版本号]分支，并对dev、pre分支进行管理维护
测试：dev[版本号]分支开发完成，组长合并代码到test分支，测试仅对test分支进行测试，测试完成之后，通知组长将功能合并到pre[版本号]
产品：在pre环境进行验收，验收通过通知组长。
运维：对pre环境、生产环境进行发布。
分支提交流程：
常规提交：
说明：
1.需求评审，经过排期后，组长/负责人以上个版本的tag为蓝本创建dev[版本号]分支。
2.开发人员以当前需求所在版本，从dev拉去代码，本地开辟功能feat分支进行开发。
3.开发完成之后push代码至dev环境，开发人员进行自测和前端进行联调。
4.提测阶段，组长将dev的代码合并到test分支，test分支不允许直接修改。
5.测试通过以后，通知组长/负责人将代码合并至pre环境，产品/业务方在pre环境验收，验收通过组长/负责人将pre分支合并至master分支。
6.上线完毕之后需要对上线的msater打tag标记。
7.上线完毕之后，如果有在上线之前拉取的dev分支，需要将master代码合并至dev分支。
8.所有的代码修改都必须要从dev合并到test,不允许在dev以后的分支进行修改和提交。
线上BUG修复，紧急上线提交流程：
说明：
线上bug修复，需要从线上master分支拉取hotfix分支。
bug修复完成之后，由组长/负责人将代码合并到test分支。
测试人员在test分支进行测试，测试通过后通知组长/负责人将代码合并到pre分支。
产品/业务方pre环境验收，验收通过通知组长负责人将代码提交到master
master上线后打tag标签。
将master代码合并到现在正在开发的dev分支中
