|
|
@@ -0,0 +1,49 @@
|
|
|
+# 代码管理说明
|
|
|
+
|
|
|
+## 原因
|
|
|
+
|
|
|
+1. 可以快速重构
|
|
|
+2. 版本历史一目了然
|
|
|
+3. 兼容 CI 平台
|
|
|
+ 1. 高大上一点就是 兼容 持续交付平台
|
|
|
+ 2. 可根据持续部署平台自动化投产
|
|
|
+ 3. 说简单点就是有了规范之下的规律，程序可识别，通过正则表达式可以将满足规律的数据进行自己想做的事情
|
|
|
+
|
|
|
+## 目录说明
|
|
|
+```
|
|
|
+
|
|
|
+├─DBScript -- 数据库脚本
|
|
|
+├─Procedure -- 项目代码
|
|
|
+│ ├─batch -- 批次代码
|
|
|
+│ ├─frontend -- 前端代码
|
|
|
+│ └─backend -- 后端代码
|
|
|
+└─ShortCode -- 短代码 也就是 平台文件
|
|
|
+
|
|
|
+```
|
|
|
+
|
|
|
+
|
|
|
+## 名词解释
|
|
|
+1. DevelopEnv **分支名称 开发环境**
|
|
|
+2. SysIntegrationEnv **分支名称 SIT 测试环境**
|
|
|
+3. UerAcceptanceEnv **分支名称 UAT 环境**
|
|
|
+4. StandardProEnv **分支名称 准生产环境**
|
|
|
+5. ProductionEnv **分支名称 生产环境**
|
|
|
+6. DEV_$(需求编号/需求短名) **分支名 新需求的分支名**
|
|
|
+7. PTB_yyyyMMdd **分支名称 投产版本整合分支**
|
|
|
+8. BUG_yyyyMMdd **分支名称 故障版本分支**
|
|
|
+9. DEV_$(需求编号/需求短名)_yyyyMMdd **标签名 开发基线 完成单元测试的基线标签名称**
|
|
|
+10. SITTest_$(需求编号/需求短名)_yyyyMMdd **标签名 测试基线 完成 SIT 环境测试的基线标签名称**
|
|
|
+11. UATTest_$(需求编号/需求短名)_yyyyMMdd **标签名 测试基线 完成 UAT 环境测试的基线标签名称**
|
|
|
+12. SP_$(需求编号/需求短名)_yyyyMMdd **标签名 测试基线 完成 投产演练 的基线标签名称**
|
|
|
+13. PRD_$(需求编号/需求短名)_yyyyMMdd **标签名 测试基线 完成 投产 的基线标签名称**
|
|
|
+
|
|
|
+## 版本工作流
|
|
|
+
|
|
|
+1. 接收需求后在 DevelopEnv 分支版本上新增分支 名称按照 DEV_需求编号/需求短名 的格式新建
|
|
|
+> 强烈建议使用需求管理系统产生的需求编号。
|
|
|
+2. 在新分支上进行需求的开发，若存在多个需求并行的情况就多创建几个分支。
|
|
|
+3. 当开发人员完成单元测试时，应在当前所在的 DEV_xxxx 开发分支上 打上 DEV_$(需求编号/需求短名)_yyyyMMdd 标签。
|
|
|
+4. 当 SIT 测试 或 UAT 测试 开始前，开发人员应将 DEV_xxxx 分支的代码 合并到 SysIntegrationEnv 或 UerAcceptanceEnv 分支上。
|
|
|
+5. 测试人员在完成 SIT 测试时 应当（人员自己定就可以，一般都是开发人员）在 SysIntegrationEnv SIT测试分支上 打上 SITTest_$(需求编号/需求短名)_yyyyMMdd 测试完成的标签， UAT 测试完成同理。
|
|
|
+6. 上述过程中，一般情况下测试过程中会产生问题，在问题被解决后新的代码会让分支产生新的提交记录，解决问题的代码只能在 DEV_$(需求编号/需求短名) 分支上修改，再完成自测后再合并到对应的测试环境上，我们在管理过程中，尽量保证当完成 UATTest 标签的推送后，就尽量不要修改代码了。
|
|
|
+7. 完成 UAT 测试后应制定版本计划，当版本计划确定后，应将上版的需求分支合并到 PTB_yyyyMMdd 分支中， 该分支应在生产分支上切分 ，合并过程中应仔细核对变更文件。
|
Cashgift Li