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整体流程

编辑

说明:

1. 研发自测通过, 定版后通过邮件发布release notes。
2. 测试经理接收到release notes开始测试, 测试通过后发布测试结果,并进行版本checklist检查。 测试不通过打回, 开发重新定版发布,并汇总所有发布版本。
3. 运维配置人员收到测试通过邮件, 并按照正式release命名规则进行产品发布/备份。
4. 发布过程通过邮件发送通知，整体版本文档汇总在wiki空间。
5. 通用产品组发布须抄送产品评审组、技术评审组，运维组，测试组。

4.2.2代码合入、编译打包与自测 、研发发布流程

版本转测试前,开发确认相关代码已全部合入gitlab库, 由开发统一接口人记录转测试代码所对应的gitlab版本号,打包 –> 自测 -> 封版。

开发自验通过标准:

1. 开发阶段, 以开发人员开发的模块功能特性性能指标阶段性达到需求要求, 并且本次转测试的bug修改自验通过, 程序无致命问题, 可转测试。
2. 维护阶段, 本次要转测试的bug修改自验通过, 程序无致命问题, 可转测试。

通过邮件发布产品release notes，包含以下版本配套文档列表:

文档模板参考：

4.2.3 开发转测试

       测试进行产品测试，并通知运维人员发布到测试环境。

测试完成之后，测试人员通过邮件递交《版本发布checklist》。审批通过后，运维定版。

版本发布checklist：

4.2.4 产品发布/备份

      运维配置人员按照正式发布版本进行产品发布。 离线部署包随产品发布

归档，放到运维指定位置。