1.编写目的
主要针对软件版本的流程, 以确保公司资产得到保护。
2.适用范围
该流程适用于产品研发部门。
3.环境资源
在整个产品生命周期中，以gitlab作为公司主要代码仓库。
4.流程
流程分为版本号定义、版本发布
4.1 版本号定义
4.1.1 版本号规则 采用语义化版本
版本格式：主版本号.次版本号.修订号，版本号递增规则如下：
主版本号：当你做了不兼容的 API 修改，
次版本号：当你做了向下兼容的功能性新增，
修订号：当你做了向下兼容的问题修正。
项目版本号可加到“主版本号.次版本号.修订号”的后面，作为延伸。
4.1.2 部署包版本
对于产品，采用上面的规则，比如1.0.0
对于项目，在上面版本的基础上，再追加一个版本号：-客户名字.项
目版本号，比如1.0.0-xinqiao.01
4.1.3 正式发布版本
正式发布版本的版本号规则：release主版本号.次版本号.修订号
linux、windows项目都需要支持离线的部署包。
4.2 版本发布流程
4.2.1整体流程
说明:
- 研发自测通过, 定版后通过邮件发布release notes。
- 测试经理接收到release notes开始测试, 测试通过后发布测试结果,并进行版本checklist检查。 测试不通过打回, 开发重新定版发布,并汇总所有发布版本。
- 运维配置人员收到测试通过邮件, 并按照正式release命名规则进行产品发布/备份。
- 发布过程通过邮件发送通知，整体版本文档汇总在wiki空间。
- 通用产品组发布须抄送产品评审组、技术评审组，运维组，测试组。
4.2.2代码合入、编译打包与自测 、研发发布流程
版本转测试前,开发确认相关代码已全部合入gitlab库, 由开发统一接口人记录转测试代码所对应的gitlab版本号,打包 –> 自测 -> 封版。
开发自验通过标准:
- 开发阶段, 以开发人员开发的模块功能特性性能指标阶段性达到需求要求, 并且本次转测试的bug修改自验通过, 程序无致命问题, 可转测试。
- 维护阶段, 本次要转测试的bug修改自验通过, 程序无致命问题, 可转测试。
通过邮件发布产品release notes，包含以下版本配套文档列表:
文档模板参考：
| 编号 | 文档名 | 适用范围 | 文档出处 | 是否必需 |
| 1 | release notes | 全生命周期 | 开发 | 必需 |
| 2 | 功能清单 | 全生命周期 | 开发 | 必需 |
| 3 | 接口说明书 | 全生命周期 | 开发 | 可选(通用产品组产品必选) |
| 4 | 部署文档 | 运维阶段 | 开发 | 可选 包含检查列表(checklist) |
| 5 | 数据库说明文档 | 全生命周期 | 开发 | 必需 两个版本之间的差异文档 |
| 6 | 产品说明书 | 交付 | 产品部 | 必需 |
4.2.3 开发转测试
测试进行产品测试，并通知运维人员发布到测试环境。
测试完成之后，测试人员通过邮件递交《版本发布checklist》。审批通过后，运维定版。
版本发布checklist：
| 检查项 | 检查结果 | 信息提供者 |
| 版本号 |
| 测试经理/运维配置管理 |
| 对外发布配套文档是否齐全并通过测试? |
| 测试经理/运维配置管理 |
| 测试报告 |
| 测试经理/运维配置管理 |
4.2.4 产品发布/备份
运维配置人员按照正式发布版本进行产品发布。 离线部署包随产品发布
归档，放到运维指定位置。
