软件版本控制管理规范与流程优化策略

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 产品发布/备份

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

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