Git工具代码分支管理和上线发布流程
2021-09-12 14:57:42 1 举报AI智能生成
Git工具代码分支管理和上线发布流程
作者其他创作
大纲/内容
1. 环境
1-0. 本地开发环境
1-1. delevop测试环境: 开发测试使用功能特性分支
1-2. 线上预发布环境：用于发布新版本前，测试功能 预发布前测试（目前暂不需要）
1-3. 线上正式环境
2. 版本号管理
2-1. 当修复一个小bug,则版本号的第三位自增1,如v 0.0.2
2-2. 当新增一个功能特性，则版本号第二位自增1，如 v 0.1.2
2-3. 当有新的模块或框架大调整时，则版本号第一位自增1，如v 1.1.2
3. 版本更新列表（后期待完善）
3-1 每次发布新版本需列出所做变更在禅道版本管理做对应说明，列明时间版本号，如v 0.0.1 2018-9-5
3-2. 系统首次上线,测试根据禅道版本管理的变更进行release新发版本测试跟踪
4. 版本分支
4-1 master(主分支)
hotfix
合并回master和develop分支
开发人员不动，由负责人合并；后面打Tag
4-2 develop(开发分支)
feature
命名规范
创建自
基于release
合并到
develop
说明
realease
命名规范
创建自
基于develop
合并到
master
说明
4-3 feature(新功能分支)
4-4 release（预发布分支）
4-5 hotfix（修复分支）
5. 注意事项
1. master主分支要打tag，tag更更新按版本号规则进行
2. 每次hotfix，合并到主分支master，tag版本第三位⾃自增1，同时hotfix也要merge到develop分支
3. 从开发develop开分支预发布release时，命名也按版本号进行，tag版本第二位自增，如release/v0.1.2（后面完善）
4. 测试发现预分⽀支版本release/v0.1.2有bug时，在该分支上修改bug，release测试通过后，将其merge到develop分支和 master分支，master分支进行行tag/v0.1.2（后面完善）
5. merge使用--no-ff参数。默认情况下，Git执行"快进式合并"（fast-farwardmerge），会直接将master分支指向develop分支。使用--no-ff参数后，会执行行正常合并，在master分支上生成⼀一个新节点。为了保证版本演进的清晰，建议采用这种做法
6. 提交代码的备注，请参考《技术中心Git分支管理规范》文档
6. 添加新功能
7-1 发新功能或改进, 从release分支检出本地功能分支。比如feature/v1.0.1_hdb_1_assign_rule ,基于release/v1.0.1开发分配规则的功能分支代码
7-2 修改代码，添加功能
7-3 提交到本地库。commit message请参考《技术中心Git分支管理规范》文档Git提交记录规范部分
7-4 本地自测，测试功能。如果有bug，修改代码未通过跳到7-2
7-5 找人 review代码，确认没问题后，切换develop分支，先pull，将新开发的功能分支合并到develop分支，解决冲突，push到远程（开发、测试相关人员沟通确认好再合并）
7-6 和前后端开发、测试相关人员沟通好后，确认发测试版的功能内容，前后端一起发布测试环境后，开发提交转测到，通知测试人员或相关人员
参考Idea操作流程例子
7. 紧急修复
9-1 从master检出本地Bug修复分支。比如 hotfix /v1.0.0_hdb_1_assign_rule
9-2 修复bug
9-3 本地自测通过后
9-4 提交到本地库。commit message请参考《技术中心Git分支管理规范》文档Git提交记录规范部分
9-5 push分支到远程
- 9-6 切换develop分支，先pull，将新开发的功能分支合并到develop分支，解决冲突，push到远程，部署到测试环境测试通过，通知测试人员或相关人员
9-7 测试通过后，测试人员通知开发和产品相关人员，根据实际紧急情况，沟通确认好发布时间、内容，按照发正式环境流程走
9-8 找人 review代码，确定后，并merge到release、master分支，打tag
9-9 部署到正式环境
8. 发布新版本
10-1 测试通过后，测试人员通知开发和产品相关人员，根据实际紧急情况，沟通确认好发布时间、内容，按照发正式环境流程走；发布时间前30-60分钟前和业务沟通确认好停服时间
10-2 大版本发布前必须提前全量备份云数据库到本地;原则上提前一天前后端开发人员做好release分支合并，尽量不临时做合并操作
10-3 相关前后端开发人员将开发的心功能或修复的bug列表，列出来发到群里，后面特别列出
复查和确认以下涉及配置在测试环境都配置好，避免部署遗漏
数据库表或字段新增或变化
最好是sql形式
数据到sql处理数据必须核查在测试环境没问题后才能通过
菜单、数据字典或自定义配置字段页面配置
用户、角色配置或调整
前后端配置文件新增或修改相关配置
定时任务
10-4 发布版本内容又前后端开发、测试、相关负责人确定无误后，再次通知业务停服确切时间，无问题后，停止正式环境服务（业务、产品、开发互相确认停服准确时间后再停服，互相沟通反馈有闭环，暂定微信群回复确认，开发停服前微信群询问产品是否通知业务人员确认停服，回复后才停服）
10-5 停止服务后，后端开发人员首先进行数据库表或sql层面的处理，处理10-3提到需要修改和注意的内容，前后端打包：打包前再次确认配置文件连接接正式数据库，启动后查询日志或登录复查（后面优化正式环境打包脚本）
10-6 前后端服务启动正常后，前后端需要进行如菜单或自定义字段等配置，前后端确认部署无问题后，，自查系统没问题，通知产品或相关负责人（业务、产品、开发互相确认部署成功，互相沟通反馈有闭环，暂定微信群回复确认，微信群通知产品通知相关业务人员，需要确认得到产品通知反馈，才算流程走完）
10-7 如有bug，按照 修复bug流程 修复，并merge到release。重新部署
10-8 给release添加tag：v+版本号（后面熟悉会确认版本号规范）
- 10-9 功能一段时间未反馈问题，稳定后，merge到master，master打tag（由项目负责人合并到master主分支，开发人员不动这个分支）
9. 代码部署和回滚
部署测试
正式部署
代码回滚
0 条评论
下一页
