增加广州信用监管代码管理工具
This commit is contained in:
parent
e67baba3bf
commit
af4fa340d8
Binary file not shown.
|
Before Width: | Height: | Size: 319 KiB After Width: | Height: | Size: 320 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 311 KiB |
|
|
@ -3,8 +3,8 @@
|
|||
# 佛山许可登记代码与版本发布管理规范
|
||||
|
||||
> <div><span>拟稿：研发中心</span></div>
|
||||
> <div><span>版本号：0.0.8 </span></div>
|
||||
> <div><span>发布时间：2022.09.9 </span></div>
|
||||
> <div><span>版本号：1.1 </span></div>
|
||||
> <div><span>发布时间：2022.09.15 </span></div>
|
||||
|
||||
**目录**
|
||||
|
||||
|
|
@ -26,6 +26,7 @@
|
|||
- [升级负责人职责](#%E5%8D%87%E7%BA%A7%E8%B4%9F%E8%B4%A3%E4%BA%BA%E8%81%8C%E8%B4%A3)
|
||||
- [开发人员管理](#%E5%BC%80%E5%8F%91%E4%BA%BA%E5%91%98%E7%AE%A1%E7%90%86-1)
|
||||
- [三、 代码分支与版本发布流程图](#%E4%B8%89-%E4%BB%A3%E7%A0%81%E5%88%86%E6%94%AF%E4%B8%8E%E7%89%88%E6%9C%AC%E5%8F%91%E5%B8%83%E6%B5%81%E7%A8%8B%E5%9B%BE)
|
||||
- [四、 常见问题](#%E5%9B%9B-%E5%B8%B8%E8%A7%81%E9%97%AE%E9%A2%98)
|
||||
|
||||
<!-- END doctoc generated TOC please keep comment here to allow auto update -->
|
||||
|
||||
|
|
@ -49,24 +50,24 @@
|
|||
|
||||
### 分支简介
|
||||
|
||||
工程的分支主要两种，一种是长期分支，一种是功能开发的主题分支。其中`master`,`dev`是长期分支。
|
||||
工程的分支主要两种，一种是长期分支，一种是功能开发的主题分支。其中`master`,`test`是长期分支。
|
||||
|
||||
**master分支**
|
||||
|
||||
master分支始终代表生产环境的状态，不能直接在上面提交代码。并大版本的发布，应该进行打标签Tag，存储正式发布的历史。
|
||||
|
||||
**dev分支**
|
||||
**test分支**
|
||||
|
||||
dev 分支作为功能的预发布集成分支，包含所有的代码提交记录。dev分支代表针对下一版本的最新交付的代码。，在合并了其他功能分支的情况下使用 dev分支的代码进行测试，然后与 master 分支合并。
|
||||
test 分支作为功能的预发布集成分支，包含所有的代码提交记录。test分支代表针对下一版本的最新交付的代码。，在合并了其他功能分支的情况下使用 test分支的代码进行测试，然后与 master 分支合并。
|
||||
|
||||
**开发分支**
|
||||
|
||||
根据系统功能需求划分，创建对应的开发分支，负责存储相应的开发功能代码。开发人员从 master分支创建新分支，并开发新功能。功能开发完毕后，将对其进行测试，与 dev分支合并。
|
||||
根据系统功能需求划分，创建对应的开发分支，负责存储相应的开发功能代码。开发人员从 master分支创建新分支，并开发新功能。功能开发完毕后，将对其进行测试，与 test分支合并。
|
||||
|
||||
### 分支管理
|
||||
|
||||
1. master分支上保留完全稳定的代码，不允许直接push代码
|
||||
2. master分支只能从dev分支合并push
|
||||
2. master分支只能从test分支合并push
|
||||
3. 开发分支创建，基于master拉取创建，并且命名采用英文定义
|
||||
4. 开发分支删除，当功能正式上线稳定一定的周期，并取得项目经理允许，即可删除分支。
|
||||
5. 工程代码与分支需要严格规范管理起来，划分清楚工程与分支的边界
|
||||
|
|
@ -83,6 +84,8 @@ dev 分支作为功能的预发布集成分支，包含所有的代码提交记
|
|||
|
||||
| 功能模块 | 涉及工程 | 分支名称 |
|
||||
| -------- | ----------------------------------------------------------- | -------- |
|
||||
| 正式环境 | `fsrl-scr`,`fsrl-server`,`fsrl-approve`,`fsrl-biz-speq-web` | master |
|
||||
| 测试环境 | `fsrl-scr`,`fsrl-server`,`fsrl-approve`,`fsrl-biz-speq-web` | test |
|
||||
| 一照通行 | `fsrl-scr`,`fsrl-server`,`fsrl-approve` | zzt |
|
||||
| 食药许可 | `fsrl-scr`,`fsrl-server`,`fsrl-approve` | food_med |
|
||||
| 质监许可 | `fsrl-scr`,`fsrl-server`,`fsrl-approve`,`fsrl-biz-speq-web` | speq |
|
||||
|
|
@ -90,7 +93,7 @@ dev 分支作为功能的预发布集成分支，包含所有的代码提交记
|
|||
### 分支负责人职责
|
||||
|
||||
1. 每天负责合并master主线代码到开发分支上
|
||||
2. 上线发版需要经过测试环境测试，主动把代码合并dev分支上
|
||||
2. 上线发版需要经过测试环境测试，主动把代码合并test分支上
|
||||
3. 发版需要告知升级负责人，本次升级涉及那些工程以及说明，要通过文本方式告知留底
|
||||
|
||||
### 开发人员管理
|
||||
|
|
@ -110,7 +113,7 @@ dev 分支作为功能的预发布集成分支，包含所有的代码提交记
|
|||
|
||||
**版本打包服务器**：172.22.80.91:22
|
||||
|
||||
**控制端访问地址**：http://172.22.80.91:8086/incre/web/#/control/app
|
||||
**控制端访问地址**：http://172.22.80.91:8086/incre/web#/login
|
||||
|
||||
**佛山客户端访问地址**：http://19.130.241.146:9888/incre/web#/client/project
|
||||
|
||||
|
|
@ -127,15 +130,15 @@ dev 分支作为功能的预发布集成分支，包含所有的代码提交记
|
|||
|
||||
### 发布流程管理
|
||||
|
||||
1. 每次发布版本要经过测试环境验证，流程：测试环境（dev） > 正式环境（master）
|
||||
2. 分支合并由分支负责人合并到dev，测试环境测试没有问题，再由升级负责人合并到主线master上打包发布正式环境
|
||||
1. 每次发布版本要经过测试环境验证，流程：测试环境（test） > 正式环境（master）
|
||||
2. 分支合并由分支负责人合并到test，测试环境测试没有问题，再由升级负责人合并到主线master上打包发布正式环境
|
||||
3. 测试环境发布版本，可以由分支负责人来负责打包升级
|
||||
4. 生产环境发布版本，由升级负责人打包升级，并且只能使用版本打包服务器打包
|
||||
5. 生产环境升级与回退只能使用版本管理系统操作
|
||||
|
||||
### 升级负责人职责
|
||||
|
||||
1. 合并分支dev至master主线
|
||||
1. 合并分支test至master主线
|
||||
2. 生产环境版本系统发布升级
|
||||
3. 系统回退版本的操作
|
||||
|
||||
|
|
@ -147,4 +150,22 @@ dev 分支作为功能的预发布集成分支，包含所有的代码提交记
|
|||
|
||||
## 三、 代码分支与版本发布流程图
|
||||
|
||||
<img src="../img/佛山许可登记代码与版本发布管理规范.png" style="width:100%"/>
|
||||
<img src="../img/佛山许可登记代码与版本发布管理规范.png" style="width:100%"/>
|
||||
|
||||
## 四、 常见情况
|
||||
|
||||
1. 同一时间段多个功能要同时上线，涉及多个开发分支如何解决？
|
||||
|
||||
答：按照顺序，一个开发分支合并到test分支，测试通过。再接合并下一个开发分支。直至完毕，再正式发版。建议业务上避免多功能上线。
|
||||
|
||||
2. 存在当两个开发分支之间存在公用或基本是实现一样的功能的代码时？
|
||||
|
||||
答：应进行梳理应从需求角度划分功能分支，判断分支是否存在歧义。
|
||||
|
||||
3. 开发过程中发现其他成员在不当地方编写业务功能？
|
||||
|
||||
答：叫上业务佬和技术佬，从两个角度进行评估。
|
||||
|
||||
4. 发现有其他成员，存在操作不规范？
|
||||
|
||||
答：要及时制止，进行沟通。有必要则反馈上报。
|
||||
|
|
@ -0,0 +1,175 @@
|
|||
|
||||
|
||||
# 广州信用监管代码与版本发布管理规范
|
||||
|
||||
> <div><span>拟稿：研发中心</span></div>
|
||||
> <div><span>版本号：1.0 </span></div>
|
||||
> <div><span>发布时间：2022.09.15 </span></div>
|
||||
|
||||
**目录**
|
||||
|
||||
<!-- START doctoc generated TOC please keep comment here to allow auto update -->
|
||||
<!-- DON'T EDIT THIS SECTION, INSTEAD RE-RUN doctoc TO UPDATE -->
|
||||
|
||||
|
||||
- [一、 代码管理](#%E4%B8%80-%E4%BB%A3%E7%A0%81%E7%AE%A1%E7%90%86)
|
||||
- [代码仓库组织](#%E4%BB%A3%E7%A0%81%E4%BB%93%E5%BA%93%E7%BB%84%E7%BB%87)
|
||||
- [分支简介](#%E5%88%86%E6%94%AF%E7%AE%80%E4%BB%8B)
|
||||
- [分支管理](#%E5%88%86%E6%94%AF%E7%AE%A1%E7%90%86)
|
||||
- [跨工程分支管理](#%E8%B7%A8%E5%B7%A5%E7%A8%8B%E5%88%86%E6%94%AF%E7%AE%A1%E7%90%86)
|
||||
- [分支负责人职责](#%E5%88%86%E6%94%AF%E8%B4%9F%E8%B4%A3%E4%BA%BA%E8%81%8C%E8%B4%A3)
|
||||
- [开发人员管理](#%E5%BC%80%E5%8F%91%E4%BA%BA%E5%91%98%E7%AE%A1%E7%90%86)
|
||||
- [二、 版本发布管理](#%E4%BA%8C-%E7%89%88%E6%9C%AC%E5%8F%91%E5%B8%83%E7%AE%A1%E7%90%86)
|
||||
- [版本发布工具](#%E7%89%88%E6%9C%AC%E5%8F%91%E5%B8%83%E5%B7%A5%E5%85%B7)
|
||||
- [版本发布时间](#%E7%89%88%E6%9C%AC%E5%8F%91%E5%B8%83%E6%97%B6%E9%97%B4)
|
||||
- [发布流程管理](#%E5%8F%91%E5%B8%83%E6%B5%81%E7%A8%8B%E7%AE%A1%E7%90%86)
|
||||
- [升级负责人职责](#%E5%8D%87%E7%BA%A7%E8%B4%9F%E8%B4%A3%E4%BA%BA%E8%81%8C%E8%B4%A3)
|
||||
- [开发人员管理](#%E5%BC%80%E5%8F%91%E4%BA%BA%E5%91%98%E7%AE%A1%E7%90%86-1)
|
||||
- [三、 代码分支与版本发布流程图](#%E4%B8%89-%E4%BB%A3%E7%A0%81%E5%88%86%E6%94%AF%E4%B8%8E%E7%89%88%E6%9C%AC%E5%8F%91%E5%B8%83%E6%B5%81%E7%A8%8B%E5%9B%BE)
|
||||
|
||||
<!-- END doctoc generated TOC please keep comment here to allow auto update -->
|
||||
|
||||
## 一、 代码管理
|
||||
|
||||
### 代码仓库组织
|
||||
|
||||
建立Git组织团队名为`crgs-project`，专门托管广州信用监管的项目代码，并把开发人员权限统一管理起来。
|
||||
|
||||
**组织地址：** http://47.107.61.133:3000/crgs-project
|
||||
|
||||
**仓库列表**
|
||||
|
||||
| 工程名 | 主题 |
|
||||
| ------------------ | ------------------------------ |
|
||||
| aiccs-pc | 行为监管系统前端页面 |
|
||||
| aiccs | 广州市市场行为监管系统后端 |
|
||||
| aiccs_gzqy | 文书系统前端 |
|
||||
| aiccs-wechat | 信用修复-移动端 |
|
||||
| crgs-pc | 质监网办PC前端 |
|
||||
| crgs | 广州信用风险后台 |
|
||||
| crev | 信用评价后台 |
|
||||
| crss-pc | 信用修复子系统 |
|
||||
| crev-pc | 信用评价pc前端 |
|
||||
| integration-pc | 一体化管理中心 |
|
||||
| mysql-aicorg | 以mysql为数据源的组织架构 |
|
||||
| gzis-pc | 异地流转 |
|
||||
| crev-online-wx | 市场主体信用信息资信证明移动端 |
|
||||
| crgs-solr-generate | 信用索引生成程序 |
|
||||
| crev-online-pc | 市场主体信用信息资信证明外网端 |
|
||||
|
||||
### 分支简介
|
||||
|
||||
工程的分支主要两种，一种是长期分支，一种是功能开发的主题分支。其中`master`,`test`是长期分支。
|
||||
|
||||
**master分支**
|
||||
|
||||
master分支始终代表生产环境的状态，不能直接在上面提交代码。并大版本的发布，应该进行打标签Tag，存储正式发布的历史。
|
||||
|
||||
**test分支**
|
||||
|
||||
test 分支作为功能的预发布集成分支，包含所有的代码提交记录。test分支代表针对下一版本的最新交付的代码。，在合并了其他功能分支的情况下使用 test分支的代码进行测试，然后与 master 分支合并。
|
||||
|
||||
**开发分支**
|
||||
|
||||
根据系统功能需求划分，创建对应的开发分支，负责存储相应的开发功能代码。开发人员从 master分支创建新分支，并开发新功能。功能开发完毕后，将对其进行测试，与 test分支合并。
|
||||
|
||||
### 分支管理
|
||||
|
||||
1. master分支上保留完全稳定的代码，不允许直接push代码
|
||||
2. master分支只能从test分支合并push
|
||||
3. 开发分支创建，基于master拉取创建，并且命名采用英文定义
|
||||
4. 开发分支删除，当功能正式上线稳定一定的周期，并取得项目经理允许，即可删除分支。
|
||||
5. 工程代码与分支需要严格规范管理起来，划分清楚工程与分支的边界
|
||||
6. 设立开发分支代码管理负责人，负责日常合并、与其他开发模块代码协同等操作
|
||||
|
||||
### 跨工程分支管理
|
||||
|
||||
所谓的跨工程分支，意义上是同一个事项或功能开发，并涉及多个工程的分支管理。
|
||||
|
||||
1. 同属一个功能开发，要统一相同的分支命名
|
||||
2. 分支拥有一致生命周期
|
||||
|
||||
例如：
|
||||
|
||||
| 功能模块 | 涉及工程 | 分支名称 |
|
||||
| -------- | ----------------------------------- | -------- |
|
||||
| 正式环境 | `aiccs-pc`,`aiccs`,`crev`,`crss-pc` | master |
|
||||
| 测试环境 | `aiccs-pc`,`aiccs`,`crev`,`crss-pc` | test |
|
||||
|
||||
### 分支负责人职责
|
||||
|
||||
1. 每天负责合并master主线代码到开发分支上
|
||||
2. 上线发版需要经过测试环境测试，主动把代码合并test分支上
|
||||
3. 发版需要告知升级负责人，本次升级涉及那些工程以及说明，要通过文本方式告知留底
|
||||
|
||||
### 开发人员管理
|
||||
|
||||
1. 编写代码时，要在正确的分支下开发，特别是负责多个模块开发人员，禁止代码串门提交不相关分支
|
||||
2. 每天来了，先拉取同步远程仓库的代码，并在下班或定期提交代码到Git仓库，禁止攒着代码放大招
|
||||
3. 禁止个人独立创建开发分支，要经过负责人同意
|
||||
5. 开发规范可参考： [技术规范](http://47.107.61.133:3000/chinaweal/public/src/branch/master/技术规范)
|
||||
|
||||
|
||||
|
||||
## 二、 版本发布管理
|
||||
|
||||
### 版本发布工具
|
||||
|
||||
版本系统主要功能有，升级补丁,退回版本,补丁文件防篡检验。改生产环境发布版本，需要通过版本管理系统工具发布，禁止私自手动拷贝替换操作。
|
||||
|
||||
**版本打包服务器**：172.22.80.91:22
|
||||
|
||||
**控制端访问地址**：http://172.22.80.91:8086/incre/web#/login
|
||||
|
||||
**正式环境客户端访问地址**：待部署
|
||||
|
||||
### 版本发布时间
|
||||
|
||||
系统升级要按照制定的时间执行，各模块的负责人要提前把代码功能测试好并提交，并告知升级负责人。逾期得等到下次升级，紧急情况下，可以向项目经理申请，通过方可以执行升级。
|
||||
|
||||
| 环境 | 升级时间 |
|
||||
| -------- | ---------------- |
|
||||
| 生产环境 | 周四（19点） |
|
||||
| 测试环境 | 获得准许即可升级 |
|
||||
|
||||
### 发布流程管理
|
||||
|
||||
1. 每次发布版本要经过测试环境验证，流程：测试环境（test） > 正式环境（master）
|
||||
2. 分支合并由分支负责人合并到test，测试环境测试没有问题，再由升级负责人合并到主线master上打包发布正式环境
|
||||
3. 测试环境发布版本，可以由分支负责人来负责打包升级
|
||||
4. 生产环境发布版本，由升级负责人打包升级，并且只能使用版本打包服务器打包
|
||||
5. 生产环境升级与回退只能使用版本管理系统操作
|
||||
|
||||
### 升级负责人职责
|
||||
|
||||
1. 合并分支test至master主线
|
||||
2. 生产环境版本系统发布升级
|
||||
3. 系统回退版本的操作
|
||||
|
||||
### 开发人员管理
|
||||
|
||||
1. 每次升级的代码，编写开发人员，需要保持在线状态
|
||||
2. 修改了工程的静态配置文件，需告知分支负责人
|
||||
3. 变更了库表字段，需告知分支负责人收集转交给数据库负责人
|
||||
|
||||
## 三、 代码分支与版本发布流程图
|
||||
|
||||
<img src="../img/广州信用监管代码与版本发布管理规范.png" style="width:100%"/>
|
||||
|
||||
## 四、 常见问题
|
||||
|
||||
1. 同一时间段多个功能要同时上线，涉及多个开发分支如何解决？
|
||||
|
||||
答：按照顺序，一个开发分支合并到test分支，测试通过。再接合并下一个开发分支。直至完毕，再正式发版。建议业务上避免多功能上线。
|
||||
|
||||
2. 存在当两个开发分支之间存在公用或基本是实现一样的功能的代码时？
|
||||
|
||||
答：应进行梳理应从需求角度划分功能分支，判断分支是否存在歧义。
|
||||
|
||||
3. 开发过程中发现其他成员在不当地方编写业务功能？
|
||||
|
||||
答：叫上业务佬和技术佬，从两个角度进行评估。
|
||||
|
||||
4. 发现有其他成员，存在操作不规范？
|
||||
|
||||
答：要及时制止，进行沟通。有必要则反馈上报。
|
||||
Loading…
Reference in New Issue