Git源代码管理方案

1. 背景

现阶段的Git源代码管理上有一些漏洞，导致在每次上线发布的时间长、出问题，对整体产品的进度有一定的影响。

1. 作用

新的Git源代码管理方案有以下作用：

1. 多功能并行开发时，测试人员可以根据需求任务分配测试自己的功能，环境互不干扰(需要提供多环境)，也可以集成全业务流程测试；
2. 功能并且支持拆分上线；
3. 所有代码冲突必须在版本环境解决；
4. 原则上V1环境打包好的版本测试通过直接推给beta环境测试，beta环境测试通过直接推到生产环境(灰度环境)，如果有拆分上线，再由各功能分支合并到版本环境从新打tag提测。

1. 权限

1. 版本环境开放给开发人员(包括组长、项目经理)；
2. master环境只开放给源代码管理员（业务线技术负责人）。

1. 角色

本流程涉及到的角色有以下：

1. 开发人员：主要负责功能开发，发送功能测试合代码请求，填写封版内容，提交脚本，解决合并代码冲突，协助解决部署问题；
2. 组长（项目经理）：主要负责创建测试封版请求（运维管理平台），督促开发人员合并代码，检查封版内容是否准确；
3. 测试人员：主要负责功能、性能测试，根据开发人员提供的版本tag打包测试，测试通过后通知运维tag分支名称与测试通过的程序包。
4. 运维人员：主要负责生产程序部署（根据测试通过的程序包），master打制品库，生产部署过程中出现问题的程序回滚。
5. 源代码管理员：主要负责master源代码合并(根据测试通过的版本分支tag），打master的release。

1. 流程
   1. 功能分支

1. 开发人员从master获取生成功能分支；
2. 功能分支线命名规范：服务名称+“-”+版本号。
3. 1. 版本提测（图1）
4. 项目经理(委托人)从master获取生成V1版本分支，分支线命名规范：服务名称+“-”+版本号；
5. 开发人员把需要提测功能分支发送合并代码请求通知组长(委托人)，组长(委托人)合并代码生成版本tag并通知测试人员；
6. 项目经理(委托人)创建测试封版请求运维管理平台，由各个开发人员填写内容；
7. 开发人员把需要的脚本提交到运维管理平台版封表格，格式以《SQL审计规范》https://archery.bndxqc.com/dbaprinciples/；
8. 测试人员基于开发人员提供的tag编译打包测试；
9. 测试完，测试人员给出最终版本tag；
10. tag命名规范：服务名称+“-”+版本号+“-”+时间（yyyymmddhhmmss）；

如：bonade-officialcar-oil-V4.2.0-20210324121145；

1. Fix bug重复上述内容，注意：如果在测试期间，生产有发生bug修复后，需要从新拉取master与现有的版本内容合一次再打tag 。
   1. 体验上线（图1）

1. 如果测试通过的版本tag是整体都上体验，就直接拿版本tag打的包推到体验环境，以下步骤不需要执行；
2. 如果测试通过的版本tag是部分上体验，需要在版本环境从新构建，打tag再上测试环境->体验环境；
3. Fix bug重复上述内容。

1. 1. 生产上线（图1）
2. 体验测试通过直接推送到生产线(包括灰度)，原则上测试与体验是同一个包；
3. 生产环境通过后，由源代码管理员最终通过的版本tag对应的源代码合到master，如果发现冲突项目经理安排开发人员解决；
4. 生产环境通过后，由源代码管理员打一个生产版本tag(v1.0.0-release)。

1. 1. Fix Bug上线（图2）
2. 开发人员从master拉取代码生成功能分支进行修复；
3. 重复<版本提测>流程。

图1

图2

图3

1. 配置规范
   1. 前端

1. 由于存在多个环境（开发，测试，体验，生产），而又使用同一个tag发布代码，故前端代码中不应该写死接口请求域名（如写死BaseUrl：薪公务用车）；
2. 若项目中有写死跨子域名的请求，则需要在代码中判断当前环境，再请求对应环境的域名；

1. 1. 后端
2. 配置文件统一放在nacos配置中心；
3. 启动配置中心的环境，通过启动脚本注入，需要运维配合实施；
4. 前端需要用到的域名，由运维统一配置然后提供给开发人员(包含APP、前端、后端)；
5. 前端用到的路由，如果是再网关层配置，如gateway，zuul配置的由后端人员配置，如果是nginx的由后端人员提供配置给运维协助配置。
   1. 运维

1. 域名，nginx，启动脚本由运维人员配置。