软件版本控制流程
文件编号:XXXX-XX-XX 版本状态:A/3
编制 XXX 日期 2009年9月15日 审核 XXX 日期 2009年9月20日 批准 XXX 日期 2009年10月1日 修订 XX 日期 2010年1月1日
北京WANDU网络科技有限公司 XXXX年XX月XX日生效
精彩文档
实用标准文案
修订历史记录
日期 2009/09/01 2009/12/03 版本 A/0 A/1 第一版 增加了修改记录;调整了部署包、评审报告、测试报告的项目;测试报告变成必须项;业务策划由需求部门提供; 2010/01/01 A/2 公司组织机构调整;应用开发部与产品研发部合并为“软件研发部”,进行相关修改;比如编制部门、发放范围 2011/02/23 A/3 调整了流程;修改了版本号定义、入库流程;增加了版本号变更流程、适用范围、三个附录表单(程序源码版本号列表、部署版本号列表、新产品升级立项审批表); XX XX XX XX 说明 XX XX 作者 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) 产品经理:填写《新产品研发立项审批表》,提交产品中心总监审批。经审批通过后,
定义产品升级版本号给产品开发经理和配置管理员。产品新版本研发完成经质量保证部批准发布后,申请入产品库,填写《产品入库申请单》给配置管理员。 e) 产品中心总监:批准产品升级申请。
2.2.2.3.产品新版本研发测试:
f) 产品开发经理:经审批通过后,研发产品新版本,完成研发后提交测试经理测试。 g) 测试经理:完成产品新版本测试后提交质量保证部经理审批发布产品新版本。 h) 质量保证部经理:批准产品新版本发布。
2.2.2.4.产品新版本入库:
i) 配置管理员:收到产品入库申请单及入库产品文档和部署包后提交研发中心总监审批
后将产品文档和部署包入产品库。 j) 研发中心总监:批准产品新版本入库。
2.3. 入库流程
1) 项目立项后两天内,
a) 开发经理向配置管理员申请版本号,由配置管理员根据“版本号定义”规范审核版本号是
否可用;
b) 开发经理提交《开发计划》。《开发计划》内必须包括入库时间(项目上线一周内)、版本
号;
2) 配置管理员根据《开发计划》整理《产品入库跟踪表》。列:产品名称、版本号、入库时间、
开发经理、项目/产品经理、预计入库时间、实际入库时间、是否按时入库; 《产品入库跟踪表》每月发送给总监一次;每季度需审核一次; 3) 当到达入库时间后,
a) 开发经理应该主动申请入库,产品经理填写《版本入库申请表》; b) 配置管理员根据《产品入库跟踪表》及时跟踪产品经理入库;
精彩文档
实用标准文案
4) 产品经理将《版本入库申请表》的“文档清单”内容 提交到配置管理员、部门经理。配置管
理员先负责审核文档是否完整;然后部门经理负责审核内容是否正确; 5) 审核通过后,发送至总监复审;
6) 复审通过后,配置管理员将入库文档及代码,上传至VSS,并刻盘两份。一份由部门中心保存,
一份由总经办保存。
2.4. 出库流程
1) 申请人填写《版本出库申请表》,分为两类:
a) 文档设计和源代码使用申请:由开发经理填写《版本出库申请表》,并提交给发起人所属
部门经理及部门总监签字;
b) 部署包使用申请:由发起人(项目经理/产品,维护人员),填写《版本出库申请表》,并提
交给发起人所属部门经理签字;
2) 配置管理员根据《版本出库申请表》,负责从VSS下载申请的内容,并发给申请人。
2.5. 产品列表流程
产品入库更新时,《产品列表》需要实时更新,研发中心的配置管理员,在更新的同时需发送对方,以确保《产品列表》的统一性。
3. 适用范围
本制度适用于公司产品、项目、公用组件等公司财产。
4. 附录
请见下页。
附录Ⅰ
版本入库申请单
编号:
精彩文档
实用标准文案
产品编号 系统名称 需求名称 旧版本号 新版本号 版本变更 监控 修改说明 配置 修改说明 入库申请人: 部门/总监: 日期: 年 月 日 日期: 年 月 日 对表操作SQL语句 表结构及索引修改说明 日 期: 年 月 日 配置管理员: 日期: 年 月 日 系统审核结 果 □ □ □ 精彩文档
产品资料(产品策略书、 需求部门 word版本、PPT)* 部署包(执行代码、部署文档、初始化SQL、初始化文件、研发中心/质量保证部 BMS菜单列表、割接方案、运行系统配置)* 需求文档(需求规格说明书、需求部门 功能列表)* 业务策划 评审报告(需求评审、策划评审、原型评审、概要设计评审、数据库设计评审、测试大纲评审报告)* 需求部门 需求/策划/测试部门 □ □ □ 文档清单升级包(执行代码、部署文 档、初始化SQL、初始化文件、研发中心 BMS菜单列表、割接方案)* 设计文档(概要设计、详细设计、数据库设计)* 操作手册* 源代码* 测试报告(原型测试报告、开发测试报告、压力测试报告)* 项目管理文档(会议纪要、立项审批、项目周报) 研发中心 质量保证部 研发中心 质量保证部 项目部门 □ □ □ □ □ □ 实用标准文案
参考资料 其他 □ □ 备注:*表示为必需文档。其中割接方案为项目入库时必需项;升级文件为产品升级时必需项;
项目变更记录表
变更 日期 类型
文档,文件名称 版本 说明 作者 附录Ⅱ
版本出库申请单
编号:YHXX-ZLJL-171 项目编号 出库产品 名称 编号:
需求名称 版本号 出库原因 (申请原因) 入库时间或说明 版本说明 对表操作SQL语句 表结构及索引说明 部门/总监: 日期: 年 月 日 配置管理员: 日期: 年 月 日 □ □ 部署包(执行代码、部署文档、初始化SQL、初始化文件、BMS菜单列表、割接方案) 出库申请人: 日期: 年 月 日 文档清单产品资料(产品策略书、word版本、PPT) 精彩文档
实用标准文案
需求文档(需求规格说明书、功能列表) 业务策划 □ □ 评审报告(页面评审、需求评审、策划评审、□ 原型评审、概要设计评审、数据库设计评审、测试大纲评审报告) 升级包(执行代码、部署文档、初始化SQL、□ 初始化文件、BMS菜单列表、割接方案) 设计文档(概要设计、详细设计、数据库设计) □ 操作手册 源代码 测试报告 项目管理文档(会议纪要、立项审批、项目周报) 参考资料 其他 □ □ □ □ □ □ 说明:如果需要需求规格说明书、概要设计书、详细设计、数据库设计、源代码等之一需要总监签字。
精彩文档
实用标准文案
附录III
程序源码版本号列表:
序号 子系统名称 产品版本号 SVN版本号 SVN存放路径 作者
部署版本号列表:
序号 子系统名称 版本号 部署总包名称 二级子包名称 部署包大小(K) 打包日期 VSS存放路径 作者
附录IV
精彩文档
实用标准文案
产品升级版本审批表
申请人 产品名称 原产品版本 申请原因 产 品 升 级 背 景 描 述 备注 本次升级 内容 本次升级可能存在风险 升级方案评审意见 研发经理 产品经理意见 研发总监意见
CN:X.X.X.X 申请时间 项目 编号 升级产品版本 CN:X.X.X.X □性能改良 □BUG修改 □客户需求 □功能完善 □创新 □其他 时间 升级计划 预计 成本 人/月 完成内容 研发 小 组 成 员 产品总监意见 质检中心总监意见 精彩文档
因篇幅问题不能全部显示,请点此查看更多更全内容