软件版本管理规范
文档编号 版 本 号 日 期
V1.0 2020-09-14 1 / 17
XXX公司软件版本管理规范
版本变更记录
版本号 V1.0
起止日期 2017-11-14 撰写内容或变更概要说明 新建
作者/变更者 XX 审核者 XX 2 / 17
XXX公司软件版本管理规范
目录
1
引言 ....................................................................................................................... 5
1.1 1.2
目的 ............................................................................................................................. 5 范围 ............................................................................................................................. 5
2 3 4
原则 ....................................................................................................................... 5 角色职责 ............................................................................................................... 6 版本管理 ............................................................................................................... 6
4.1
版本管理流程 ............................................................................................................. 6
部门职责及输出物 ............................................................................................ 6 版本管理流程图 ................................................................................................ 7 禅道项目管理流程图 ........................................................................................ 8
4.1.1 4.1.2 4.1.3 4.2
版本标识方法 ............................................................................................................. 8
正式版本 ............................................................................................................ 8 内部测试版本 .................................................................................................... 9
4.2.1 4.2.2 4.3
版本升级管理 ............................................................................................................. 9
版本升级原则 .................................................................................................... 9 新版本发布原则 .............................................................................................. 10
4.3.1 4.3.2
4.4 文档的存放 ............................................................................................................... 11 4.4.1 4.4.2 4.4.3 4.4.4 4.4.5
当前版本和历史版本的存放 .......................................................................... 11 开发文档的存放 .............................................................................................. 11 源代码的存放 .................................................................................................. 11 SQL语句的存放 ............................................................................................... 11 发行文档的存放 .............................................................................................. 12
4.5 权限控制管理 ........................................................................................................... 12
5 版本提交规则 ..................................................................................................... 12
5.1 5.2
开发交付测试要求 ................................................................................................... 12 测试接收标准 ........................................................................................................... 13
3 / 17
XXX公司软件版本管理规范
5.3 5.4
测试中断标准（冒烟测试） ................................................................................... 13 测试通过标准 ........................................................................................................... 13
6 7 8
备份管理 ............................................................................................................. 14 各开发组提交文档及源码以及规则 ................................................................. 14 版本发布流程 ..................................................................................................... 15
4 / 17
XXX公司软件版本管理规范
1 引言
版本控制就是对软件开发过程中所创建的配置对象不同版本进行管理，保证任何时间都可以取到正确的版本以及版本的组合。
版本控制的主要功能是记录开发过程中的每一次修改，让开发的工作可以随时检查过往历史记录和获得正确版本，是系统的成长记录。
1.1 目的
本文档的编制是为了规范产品管理中心、运营开发中心、产品开发中心、项目管理中心对软件产品版本的管理。
1.2 范围
本文档为产品部、研发部、测试部的管理员提供有关版本管理规范的相关内容，包括：
➢ 版本标识方法 ➢ 软件系统数据的存放 ➢ 文档的修改控制
➢ 文档的备份制度
2 原则
软件版本发布管理应遵循以下原则：
1）实施版本变更应符合以下原则之一： ✓ 为满足客户新业务、新功能需求；
✓ 为满足提高业务质量、提升业务性能指标和容量扩充的需求； ✓ 为解决软件故障和软件稳定性、安全性、可控性问题； ✓ 为了提高软件可维护性。
5 / 17
XXX公司软件版本管理规范
2）版本的集成和发布应严格按照计划执行，避免随意和频繁更新版本； 3)为保证软件质量，任何一个软件版本须通过版本测试后方可上线； 4)所有软件版本必须通过正式渠道发布给用户，未经审批各部门和个 人不得擅自向用户发布软件版本。
3 角色职责
角色 产品负责人/部门 开发人员/部门 布说明； 确认原有BUG的是否彻底解决；对遗留缺陷做出风险评估，出具测试人员/部门 测试报告；提交上线软件程序包； BM/配置管理员 （暂无） PMO 审批上线发布计划；跟进上线过程、监督上线流程； （暂无） 接收上线软件程序包，正式发布通知，通知开发、测试、各业务部门并附上产品发布说明；源码、文档入库、基线维护； 职责 制定版本功能，核对研发计划执行偏差； 确认代码完整提交；提交相关配置文件、数据库表脚本；提交发4 版本管理 4.1 版本管理流程 4.1.1 部门职责及输出物
部门 职责说明 1）产品运营部负责公司用户运营类的产品管理，各产品指定唯一的产品经理负责管理； 产品运管部 2）拟定版本功能，组织需求评审，将系统原型图、UI设计图、产品需求文档提交给开发部及产品测试部； 3）对产品测试部测试通过的版本做确确定版本 ➢ 版本发布通知（邮件形式） 提出版本 涉及阶段 ➢ ➢ ➢ 输出物 系统原型图 UI设计图 产品需求文档 6 / 17
XXX公司软件版本管理规范
认，提交版本给项目部； 1）产品管理部负责公司销售类的产品管理，，各产品指定唯一的产品经理负责管理； 产品管理部 2）拟定版本功能，组织需求评审，将系统原型图、UI设计图、产品需求文档提交给开发部及产品测试部； 3）对产品测试部测试通过的版本做确认，提交版本给项目部； 根据产品运营部提交的版本进行设开发部 计、开发并完成版本内测，内测通过的版本提交给产品测试部，对测试中发出的缺陷做问题修复 依据需求文档对版本功能进行验证测产品测试部 试，测试不通过的版本返回给开发部修复，测试通过的版本提交给产品运营部 项目部 将产品运营部提交的版进行发布上线 发布版本 版本测试 版本开发 确定版本 提出版本 ➢ ➢ ➢ 系统原型图 UI设计图 产品需求文档 ➢ 版本发布通知（邮件形式） 4.1.2 版本管理流程图
7 / 17
XXX公司软件版本管理规范
4.1.3 禅道项目管理流程图
流程说明如下： 1. 产品经理创建产品 2. 产品经理创建需求 3. 项目经理创建项目
4. 项目经理确定项目要做的需求 5. 项目经理分解任务，指派到人 6. 测试人员测试，提交bug
4.2 版本标识方法
为了使工作规范化、统一化，各项目组实行的版本标识管理方法分为：正式版本和内部测试版本。
4.2.1 正式版本
公司发布的正规版本。
8 / 17
XXX公司软件版本管理规范
以“V”开头，版本号放后。V前面增加项目名称，版本号分3节：主版本号，次版本号和内部版本号，每节之间以小数点（.）间隔。如V2.0.1表示主版本号为2，次版本号为0，内部版本号为1。产品部控制主版本号和次版本号，项目部控制内部版本号。
4.2.2 内部测试版本
公司发布的内部测试版本。
以“T”开头，版本号放后。T前面增加项目名称，版本号分4节：主版本号，次版本号，内部版本号和修正版本号，每节之间以小数点（.）间隔。如V2.0.1.12表示主版本号为2，次版本号为0，内部版本号为1，修正版本号为12。产品部控制主版本号和次版本号，开发部控制内部版本号，测试部控制修正版本号。
示例：
版本名 嘀嘀打饭V4.2.1 +次版本号+内部版本号。 内部测试版本，证联桌面为产品名称，V4.2.1.4为主版本嘀嘀打饭T4.2.1.4 号+次版本号+内部版本号+修正版本号。每次修正缺陷后，修正版本号应增加1。 含义 正式发布版本，证联桌面为产品名称，V4.2.1为主版本号4.3 版本升级管理
4.3.1 版本升级原则
版本升级应严格纳入版本管理的控制之下。应当谨慎地控制版本的升级，保障高版本的向下兼容性，或提供严格定义的升级方法。
在下面几种情况下，进行版本演化和升级：
1、当产品发生重大修改和改进时，主版本号加1。重大修改和改进包括： 1）平台迁移； 2）开发工具的迁移；
9 / 17
XXX公司软件版本管理规范
3）体系结构的变迁。
2、当产品发生较小的改进或修改时，次版本号可以加1。
3、对于改动量比较少的，如修改产品的错误，可增加内部版本号。内部版本号对用户来说是不可见的，只对项目部内部版本控制有用。
4、记录版本升级过程。每次版本升级，都要填写版本升级记录表，记录表样例如下：
版本升级记录表
版本号 发布日期 修改文件 问题简要描述 发布责任人 批准人 备注 说明：
版本号： 记录当前发布的版本。 发布日期：该版本批准发布的日期。
修改文件：版本修改记录文件，一般为版本修改日志。
4.3.2 新版本发布原则
新版本的发布包括主版本号和次版本号的升级，一般不包括内部版本号的升级。流程如下：
1、根据项目进展情况，或者根据用户需要进行发布准备。
2、在指定目录中，根据本次发布的版本号建立相应的子目录，将current
下的所有内容拷贝至新建目录下。
3、可在新建目录下建立readme.txt，并加入相应的内容。
readme.txt文件是记录该版本与上一版本的不同，作过哪些改动。格式样例如下：
增加或修改功能 涉及源文件 改动原因 10 / 17
XXX公司软件版本管理规范
4.4 文档的存放
4.4.1 当前版本和历史版本的存放
对于源码文件，设定Current目录，存放当前正在开发与维护的源码文件，当前未发布版本的所有数据都存放在.....\\CURRENT\\下。一旦当前版本正式发行，则当前目录被修改为相应的历史目录。
历史版本是指已经发行的版本，存放在相应的版本目录之下，一般不允许改动，改动需提交申请，填写原因。
4.4.2 开发文档的存放
根据各项目部自己的情况，将系统用户需求记录、总体设计文档、详细设计及数据结构文件、测试记录、用户手册等放入相应的目录下。
4.4.3 源代码的存放
源代码包括如：java，jsp，BMP，ICO等相关文件，是未经编译处理的、不能直接交付使用的产品文件以及编译产品所需的文件；联机帮助文件HLP在未生成HLP文件之前的DOC，RTF等格式的文档也视为源代码。
各子系统当前的程序源文件放入相应的目录下。对于一个子系统又分多个分子系统的情况，应在该目录下分别建立几个相应的目录。
4.4.4 SQL语句的存放
各子系统SQL文件放入…..\\.......\\SQL下，对于不同的数据库，分别建立不同的子目录，如oracle、sysbase、db2等。公共SQL文件直接放入…\\SQL下即可，不同数据库的特殊SQL分别放入对应的子目录下。
11 / 17
XXX公司软件版本管理规范
4.4.5 发行文档的存放
发行文档是指产品交付用户使用所必须的文件。包括：产品可执行文件，用户使用说明书，联机帮助（HLP）；资源文件（JPG，ICO等），环境配置文件等。
4.5 权限控制管理
为保障文档的安全性，一致性，以及防止意外修改，必须对不同的文档设置不同的访问权限。
文档权限类别：只读权限，读写权限。 文档类别：设计文档，源码，发行文档。
用户类别：开发人员、测试人员、分析设计人员、项目经理、配置管理员、安装盘制作人员、问题及需求管理人员、用户文档编写人员等。
为了控制不同的使用权限，根据要求在服务器上分别建立不同的用户，针对不同的配置项所在目录分配不同的权限。
为了便于管理，应以表格的形式列出人员与管理对象的访问关系（用户权限清单）。
5 版本提交规则
5.1 开发交付测试要求
➢ 提供自测报告（不限形式，可以是文档/截图/结果说明） ➢ 测试的版本号；
➢ 需求/设计变更版本,必须提供对应版本说明和操作说明；
➢ 测试范围：需要测试哪些功能包括因修复问题导致受影响的关联功能； ➢ 给出版本测试完成的具体时间；
➢ 明确指定1个固定人员提交版本给测试部门（提交前需要确认打包完所有功
能）；
12 / 17
XXX公司软件版本管理规范
软件测试申请单V1.0.docx
说明：按软件测试申请单统一填写。
5.2 测试接收标准
➢ 首次进入必须保证软件能正常安装和运行、核心和关键业务功能100%实现,
并提供对应交付件；
➢ 回归测试版本致命缺陷必须100%修改,严重缺陷修改率不能低于85%,总缺
陷修改率不能低于80%；
5.3 测试中断标准（冒烟测试）
➢ 测试环境安装无法正确进行的；
➢ 产品关键业务功能、性能、可靠性存在致命缺陷导致后续测试活动无法继续
开展的；
➢ 已修复的致命bug重现或修复时引入新的致命bug导致后续测试活动无法进
行的；
➢ 修改bug没有(描述不清晰)提交缺陷分析和修改方案及测试建议的； 5.4
测试通过标准
➢ 严重缺陷100%修复； ➢ 较严重缺陷100%修复； ➢ 一般缺陷修复率95%以上； ➢ 轻微缺陷修复率在85%以上； ➢ 测试用例执行：100%； ➢ 用例通过率：不低于95%； 缺陷严重级别说明见禅道。
13 / 17
XXX公司软件版本管理规范
6 备份管理
为了保证文档的最大可恢复性，要随时及定期地进行备份工作。 1、随时备份：
➢ 开发人员每天都要将自已当日修改的源文件在本地机器上进行备份。 ➢ 开发负责人每天要将所有源文件在本地机备份。
2、定期备份
➢ 备份周期视各产品部、事业部的具体情况而定。如果处于开发阶段，每周应
对所有的源程序项进行备份，一般为每周周五；如果处于其它阶段，根据具体情况而定，但周期不能超过两周。
➢ 备份要由版本管理员负责，备份原则应是保证文档的最大可恢复性。备份文
件应该记录以下内容：本次备份时间，备份内容，执行人。
7 各开发组提交文档及源码以及规则
各开发组需要提交的文档 名称 软件需求说明书 成果描述 目标客户、业务流程、系统中的角色、子功能模块介绍、质量要求、界面要求 系统约束、开发环境、数据流程图、用例图、模块之间的关系图、类函数文件变量等命名规则、系统安全设计说明、性能分析 所有表名、表设计、表ER图、生成库的sql语句、存储过程等。表及字段命名规则。 系统界面设计说明、原型图 编程的接口、主要的数据结构、主要算法 用例名称、用例描述、输入值、希望输出值 Bug名称、bug状态、bug紧急情况、bug处理人等 界面测试报告、性能测试报告 部署环境说明、初始化的数据、注意事项、数据的迁移等 安装过程描述、各模块使用手册、FAQ手册 源代码、开发工具、API详细说明、代码注释、编译后程序 问题描述、问题解决情况 评审内容、评审结果、评审人 打包程序、打包工具、打包完以后的安装程序 系统设计说明书 数据库设计说明书 用户界面设计说明书 模块设计说明书 测试用例 缺陷报告 测试报告 部署说明书 安装和使用手册 软件源代码 系统维护记录 技术评审报告 系统安装程序 14 / 17
XXX公司软件版本管理规范
8 版本发布流程
依据版本发布原因及执行流程的不同，软件版本可分为例行版本和紧急放行版本：
1) 例行版本是指依照版本计划生成的升级版本，例行版本按固定周期发
布，执行例行版本发布流程；
15 / 17
XXX公司软件版本管理规范
16 / 17
XXX公司软件版本管理规范
2) 紧急放行版本是指版本计划外生成，由客户紧急需求或影响生产的紧
急故障所引发的需及时发布的软件版本，执行紧急版本发布流程。
17 / 17
因篇幅问题不能全部显示，请点此查看更多更全内容