SVN配置库管理过程文件

SVN配置管理过程文件
修订记录
目录
1.目的 (4)
2.适用范围 (4)
3.裁剪指南 (4)
4.环境资源 (4)
5.定义和缩写 (5)
6.职责 (5)
7.规范 (6)
7.1用户命名及权限配置 (6)
7.1.1SVN用户命名 (6)
7.1.2访问规约 (6)
7.1.3权限管理 (6)
7.2SVN库的划分 (7)
7.2.1配置库命名约束 (7)
7.2.2Common库 (7)
7.2.3Dev库 (7)
7.2.4Baseline库 (8)
7.3版本控制 (9)
7.3.1文档命名规范 (9)
7.3.2版本命名规范 (9)
7.4配置状态报告 (10)
7.5配置审计 (10)
7.6备份策略 (11)
8.附录 (11)
附录1 开发库目录结构 (11)
附录2 基线库目录结构 (12)
1. 目的
本文档主要目的是规范配置管理活动的过程，以指导配置人员制定合理的《配置管理计划》与进行配置管理活动，阐述了在项目开发的过程中SVN库的组成和使用规约，指导使用者正确地操作SVN库，以保证项目中所产生的代码、文档各版本之间完整性、可追踪性和一致性。

2. 适用范围
该规范适用于公司内部所有项目的配置管理过程。

3. 裁剪指南
项目规模小，或复杂度低，或者因为进度紧等原因，项目计划基线和详细设计基线可以裁剪。

其余基线不可裁剪。

4. 环境资源
引用标准：
Capability Maturity Model Integration，Version 1.2
在整个项目过程或产品生命周期中,选择SVN作为配置管理工具。

5. 定义和缩写
表格 5-1定义和缩写
6. 职责
表格 6-1职责
7. 规范
7.1 用户命名及权限配置
7.1.1SVN用户命名
项目组成员在各自的PC上安装SVN客户端，根据配置管理员所分配的用户和权限登录配置库进行各项配置管理活动。

初始用户命名规则：
用户名：姓+名的第一个字母
密码：123
注：如果需要修改密码，通知配置人员进行修改。

7.1.2访问规约
为了保证各个项目组开发成果的安全性，以项目为单位，进行了精确权限划分，使得成员只能操作该项目组内的配置项。

外网访问svn资源库地址：svn://外网Ip/dev/项目名称
内网访问svn资源库地址：
svn://SVN服务器ip地址/dev/项目名称
7.1.3权限管理
各个项目组成员只能访问、操作所在组的项目，并具有读和写的权限，为防止误删除操作，现将项目组成员删除权限进行控制，当要进行删除时，由项目负责人确认，配置管理员来进行删除操作。

svn库存放了研发部所有项目，为了方便其他项目组成员也能互相浏览、共享资料，现开通一个超级用户，用户名=viewer密码= viewer，此用户可以浏览整个SVN库。

7.2SVN库的划分
结合公司现项目的开发管理特点，为了更好地管理项目过程中产生的文档、源代码以及组织财富，现将SVN库划分为3个库：
通用库（Common）：主要存放可以复用的框架、组件、文档等，以提高软件的质量和生产效率；
开发库(dev)：项目在开发过程中，开发人员的工作空间，存放交付给客户的各个版本文档、发布包、数据库脚本；
基线库（baseline）：各个阶段的最终产物，即必须评审通过，已评审通过的工件发生变更，须走配置变更申请流程。

7.2.1配置库命名约束
开发库、通用库、基线库各个配置项文件的命名根据项目的【配置管理计划】中配置项标识表统一命名。

7.2.2Common库
Common库是公司的组织财富库，主要保存项目可复用的组件资源，以提高代码的复用率和工作效率。

在项目计划、设计阶段，项目负责人搭建项目代码框架，该项目框架第一次提交至Common库中，在开发阶段，配置人员从Common库中构建分支及作为开发库的code配置项，在开发过程中，模块组件是否可复用由项目经理、项目负责人以及组件开发者共同进行评估，如果可以复用由开发人员将组件从开发库中merger到Common库中。

7.2.3Dev库
开发库: 主要是项目周期中开发人员的工作空间。

7.2.3.1管理流程
1)项目立项后，配置管理员根据公司已制定的目录结构和项目特点来获取配置
项，创建配置库，编写【配置管理计划】，配置库目录结构如附录1所示；
2)配置人员按照项目角色给各个配置项分配用户权限；
3)在计划、需求、设计、编码、测试、发布各个阶段达到项目里程碑处，配置人
员建立基线，如果需要修改配置项，通知配置人员做相关修改；
4)配置项有变动或建立基线时，配置管理员维护《配置管理台帐》，并将《配置
状态报告》签发给项目组成员并上报部门领导；
7.2.3.2使用规约
1)提交代码时机：
●代码测试或组织review评审通过，则提交至SVN中；
●如果在开发过程中，第一次开发完成周期比较长，如按照代码必须测试
或评审通过才能提交，这样无形中增加了开发人员保存代码的风险，此
时，代码在编译通过，不影响其它模块正常运行情况下，开发人员可以
将代码提交至SVN，从而减少因为系统崩溃或者本机备份丢失而导致代
码无法追溯；
●新功能点或缺陷修复通过编译、测试或评审后，提交时，在SVN的message
处详细写明提交内容，产生相应版本；当项目测试通过已发布实施，配
置人员建立代码基线，以便后期可以回溯。

2)开发人员在提交代码时，必须输入注释且必须是5个以上有效字符：
●如果提交的是针对bug的代码，必须填写处理结果；
●如果是第一次开发代码review后提交，注释中明确提交内容。

3)如果是迭代版本开发由配置人员建立分支；
4)当项目准备实施时，实施人员将创建数据库脚本、初始化脚本、War包、用户
手册等提交至SVN配置项12 Release下；
5)当实施人员离开现场时，将现场sql脚本、War包备份，存放至SVN配置项
12 Release下，以便进行后续的调试；
6)提交的文件确保是有效的成果，配置人员将不定期对注释、提交规范性进行抽
查，并在项目会议中进行讨论。

7.2.4Baseline库
基线库由配置人员进行管理和维护，当项目达到里程牌时，该阶段的产出工件将由配置人员打入基线库中。

7.2.4.1基线库目录机构
基线库目录结构参照附录2，每个项目的基线都分为计划基线、需求基线、设计基线和发布基线，基线必须能作为下一阶段工作的基础，基线库只有配置管理员有权限读写。

7.2.4.2基线建立流程
项目经理在计划阶段，需求阶段、设计阶段和发布阶段完成后，申请配置人员建立相应的基线，并且更新《配置状态报告》。

7.2.4.3基线申请流程
项目经理需要基线时，提出基线申请，配置管理员把相应的基线提取出来，在开发库中建立分支，以供开发人员使用。

7.3 版本控制
7.3.1文档命名规范
[项目简称] -[文档简称]- <版本号>[可选项]
如：项目简称_PPlan.doc
提交至svn上的工件必须按照《配置管理计划》中已定义的标识进行命名。

7.3.2版本命名规范
为了有效的管理公司产品变更情况，现将产品分为2种版本：正式版本、补丁版本。

正式版本以如下格式编号：[项目简称] - [版本号]
版本号格式如：V_X_Y_Z[后缀].
补丁版本以如下格式编号：V_X_Y_Z_SP_H [后缀].
其中：
1)V：版本标志，V标记主开发分支版本；
2)SP：补丁版本的标志，以主开发分支版本号为前缀；
3)X：主版本号，从1开始流水编号，由项目负责人统一按照开发计划制定。

4)Y：子版本号，从0开始流水编号，当整个项目中任何一个非补丁分支标记版
本时刻子版本号递增。

5)Z：内部版本号，从01开始流水编号。

6)H：补丁号，从01开始流水编号，可选，根据版本补丁的修改情况制定。

7)后缀：后缀表示版本的状态，可选值：a, r。

版本编号采用以下约定：
a)版本编号以版本标志开始。

主分支版本的标志为V，补丁分支版本的标志
为SP。

b)主分支版本编号有主版本号、子版本号、内部版本号。

c)补丁分支的版本编号中，以主分支版本编号为前缀后加补丁标志，补丁分
支版本号升级时，相应地只增加补丁编号。

d)开发完成未经过测试的合并版本以“a”为后缀。

e)后缀为“a”的版本经过测试没有通过，提交开发人员重新进行修改。

f)修改通过，可以作为该项目的正式版本，以后缀r标记，放置源代码版本
发布目录下。

7.4配置状态报告
配置管理员按照《配置管理计划》中拟订的报告计划，向项目经理提交《配置状态报告》，报告当前建立基线的配置项状态，包括已纳入基线的配置项，和将要纳入基线的配置项，以及变更情况。

《配置状态报告》除了在里程碑点发布以外，在重大配置管理活动发生时也要发布，包括基线建立等。

7.5配置审计
对配置管理库状况进行审计，确定配置库中的配置项和建立的基线的正确性和完整性，并且记录审计结果。

审查包含的内容有：
1)评估基线的完整性。

2)检查配置记录是否正确反映了配置项的配置情况。

3)审查配置管理系统中配置项的结构完整性。

4)验证配置管理系统中配置项的完备性和正确性。

5)验证是否符合使用的配置管理标准和规程。

6)对审计后提出的各项行动进行跟踪，直到结束。

7.6备份策略
在项目开发实施过程的各个阶段，配置管理员应定期做好软件配置库的备份，以防造成劳动成果的丢失而给整个项目及公司带来的严重损失。

每周五进行增量备份，月末进行完全备份，如果周五和月末的天数差不大于5那么就不进行增量备份，直接到月末进行完全备份；在每个阶段或里程碑处做完基线工作后应进行备份。

备份文件介质为DVD/CD，确保可靠性。

8. 附录
附录1 开发库目录结构
附录2 基线库目录结构。