论软件项目的配置管理

【摘要】

本人于2005年1月至2006年1月参加了某个知名饮料集团公司的企业信息系统的开发工作，该大型集团的业务主要涉及到奶制品的进销存。本人在项目中负责系统分析，设计和部分测试与系统实施的工作，本文从配置管理工具的选择、配置管理流程制定、配置管理库结构的确定，以及作为配置管理工作的推动者如何推动这项工作等方面仔细描述。本人参与了该项目的系统分析、设计、测试和实施工作，实现了该系统的库存管理、供应链管理、销售管理和OA等子系统。通过该项目的配置管理和实施，应该说，这次本人们对项目的配置管理实施是非常成功的，在整个开发过程中，基本没有出现因为配置管理的问题导致的对开发进度的延误。当然，在开发过程中也发生了由于需求变化导致基线变更引起开发进度的延迟，不过这不应该算作是配置管理的失误，因为作为配置管理来说，只能尽量保证基线变更不会导致项目失控。

【正文】

2005年年初，本人参加了某个知名饮料集团公司的企业信息系统的开发工作，该大型集团的业务主要涉及到奶制品的进销存，该项目的工作量大约是12人年，项目周期约为1年。大部分（90%以上）的开发工作在前6个月内完成，后期的工作主要由维护人员进行系统维护和调整。在6个月的开发时间中，前4个月由开发人员在公司进行开发，根据用户的需求完成设计，确定系统架构并实现整个框架，部分明确的功能以及公用模块也在这段时间内完成；后2个月的时间部分开发人员在现场，部分开发人员在公司共同完成后期的开发工作。整个项目采用的开发语言是C++、Java、ASP，涉及的平台包括Solaris和Windows，采用的开发工具包括Visual Studio和Solaris上的CC。此外，整个项目还使用了一些第三方的平台，如IBM的MQ等。除用户需求之外，公司还对项目组提出了代码复用方面的要求，开发人员在开发过程中必须注意代码的可重用性。

在项目正式启动之后，配置管理工作就可以开始了。配置管理工作开始的第一步就是一份配置管理计划。本人认为需要在配置管理计划中明确的内容包括：

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

2、 配置库结构；

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

4、 基线计划；

5、 配置库备份计划；

配置管理环境包括软硬件环境。具体的资源需求应该根据项目实际情况来确定，一般需要考虑的包括：网络环境、配置管理服务器的处理能力、空间需求，配置管理软件的选择等。配置管理环境的确定需要综合考虑各个方面的因素，包括本人们采用的开发工具，开发方式，开发人员对配置管理工具的熟悉程度等，其中，开发人员对配置管理工具的认可和熟悉程度常常直接决定配置管理能否正常进行，如果选择了需要开发人员花费比较大的精力去熟悉的配置管理软件，本人们就必须花费大量时间来进行培训；同时，配置管理软件和开发工具的集成程度也是一个必须考虑的因素，根据本人们的经验，选择一个和开发环境集成紧密的配置管理工具至少可以减少20%花费在Check In/Check Out和配置管理人员保持配置库完整上的工作量。根据本人们项目的实际情况，本人们有如下一些考虑：

根据历史经验，一个类似项目的配置库大小约为3G，考虑到备份等操作对空间的需求，至少应该为配置管理库保留10G以上的空间。为了保证配置管理库的安全，除了相应的备份计划之外，还可以采用了RAID 0＋1的方式为配置数据库提供更好的可用性保证；考虑到在项目的后期有部分开发人员会在现场进行开发，因此在网络条件上需要提供对远程访问方式的支持；配置管理服务器的选择和配置管理软件的选择相关，考虑到目前公司有一台闲置的PC服务器，最好能充分利用这台服务器；配置管理软件必须可以以某种方式支持远程访问，而且由于本人们的开发平台涉及Solaris和Windows，配置管理软件要能够支持这两种平台；考虑到开发工具方面，配置管理工具要求能和本人们选择的开发工具进行很好的集成；项目组的开发人员缺乏使用配置管理工具的经验，有将约30%的开发人员使用过VSS配置管理工具，但仅限于最基础的使用，对VSS的Label等功能没有概念；结合以上的情况，本人们首先考虑配置工具的选择。

从开发人员具有的配置管理工具使用经验和配置管理工具使用的难易度方面来说，VSS是最好的选择，在现有的基础上只需要对开发人员进行简单培训；考虑到和开发工具的集成，VSS也是一个不错的选择。因为VSS简单易用，在大多数人眼里，VSS似乎都只是一个玩具，难登大雅之堂，最多能管管自己的代码，要用团队开发中，那似乎是不可能的。刚接触VSS时，本人也是抱着差不多的想法，觉得要用VSS作为一个较大的项目的配置管理工具完全不可能，但随着对VSS研究的深入，加上在工作中也使用了其它一些配置管理工具，如CVS、ClearCase、CCC harvest等工具，反过来比较，反而觉得VSS有它独到的地方。不过本项目还要求对远程接入方式的支持，以及对Solaris平台的支持，VSS肯定是不能满足要求的（VSS通过VPN方式应该是可以实现对远程访问的支持，但VSS的完全共享方式实在是不敢在Internet上使用）。除VSS外，可以选择的配置管理工具还有CCC Harvest、ClearCase、CVS等，但Harvest和ClearCase使用起来比较复杂，需要一个专门的配置库管理员负责技术支持，还需要对开发人员进行较多的培训，另外，Harvest和ClearCase价格不菲；CVS在Unix下使用方便，而且是免费的，但其文本方式的操作界面对于习惯在Windows平台上开发的开发人员来说使用非常不习惯（CVS也有windows下的GUI版本，但经过本人们的试用，在操作习惯上和本人们目前开发人员习惯的方式很不相同，较难被接受）。 经过在MSDN和Internet上查找，终于找到了一个VSS的增强软件SOS（Source Offsite），它基于VSS的数据库，可以支持通过TCP/IP方式访问和操作VSS库，在Windows、Slolaris和Linux上都提供了客户端，并且通过传输数据的压缩和加密方式，使得文件操作的速度大大加快并增强了系统的安全性。事实证明，VSS＋SOS的组合在本人们的整个项目过程中起到了关键的支持作用。本人们使用的SOS是3.53的Standard版本。

确定了配置管理工具后，本人们使用公司购置的一台Compaq PC Server作为配置管理的硬件环境，VSS对硬件配置要求不高；作为一个工作组级别的配置管理工具，在本人们的项目中，安装VSS的配置服务器是一台P4 2.2G/512M RAM/30G×4 Disk的HP PC服务器，这样的条件下VSS运行已经足够稳定和快速，相比起CC和CCC harvest的要求，这部分的投资是很小的；如果再考虑到CC和CCC都运行在Unix平台上需要的维护费用，当然是VSS更加划算了。

最终确定的方案是安装该服务器安装Windows 2000 Server操作系统，为了保证配置数据的安全性，本人们采用RAID 0＋1方式，总的可用空间在50G左右；另外为了备份的需要，还为服务器配置了一个CDR刻录机。

对于网络环境的选择，因为公司已有现成的100M局域网，通过一个交换机和路由器连接至Internet，有一个公网的静态IP；配置管理服务器是内网的一台机器，具有一个内网IP。为了满足远程访问的需要，本人们通过在路由器上设置端口映射，将SOS需要使用的端口映射到配置管理服务器上（缺省情况下，SOS使用8888和8890两个端口）。网络拓扑图如下：

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

本人制订了配置库维护和备份计划 ，配置库的维护的备份需要专职的配置库管理员来负责。在整个项目中本人们采用的配置库维护策略是根据Microsoft的Best Practice白皮书建议，包括以下要点：

1、 保持配置数据库的大小不超过5G；Microsoft建议，配置库的大小在3－5G比较合适，太大的数据库会极大影响VSS的效率；减小配置库大小的

2、 每周进行VSS数据库的分析（Analysis），发现问题及时修正；VSS提供了Analysis和Fix工具，由于不合理的Delete等操作，VSS数据库有可能会出现一些Interrupt Data之类的问题，通过定期的每周的分析工作，可以极大减少数据库出现问题的风险；

3、 每日进行配置库的增量备份，每周进行数据库的完全备份；VSS库的备份可以通过VSS自己的Archive功能或者是操作系统的Backup程序来进行。VSS的Archive功能对VSS中的文件数据进行压缩并保留VSS的所有状态，但只能对VSS库进行完全备份，不能实现增量备份功能。Windows2000 Server提供的Backup实用程序可以对文件进行备份，由于VSS库就是以文件形势存在的，因此针对VSS的data目录进行备份也可以完全达到备份的目的，使用系统备份工具的好处是可以实现增量备份。本人们在实际中使用的系统的备份工具，每周五生成的完全备份采用刻录光盘的方式保存，每天的增量备份数据存放在文件服务器上进行备份。

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

1、配置项标识：在本人们的项目中，一般使用“项目名_配置类别_配置项特殊标识”来命名。配置项命名中的“配置项特殊标识”根据配置类别的不同而不同。比如，对“设计文档”，如果细分的话，可以分为“概要设计”和“详细设计”；对“代码”，可以按照模块来命名配置项。

2、配置项版本命名：配置项版本命名是针对配置项的版本进行命名，在本人们的项目中，配置项版本通过对Project的Label操作来实现，配置项版本的命名需要能清楚标识配置项的状态。一般说来，配置库至少包括个人工作区、受控库、发布区三个部分，在本人们的项目中，所有的配置项都保存在一个VSS库中，对这三个部分的划分是通过逻辑划分方式进行的，具体来说，就是通过配置项版本命名来划分的。因此，本人们配置项的版本命名规定如下：

a) 基线版本：按照基线的状态，本人们这个项目中的基线有两个方面：一是作为里程碑的基线；另一个是模块的阶段性成果基线（对工作产品而言），由模块的负责人确定。

里程碑基线――对本人们的项目来说，采用的是迭代的开发过程，以一个迭代过程为例，分为需求、概要设计、详细设计、代码实现、单元测试、集成测试、系统测试七个阶段，每个阶段都需要产生里程碑。对每个里程碑都有明确的标识标明当前状态。

阶段性成果基线――阶段性成果主要体现在代码过程中，比如代码进行到一个阶段，开发组长认为代码的这个状态可以保留，就可以确定为一个代码基线。这种基线一般不需要通过评审等正式手段来确定，但也必须有相应的验证手段；比如在本人们的项目中，在代码阶段，确定代码基线的责任人是开发组长，但开发组长必须保证代码基线符合一定的条件。

b) 其他版本：除基线版本外，有时候还需要在开发和维护过程中确定其他版本。例如，产品在测试过程中不断的问题修复过程中，可能会有多种反复，此时需要将每次修改的内容作为一个版本。

关于版本，还有另一个需要注意的问题。一般来说，按照模块来划分，每个模块有自己的版本演进比较合理。首先，一个模块一般是由一个或两个开发人员完成的；其次，一个模块的功能会比较单一且独立，在版本的演化过程中便于控制，也不会和其他模块产生过于复杂的关系。而产品的版本则需要由各个模块的不同版本组成，这个纵横的关系需要很好地管理，本人们的做法是在VSS库上用Label来标识，同时维护一张描述产品版本和模块版本关系的矩阵图便于追踪。

在确定了配置项之后，就可以确定配置库的目录结构了。配置库的目录结构直接关系到配置管理的工作量和使用的方便性，所以需要根据自己的需要确定一个合理的结构。

在确定配置管理库目录结构的时候，本人们曾经考虑过两种产品目录结构的方式：一种是按照模块划分，在模块下再划分诸如设计文档、代码等目录；另一种方式是按照产品类型划分，例如首先是文档、代码，然后在其下按照模块划分。这两种方式都有自己的优点，最终本人们还是选择了前一种划分方式，一方面是考虑便于进行权限的分配，另一方面是考虑到便于将同一模块的所有内容组织起来进行版本的管理。

角色是配置管理流程的执行者和参与者，定义明确的角色有利于实现明确的授权和明晰的流程，虽然在实际中可能多个角色由一个人担任，但还是应该保留角色的定义。

本人们所说的配置项变更流程主要是针对配置项发生变化的控制，在本人们的项目中分为两个部分，首先是对配置项新建、检入（CheckIn）和检出（CheckOut）的规定；其次是对入库的文件类型和大小的规定：新建、检入、检出及破坏

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

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

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

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

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

iv. 为配合检查、备份工作，需在检查备份周期前全部check in (不保持check out)并退出登录。详见“检查及备份”部分

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

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

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

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

7、 各阶段环境职责

配置项发布是指配置项进行到一定的阶段（例如，里程碑阶段），需要对外发布时的规则。在本人们的项目中，配置项发布是通过标签，即LABEL，来实现的。

基线确立与变更 ，基线的确定在上一部分中已经说到过，本人们的项目基线分为两类，一类是作为里程碑和其他工作依赖的基线（例如需求文档、设计文档等），另一类是开发过程中有必要保留的一种状态（例如代码过程中某个模块的一个有保留价值的snapshot）。对这两种不同的基线，其影响的范围不同，确立和变更方式也不一样。

本人们项目的基线变更控制委员会由客户代表、产品经理、项目经理以及技术经理组成，对发布的里程碑类基线的变更必须由变更控制委员会确认并由QA进行变更记录，所有被变更影响的配置项都需要重新同步后再次发布；而对于仅仅作为工作状态保留的基线，一般只需要建立基线的小组确认更改并在QA进行记录即可。

通过该项目的配置管理和实施，应该说，这次本人们对项目的配置管理实施是非常成功的，在整个开发过程中，基本没有出现因为配置管理的问题导致的对开发进度的延误。当然，在开发过程中也发生了由于需求变化导致基线变更引起开发进度的延迟，不过这不应该算作是配置管理的失误，因为作为配置管理来说，只能尽量保证基线变更不会导致项目失控。选择一个合适的配置管理工具绝对是必要的，本人们在前面用了一章多的篇幅介绍本人们使用的配置管理工具及其方案，事实证明，本人们选择的配置管理工具对本人们项目管理实施的效果是决定性的。 在配置管理实施的初期，及时的指导起的作用是巨大的，甚至可以说是成功的主要因素；对不熟悉配置管理的开发工程师来说，配置管理工作容易在一开始就让他们产生厌烦情绪，一点点使用上的不方便就会导致开发人员对配置管理的怨言，这个时候，及时的指导就显得非常重要了，本人们在配置管理实施过程中，准备了《VSS操作手册》、《SOS简明操作手册》、《配置管理操作指导书》等手册，进行了三次的培训，并在实施过程中随时解决开发人员在使用配置管理工具中的问题。而且，在实施初期，本人们以奖励为主，在一个月的时间内没有将配置管理工作作为考核内容。 在配置管理基本走上正规后，每周的配置状态检查是本人们对配置管理执行效果的检查，一旦发现问题，会作为QA问题报告发出并要求限期改正。如果没有这个检查制度，配置管理工作很难持续受控。