文档介绍：该【(完整版)软件版本管理规范 】是由【南】上传分享，文档一共【11】页，该文档可以免费在线阅读，需要了解更多关于【(完整版)软件版本管理规范 】的内容，可以使用淘豆网的站内搜索功能，选择自己适合的文档，以下文字是截取该文章内的部分文字，如需要获得完整电子版，请下载此文档到您的设备，方便您编辑和打印。:.
软件版本管理规范
第一章目的
本规范详细规定软件项目版本管理的对象、存储目录、分支、权限、维护等内容,使
软件项目版本管理流程化并规范化,确保在系统开发和实施过程中项目的完整性和一
致性。
所有系统开发及实施项目的软件项目都应进行版本管理。项目中所有正式文档和代码
都应纳入配置库(可使用工具建立配置库,本文所述使用的是SVN)进行版本管理。
配置库管理员:负责配置库的日常维护和管理;监督开发及测试部门及时提交版本管
理对象(即配置项)。
此岗位可由开发或测试人员兼任。
包括但不限于:
项目总体计划
可行性研究报告
开发计划
需求说明书
欢迎您阅读并下载本文档,本文档来源于互联网,如有侵权请联系删除!我们将竭诚为您提供优质的文档!:.
需求设计原型
设计说明书
系统开发变更申请单
系统管理手册
用户操作手册
培训计划
培训记录
源程序
支持系统运行的配置文件
存储过程脚本
测试计划
测试用例
测试脚本
测试报告
上线计划
上线申请
版本维护日志
每个项目在配置库中应拥有唯一的项目名称。配置库目录结构与项目内部的目录结构
建议按下列格式创建。
欢迎您阅读并下载本文档,本文档来源于互联网,如有侵权请联系删除!我们将竭诚为您提供优质的文档!:.
配置库目录结构规划:
┠tags(发布)
┃├
┃├
┃├
┃├
┃└
┠trunk(主版本)
┃└projectA
┃├src
┃├MY_MOOC
┃├doc
┃├tool
┃├。。。
┖branches(分支)
├SY_ABC
├TJ_ABC
├WH_MOOC
其中,项目内部的目录结构:
|–projectA
欢迎您阅读并下载本文档,本文档来源于互联网,如有侵权请联系删除!我们将竭诚为您提供优质的文档!:.
|–src(保存该项目的源程序)
|–doc(保存项目相关文档)
|–(保存项目过程管理相关文档)
|–(保存项目计划相关文档)
|–(保存项目需求相关文档)
|–(保存项目设计相关文档)
|–(保存项目代码测试相关文档)
|–(保存项目部署实施相关文档)
|–(保存项目运维文档,包括培训、用户手册等)
|–(保存项目技术文档,包括第三方技术资料等)
|–。。。(保存项目过程管理相关文档)
|–tool(包括该项目特定的开发、编译、测试等工具)
(branch)
建议使用分支来协同不同职能小组对同一个配置库的使用,可按照以下方式进行分支
的管理。
解决方案建立三个分支,包括主版本开发(trunk)、分支版本开发(branches)和发布
(tags)。
主版本开发
是所有分支版本的基准版本,主版本的开发分支。开发部门开发使用。
分版本开发
欢迎您阅读并下载本文档,本文档来源于互联网,如有侵权请联系删除!我们将竭诚为您提供优质的文档!:.
主版本的分支版本,供开发部门开发使用。开发工程师如果以主版本为基准,进行软
件项目开发,要先将trunk目录下的代码分支到branches目录的一个子目录,在那
里对代码进行开发。多个主版本的分版本可通过在branches顶级目录创建多个分支
目录来区分。
发布
测试和发布专用分支,该分支代码不允许任何形式的修改。每个经过测试后的不同版
本的代码做快照放到此分支文件夹下。
应对配置库的访问权限进行管理,确保软件系统的完整性和安全性。建议按如下方式
进行管理。
仅拥有自己所属项目的addfile、deletefile、checkout、checkin权限,无目录
创建和删除权限。开发工程师若想创建目录,需向配置库管理员申请。
拥有每个项目的测试分支的addfile、deletefile、checkout、checkin权限,无
目录创建和删除权限,对于其他分支只有只读权限。
拥有全部权限,但增删项目和增删目录需要有项目负责人批准。
若需要配置库访问权限,需经技术总监或经技术总监授权的项目经理批准,由配置库
欢迎您阅读并下载本文档,本文档来源于互联网,如有侵权请联系删除!我们将竭诚为您提供优质的文档!:.
管理员分配权限。
应对软件系统的版本进行管理,确保版本的准确性和可追溯性。建议按如下方式进行
管理。
软件工程各阶段产生的各种文档和代码,应及时并统一上载到配置库由配置库管理员
统一管理。对于要修改的配置项,应从配置库中检出(checkout)后修改,修改完
毕后及时检入(checkin),并填写修改的原因和内容。配置项的历史版本应保存在
配置库中。
从开发分支到测试分支的迁移,由开发工程师操作。迁移的时机有:
;
,修改好一个或多个bug,需要测试工程师验证时。
从测试分支到发布分支的迁移,由配置库管理员操作。迁移的时机有:
。
对于每个项目从测试分支到发布分支的迁移,配置库管理员要建立分支迁移日志,并
详细记录。
软件系统迁移到发布分支后,生成新的版本。
每个系统新的版本不仅以分支形式存在于配置库中,并且要以独立压缩包形式备份。
欢迎您阅读并下载本文档,本文档来源于互联网,如有侵权请联系删除!我们将竭诚为您提供优质的文档!:.
版本的命名规则为,[.N4][_][T/R5]_YYYYMMDD
。当项目整体重新设计时,N1加1,基数为1
。当模块重新设计时,N2加1,基数为0
。当项目增加某一功能,或某一功能需要修改时,N3加1,基数为
0
。当项目的BUG被修复时,N4加1,基数为0
。当项目发布时为R,当项目提交测试时为
T,T/R5数值基数为0,以发布/测试提交顺序递增加1。
,如:20160202
公司首次采用版本管理规范时,可以采取下列方法定义一个基线版本。
获取各项目最新的源程序、配置文件和文档,形成发布分支、测试分支和开发分支。
对每个项目的提测和发布分支都生成一个版本基线,如:
。
更新的原则是要随时更新,随时提交。当完成了一个小功能,能够通过编译并且自己
测试之后,谨慎地提交。
如果在修改的期间其他同事也更改了同一个文件,那么update更新时会自动进行合
并,如果修改的是同一行或者二者修改差异过大,那么合并时会产生冲突。这种情况
欢迎您阅读并下载本文档,本文档来源于互联网,如有侵权请联系删除!我们将竭诚为您提供优质的文档!:.
就需要同之前的开发人员联系,两人一起协商解决合并冲突。解决合并冲突之后,还
需要两人一起测试,以保证解决冲突之后,各自的程序不会受到影响。
在更新时注意所更新文件的列表,如果提交过程中产生了更新,则需要重新编译并且
再次完成单元测试,再进行提交。这样既能了解别人修改了哪些文件,同时也能避免
合并错误导致代码有错。
为确保在需要时可以随时回溯代码版本,每次提交的代码只能包含实现一个独立、完
整功能所必需的代码,不能夹带提交其他与此功能不相关的代码。为尽早提交,也可
以将此独立、完整功能分解为若干小细节功能,分别开发并提交所必需的代码,但必
须确保多次提交的功能代码组合在一起,完全实现此独立、完整功能。
仅提交自己修改的部分,最好不要一下子将整个项目提交。
每完成一个独立、完整的功能后,最好尽早提交,以免后续更改时出现bug,无法恢
复到正常代码。
每次提交的间歇尽可能地短,以几个小时的开发工作为宜。我们提倡多提交,也就能
多为代码添加上保险。为做到尽早提交,在开发功能模块的时候,先将功能分解成一
个个独立的、不可再分割的小细节功能,分别完成。每完成一个并通过单元测试,就
提交一次。在修改bug的时候,每修改掉一个bug并且确认修改了这个bug,也就
提交一次。
一般配置管理员都会将项目中一些自动生成的文件或者与本地配置环境有关的文件
欢迎您阅读并下载本文档,本文档来源于互联网,如有侵权请联系删除!我们将竭诚为您提供优质的文档!:.
屏蔽提交(,,
Debug,Release,Obj等编译文件夹及其下文件,以及其他的一些自动生成,同编译代
码无关的文件)。如果项目中没有进行这方面的配置来强行禁止提交这样的文件,请
自觉不要提交这样的文件,如果不小心签入了,需要从配置库中删除,以免其他同事
在更新后就可能与本地的环境冲突从而影响大家的工作。
代码在提交之前,首先要确认自己能够在本地编译通过,并且代码在提交前已经通过
自己的单元测试。
如果在代码中使用了第三方类库,要把相应类库文件统一存储在代码相应目录中并提
交,以免项目组成员中有些成员可能没有安装相应的第三方类库,从而在更新代码后
引起代码运行错误。
代码在提交之后即被项目成员所分享。如果提交了不明白的代码,自己看不懂,别人
也看不懂,如果在以后出现了问题将会成为项目质量的隐患。因此在引入任何第三方
代码之前,确保对这个代码有一个很清晰的了解(必要时应有对应文档说明)。
(同一模块)前沟通
如果开发小组采用并行开发模式开发同一模块功能,在开发前,需要对协作开发进行
合理的工作计划与任务分配,让小组成员相互间了解对方的工作计划与工作内容。这
样能尽可能的减少在开发过程中可能出现的冲突,提高开发效率。同时也能够在和成
员的交流中发现自己之前设计的不足,完善自己的设计。
欢迎您阅读并下载本文档,本文档来源于互联网,如有侵权请联系删除!我们将竭诚为您提供优质的文档!:.
如果提交空的标注或者不确切的标注将会让项目组中其他的成员不了解此次签入动
作的背景情况(如新增/修改签入的原因是什么?新增/修改什么内容?),项目经理
无法通过提交的标注信息,清晰的掌握开发工作进度细节进度。没有清晰标注,甚至
会对回溯代码版本造成影响。所以,在提交工作时,要填写明晰的标注,能够概要的
描述所提交文件的信息,让项目组其他成员在看到标注后不用详细看代码就能了解你
所做的修改。
统一的标注格式为:
签入动作+””+”#”+标识ID+”;”+签入内容+[“;”]+[签入原因]
签入动作:
+:表示增加了功能(新增功能)
*:表示对某些功能进行了更改(修改功能)
-:表示删除了文件,或者对某些功能进行了裁剪,删除,屏蔽(删除功能)
^:表示修正bug(修复功能缺陷)
!:优化功能代码的执行性能(代码性能优化)
标识ID:
ID值是从项目开发计划中的WBS任务分解表中获取,对应具体功能编号。
签入内容:
对新增/修改/删除的内容进行简单描述
签入原因:
欢迎您阅读并下载本文档,本文档来源于互联网,如有侵权请联系删除!我们将竭诚为您提供优质的文档!:.
对修改/删除的原因进行简单描述
示例:
+#62235;新增房源审核功能
*#62236;将房源审核的二级审核修改为一级审核;为缩短业务流程长度,提高业务
响应速度
-#62237;删除多余功能;房源审核由二级审核改为一级审核后删除无用功能
^#108;房源主图显示尺寸控制为300*300;房源主图显示尺寸撑大页面
结束。
欢迎您阅读并下载本文档,本文档来源于互联网,如有侵权请联系删除!我们将竭诚为您提供优质的文档!