版本管理规范

背景
项目开发过程中，代码分支版本、打包出来的构建版本等不统一，造成团队协作之间的困惑和
不便，本质原因是没有一套规范、统一的版本管理规范。
版本分类
需求层面
产品/项目迭代版本
实际项目一般是按功能模块划分，分期开发、上线。这个过程中涉及到产品/项目的迭代版本
需求文档版本
需求文档主要描述产品/项目背景、非功能需求、流程图等不便在原型中体现的内容。如果需求有
变更，需求文档也涉及版本的管理
原型版本
原型主要是对软件要实现功能的视觉上的设计，根据实际情况，原型有时会按照需求迭代演进，就
设计到版本管理
开发层面
设计文档版本
每一个迭代编码之前有设计环节，需要编写设计文档，随着迭代的演进，也会出现不同的版本
pom版本

后端项目maven pom文件中的版本
git代码库版本

分支版本，如master、develop等
数据库脚本版本
随着功能迭代演进、bug修复等，会出现需要修改表结构的场景，这些表结构修改也会对应不同的
版本
测试层面
测试计划版本
需求评审后，测试人员需要出具测试计划，包括测试功能列表、测试资源、测试排期等，随着迭代
的演进，也会涉及到版本管理
测试用例版本
测试人员需要针对功能列表编写测试用例，功能所属迭代版本不同，进而测试用例也会有版本概念
测试报告版本
测试完毕后，测试人员应该生成测试报告，也会涉及不同迭代版本的测试报告
发布层面
产品/项目对外版本
即产品/项目层面客户可见的版本号
版本发布内容
包括前后端部署构件及对应的版本
docker镜像版本

主要是后端镜像，有些需要在k8s上容器化部署的项目需要打包成镜像，就会涉及到版本
操作手册版本
产品人员编写的用户操作手册的版本
版本管理策略
主版本号
表示大版本号，一般当软件整体重写，或出现不向后兼容时改变
副版本号
表示功能更新，出现新功能是增加。
修复版本号
表示小修改，主要是bug修复、小调整等
 快照版本
后端临时打包版本
日期
表示构件或发布日期
版本组合整体如下：
[主版本号].[副版本号](.[修复版本号])(快照版本|日期)，其中[]表示必须要有，()中内容表示可选

需求层面
产品/项目迭代版本
命名
[主版本号].[副版本号]
主版本号
针对实际情况，如果是项目，主版本对应项目期号，从1开始，例如项目一期为1.x，项目二
期为2.x
副版本号
针对实际情况，如果是项目，对应到项目的迭代迭代版本，随着迭代演进增加。从0开始
需求文档版本
建议
目前已经弱化需求文档，需求评审以原型为主
对于非功能描述，例如背景介绍、脑图、业务流程图等，产品人员自行决定是放到需求文档
（World）、内网笔记文档或是原型中；如果是放在原型中，版本策略跟随原型版本；如果是
放到需求文档或是内网笔记，版本策略建议遵从[主版本号].[副版本号].[修复版本号]机制
原型版本
现状
原型目前是通过Axure软件设计，手动导出html后发布到服务器，个别项目通过服务器上新建版本
目录来管理不同版本的原型
建议
建议
针对项目规模比较小，原型一次性编写出来的情况，原型版本产品人员自己把控
针对项目规模比较大，原型分迭代编写出来的场景，原型版本建议遵从[主版本号].[副版本号]机
制，即跟迭代版本保持一致

开发层面
设计文档版本
命名
[主版本号].[副版本号]，即保持跟迭代版本一致
pom 版本
命名
[主版本号].[副版本号].[修复版本号](-SNAPSHOT)
其中，[主版本号].[副版本号]严格follow迭代版本，[修复版本号](-SNAPSHOT)部分开发人员自己控制
git 代码库版本
命名
develop

开发分支，所有人员在该分支上开发并提交代码
stage

测试分支，需要提测或修复bug时，将develop分支merge到stage分支，stage分支会自动
部署
master

生产环境分支，测试阶段完成后，代码从stage分支merge到master分支，并打上tag，tag
遵从[主版本号].[副版本号].[修复版本号](.yyyyMMdd)规范
release

对应线上多个环境的场景，示例：xxx-release
数据库脚本版本
DDL
 DDL

DDL 统一由开发人员通过Flyway管理，版本遵从V[主版本号].[副版本号].[修复版本号]__[描述].sql规范，
其中，[主版本号].[副版本号]严格follow迭代版本；DDL修改时，不允许直接修改之前版本的sql文件，统一通过
增加[修复版本号]或[副版本号]实现
DML
主要是初始化数据，如果是系统内置的数据，例如菜单数据、管理员账号等，由开发人员通过Flyway管理；如果
是业务数据，后续上线前单独导入。

测试层面
测试计划版本
建议通过文档系统维护，命名遵循[主版本号].[副版本号]规范
测试用例版本
通过禅道维护，先创建套件，套件版本名称严格保持跟产品迭代版本一致；产品创建测试单时，测
试单版本命名遵循[主版本号].[副版本号]规范，并选择对应版本的测试套件
测试报告版本
跟随测试单
发布层面
产品/项目对外版本
即产品/项目层面客户可见的版本号
命名
[主版本号].[副版本号].[修复版本号]，其中，[修复版本号]产品人员控制
版本发布内容
包括前后端部署构件及对应的版本，后端构件版本由pom版本指定，前端构件版本如何指定？
说明：
遵循发布版本
docker 镜像版本
 镜像版本
整体跟随pom版本，[主版本号].[副版本号].[修复版本号](-SNAPSHOT)(:latest)
说明：
遵循发布版本
操作手册版本
命名
如果是分阶段交付操作手册，建议遵循[主版本号].[副版本号].[修复版本号]规范；如果项目整体结束后统一
交付操作手册，版本号由产品人员自行控制。
说明：
产品自行把控