- 背景
现阶段的Git源代码管理上有一些漏洞,导致在每次上线发布的时间长、出问题,对整体产品的进度有一定的影响。
- 作用
新的Git源代码管理方案有以下作用:
- 多功能并行开发时,测试人员可以根据需求任务分配测试自己的功能,环境互不干扰(需要提供多环境),也可以集成全业务流程测试;
- 功能并且支持拆分上线;
- 所有代码冲突必须在版本环境解决;
- 原则上V1环境打包好的版本测试通过直接推给beta环境测试,beta环境测试通过直接推到生产环境(灰度环境),如果有拆分上线,再由各功能分支合并到版本环境从新打tag提测。
- 权限
- 版本环境开放给开发人员(包括组长、项目经理);
- master环境只开放给源代码管理员(业务线技术负责人)。
- 角色
本流程涉及到的角色有以下:
- 开发人员:主要负责功能开发,发送功能测试合代码请求,填写封版内容,提交脚本,解决合并代码冲突,协助解决部署问题;
- 组长(项目经理):主要负责创建测试封版请求(运维管理平台),督促开发人员合并代码,检查封版内容是否准确;
- 测试人员:主要负责功能、性能测试,根据开发人员提供的版本tag打包测试,测试通过后通知运维tag分支名称与测试通过的程序包。
- 运维人员:主要负责生产程序部署(根据测试通过的程序包),master打制品库,生产部署过程中出现问题的程序回滚。
- 源代码管理员:主要负责master源代码合并(根据测试通过的版本分支tag),打master的release。
-
流程
- 功能分支
- 开发人员从master获取生成功能分支;
- 功能分支线命名规范:服务名称+“-”+版本号。
-
- 版本提测(图1)
- 项目经理(委托人)从master获取生成V1版本分支,分支线命名规范:服务名称+“-”+版本号;
- 开发人员把需要提测功能分支发送合并代码请求通知组长(委托人),组长(委托人)合并代码生成版本tag并通知测试人员;
- 项目经理(委托人)创建测试封版请求运维管理平台,由各个开发人员填写内容;
- 开发人员把需要的脚本提交到运维管理平台版封表格,格式以《SQL审计规范》https://archery.bndxqc.com/dbaprinciples/;
- 测试人员基于开发人员提供的tag编译打包测试;
- 测试完,测试人员给出最终版本tag;
- tag命名规范:服务名称+“-”+版本号+“-”+时间(yyyymmddhhmmss);
如:bonade-officialcar-oil-V4.2.0-20210324121145;
- Fix bug重复上述内容,注意:如果在测试期间,生产有发生bug修复后,需要从新拉取master与现有的版本内容合一次再打tag 。
- 体验上线(图1)
- 如果测试通过的版本tag是整体都上体验,就直接拿版本tag打的包推到体验环境,以下步骤不需要执行;
- 如果测试通过的版本tag是部分上体验,需要在版本环境从新构建,打tag再上测试环境->体验环境;
- Fix bug重复上述内容。
-
- 生产上线(图1)
- 体验测试通过直接推送到生产线(包括灰度),原则上测试与体验是同一个包;
- 生产环境通过后,由源代码管理员最终通过的版本tag对应的源代码合到master,如果发现冲突项目经理安排开发人员解决;
- 生产环境通过后,由源代码管理员打一个生产版本tag(v1.0.0-release)。
-
- Fix Bug上线(图2)
- 开发人员从master拉取代码生成功能分支进行修复;
- 重复<版本提测>流程。
图1
图2
图3文章来源:https://www.toymoban.com/news/detail-586863.html
文章来源地址https://www.toymoban.com/news/detail-586863.html
-
配置规范
- 前端
- 由于存在多个环境(开发,测试,体验,生产),而又使用同一个tag发布代码,故前端代码中不应该写死接口请求域名(如写死BaseUrl:薪公务用车);
- 若项目中有写死跨子域名的请求,则需要在代码中判断当前环境,再请求对应环境的域名;
-
- 后端
- 配置文件统一放在nacos配置中心;
- 启动配置中心的环境,通过启动脚本注入,需要运维配合实施;
- 前端需要用到的域名,由运维统一配置然后提供给开发人员(包含APP、前端、后端);
- 前端用到的路由,如果是再网关层配置,如gateway,zuul配置的由后端人员配置,如果是nginx的由后端人员提供配置给运维协助配置。
- 运维
- 域名,nginx,启动脚本由运维人员配置。
到了这里,关于Git源代码管理方案的文章就介绍完了。如果您还想了解更多内容,请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章,希望大家以后多多支持TOY模板网!