01配置管理过程指南

1 综述
1.1 前言
本指南的编写，是为了指导软件开发团队对软件过程中的程序、文档等配置项进行明确的、量化的管理。软件配置管理贯穿于软件开发活动的始终，覆盖了开发活动的各个环节，它的重要作用之一就是要全面的管理保存各个配置项，监控各配置项的状态，并向项目经理及相关的人员报告，从而实现对软件过程的控制。

1.2 设备
l Dell 1600sc server

1.3 工具
配置管理工具的使用方法请查阅相关工具的文档。

1.4 角色
项目经理：整个项目研发活动的负责人。

开发人员：负责软件的设计、代码实现。

配置管理员：配置管理计划的执行人。

系统集成员：生成和管理项目的内部和外部发布版本。

测试人员：设计、执行测试和评估测试结果。

1.5 活动

2 过程描述
2.1 配置管理计划
配置管理员根据项目计划和项目需求在项目立项后制定配置管理计划。

配置管理计划的制定请参考《软件配置管理计划模板》。

2.2 VSS配置库管理
2.2.1 结构
配置管理员根据立项的申请和配置管理计划，在配置服务器上建立基本的配置库。

对于产品更新项目仍然使用原项目的配置库。

对于新项目则由配置管理员建立新配置库。

项目配置库在配置服务器上的目录结构如下图所示：

项目配置库采用分支管理，基本的分支结构如下图所示：

项目：由项目经理保存项目过程中产生的各类不可发布的非程序源代码资料，比如项目计划、任务分配、跟踪报告、工作周报、设计、需求文档等，可发布给用户的资料放在其它分支中。项目分支的基本结构如下图所示：

私有分支：项目成员在私有分支上工作，他的所有工作成果体现为在该配置项的私有分支上的版本的推进。个人工作成果完成后提交到公共分支。私有分支的基本结构如下图所示：

公共分支：项目人员将自己的开发成果从私有分支合并到公共分支上，提供给系统集成人员使用。公共分支的基本结构如下图所示：

集成分支：系统集成人员从公共分支取出源代码，集成编译通过后，将公共分支上的源代码合并到集成分支上，集成分支的基本结构如下图所示：

测试包：集成人员从集成分支取出源代码，集成编译后，将编译后的测试包放在测试包分支上，供测试人员使用。测试包分支的基本结构如下图所示：

发布包：集成人员从主干分支取出源代码，集成编译后，将编译后的发布包放在发布包分支上，保存各类发布编译后的发布文件。发布包分支基本结构如下图所示：

2.2.2 权限
配置管理员根据立项的申请和配置管理计划为项目组成员分配权限，项目过程中，配置管理员可以为项目组成员需要临时分配相应目录的读写权限。基本的权限分配如下表所示：

2.3 CVS配置库管理
2.3.1 结构
项目配置库采用一个项目对应一个仓库的形式存放在配置服务器上，目录结构如下图所示：

项目配置库的模块如下图所示：

CVSROOT：项目配置库的管理文件放在此模块中

release：项目的发布包放在此模块中

bate：项目的测试包放在此模块中

source：项目的源代码放在此模块中

项目一般分为如下几个分支：

HEAD：当前工作分支，开发人员在此分支工作

public：公共分支，开发人员将开发成果提交到此分支

integration：集成分支，集成人员在此分支集成项目

2.3.2 权限
配置库的权限采用将同样性质的用户归入一个组，然后用给用户赋权限的方式给组赋权限的方式，这样，一个组的用户就会具有同样的权限。

基本的模块权限分配如下表所示：

基本的分支权限分配如下表所示：

2.4 版本管理
配置管理员负责根据配置工具制定配置项的版本规则。

版本号规则是：Major.Minor.Build

Major：项目主版本号；

Minor：对项目主版本的更新；

Build：开发过程中集成后的版本，提供测试使用。

版本变更规则：开发人员从主干分支取出源代码到私有分支的个人分支上开发，私有分支的版本号由开发人员自己制定。集成人员提交编译通过的代码到集成分支后，根据版本规则对集成分支标记版本。版本变更如下图所示：

版本签入、签出标准：

签入集成分支前必须编译通过，避免其他人更新时无法编译的错误。

签出必须更新本地版本，避免在旧版本上开发的问题。

2.5 基线管理
配置管理员根据项目的特点，在项目的生命周期中的不同时间点处建立基线。

基线一般分为如下：

功能基线：功能基线是指在系统分析与软件定义阶段结束时，经过正式评审和批准的系统设计规格说明书中对待开发系统的规格说明；或是指经过项目委托单位和项目承办单位双方签字同意的协议书或合同中所规定的对待开发软件系统的规格说明；或是由下级申请经上级同意或直接由上级下达的项目任务书中所规定的对待开发软件系统的规格说明。功能基线是最初批准的功能配置标识。

指派基线：派基线是指在软件需求分析阶段结束时，经过正式评审和批准的软件需求的规格说明。指派基线是最初批准的指派配置标识。

产品基线：产品基线是指在软件组装与系统测试阶段结束时，经过正式评审的批准的有关所开发的软件产品的全部配置项的规格说明。产品基线是最初批准的产品配置标识。

除了以上几种基线，也可以在不同阶段中的各次迭代结束时生成基线，甚至可以更为频繁。

2.6 配置标识
配置管理员负责制定配置项的命令规则、编号规则。

文档标识规则：项目简称+文档类型

项目简称：开发项目的简称

文档类型：开发不同阶段的文档类型名称

文档标识如下图所示：

JAVA目录标识规则：

请参考《JAVA开发规范》。

JAVA包标识规则：

请参考《JAVA开发规范》。

C#目录标识规则：

请参考《C#开发规范》。

2.7 配置审查
配置管理员根据配置管理计划定期审查配置项，提交配置状态报告。

配置检查文档请参考《配置审查报告》、《配置状态报告》。

2.8 变更控制
配置管理员根据项目配置项评审的结果，将配置项提升到新的基线或提交主干分支并确定新的基线。

配置管理员根据批准后的项目变更申请，从主干分支提取配置项到私有分支，并检查开发过程中的版本变更，直至配置项评审后提交主干分支，完成基线变更。

变更管理文档请参考《变更申请单》。

2.9 系统集成
系统集成员根据配置管理计划定期执行从源代码到映像文件自动集成的命令行编译脚本，采用命令行方式从集成分支或主干分支提取源代码，自动编译后提交测试版本或发布版本。

系统集成工具的使用请参考知识库中的相关文档。

2.10 版本发布
系统集成员负责生成和管理项目的发布包。

版本发布管理文档请参考《软件发布说明模板》、《软件提取记录》、《质量保证书》。

2.11 配置审核
配置管理员根据基线状态报告对基线进行审核，保证基线化软件工作产品的完整性和一致性。

配置审核文档请参考《配置审核报告》、《基线状态报告》。

2.12 配置库整理和备份
配置服务器要采取磁盘镜像防止意外的硬件故障导致数据丢失。

配置管理员要定期对项目的配置库做整理、完全备份和增量备份，以减小意外情况所造成的损失。

配置库的备份工具的使用方法请参考配置工具的随机帮助文档。

配置库的备份文件存放在文件服务器上的目录结构如下图所示：

一般备份策略：

每周一次的数据全备，至少保存4周以上的全备份数据。