文档介绍：该【软件版本管理规范范本 】是由【书生教育】上传分享，文档一共【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是系统编号。当项目整体从头设计时,N1加1,基数为1
N2是模块编号。当模块从头设计时,N2加1,基数为0
。当项目增添某一功能,或某一功能需要改正时,N3加1,基数为
0
N4是BUG编号。当项目的BUG被修复时,N4加1,基数为0
T/R5中的T/R分别对应Test/Release。当项目公布时为R,当项目提交测试时为
T,T/R5数值基数为0,以公布/测试提交次序递加添1。
YYYYMMDD代表生成版本的实质年代日,如:20160202
版本基线定义
企业初次采纳版本管理规范时,能够采纳以下方法定义一个基线版本。
获得各项目最新的源程序、配置文件和文档,形成公布分支、测试分支和开发分支。对每个项目的提测和公布分支都生成一个版本基线,如:
。
更新的原则是要随时更新,随时提交。当达成了一个小功能,能够经过编译而且自己
测试以后,慎重地提交。
假如在改正的时期其余同事也改正了同一个文件,那么update更新时会自动进行合
并,假如改正的是同一行或许两者改正差别过大,那么归并时会产生矛盾。这类状况
.
精选文档
就需要同以前的开发人员联系,两人一同磋商解决归并矛盾。解决归并矛盾以后,还
需要两人一同测试,以保证解决矛盾以后,各自的程序不会遇到影响。
在更新时注意所更新文件的列表,假如提交过程中产生了更新,则需要从头编译而且
再次达成单元测试,再进行提交。这样既能认识他人改正了哪些文件,同时也能防止
归并错误致使代码有错。
为保证在需要时能够随时回溯代码版本,每次提交的代码只好包含实现一个独立、完
整功能所必需的代码,不可以夹带提交其余与此功能不有关的代码。为尽早提交,也可
以将此独立、完好功能分解为若干小细节功能,分别开发并提交所必需的代码,但必
须保证多次提交的功能代码组合在一同,完好实现此独立、完好功能。
仅提交自己改正的部分,最好不要一下子将整个项目提交。
每达成一个独立、完好的功能后,最好尽早提交,免得后续改正时出现bug,没法恢
复到正常代码。
每次提交的间歇尽可能地短,以几个小时的开发工作为宜。我们倡导多提交,也就能
多为代码增添上保险。为做到尽早提交,在开发功能模块的时候,先将功能分解成一
个个独立的、不行再切割的小细节功能,分别达成。每达成一个并经过单元测试,就
提交一次。在改正bug的时候,每改正掉一个bug而且确认改正了这个bug,也就
提交一次。
一般配置管理员都会将项目中一些自动生成的文件或许与当地配置环境有关的文件
.
精选文档
障蔽提交(,,
Debug,Release,Obj等编译文件夹及其下文件,以及其余的一些自动生成,同编译代
码没关的文件)。假如项目中没有进行这方面的配置来强行严禁提交这样的文件,请
自觉不要提交这样的文件,假如不当心签入了,需要从配置库中删除,免得其余同事
在更新后便可能与当地的环境矛盾进而影响大家的工作。
代码在提交以前,第一要确认自己能够在当地编译经过,而且代码在提交前已经经过
自己的单元测试。
假如在代码中使用了第三方类库,要把相应类库文件一致储存在代码相应目录中并提
交,免得项目构成员中有些成员可能没有安装相应的第三方类库,进而在更新代码后
惹起代码运转错误。
代码在提交以后即被项目成员所分享。假如提交了不理解的代码,自己看不懂,他人
也看不懂,假如在此后出现了问题将会成为项目质量的隐患。所以在引入任何第三方
代码以前,保证对这个代码有一个很清楚的认识(必需时应有对应文档说明)。
(同一模块)前交流
假如开发小组采纳并行开发模式开发同一模块功能,在开发前,需要对协作开发进行
合理的工作计划与任务分派,让小构成员互相间认识对方的工作计划与工作内容。这
样能尽可能的减少在开发过程中可能出现的矛盾,提升开发效率。同时也能够在和成
员的交流中发现自己以前设计的不足,完美自己的设计。
.
精选文档
假如提交空的标明或许不切实的标明将会让项目组中其余的成员不认识此次签入动
作的背景状况(如新增/改正签入的原由是什么?新增/改正什么内容?),项目经理
没法经过提交的标明信息,清楚的掌握开发工作进度细节进度。没有清楚标明,甚至
会对回溯代码版本造成影响。所以,在提交工作时,要填写清楚的标明,能够纲要的
描绘所提交文件的信息,让项目组其余成员在看到标明后不用详尽看代码就能认识你
所做的改正。
一致的标明格式为:
签入动作+””+”#”+表记ID+”;”+签入内容+[“;”]+[签入原由]
签入动作:
:表示增添了功能(新增功能)
:表示对某些功能进行了改正(改正功能)
:表示删除了文件,或许对某些功能进行了裁剪,删除,障蔽(删除功能)
:表示修正bug(修复功能缺点)
!:优化功能代码的履行性能(代码性能优化)表记ID:
ID值是从项目开发计划中的WBS任务分解表中获得,对应详细功能编号。
签入内容:
对新增/改正/删除的内容进行简单描绘
签入原由:
.