软件版本管理规范
- 1、下载文档前请自行甄别文档内容的完整性,平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益,请联系客服反馈,我们会尽快为您处理(人工客服工作时间:9:00-18:30)。
软件版本管理规范集团标准化工作小组 #Q8QGGQT-GX8G08Q8-GNQGJ8-MHHGN#
软件版本管理
目录
1.引言
版本控制就是对软件开发过程中所创建的配置对象不同版本进行管理,保证任何时间都可以取到正确的版本以及版本的组合。
版本控制的主要功能是记录开发过程中的每一次修改,让开发的工作可以随时检查过往历史记录和获得正确版本,是系统的成长记录。
1.1. 目的
本文档的编制是为了规范产品部、研发部、测试部对软件产品版本的管理。
1.2. 范围
本文档为产品部、研发部、测试部的管理员提供有关版本管理规范的相关内容,包括:
●版本标识方法
●软件系统数据的存放
●文档的修改控制
●文档的备份制度
1.3. 术语定义
SCM
软件配置管理(Software Configuration Management)缩写
SVM
软件版本管理(Software Version Management)缩写
SVN
一个开源的版本控制系统Subversion.
文档
一种数据媒体和其上所记录的数据。
配置管理
标识和确定系统中配置项的过程,在系统整个生存周期内控制这些项的投放和更动,记录并报告配置的状态和更动要求,验证配置项的完整性和正确性。
软件配置
软件的具体形态在某时刻的瞬时影像。
配置项
软件配置管理的对象称为配置项,如:系统规格说明书,项目开发计划,用户手册,源码。
基线
软件生存周期中各开发阶段末尾的标记,它的作用是把各阶段工作的划分更加明确化,使本来连续的工作在这些点上断开,使之便于检验和肯定阶段成果。
1.4. 参考资料
《软件版本管理规范》浪潮集团山东通用软件有限公司
《泰豪软件开发软件版本管理制度》
《tortoise SVN的使用手册》
1.5. 版本控制记录
1.6. 版本更新记录
*A - 增加M - 修改D - 删除
2.版本管理
2.1. 版本标示方法
为了使工作规范化、统一化,研发本部各部门实行的版本标识管理方法。
2.1.1.正式版本
X:主版本号,用来表示提供给客户的产品功能的主要增强。在一个极端的例子中,主版本号的上升用来说明产品现在已经拥有了一个全新的功能类。从市场和许可权的角度来看,主版本号的升级相当于购买一个完全独立的产品。从开发者角度来看,一个主版本号的迭代差不多总是反映了一个新的独立分支或是其主干还可以延续主版本的生命期。
Y:特征版本号,用来表示产品新增了一些特征,或者是在原来文档中描述的特征上作了重要的修改。用来确定特征版本号什么时候需要修改的一个衡量标准就是产品功能说明书。产品的特征版本升级是在主版本之间保持产品竞争力的一种重要机制。
Z:缺陷修复版本号,用来表示在该版本上所做的缺陷维护行为的等级。版修复版本是稳定市场和最小化客户技术支持费用负担的一种重要机制。
Alpha版: 此版本表示该软件在此阶段主要是以实现软件功能为主,通常只在软件开发者内部交流,一般而言,该版本软件的Bug较多,需要继续修改。
Beta版: 该版本相对于α版已有了很大的改进,消除了严重的错误,但还是存在着一些缺陷,需要经过多次测试来进一步消除,此版本主要的修改对像是软件的UI。
RC版: 该版本已经相当成熟了,基本上不存在导致错误的BUG,与即将发行的正式版相差无几。
Release版: 该版本意味“最终版本”,在前面版本的一系列测试版之后,终归会有一个正式版本,是最终交付用户使用的一个版本。该版本有时也称为标准版。一般情况下,Release不会以单词形式出现在软件封面上,取而代之的是符号(R)。
2.2. 目录结构
由于各部门的实际情况不同,目录结构很难统一,但为了能更好地管理各部门部文档,建议可将被管理的配置项分为三大类:文档类、源码类及安装盘
2.3. 文档的存放
2.3.1.开发文档的存放
文档归档流程:
2.3.2.源代码的存放
2.3.3.SQL的语句存放
各子系统SQL文件放入…..\.......\SQL下,对于不同的数据库,分别建立不同的子目录,如WAT、SYB、MSS、ORC、DB2等。公共SQL文件直接放入…\SQL下即可,不同数据库的特殊SQL分别放入对应的子目录下。
2.3.4.发行文档的存放
发行文档是指产品交付用户使用所必须的文件。包括:产品可执行文件,用户使用说明书,联机帮助(HLP);资源文件(BMP,ICO等),环境配置文件等。
2.4. 配置管理流程
流程说明:
1.开发人员完成所负责代码模块的编写任务后,提交到项目经理处;
2.项目经理向测试部提交测试任务;
3.配置管理员准备测试所需环境;
4.测试员开始测试并提供实时测试BUG;
5.开发人员处理测试人员提供的BUG,并提交测试员进行回归测试,直至BUG 关闭;
6.测试完成后,测试人员提供测试报告;
7.根据项目情况决定是否发布新版本;
8.配置管理员与各成员确定好新版本的各项信息;
9.配置管理员发布新版本。
2.5. 权限控制的管理
为保障文档的安全性,一致性,以及防止意外修改,必须对不同的文档设置不同的访问权限。
文档权限类别:只读权限,读写权限。
文档类别:DOC,SRD,RELEASE。
用户类别:开发人员、测试人员、分析设计人员、部门经理、配置管理员、安装盘制作人员、问题及需求管理人员、用户文档编写人员等。
为了控制不同的使用权限,根据要求在服务器上分别建立不同的用户,针对不同的配置项所在目录分配不同的权限。
为了便于各部门的管理,应以表格的形式列出人员与管理对象的访问关系(用户权限清单)。
3.更新管理
3.1. 源程序的修改
当开发小组在开发同一产品时,应能保障:各成员间的修改不会互相覆盖;程序员的修改能及时反映到产品的最新版本中。
建议首先在相应子系统的下一级建一目录,如checkout,存放正在修改的文档及修改登记表。当某个程序员要修改某一文档时,遵循以下程序:
1)接收维护任务;
2)查看需要修改的文件(如PBL及SQL等)是否正在被其它人员修改(检查checkout目录下是否存在要修改的文件或后缀已改为该程序员姓名简写);
3)如果有人在修改该文件,等待或与相应的开发员联系,重复2。否则继续;