软件版本管理标准规范范文.doc

软件版本管理规范
第一章　目标
本规范具体要求软件项目版本管理对象、存放目录、分支、权限、维护等内容，使软件项目版本管理步骤化并规范化，确保在系统开发和实施过程中项目标完整性和一致性。
1. 第二章　适用范围
全部系统开发及实施项目标软件项目全部应进行版本管理。项目中全部正式文档和代码全部应纳入配置库（可使用工具建立配置库，本文所述使用是SVN）进行版本管理。
2. 第三章　职责
配置库管理员：负责配置库日常维护和管理；监督开发及测试部门立即提交版本管理对象（即配置项）。
此岗位可由开发或测试人员兼任。
3. 第四章　内容
4.1. 版本管理对象
包含但不限于：
ü 项目总体计划
ü 可行性研究汇报
ü 开发计划
ü 需求说明书
ü 需求设计原型
ü 设计说明书
ü 系统开发变更申请单
ü 系统管理手册
ü 用户操作手册
ü 培训计划
ü 培训统计
ü 源程序
ü 支持系统运行配置文件
ü 存放过程脚本
ü 测试计划
ü 测试用例
ü 测试脚本
ü 测试汇报
ü 上线计划
ü 上线申请
ü 版本维护日志
4.2. 配置库目录结构
每个项目在配置库中应拥有唯一项目名称。配置库目录结构和项目内部目录结构提议按下列格式创建。
配置库目录结构计划：
┠tags(公布)
┃ ├v1.0.0_T1_909
┃ ├v1.0.0.33899_T1_1009
┃ ├v1.0.0_R1_1109
┃ ├v1.1.0_T1_0109
┃ └v1.1.0_R1_0209
┠trunk(主版本)
┃ └projectA
┃ ├src
┃ ├MY_MOOC
┃ ├doc
┃ ├tool
┃ ├。。。
┖branches(分支)
├SY_ABC
├TJ_ABC
├WH_MOOC
其中，项目内部目录结构：
|–projectA
|–src （保留该项目标源程序）
|–doc （保留项目相关文档）
|–000.项目管理 （保留项目过程管理相关文档）
|–010.项目计划 （保留项目计划相关文档）
|–020.项目需求 （保留项目需求相关文档）
|–030.系统设计 （保留项目设计相关文档）
|–030.系统测试 （保留项目代码测试相关文档）
|–040.系统实施 （保留项目布署实施相关文档）
|–050.系统运维 （保留项目运维文档，包含培训、用户手册等）
|–060.技术资料 （保留项目技术文档，包含第三方技术资料等）
|–。。。 （保留项目过程管理相关文档）
|–tool （包含该项目特定开发、编译、测试等工具）
4.3. 分支(branch)
提议使用分支来协同不一样职能小组对同一个配置库使用，可根据以下方法进行分支管理。
处理方案建立三个分支，包含主版本开发(trunk)、分支版本开发(branches)和公布(tags)。
ü 主版本开发
是全部分支版本基准版本，主版本开发分支。开发部门开发使用。
ü 分版本开发
主版本分支版本，供开发部门开发使用。开发工程师假如以主版本为基准，进行软件项目开发，要先将trunk目录下代码分支到branches目录一个子目录，在那里对代码进行开发。多个主版本分版本可经过在branches顶级目录创建多个分支目录来区分。
ü 公布
测试和公布专用分支，该分支代码不许可任何形式修改。每个经过测试后不一样版本代码做快照放到此分支文件夹下。
4.4. 权限管理
应对配置库访问权限进行管理，确保软件系统完整性和安全性。提议按以下方法进行管理。
4.4.1. 开发工程师
仅拥有自己所属项目标add file、delete file、check out、check in权限，无目录创建和删除权限。开发工程师若想创建目录，需向配置库管理员申请。
4.4.2. 测试工程师
拥有每个项目标测试分支add file、delete file、check out、check in权限，无目录创建和删除权限，对于其它分支只有只读权限。
4.4.3. 配置库管理员
拥有全部权限，但增删项目和增删目录需要有项目责任人同意。
4.4.4. 其它人员
若需要配置库访问权限，需经技术总监或经技术总监授权项目经理同意，由配置库管理员分配权限。
4.5. 版本管理
应对软件系统版本进行管理，确保版本正确性和可追溯性。提议按以下方法进行管理。
4.5.1. 版本维护
软件工程各阶段产生多种文档和代码，应立即并统一上载到配置库由配置库管理员统一管理。对于要修改配置项，应从配置库中检出（check out）后修改，修改完成后立即检入（check in），并填写修改原因和内容。配置项历史版本应保留在配置库中。
4.5.2. 分支迁移
从开发分支到测试分支迁移，由开发工程师操作。迁移时机有：
1. 当开发责任人提交测试申请时；
2. 开发过程中进行测试，修改好一个或多个bug，需要测试工程师验证时。
从测试分支到公布分支迁移，由配置库管理员操作。迁移时机有：
1.当开发组提交上线申请时。
对于每个项目从测试分支到公布分支迁移，配置库管理员要建立分支迁移日志，并具体统计。
4.5.3. 版本升级
软件系统迁移到公布分支后，生成新版本。
每个系统新版本不仅以分支形式存在于配置库中，而且要以独立压缩包形式备份。
版本命名规则为，version N1.N2.N3[.N4][_][T/R5]_YYYYMMDD
1. N1是系统编号。当项目整体重新设计时，N1加1，基数为1
2. N2是模块编号。当模块重新设计时，N2加1，基数为0
3. N3是功效编号。当项目增加某一功效，或某一功效需要修改时，N3加1，基数为0
4. N4是BUG编号。当项目标BUG被修复时，N4加1，基数为0
5. T/R5中T/R分别对应Test/Release。当项目公布时为R，当项目提交测试时为T，T/R5数值基数为0，以公布/测试提交次序递增加1 。
6. YYYYMMDD代表生成版本实际年月日，如：0202
4.5.4. 版本基线定义
企业首次采取版本管理规范时，能够采取下列方法定义一个基线版本。
获取各项目最新源程序、配置文件和文档，形成公布分支、测试分支和开发分支。
对每个项目标提测和公布分支全部生成一个版本基线，如：Version1.0.0_R1_0202。
4.6. 第五章　版本提交准则
4.6.1. 提交之前先更新
更新标准是要随时更新，随时提交。当完成了一个小功效，能够经过编译而且自己测试以后，谨慎地提交。
假如在修改期间其它同事也更改了同一个文件，那么update更新时会自动进行合并，假如修改是同一行或二者修改差异过大，那么合并时会产生冲突。这种情况就需要同之前开发人员联络，两人一起协商处理合并冲突。处理合并冲突以后，还需要两人一起测试，以确保处理冲突以后，各自程序不会受到影响。
在更新时注意所更新文件列表，假如提交过程中产生了更新，则需要重新编译而且再次完成单元测试，再进行提交。这么既能了解她人修改了哪些文件，同时也能避免合并错误造成代码有错。
4.6.2. 保持原子提交
为确保在需要时能够随时回溯代码版本，每次提交代码只能包含实现一个独立、完整功效所必需代码，不能夹带提交其它和此功效不相关代码。为尽早提交，也能够将此独立、完整功效分解为若干小细节功效，分别开发并提交所必需代码，但必需确保数次提交功效代码组合在一起，完全实现此独立、完整功效。
仅提交自己修改部分，最好不要一下子将整个项目提交。
每完成一个独立、完整功效后，最好尽早提交，以免后续更改时出现bug，无法恢复到正常代码。
每次提交间歇尽可能地短，以多个小时开发工作为宜。我们提倡多提交，也就能多为代码添加上保险。为做到尽早提交，在开发功效模块时候，先将功效分解成一个个独立、不可再分割小细节功效，分别完成。每完成一个并经过单元测试，就提交一次。在修改bug时候，每修改掉一个bug而且确定修改了这个bug，也就提交一次。
4.6.3. 不要提交当地自动生成文件
通常配置管理员全部会将项目中部分自动生成文件或和当地配置环境相关文件屏蔽提交（比如Eclipse中.classpath文件等，Visual Studio中.suo文件，Debug,Release,Obj等编译文件夹及其下文件，和其它部分自动生成，同编译代码无关文件）。假如项目中没有进行这方面配置来强行严禁提交这么文件，请自觉不要提交这么文件，假如不小心签入了，需要从配置库中删除，以免其它同事在更新后就可能和当地环境冲突从而影响大家工作。
4.6.4. 不要提交不能经过编译代码
代码在提交之前，首先要确定自己能够在当地编译经过，而且代码在提交前已经经过自己单元测试。
假如在代码中使用了第三方类库，要把对应类库文件统一存放在代码对应目录中并提交，以免项目组组员中有些组员可能没有安装对应第三方类库，从而在更新代码后引发代码运行错误。
4.6.5. 不要提交自己不明白代码
代码在提交以后即被项目组员所分享。假如提交了不明白代码，自己看不懂，她人也看不懂，假如在以后出现了问题将会成为项目质量隐患。所以在引入任何第三方代码之前，确保对这个代码有一个很清楚了解（必需时应有对应文档说明）。
4.6.6. 并行开发（同一模块）前沟通
假如开发小组采取并行开发模式开发同一模块功效，在开发前，需要对协作开发进行合理工作计划和任务分配，让小组组员相互间了解对方工作计划和工作内容。这么能尽可能降低在开发过程中可能出现冲突，提升开发效率。同时也能够在和组员交流中发觉自己之前设计不足，完善自己设计。
4.6.7. 对提交更新信息采取明晰标注
假如提交空标注或不确切标注将会让项目组中其它组员不了解此次签入动作背景情况（如新增/修改签入原因是什么？新增/修改什么内容？），项目经理无法经过提交标注信息，清楚掌握开发工作进度细节进度。没有清楚标注，甚至会对回溯代码版本造成影响。所以，在提交工作时，要填写明晰标注，能够概要描述所提交文件信息，让项目组其它组员在看到标注后不用具体看代码就能了解你所做修改。
统一标注格式为：
签入动作+””+”#” +标识ID+”;”+签入内容+[“;”]+[签入原因]
签入动作：
+：表示增加了功效（新增功效）
*：表示对一些功效进行了更改（修改功效）
-：表示删除了文件，或对一些功效进行了裁剪，删除，屏蔽（删除功效）
^：表示修正bug（修复功效缺点）
！：优化功效代码实施性能（代码性能优化）
标识ID：
ID值是从项目开发计划中WBS任务分解表中获取，对应具体功效编号。
签入内容：
对新增/修改/删除 内容进行简单描述
签入原因：
对修改/删除 原因进行简单描述
示例：
+ #62235；新增房源审核功效
* #62236；将房源审核二级审核修改为一级审核；为缩短业务步骤长度，提升业务响应速度
- #62237；删除多出功效；房源审核由二级审核改为一级审核后删除无用功效
^ #108；房源主图显示尺寸控制为300*300；房源主图显示尺寸撑大页面
结束。本文已收录于以下专栏：