四、建立配置管理体系

　　1、管理层次

　　依据配置管理系统功能特性，结合我们实际情况和需要，建立自己的管理体系。以往，我们已经成功地开发了其他大中型软件，但配置管理体系很不完善，一些主要配置项（源代码和程序文档）是靠手工管理，由于人员流动性大，又没有统一的配置管理体系，开发活动不能受到有效的控制，不能形成团队财富的积累。有人对配置管理是什么都不清楚，对配置管理系统的使用在思想上不容易接受，认为使用配置管理系统进行程序版本控制使开发活动受到了限制，给开发增加了工作量。特别是这次超大规模软件系统的开发，时间紧，任务重，如果配置管理系统使用不当影响项目进度或造成源程序丢失，会给开发带来巨大损失，后果不堪设想。

　　为此，从管理层次和系统集成两个方面考虑，选择了降低管理风险方案，首先采用了两层管理层次（图1 二层管理层次图）。

　　2、存储库创建

　　依据两层管理模式，配置管理和版本控制主要在项目级和子项目级配置管理员中使用。从一体化系统的结构来说，尽管该系统庞大，包括许多子系统，但是，最终要集成一个系统，而且管理模式决定了版本控制是在项目开发到一定阶段，形成初步系统模型时纳入版本控制。因此在Firefly服务器上创建一个程序代码库，用来存储初步集成的源代码。使用这样的库结构有利于对配置项的统一管理和控制，同时也能提高编译和发布的效率。
　
　 3、权限设置

　　创建一个代码存储库，是为了便于统一管理，但是如何让开发人员根据任务分工的不同而获得对相应配置项（源代码）的操作许可，而对于其他源代码不能操作。为此，利用Firefly提供的文件级访问权限设置，对不同目录进行用户权限设置，只有对该目录具有读写权限的用户才能对其进行操作，为子系统配置管理员授权一个文件目录，如图２权限设置图中src/ap目录授权给smq用户。

　　图2 权限设置

　　4、分支的划分

　　·　集成分支　　

　　为了系统集成测试需要，创建集成分支，并对该分支进行了不同子项目的权限控制，各子项目必须将开发成果纳入到该分支，凡是对纳入到该分支的配置项进行的任何变更，都必须首先从该分支获得，变更后再上传到该分支。软件的集成测试工作在这一分支中进行。项目级配置管理员拥有对该集成分支的管理和读写权限，子项目级配置管理员只有对指定的目录有读写权限。（图3分支图）

　　·　主干分支

　　主干分支对应的是整个软件开发组织的发布分支。各个子项目在现阶段的任务完成后，将可以发布的版本归并到该分支上，由该分支产生发布版本，对每次的发布基线和相关资料，以该分支上的版本为准。该分支的管理工作由项目级配置管理员负责。（图4分支及标签）　
　
上面定义的2类（分支）由配置管理员统一管理，根据各开发阶段的实际情况定制相应的版本选取规则，来保证开发活动的正常运作。

　　比如，软件已经发布了1.0版本，开发小组在为该软件添加新的功能，正在进行2.0版本的开发。而此时，如果Release 1.0中发现了Bug必须修正，我们就必须从Release 1.0中建立bugfix分支，进行必要的修正后，发布修正版Release 1.1，而这个版本的发布与2.0版本的开发没有直接关系。当2.0版本测试结束后，要与1.0版本中bugfix分支合并，从而发布2.0的版本。在这个并行开发过程中，创建分支和分支的合并起了非常重要的作用。

　　图4 分支及标签

　　·　产品基线

　　当一个开发里程碑结束，或有重大事件发生时，利用配置管理系统提供的标签功能，对集成分支和主干分支进行标记，该标记作为产品基线，可以按标记进行版本发布和再现（图4分支及标签）。

　　·　与分支对应的本地工作区

　　把相关配置项纳入集中的存储库、为不同目的建立了不同分支后，按照初始设定的管理层次，子项目级配置管理员遵照“检出/检入”的工作模式对配置项进行修改，就要为每位子项目级配置管理员设定本地工作区，对所授权的目录进行的任何变更都要在本地工作区进行。

　　·　开发工作区

　　开发人员根据项目要求在自己的私有工作区中对配置项进行修改和测试活动，私有工作区可以是CVS版本控制软件工作空间或其他，自己的修改活动不会受到他人的影响，也不会影响到其他开发人员，修改和测试后的配置项提交给子系统配置管理员，由子项目级配置管理员上传到集成分支。