部署方案@项目版本管理控制流程规范
1 项目版本管理控制流程规范的好处
1. 保证各个环境（开发、测试、生产、主干）的独立，避免相互影响
2. 各个环境的职能更明显，开发分支只负责开发，测试分支只用于测试，各司其职，提高开发和测试的效率
3. 多个版本，多次合并，便于追溯问题
4. 开发版本没有问题才会合并到测试版本，测试版本没有问题才会合并到生产版本，每次的合并都尽量的确保了代码的正确性，提高软件版本稳定性，
5. 减少最终发布时合并主干出现冲突的概率
6. 降低冲突处理的难度
2 项目版本管理控制流程规范
2.1 项目版本管理控制流程图
2.2 基本流程介绍
- 2.2.1 需求A的开发发版流程
**节点1** 每个项目都有一个主分支 Master，它是一个稳定的可用版本，Master 上的每个版本就是拿来可以用的对应版本号的发布版本，Master 是不允许随意改动的
**节点2** 开发人员A拿到一个具体需求A（新模块或异常修复），从 Master 唯一新建分支DevelopA，并进行开发
**节点3** 开发人员A完成分支DevelopA后，从Master分支上新建唯一SIT分支，将DevelopA分支合并到该SIT分支进行集成测试，此时由测试人员A对SIT分支上的需求A进行测试**（集成测试）**
**节点4** 经过SIT测试发现A没有问题，从Master分支上新建唯一UAT分支，将DevelopA分支合并到UAT分支，进行验收测试，此时由业务人员A对UAT分支上的需求A进行测试**（用户验收测试）**
**节点5** 经过UAT测试发现A没有问题，从Master分支上新建唯一Master_1分支，将DevelopA分支合并到Master_1分支，初步发布生产版本，投入使用检查新版本的稳定性
**节点6** 经过一段时间（大概一周），生产上的版本趋于稳定，经过确认没有问题，则将DevelopA分支合并到Master分支作为功能的最后输出
- 2.2.2 需求A测试过程接到需求B的开发发版流程
**节点7** 在需求A进行节点2到节点6（测试）的全过程，开发人员B拿到一个新的具体需求，从 Master 唯一新建分支DevelopB，并进行开发
**节点8** 开发人员B完成分支DevelopB后，则将DevelopB分支合并到**现有SIT分支**，进行集成测试，此时由测试人员B对SIT分支上的需求B进行测试
**节点9** 经过SIT测试发现B没有问题，则将DevelopB分支合并到**现有UAT分支**，进行验收测试，此时由业务人员B对UAT分支上的需求B进行测试
**节点10** 经过UAT测试发现B没有问题，则将DevelopB分支合并到**现有Master_1分支**，初步发布生产版本，投入使用检查新版本的稳定性
**节点11** 经过一段时间（大概一周），生产上的版本趋于稳定，经过确认没有问题，则将DevelopB分支合并到Master分支作为功能的最后输出
2.3 注意事项
1. 每一个分支都是**以Master分支为源**分支进行新建，再进行修改或者合并操作的
2. **代码的开发和修改只能使用源需求分支**：
需求的开发或者测试过程发现问题而对代码的改动，**只可以从需求分支上进行修改**
开发人员需要对该分支的代码本地进行自测，确保分支能运行跑通，才可以合并到SIT分支上进行测试
3. **代码的合并只能使用源需求分支**：
不能直接将SIT分支合并到UAT分支
不能直接将UAT分支合并到Master_1分支
不能直接将Master_1分支合并到Master分支
因为SIT、UAT、Master_1分支上同时存在着多个需求进行测试，如果将SIT、UAT、Master_1分支作为源代码合并到目标分支，那也会将尚未完成测试的其他需求的代码合并到目标分支，这样会影响到目标分支代码的正确性和稳定性
4. SIT分支，UAT分支，Master_1分支，是测试人员和业务人员用来测试需求完成情况的分支：
测试过程发现问题，**不能直接对该测试分支进行修改**，需要通知开发人员，由开发人员对源需求分支进行修改
5. Master分支是用于输出稳定代码版本的分支：
只有当代码经过生产验证，趋于稳定才可以合并到Master分支上
6. 在SIT测试节点、UAT测试节点、检查功能稳定性节点：
凡是测试中发现某个需求未完成要求或者出现相关bug，则需要从该问题所对应的需求分支上进行修改（从源头需求节点），然后按照流程规范的顺序**重头开始**进行发版测试，不可以直接修改发现问题的节点
3 发版流程控制案例
下面使用IDEA，以一个简单案例对发版流程控制进行介绍
3.1 需求A的开发发版流程
- 3.1.1 节点1 初始版本
每个项目都有一个主分支 Master，它是一个稳定的可用版本，Master 上的每个版本就是拿来可以用的对应版本号的发布版本，Master 是不允许随意改动的
场景模拟：现在假设Master分支上有文件index.jsp,内容如下
- 3.1.2 节点2 需求A的开发
开发人员A拿到一个具体需求A（新模块或异常修复），从 Master 唯一新建分支DevelopA，并进行开发
场景模拟：开发人员A拿到需要A，需要着手开发
3.1.2.1 从Master新建需求A分支
3.1.2.2 在需求A分支上进行代码的开发
- 3.1.3 节点3 需求A的SIT测试
开发人员A完成分支DevelopA后，从Master分支上新建唯一SIT分支，将DevelopA分支合并到该SIT分支进行集成测试，此时由测试人员A对SIT分支上的需求A进行测试（集成测试）
场景模拟：开发人员A完成需求A的开发，要发布SIT版本供测试人员A测试
3.1.3.1 从Master新建SIT分支
3.1.3.2 将需求A分支合并到该SIT分支进行测试
在SIT分支上，对需求A分支的代码改动进行合并：
合并完成的结果：
代码合并完成，发布SIT测试版本，由测试人员A对需求A的完成情况进行测试
- 3.1.4 节点4 需求A的UAT测试
经过SIT测试发现A没有问题，从Master分支上新建唯一UAT分支，将DevelopA分支合并到UAT分支，进行验收测试，此时由业务人员A对UAT分支上的需求A进行测试（用户验收测试）
场景模拟：测试人员A完成需求A的测试，要发布UAT版本供业务人员A测试
3.1.4.1 从Master新建UAT分支
3.1.4.2 将需求A分支合并到该UAT分支进行测试
在UAT分支上，对SIT分支的代码进行合并：
合并完成的结果：
代码合并完成，发布UAT测试版本，由业务人员A对需求A的完成情况进行测试
- 3.1.5 节点5 需求A的版本稳定性检验（上线版本）
经过UAT测试发现A没有问题，从Master分支上新建唯一Master_1分支，将DevelopA分支合并到Master_1分支，初步发布生产版本，投入使用检查新版本的稳定性
场景模拟：业务人员A测试需求A的UAT版本没有问题，要发布到生产上投入使用，检验新版本代码的稳定性
3.1.5.1 从Master新建Master_1分支
3.1.5.2 将需求A分支合并到该Master_1分支并发版使用
在Master_1分支上，对UAT分支的代码进行合并：
合并完成的结果：
代码合并完成，发布生产检验版本Master_1，投入生产使用，检验代码的稳定性
- 3.1.6 节点6 需求A的稳定代码输出
经过一段时间（大概一周），生产上的版本趋于稳定，经过确认没有问题，则将DevelopA分支合并到Master分支作为功能的最后输出
3.2 需求A 测试过程接到需求B的开发发版流程
- 3.2.1 节点7 需求B的开发
在需求A进行节点2到节点6（测试）的全过程，开发人员B拿到一个新的具体需求，从 Master 唯一新建分支DevelopB，并进行开发
场景模拟：在需求A的开发或者测试的过程中，开发人员B拿到一个需求B，需要着手开发
3.2.1.1 从Master新建需求B分支
3.2.1.2 在需求B分支上进行代码的开发
- 3.2.2 节点8 需求B的SIT测试
开发人员B完成分支DevelopB后，则将DevelopB分支合并到现有SIT分支，进行集成测试，此时由测试人员B对SIT分支上的需求B进行测试
场景模拟：开发人员B完成需求B的开发，要发布SIT版本供测试人员B测试，此时，由于SIT环境只有一个，所以需要将需求B分支上的代码合并到正在进行需求A测试的SIT分支上
在SIT分支上，对需求B分支的代码改动进行合并：
合并完成的结果：
代码合并完成，发布SIT测试版本，由测试人员B对需求B的完成情况进行测试
- 3.2.3 节点9 需求B的UAT测试
经过SIT测试发现B没有问题，则将DevelopB分支合并到现有UAT分支，进行验收测试，此时由业务人员B对UAT分支上的需求B进行测试
场景模拟：测试人员B完成需求B的SIT测试，要发布UAT版本供业务人员B测试，此时，由于UAT环境只有一个，所以需要将需求B分支上的代码合并到正在进行需求A测试的UAT分支上
在UAT分支上，对需求B分支的代码改动进行合并：
合并完成的结果：
代码合并完成，发布UAT测试版本，由业务人员B对需求B的完成情况进行测试
- 3.2.4 节点10 需求B的版本稳定性检验（上线版本）
经过UAT测试发现B没有问题，则将DevelopB分支合并到现有Master_1分支，初步发布生产版本，投入使用检查新版本的稳定性
场景模拟：业务人员B完成需求B的UAT测试，要发布到生产上投入使用，检验新版本代码的稳定性，此时，由于生产环境只有一个，所以需要将需求B分支上的代码合并到正在检验需求A稳定性的Master_1分支上
在Master_1分支上，对需求B分支的代码改动进行合并：
合并完成的结果：
代码合并完成，发布生产检验版本Master_1，投入生产使用，检验代码的稳定性
- 3.2.5 节点11 需求B的稳定代码输出
经过一段时间（大概一周），生产上的版本趋于稳定，经过确认没有问题，则将DevelopB分支合并到Master分支作为功能的最后输出
3.3 补充：测试发现了问题
凡是测试中发现某个需求未完成要求或者出现相关bug，则需要从该问题所对应的需求分支上进行修改（从源头需求节点），然后按照流程规范的顺序重头开始进行发版测试，不可以直接修改发现问题的节点
场景模拟：测试人员或者业务人员在测试过程中发现了需求A的bug
此时开发人员A不能直接修改测试人员或者业务人员正在测试的分支，而应该修改需求A对应的源开发分支，然后再按照发版控制规范流程将修改后的代码合并到相关版本，发版测试
3.4 代码合并过程的问题
发现问题：合并操作没有效果
场景模拟：Master_1在合并UAT分支的最新代码，发现合并没有效果
可能的原因：Master_1已经合并过UAT分支的代码，后来其他人提交过UAT分支的代码，所以本地的UAT分支上的代码不是最新的，本地需要切换到UAT分支，进行更新，然后再切换到Master_1分支，重新进行代码的合并
4 添加分支
4.1添加分支的时机
以下情况建议添加分支进行开发：
1. 在必须按与现有分支不同的时间表或周期发布代码时
2. 在向客户发布功能且团队打算进行不影响计划的发布周期的更改时，不应该对每个客户情景创建分支，因为这会产生较高的集成成本
4.2添加分支的原则
在创建分支时，应从Master上创建分支，因为Master分支最稳定，如果从其他工作分支创建分支，会导致集成问题，因为无法保证其他工作分支的稳定性
5 开发人员注意事项
-
1.开发人员每天早上工作前至少更新一遍工作分支上的代码
-
2.代码写到一段落，需要更新一遍代码并提交自己修改的代码（勤update，勤提交）
-
3.提交代码前一定要进行update，更新代码后再提交
-
4.更新或者提交代码时如果发现代码有冲突，需要立即找到代码冲突的相关人员查找原因，合并之后才能提交，不能直接强制提交
-
5.发布到UAT和生产环境的代码，需要由专门的发版人员进行操作，每次发版需要要有对应的记录，文档留底
