软件版本控制流程.docx

软件版本控制流程.docx

《软件版本控制流程.docx》由会员分享，可在线阅读，更多相关《软件版本控制流程.docx（5页珍藏版）》请在冰豆网上搜索。

软件版本控制流程

软件版本控制流程

编制XXX日期2009年9月15日

审核XXX日期2009年9月20日

批准XXX日期2009年10月1日

修订XX日期2010年1月1日

XXX有限公司

XXXX年XX月XX日生效

修订历史记录

日期

版本

说明

作者

审批人

2009/09/01

A/0

第一版

XX

XX

2009/12/03

A/1

增加了修改记录；调整了部署包、评审报告、测试报告的项目；测试报告变成必须项；业务策划由需求部门提供；

XX

XX

2010/01/01

A/2

公司组织机构调整；应用开发部与产品研发部合并为“软件研发部”，进行相关修改；比如编制部门、发放范围

XX

XX

2011/02/23

A/3

调整了流程；修改了版本号定义、入库流程；增加了版本号变更流程、适用范围、三个附录表单（程序源码版本号列表、部署版本号列表、新产品升级立项审批表）；

XX

XX

编制部门：

研发中心

发放范围：

项目管理部、研发中心、产品中心、系统网络部、质量保证部、运营维护部、商务部

软件版本控制流程

1.目的

主要针对软件版本的控制，以确保公司资产得到保护。

2.流程

流程共分为版本号定义、版本号变更、入库流程、出库流程、产品列表流程五个部分。

2.1.版本号定义

2.1.1文档版本

文件版本规范提供文件撰写时的版本变更规则。

文件版本号并无特别的要求，不过考虑到不断变更的要求，一般考虑无限制进阶式，如下面是典型的文件版本规范：

采用【主版本号】_【从版本号】_【功能版本号】_【项目号】的四位格式，【主版本号】_【从版本号】_【功能版本号】_【项目号】均为数字。

初始版本为1.0.0.0。

【主版本号】：

产品大功能/整体架构/用途产生变更时增加。

【从版本号】：

产品模块级功能有一定的增强。

【功能版本号】：

产品有一些小的变动，一般是缺陷修复或通用性修改。

【项目号】：

应用在项目中个性化需求。

2.1.2.代码/部署包版本

2.1.2.1正式发布版本

采用“【应用名】_【版本号】_【日期】_【SVN号】.tar/jar..”的形式

这是大部分产品代码/部署包版本号的基础标识形式，其中每个版本号是阿拉伯数字，同以上文档版本号规范。

以这种方式来标识版本之后，当前版本的状态，以及版本发布的轨迹，都可以看得比较清楚。

如SSO_3.2.0.0_20110923_38683.tar。

【应用名】的含义：

标识应用的名称。

一般指产品名称、项目名称、中间件等应用名称。

如统一认证平台（SSO）。

【版本号】的含义：

标志部署包及代码的版本。

同上文档版本的规则，如1.0.0.0。

【日期】的含义：

标志部署包及代码的封板日期。

如20110222。

【SVN号】的含义：

标识部署包及代码的版本，系统是自动递增的。

如38683。

【tar/jar.】的含义：

标识打包的名称。

2.1.2.2.非正式发布版

对于非正式发布（如内部测试）的产品/代码，一般使用附加日期、附加流水号或者Build号的方法记录，如V1.1.4.20110112。

2.2.版本号变更

2.2.1版本号变更流程图

参与角色：

项目经理、产品开发经理、产品经理、测试经理、配置管理员、质量保证部经理、研发中心总监

版本变更发起方：

项目经理、产品开发经理、产品经理；

使用工具：

版本控制工具CVS、SVN、VSS;

2.2.2.主要活动

2.2.2.1发起产品版本变更：

a）项目经理：

根据项目需求提出产品升级,要求给产品开发经理。

b）产品开发经理：

修复产品原有版本的缺陷或满足项目需求，填写《新产品研发立项审批表》给产品经理。

c）产品经理：

产品经理根据市场需求或其他部门反馈意见，提出产品升级要求，填写《新产品研发立项审批表》，提交产品中心总监审批。

2.2.2.2.产品版本变更审批：

d）产品经理：

填写《新产品研发立项审批表》，提交产品中心总监审批。

经审批通过后，定义产品升级版本号给产品开发经理和配置管理员。

产品新版本研发完成经质量保证部批准发布后，申请入产品库，填写《产品入库申请单》给配置管理员。