sourcegear

工程型软件项目的配置管理实例

前言

软件配置管理作为贯穿软件开发过程始终的一项工作，其重要性不言而喻。51cmm上已有众多关于配置

管理介绍、配置管理计划、配置管理工作开展心得一类的文章，这些文章从概念和实施上介绍了配置管理

工作的内容，但美中不足的是仍嫌抽象，那些想要依葫芦画瓢的兄弟姐妹们在试图将这些理论应用到自己

项目的配置管理中的时候，会发现仍然是无从下手（我也曾是这些感觉无从下手的人中的一个）。因此，本

文拟从另外一个角度，以本人最近实际操作的一个项目的配置管理工作谈起，从配置管理工具的选择、配

置管理流程制定、配置管理库结构的确定，以及作为配置管理工作的推动者如何推动这项工作等方面仔细

描述一下本人的做法，希望这几篇文章能给那些水深火热中的兄弟姐妹们一点帮助。

这里有两点需要特别说明：

1、本文描述的内容是以一个项目的配置管理为主线，对组织级的配置管理和配置管理策略没有进行详细

讨论；

2、本文用来做示例的项目是一个―工程型‖的项目，所谓的―工程型‖是和―产品型‖对应的，这样的项目需

要公司的开发人员和现场的开发人员进行协作开发，一般而言，在公司的开发人员完成大部分的功能，现

场的开发人员根据用户需求，对软件进行修改（这部分的工作量一般会较大，在一个16人年的项目中，这

部分的工作可能会占到三分之一以上的工作量）。

配置管理工作概述

配置管理工作的工作范围，在51cmm的很多文章中都有描述，具体可以参考河清专栏的《基于CMM和

CMMI的配置管理》和陈越的《软件配置管理实施体会》。在这里不作详细的描述。

本文涉及的项目背景

本文用来示例的项目是某省电信的一个项目，该项目的工作量大约是16人年，项目周期约为1年。大部

分（90%以上）的开发工作在前8个月内完成，后期的工作主要由维护人员进行系统维护和调整。在8个

月的开发时间中，前5个月由开发人员在公司进行开发，根据用户的需求完成设计，确定系统架构并实现

整个框架，部分明确的功能以及公用模块也在这段时间内完成；后3个月的时间部分开发人员在现场，部

分开发人员在公司共同完成后期的开发工作。

整个项目采用的开发语言是C++、Java、ASP，涉及的平台包括Solaris和Windows，采用的开发工具包括

VisualStudio和Solaris上的CC。此外，整个项目还使用了一些第三方的平台，如IBM的MQ等。

除用户需求之外，公司还对项目组提出了代码复用方面的要求，开发人员在开发过程中必须注意代码的可

重用性。

配置管理前期准备工作

在项目正式启动之后，配置管理工作就可以开始了。配置管理工作开始的第一步就是一份配置管理计划。

51cmm上已有不少配置管理计划的模板，大家可以参考。

一般而言，需要在配置管理计划中明确的内容包括：

1、配置管理软硬件资源；

2、配置库结构；

3、人员、角色以及配置管理规范；

4、基线计划；

5、配置库备份计划；

在下文中，我们将围绕这些内容进行详细描述。

配置管理环境

配置管理环境包括软硬件环境。具体的资源需求应该根据项目实际情况来确定，一般需要考虑的包括：网

络环境、配置管理服务器的处理能力、空间需求，配置管理软件的选择等。配置管理环境的确定需要综合

考虑各个方面的因素，包括我们采用的开发工具，开发方式，开发人员对配置管理工具的熟悉程度等，其

中，开发人员对配置管理工具的认可和熟悉程度常常直接决定配置管理能否正常进行，如果选择了需要开

发人员花费比较大的精力去熟悉的配置管理软件，我们就必须花费大量时间来进行培训；同时，配置管理

软件和开发工具的集成程度也是一个必须考虑的因素，根据我们的经验，选择一个和开发环境集成紧密的

配置管理工具至少可以减少20%花费在CheckIn/CheckOut和配置管理人员保持配置库完整上的工作量。

根据我们项目的实际情况，我们有如下一些考虑：

根据历史经验，一个类似项目的配置库大小约为3G，考虑到备份等操作对空间的需求，至少应该为配置

管理库保留10G以上的空间。为了保证配置管理库的安全，除了相应的备份计划之外，还可以采用了RAID

0＋1的方式为配置数据库提供更好的可用性保证；

考虑到在项目的后期有部分开发人员会在现场进行开发，因此在网络条件上需要提供对远程访问方式的

支持；

配置管理服务器的选择和配置管理软件的选择相关，考虑到目前公司有一台闲置的PC服务器，最好能充

分利用这台服务器；

配置管理软件必须可以以某种方式支持远程访问，而且由于我们的开发平台涉及Solaris和Windows，配

置管理软件要能够支持这两种平台；考虑到开发工具方面，配置管理工具要求能和我们选择的开发工具进

行很好的集成；

项目组的开发人员缺乏使用配置管理工具的经验，有将约30%的开发人员使用过VSS配置管理工具，但

仅限于最基础的使用，对VSS的Label等功能没有概念；结合以上的情况，我们首先考虑配置工具的选择。

配置管理工具的选择

从开发人员具有的配置管理工具使用经验和配置管理工具使用的难易度方面来说，VSS是最好的选择，在

现有的基础上只需要对开发人员进行简单培训；考虑到和开发工具的集成，VSS也是一个不错的选择。不

过本项目还要求对远程接入方式的支持，以及对Solaris平台的支持，VSS肯定是不能满足要求的（VSS通

过VPN方式应该是可以实现对远程访问的支持，但VSS的完全共享方式实在是不敢在Internet上使用）。

除VSS外，可以选择的配置管理工具还有CCCHarvest、ClearCase、CVS等，但Harvest和ClearCase使

用起来比较复杂，需要一个专门的配置库管理员负责技术支持，还需要对开发人员进行较多的培训，另外，

Harvest和ClearCase价格不菲；CVS在Unix下使用方便，而且是免费的，但其文本方式的操作界面对于

习惯在Windows平台上开发的开发人员来说使用非常不习惯（CVS也有windows下的GUI版本，但经过

我们的试用，在操作习惯上和我们目前开发人员习惯的方式很不相同，较难被接受）。

经过在MSDN和Internet上查找，终于找到了一个VSS的增强软件SOS（SourceOffsite），它基于VSS的

数据库，可以支持通过TCP/IP方式访问和操作VSS库，在Windows、Slolaris和Linux上都提供了客户端，

并且通过传输数据的压缩和加密方式，使得文件操作的速度大大加快并增强了系统的安全性。SOS可以在

SourceGear的网站上找到详细介绍和试用的下载（/sos）。事实证明，VSS＋SOS

的组合在我们的整个项目过程中起到了关键的支持作用。我们使用的SOS是3.53的Standard版本，本文也

将以该版本为例在下一部分中说明具体的操作和使用步骤。

软硬件环境的选择

确定了配置管理工具后，我们使用公司购置的一台CompaqPCServer作为配置管理的硬件环境，该服务

器配置如下：

CPU：1CPU，P42.0G

内存：512MDDR

硬盘空间：30G×4

网卡：HPGbit网卡一张

最终确定的方案是安装该服务器安装Windows2000Server操作系统，为了保证配置数据的安全性，我们

采用RAID0＋1方式，总的可用空间在50G左右；另外为了备份的需要，还为服务器配置了一个CDR刻

录机。

网络环境的选择

公司已有现成的100M局域网，通过一个交换机和路由器连接至Internet，有一个公网的静态IP；配置管

理服务器是内网的一台机器，具有一个内网IP。为了满足远程访问的需要，我们通过在路由器上设置端口

映射，将SOS需要使用的端口映射到配置管理服务器上（缺省情况下，SOS使用8888和8890两个端口）。

网络拓扑图如下：

在公司的开发人员通过局域网使用VSS访问和操作配置库，在现场的开发人员通过Internet接入对配置库

进行访问和操作。

配置库维护和备份计划

配置库的维护的备份需要专职的配置库管理员来负责。在整个项目中我们采用的配置库维护策略是根据

Microsoft的BestPractice白皮书建议，包括以下要点：

1、保持配置数据库的大小不超过5G；Microsoft建议，配置库的大小在3－5G比较合适，太大的数据库

会极大影响VSS的效率；减小配置库大小的

2、每周进行VSS数据库的分析（Analysis），发现问题及时修正；VSS提供了Analysis和Fix工具，由

于不合理的Delete等操作，VSS数据库有可能会出现一些InterruptData之类的问题，通过定期的每周的分

析工作，可以极大减少数据库出现问题的风险；

3、每日进行配置库的增量备份，每周进行数据库的完全备份；VSS库的备份可以通过VSS自己的Archive

功能或者是操作系统的Backup程序来进行。VSS的Archive功能对VSS中的文件数据进行压缩并保留VSS

的所有状态，但只能对VSS库进行完全备份，不能实现增量备份功能。Windows2000Server提供的Backup

实用程序可以对文件进行备份，由于VSS库就是以文件形势存在的，因此针对VSS的data目录进行备份

也可以完全达到备份的目的，使用系统备份工具的好处是可以实现增量备份。我们在实际中使用的系统的

备份工具，每周五生成的完全备份采用刻录光盘的方式保存，每天的增量备份数据存放在文件服务器上进

行备份。

【小结】在本章中，我们描述了工程型项目配置管理的一些概念，着重介绍了配置管理的环境，包括配置

管理工具的选择等。在配置工具选择方面，我们采用VSS＋SOS的组合方案，第二章中，我们将重点介绍

VSS和SOS工具的使用，并在介绍配置管理规范中结合配置管理工具讲解具体的操作。

说起VSS，接触过的人应该不少。尤其是用用VC和VB做开发的人，绝大多数人应该都接触过和使用过

VSS。VSS小巧精干，和VS开发工具集成极为紧密，就算不使用专门的配置服务器，直接在自己的开发

用机上安装一个VSS，也能在代码管理方面方便不少。SOS在上一章中已经做了介绍，这一章将详细介绍

之。

VSS概念

也许正因为VSS简单易用，在大多数人眼里，VSS似乎都只是一个玩具，难登大雅之堂，最多能管管自

己的代码，要用团队开发中，那似乎是不可能的。刚接触VSS时，我也是抱着差不多的想法，觉得要用

VSS作为一个较大的项目的配置管理工具完全不可能，但随着对VSS研究的深入，加上在工作中也使用了

其它一些配置管理工具，如CVS、ClearCase、CCCharvest等工具，反过来比较，反而觉得VSS有它独到

的地方。关于VSS和其他配置工具的比较，在google上搜索的话应该能找到一大堆，我这里给出几个对我

来说印象最深刻的VSS的优势：

1、VSS操作使用简单；要在配置管理工具中评选―最平易近人奖‖，那一定非VSS莫属。VSS中包含了

配置管理需要的全部操作，但应用起来却非常简单，首先是全部操作都可以通过GUI完成，如CheckIn/Check

Out操作、GetLatest等基本操作；Label、Share、Branch、Merge等高级操作；其次是VSS和开发环境集

成紧密，在开发环境的IDE中就可以方便地完成操作；

2、VSS对硬件配置要求不高；作为一个工作组级别的配置管理工具，在我们的项目中，安装VSS的配

置服务器是一台P42.2G/512MRAM/30G×4Disk的HPPC服务器，这样的条件下VSS运行已经足够稳定

和快速，相比起CC和CCCharvest的要求，这部分的投资是很小的；如果再考虑到CC和CCC都运行在

Unix平台上需要的维护费用，当然是VSS更加划算了；

3、VSS几乎是免费的；只要购买了VS开发工具，就能免费使用VSS；

4、VSS备份/恢复非常简单；只需要通过拷贝——覆盖就能完成VSS的备份/恢复工作，你说简不简单？：）

5、有良好的可扩展性；通过VSS的自动化接口（Automation），可以自己写程序来完成对VSS库的访问，

也正是基于这点，目前市面上已有一些VSS的扩展工具出现，我们在本章要讲的就是其中之一

——Sourcegear的SOS。

说了这么多优点，当然不是说VSS就只有优点，和其他的配置管理软件比起来，VSS也有一些不足之处：

主要表现在以下几点：

1、缺乏对Unix的支持（没有Unix上的客户端或者服务器，这是微软的一贯作风）；

2、不支持远程访问方式（只能通过第三方的扩展工具实现）；

3、支持的配置数据库大小建议不超过5G，因此需要良好地规划备份等工作；

关于VSS的操作和应用，建议在网上找找VSS的教程，写得比较详细的有不少，都可以参考。在

/CasePanel/CM/有详细的《版本管理器VisualSourceSafe6.0实用指南》，在这里我只是非常概

括地介绍一些VSS的基本概念：

Project：VSS中类似于文件夹的概念，一个Project可以包含多个File，同时Project也是VSS中权限分配

的最小单位，一个Project下可以包括其他Project；

File：VSS中的最小管理单位，VSS中的每个File对象对应操作系统上的一个文件，多个File可以属于一

个Project；

WorkingFolder：和VSS的Project对应的本地文件夹。WorkingFolder是Get到的Project和File的存放目

录，同时也是执行CheckIn/CheckOut操作时的缓存文件夹；

Get(Latest)：Get操作可以获取指定的Project和File的某个版本，常用操作是GetLatest操作，获取Project

和File的最新版本；

Version：对VSS来说，一次CheckIn操作就为被CheckIn的Project或者File增加了一个版本（在文件没

有修改的情况下，CheckIn操作不生成新的版本）。VSS中的File版本从1开始编号，每次新版本在原有版

本上加1；Project的版本没有编号；

Label：Label是配置管理中常用的一个操作，Label可以作为配置项某个状态的标识；

Share：Share可以用于协作开发的模式，通过Share，可以在两个或多个不同的Project之间共享下层的Project

或是File，对其中一个位置的File进行的修改会反映到其他位置的File（类似于Unix的ln的方式）；

Branch/Merge：Branch和Merge可以用于并行开发的过程。

SOS（SourceOffSite）软件介绍

接下来，我们重点介绍SOS软件，包括软件的安装、配置和使用。

SOS软件的安装

SOS软件分为服务端和客户端两个部分，客户端运行在配置管理服务器上，客户端运行在需要访问配置库

的客户机上。以下以SOS3.5.3标准版的SOS为例，说明该软件的安装、配置和使用。

服务端的安装和设置

SOS可以从Sourcegear的网站上下载试用，免费版本可以试用30天，允许10个用户，目前最新版本是

4.0。不过为了解决SOS中的中文问题，建议大家从华军软件园中找到中文SOS进行安装（所谓的中文SOS

是国内的高手修改了SOS3.53程序使其支持中文）。

上图是中文SOS安装时的安装界面，选择安装目录等，一路Next，很容易就安装完成了。安装完成后，

系统在―开始‖菜单中生成了中文SOS的相关菜单项目。

下图是安装完成中文SOS之后生成的菜单：

安装完成后，需要对SOS进行设置。选择中文SOS菜单的―服务器管理‖进入设置界面：

―SystemInfo‖页面显示的是SOS的概要信息；

―GeneralSetting‖页包含了重要的设置信息，选中―useunsecureport‖表示允许使用非加密模式进行数据传

输，端口号在后面的编辑框中设置；选中―usesecureport‖表示允许使用加密模式进行数据传输，端口号在

后面的编辑框设置。―Version2.0Compatibility‖用来选择加密模式，一般选择128bit模式即可。在―Logging‖

选项中，选择日志的记录方式；最后的―IdleConnections‖，如果选中的话，在指定时间内没有数据传输的

话，连接就会自动断开。

―SerialNumber‖页面用来管理SOS的license。通过Add…按钮可以增加新的SerialNumber。SOS中可以

添加多个SerialNumber。

―Databases‖页面用来添加SOS管理的VSS数据库。点击Add…按钮可以添加数据库，添加对话框的上一

个框填入VSS库的ini文件所在路径，下一个是数据库的别名，可以任意设置。SOS可以同时管理多个数

据库。

―Users‖页面输入SOS中有效的用户和使用规则，注意，这里的用户和VSS的用户没有关系，VSS用户和

SOS用户的关联在下面的―UserKeys‖页面中设置。要说明的是规则的描述：―Users‖中的一行对应一个规则，

每行的开头是规则的编号，第二个字段是用户名，第三个字段是允许访问的网络段，第四个字段（取值为

0、1、2）是控制访问允许以及访问是否使用加密方式的描述（0表示部允许访问；1表示要求加密访问；2

表示允许使用加密或者不加密方式访问）。

例如，对第一行―0000admin192.168.3.0/241‖表示这是第一个规则，规则内容是允许admin用户在

192.168.3.0/24的网段上访问SOS服务器。最后的1表示要求使用加密方式访问。

这里要说明的是―用户‖的概念。SOS没有自己的用户概念，SOS中的用户通过用户名称和VSS中的用户

一一对应。

―UserKeys‖页面用来生成客户端访问控制的Key文件：

使用―AddKey…‖按钮可以弹出―AddUserKey‖的对话框。该对话框的第一个输入框要求输入要增加的用

户在VSS中对应的用户名；第二个输入框要求输入SOS服务器的IP地址，例如―202.100.68.88‖，在局域

网中可以设置为―192.168.1.1‖；（注意，如果配置管理服务器同时具有局域网和广域网的IP地址，并且用户

需要从局域网和广域网都可以访问SOS，则对同一个用户需要两个不同的Key文件。在我们的实际工作中，

我们只使用SOS进行Internet上的访问，在局域网内还是使用VSS，因此没有这个问题）。下面的Expiration

要求输入用户的过期有效时间期限，选择―KeyNeverExpired‖允许用户永不过期。

输入完相应信息后，点击―OK‖确认生成用户Key文件。生成的用户Key文件保存在SOS安装目录下，文

件名为[用户名].iky，注意保留此文件，SOS客户端在启动时需要首先导入一个key文件。

―WebProject‖页面用于设置WebProject的发布路径：

在第一个编辑框中填入该工程在VSS中的路径，例如―$/WebProject1/test‖，在下面的编辑框中输入发布的

路径，例如―d:temp‖。发布路径也可以是在其他机器上的网络路径。

―Debug‖页面是两个调试级别的选项：

这两个选项的具体含义在SOS的Manual中也没有明确提到，我们在实际运用中也没有发现该选项的具体

作用，建议不选取。

―ExcludedFileTypes‖页面设置不允许添加到VSS库中的文件类型：

添加的条目是文件后缀，具有在列表中的后缀的文件都不能被添加到VSS库中。

―PinSupport‖页面用于设置是否允许PIN操作：

如果允许―PIN‖操作，还需要指定文件所在的目录。

设置完成后，需要重新启动SOS服务端，具体方法是在―服务‖中启动相应服务：启动服务完成后，服务

端的安装设置就已经完成了，接下来我们介绍SOS客户端的安装和使用。

SOS客户端的安装和使用

SOS的客户端分为Windows版本、Solaris版本和Linux版本。Windows版本的安装非常简单，直接执行

安装程序就可以顺利安装。Solaris版本的SOS客户端以tar形式发布，首先在Solaris上安装GTK和GLIB，

然后展开安装程序到任意目录即可。对Linux版本的SOS客户端，也需要首先安装GTK和GLIB，然后展

开相应tar包到任意目录即可。

Solaris、Linux和Windows版本的SOS客户端运行界面都非常类似，下面以Windows版本为例说明其使

用。

第一次运行SOS客户端时，系统会弹出一个对话框要求输入服务器和端口号。这时用―Cancel‖按钮取消，

选择菜单项的―Tools‖——―ImportEncryptionKey…‖，导入服务端生成的Key文件：

导入完成后，选择菜单项的―File‖——―ConnecttoServer…‖，输入服务器IP地址和端口，如果连接成功，

系统会给出可以连接的数据库列表，可以从列表中选择合适的数据库进行连接访问。

连接成功后，显示的主界面和VSS的基本一致，SOS的操作方式和VSS的也一样，具体可以参见VSS

的文档。

下图是SOS的主界面：

当然，SOS在操作上也有一些和VSS不同的地方，下面列出这些不同点：

1、缺省设置下，SOS中每次登录不会主动刷新工程树和文件列表，需要用工具条上的刷新按钮进行刷新；

2、SOS的―Search‖功能较VSS弱，只能查找CheckOut的文件；

3、SOS的Option设置项目很多，大部分都是SOS增加的为适应远程连接的设置项：

【小结】本章介绍了VSS、SOS的使用，重点是SOS的安装和使用方法。SOS在使用上其实还有很多小

技巧，在此不能一一列举，在sourcegear的网站上都能找到相关的资料。在下一章中，我们将结合配置管

理工具介绍配置管理规范的内容。

配置管理规范

对于一个一般的项目来说，配置管理规范的内容至少需要包括以下的内容：

1、配置项及其命名规则；

2、配置库文件目录结构；

3、角色和权限定义；

4、配置项变更流程；

5、配置项发布；

6、基线定义和基线变更。

配置项及其命名规则

对我们的项目来说，配置项需要包括以下的内容：

1、项目管理过程文档；

a)项目任务书；

b)项目计划；

c)项目周报；

d)个人日报和周报；

e)项目会议纪要；

f)培训记录和培训文档；

2、QA过程文档；

a)QA不符合报告；

b)QA周报；

c)评审记录；

3、工作产品

a)需求文档；

b)设计文档；

c)代码；

d)测试文档；

e)软件说明书和手册；

4、项目中使用的第三方产品

上文中用红色部分标识的是容易遗漏的配置项，尤其是第4个（项目中使用的第三方产品），实际上，一

个工程型的项目会大量使用第三方的软件（例如，我们的产品中就使用了IBM的MQSeries、Oracle、一些

第三方的开发控件），对这些产品的管理至少可以解决三个方面的问题：

1、版本配合的问题：大部分的第三方软件在升级之后，并不能实现二进制层面上的兼容，需要对原有的

代码重新编译；甚至有的第三方软件在升级之后，API层面上的兼容性都做不到；因此，在工程实施的过

程中，版本的配合问题是一个需要关注的问题；

2、发布的完整性问题：一般来说，比较大型的第三方软件在发布过程中都不会有遗漏，但对一些小的第

三方软件来说，比如我们使用的许多perl的CPan模块，如果在开发过程中没有有意识的进行管理的话，

很容易就会发生遗漏；

3、在某些特殊条件下由于第三方软件的变化引起的基线变更：这种情况极少会发生，但在我们以前的项

目中，确实还遇见过。一般是因为原来选型时使用的第三方软件不能满足要求，只能通过更换新的第三方

软件，这就补课避免地需要变更基线（例如需求文档、设计文档等）；将第三方软件纳入配置管理的范畴

可以更方便地管理基线的变更。

关于第三方软件产品配置项的管理还有一点需要说明：由于第三方软件有可能会比较大，而且相对我们的

项目来说，是很少会发生变更的（一般在一个项目过程中，不会采用不同的配置项的命名可以便于查找相

关配置项。配置项的命名包括两个方面的内容：

1、配置项标识：在我们的项目中，一般使用―项目名_配置类别_配置项特殊标识‖来命名。下表列出了我

们在项目中使用的配置类别命名：

配置类别命名配置类别命名

项目任务书PT项目计划PP

项目周报PR个人日报和周报PER

项目会议纪要PM培训记录和培训文档TR

QA不符合报告QAPQA周报QAR

评审记录RR需求文档REQ

设计文档DD代码CODE

测试文档TD软件说明书和手册MAN

项目中使用的第三方产品PART3

配置项命名中的―配置项特殊标识‖根据配置类别的不同而不同。比如，对―设计文档‖，如果细分的话，可

以分为―概要设计‖和―详细设计‖；对―代码‖，可以按照模块来命名配置项。

2、配置项版本命名：配置项版本命名是针对配置项的版本进行命名，在我们的项目中，配置项版本通过

对Project的Label操作来实现，配置项版本的命名需要能清楚标识配置项的状态。一般说来，配置库至少

包括个人工作区、受控库、发布区三个部分，在我们的项目中，所有的配置项都保存在一个VSS库中，对

这三个部分的划分是通过逻辑划分方式进行的，具体来说，就是通过配置项版本命名来划分的。因此，我

们配置项的版本命名规定如下：

a)基线版本：按照基线的状态，我们这个项目中的基线有两个方面：一是作为里程碑的基线；另一个是

模块的阶段性成果基线（对工作产品而言），由模块的负责人确定。

里程碑基线――对我们的项目来说，采用的是迭代的开发过程，以一个迭代过程为例，分为需求、概要

设计、详细设计、代码实现、单元测试、集成测试、系统测试七个阶段，每个阶段都需要产生里程碑。对

每个里程碑都有明确的标识标明当前状态。

阶段性成果基线――阶段性成果主要体现在代码过程中，比如代码进行到一个阶段，开发组长认为代码

的这个状态可以保留，就可以确定为一个代码基线。这种基线一般不需要通过评审等正式手段来确定，但

也必须有相应的验证手段；比如在我们的项目中，在代码阶段，确定代码基线的责任人是开发组长，但开

发组长必须保证代码基线符合一定的条件。

b)其他版本：除基线版本外，有时候还需要在开发和维护过程中确定其他版本。例如，产品在测试过程

中不断的问题修复过程中，可能会有多种反复，此时需要将每次修改的内容作为一个版本。

关于版本，还有另一个需要注意的问题。一般来说，按照模块来划分，每个模块有自己的版本演进比较合

理。首先，一个模块一般是由一个或两个开发人员完成的；其次，一个模块的功能会比较单一且独立，在

版本的演化过程中便于控制，也不会和其他模块产生过于复杂的关系。而产品的版本则需要由各个模块的

不同版本组成，这个纵横的关系需要很好地管理，我们的做法是在VSS库上用Label来标识，同时维护一

张描述产品版本和模块版本关系的矩阵图便于追踪。

配置库目录结构

在确定了配置项之后，就可以确定配置库的目录结构了。配置库的目录结构直接关系到配置管理的工作量

和使用的方便性，所以需要根据自己的需要确定一个合理的结构。

在确定配置管理库目录结构的时候，我们曾经考虑过两种产品目录结构的方式：一种是按照模块划分，在

模块下再划分诸如设计文档、代码等目录；另一种方式是按照产品类型划分，例如首先是文档、代码，然

后在其下按照模块划分。这两种方式都有自己的优点，最终我们还是选择了前一种划分方式，一方面是考

虑便于进行权限的分配，另一方面是考虑到便于将同一模块的所有内容组织起来进行版本的管理。

下表是我们在实际中采用的配置库结构（部分）：

第一级第二级第三级第四级说明

M管理类文档

PM项目管理

0－Init初始阶段

PC

PTR

PN

1－Plan计划阶段

…………………………

QA

0－PPQAP质量保证计划

…………………………

P项目产品

0－Req需求阶段

0－CRS客户需求

1－SRS需求分析文档

2－RTM需求跟踪矩阵

1－Des设计阶段

0－HLD概要设计

1－DBD数据库设计

2－Imp实现/编码阶段

0－Module1模块1

0－COD代码

1－DDS详细设计

2－HLD概要设计

3－UNT单元测试

…………………………

3－Test

0－Int集成测试

1－Syt系统测试

…………………………

4－Man手册

…………………………

5－Others其他

…………………………

从这里的配置库结构中可以看到，我们在最上层将配置项分为管理类和产品类：管理类中的项目管理部分

基本是按照初始－计划－执行－收尾四个阶段来划分。在项目产品类别中，我们按照需求－设计－实现－

测试四个阶段划分目录，在实现阶段，为每个模块划分了代码、详细设计、概要设计和单元测试四个目录，

需要说明的是，在第三层中有一个HLD的目录，在模块下同样有一个HLD的目录，在我们的实际工作中，

第三层的HLD目录用来存放系统级别的概要设计文档，而模块下的HLD目录用来存放模块级别的概要设

计文档。

当然，这里的配置库结构仅仅起到了示范作用，在实际使用中，可以根据自己的需要修改。例如，在Module

的级别上可以增加一个SubSystem的层，便于在产品集成时更加方便。

角色定义及权限分配

角色是配置管理流程的执行者和参与者，定义明确的角色有利于实现明确的授权和明晰的流程，虽然在实

际中可能多个角色由一个人担任，但还是应该保留角色的定义。

下面是该项目中我们的角色定义：

配置管理员

整个配置管理库由配置管理员管理。配置管理员负责分配和修改其他成员的权限，要维护所有目录和配置

项。

开发经理

开发经理在本项目中负责主导完成需求分析和系统总体设计，对项目的总体进度负责。开发经理拥有对管

理类文档的读取权限，可以对项目类文档进行读写操作；

开发组长

开发组长对本小组的工作负有组织和管理任务，同时开发组长也需要承担一定的开发任务。开发组长对管

理类文档有读取权限，对本组负责的模块有读取权限，对自己负责的模块有读写的权限；

开发工程师

开发工程师完成具体的开发任务，对自己负责的模块目录有读写权限，对管理类文档有读取权限；

测试组长

测试组长负责组织测试，给出测试计划和测试方案，并核定测试报告。测试组长对所有目录都有读取权限，

对测试目录有读写权限；

测试工程师

测试工程师负责完成测试工作，包括测试用例开发和测试执行，测试报告编写。测试工程师对自己负责的

模块有读取权限，对测试用例目录有读写权限。

QA工程师

QA工程师拥有对所有目录的读取权限，拥有对QA类文档目录的读写权限。

〔说明〕除配置管理员外，其他所有成员都没有Destroy目录和文件的权限，这是为了防止误删除操作带

来不可挽回的损失。如果需要对目录进行Destroy操作，必须由配置管理员进行。

【小结】在本章中，我们介绍了配置管理规范的配置项及其命名、配置库的目录结构以及配置管理的角色

权限分配。在下一章中，我们将介绍完配置管理规范的其他内容并给出配置管理实施过程中的一些心得体

会。

配置项变更流程

我们所说的配置项变更流程主要是针对配置项发生变化的控制，在我们的项目中分为两个部分，首先是对

配置项新建、检入（CheckIn）和检出（CheckOut）的规定；其次是对入库的文件类型和大小的规定：

新建、检入、检出及破坏

1、新建：即Add，除特殊情况外，一般不规定由谁来新建（只要有权限即可），但尽量指定每个project

只有一人负责新建。

2、检入：即checkin，检入频率规定如下：

i.在代码编写前，至少每周一次

ii.代码编写阶段，至少每天一次

iii.测试阶段以后，根据代码、文档的变动，只要当天有变动就要检入一次。

iv.为配合检查、备份工作，需在检查备份周期前全部checkin(不保持checkout)并退出登录。详见―检查

及备份‖部分

3、检出：即checkout。原则上只对要修改的文档方可检出。

4、破坏（Destroy）：一般情况不可以破坏文件、目录。

5、如果是误操作，则可在一天内提交管理员处

6、如果超过一天，则需要由项目经理同意，且管理员破坏前要备份。

7、各阶段环境职责

环境阶段负责人职责

公司内部

编码前

开发人员

每周及需要评审前checkin工作产品（包括版本发布说

明）到VSS上

开发组长每周

SCM人员每周统计

编码

开发人员每天checkin工作产品（包括版本发布说明）到vss上

开发组长每周检查

经理及组长抽查及走读

SCM人员每周统计，检查代码风格

测试

开发人员

每天checkin工作产品到vss上（如当天没有修改可以不

进行checkin）

以LABEL形式提交一个新版本给测试，附带版本发布

说明

测试人员对测试完成后的程序打LABEL

发布后

开发人员

将新版本checkin到vss,打测试LABEL,向测试人员提交

申请

测试人员对测试完成后的程序打LABEL

SCM人员对变更做好控制和记录，并发布

现场开发负责人将发布后的产版本更新至现场，或指定人员进行

公司外部

编码

现场开发负责人

在无法通过sos连到公司vss的情况下，需要在现场建立

配置库（文件方式或VSS等），做到基本的版本控制和

备份。每周至少通过SOS提交一次至公司的VSS库中。

现场开发人员

每天checkin工作产品到现场配置库（包括版本发布说

明）。

SCM人员

做好督促和监督工作，每周将现场开发负责人提交的现

场版本更新到公司配置库（vss）。

测试

现场开发人员

每天checkin工作产品到现场配置库（如当天没有修改

可以不进行checkin）。

如已经回公司则每天checkin工作产品到公司配置库vss

（如当天没有修改可以不进行checkin）。

每周通过SOS提交一个新版本给测试，打测试LABEL,

附带版本发布说明(如没有更新可不提交)

对测试完成后的程序打LABEL

SCM人员做好督促和监督工作

发布后

现场调

试现场

维护

现场开发负责人

在无法通过sos连到公司vss的情况下，需要在现场建立

配置库（文件方式或VSS等），做到基本的版本控制和

备份。每周至少通过SOS提交一次至公司的VSS库中。

通过LABEL提交测试版本

现场开发人员

对修改后的版本通过SOScheckin新版本到vss,打测试

LABEL,向测试人员提交申请（由修改至提交测试人员不

应超过三天）

测试人员对测试完成后的程序打LABEL

SCM人员

对变更做好控制和记录，并发布

做好督促和监督现场提交更新版本到vss。

关于VSS库内存放文件类型及大小的规定

1、文件名及目录规定：以英文名字命名

2、文件大小规定：最大不超过20M

3、允许类型：

4、表2.1中提至的文档类

5、代码及脚本类及为配合编译需要的类库等

6、以下类型不允许存放在VSS库中：

7、备份数据

8、安装程序、打包程序（ziprar）

9、超过20M以上的非代码类及开发文档类文件

10、对于特殊情况或不确定情况，需向配置管理人员咨询后再加入

11、对于不允许存放类型的配置类文件，可与配置管理员联络，随件附《说明清单》，以文件型式保存

于服务器。

配置项发布

配置项发布是指配置项进行到一定的阶段（例如，里程碑阶段），需要对外发布时的规则。在我们的项目

中，配置项发布是通过标签，即LABEL，来实现的。

阶段触发事件操作人标签类型打标签的级别

单元测试单元测试完成，可以提交集成测试开发人员FOR_TEST模块级

集成测试

集成测试完成，不通过（如通过进入系统

测试阶段）

测试人员TESTED模块级

BUG修改完成，可以提交测试开发人员FOR_TEST模块级

集成测试通过，可以提交系统测试测试负责人TESTED模块级

系统测试

系统测试完成后，不通过，（如通过进入

系统测试阶段）

测试负责人TESTED项目级

BUG修改完成，可以提交测试开发人员FOR_TEST项目级

系统测试通过测试负责人TESTED项目级

验收测试

验收前的版本，可发布到现场安装配置管理员LOAD项目级

验收后的版本，可发布的正式版本配置管理员LOAD项目级

现场维护

修改BUG后提交测试维护工程师FOR_TEST

模块级/项目级/

文件级

测试通过与否测试人员TESTED

模块级/项目级/

文件级

基线确立与变更

基线的确定在上一部分中已经说到过，我们的项目基线分为两类，一类是作为里程碑和其他工作依赖的基

线（例如需求文档、设计文档等），另一类是开发过程中有必要保留的一种状态（例如代码过程中某个模

块的一个有保留价值的snapshot）。对这两种不同的基线，其影响的范围不同，确立和变更方式也不一样。

我们项目的基线变更控制委员会由客户代表、产品经理、项目经理以及技术经理组成，对发布的里程碑类

基线的变更必须由变更控制委员会确认并由QA进行变更记录，所有被变更影响的配置项都需要重新同步

后再次发布；而对于仅仅作为工作状态保留的基线，一般只需要建立基线的小组确认更改并在QA进行记

录即可。

检查与备份

1、检查：

根据VSS白皮书建议，要定期检查数据的正确性。故VSS库管理员应每周检查一次，流程如下：

a)开发人员于每周五下午5:30前checkin（(不保持checkout)）并退出登录

b)VSS库管理人员用analyze工具检查VSS数据库，操作如下：

在dos命令行中输入：analyze–f–d–c–v4c:vssdata

其中―c:vssdata‖为vss库的数据目录

2、备份：

a)每天增量备份，通过windowsNT以上自带的备份工具进行增量备份，备份以硬盘存放即可。

b)每周全备份：每周检查完毕之后，对VSS数据库进行全备份，建议以光盘介质备份。

配置管理实施后记

应该说，这次我们对项目的配置管理实施是非常成功的，在整个开发过程中，基本没有出现因为配置管理

的问题导致的对开发进度的延误。当然，在开发过程中也发生了由于需求变化导致基线变更引起开发进度

的延迟，不过这不应该算作是配置管理的失误，因为作为配置管理来说，只能尽量保证基线变更不会导致

项目失控。

总结我们这次的配置管理实施工作，除了这几篇文章中讲到的需要注意的问题外，我觉得有一些应该算做

是决定实施成败的关键因素：

1、一个好的执行人员是成功的关键；

一个好的执行人员的重要性怎么强调都不过分。所谓的一个好的执行人员应该具备这样的素质：

a)对配置管理工作有较为深刻的理解；

b)对使用的配置管理工具运用熟练；

c)具有好的沟通能力，能和开发组长、开发人员以及其他干系人沟通；

d)有好的执行力，对流程的执行能起到监督和推动作用；

e)耐心细致，很多时候，细节决定了成败；

2、好的工具能起到事半功倍的效果；

选择一个合适的配置管理工具绝对是必要的，我们在前面用了一章多的篇幅介绍我们使用的配置管理工具

及其方案，事实证明，我们选择的配置管理工具对我们项目管理实施的效果是决定性的。

3、在配置管理实施的初期，及时的指导起的作用是巨大的，甚至可以说是成功的主要因素；

对不熟悉配置管理的开发工程师来说，配置管理工作容易在一开始就让他们产生厌烦情绪，一点点使用上

的不方便就会导致开发人员对配置管理的怨言，这个时候，及时的指导就显得非常重要了，我们在配置管

理实施过程中，准备了《VSS操作手册》、《SOS简明操作手册》、《配置管理操作指导书》等手册，进

行了三次的培训，并在实施过程中随时解决开发人员在使用配置管理工具中的问题。而且，在实施初期，

我们以奖励为主，在一个月的时间内没有将配置管理工作作为考核内容。

4、每周的配置状态检查非常重要；

在配置管理基本走上正规后，每周的配置状态检查是我们对配置管理执行效果的检查，一旦发现问题，会

作为QA问题报告发出并要求限期改正。如果没有这个检查制度，配置管理工作很难持续受控。

〔后记〕

《工程型软件项目配置管理实例》这几篇文章是我们在项目的配置管理实施过程中的一些体会，和其他配

置管理文章不同的是，这里我们给出的都是马上就可以应用的实践步骤。当然，每个公司的环境各有不同，

同样的实践不可能在每个地方都能产生一样的效果，只是希望这一系列文章能给大家一些启发。

时间仓促，文章中有些地方可能还有未能表达清楚的地方，欢迎大家和我探讨。