文档介绍：前言 2
配置管理工作概述 2
本文涉及的项目背景 2
配置管理环境 3
配置管理工具的选择 3
软硬件环境的选择 4
网络环境的选择 4
配置库维护和备份计划 5
配置管理双抢将VSS+SOS 5
5
(SourceOffSite)软件介绍 6
6
6
配置管理规范 14
15
16
18
配置管理项变更与发布 18
18
、检入、检出及破坏 18
20
20
21
21
21
前言
软件配置管理作为贯穿软件开发过程始终的一项工作,其重要性不言而喻。**网站上已有众多关于配置管理介绍、配置管理计划、配置管理工作开展心得一类的文章,这些文章从概念和实施上介绍了配置管理工作的内容,但美中不足的是仍嫌抽象,那些想要依葫芦画瓢的兄弟姐妹们在试图将这些理论应用到自己项目的配置管理中的时候,会发现仍然是无从下手(我也曾是这些感觉无从下手的人中的一个)。因此,本文拟从另外一个角度,以本人最近实际操作的一个项目的配置管理工作谈起,从配置管理工具的选择、配置管理流程制定、配置管理库结构的确定,以及作为配置管理工作的推动者如何推动这项工作等方面仔细描述一下本人的做法,希望这几篇文章能给那些水深火热中的兄弟姐妹们一点帮助。
这里有两点需要特别说明:
1、本文描述的内容是以一个项目的配置管理为主线,对组织级的配置管理和配置管理策略没有进行详细讨论;
   2、本文用来做示例的项目是一个“工程型”的项目,所谓的“工程型”是和“产品型”对应的,这样的项目需要公司的开发人员和现场的开发人员进行协作开发,一般而言,在公司的开发人员完成大部分的功能,现场的开发人员根据用户需求,对软件进行修改(这部分的工作量一般会较大,在一个16人年的项目中,这部分的工作可能会占到三分之一以上的工作量)。
配置管理工作概述
配置管理工作的工作范围,在**网站的很多文章中都有描述,具体可以参考**的《基于CMM和CMMI的配置管理》和**的《软件配置管理实施体会》。在这里不作详细的描述。
本文涉及的项目背景
本文用来示例的项目是某省电信的一个项目,该项目的工作量大约是16人年,项目周期约为1年。大部分(90%以上)的开发工作在前8个月内完成,后期的工作主要由维护人员进行系统维护和调整。在8个月的开发时间中,前5个月由开发人员在公司进行开发,根据用户的需求完成设计,确定系统架构并实现整个框架,部分明确的功能以及公用模块也在这段时间内完成;后3个月的时间部分开发人员在现场,部分开发人员在公司共同完成后期的开发工作。
整个项目采用的开发语言是C++、Java、ASP,涉及的平台包括Solaris和Windows,采用的开发工具包括Visual 。此外,整个项目还使用了一些第三方的平台,如IBM的MQ等。
除用户需求之外,公司还对项目组提出了代码复用方面的要求,开发人员在开发过程中必须注意代码的可重用性。
配置管理前期准备工作
在项目正式启动之后,配置管理工作就可以开始了。配置管理工作开始的第一步就是一份配置管理计划。**网站上已有不少配置管理计划的模板,大家可以参考。
一般而言,需要在配置管理计划中明确的内容包括:
配置管理软硬件资源;
配置库结构;
人员、角色以及配置管理规范;
基线计划;
配置库备份计划;
在下文中,我们将围绕这些内容进行详细描述。
配置管理环境
配置管理环境包括软硬件环境。具体的资源需求应该根据项目实际情况来确定,一般需要考虑的包括:网络环境、配置管理服务器的处理能力、空间需求,配置管理软件的选择等。配置管理环境的确定需要综合考虑各个方面的因素,包括我们采用的开发工具,开发方式,开发人员对配置管理工具的熟悉程度等,其中,开发人员对配置管理工具的认可和熟悉程度常常直接决定配置管理能否正常进行,如果选择了需要开发人员花费比较大的精力去熟悉的配置管理软件,我们就必须花费大量时间来进行培训;同时,配置管理软件和开发工具的集成程度也是一个必须考虑的因素,根据我们的经验,选择一个和开发环境集成紧密的配置管理工具至少可以减少20%花费在Check In/Check Out和配置管理人员保持配置库完整上的工作量。
根据我们项目的实际情况,我们有如下一些考虑:
根据历史经验,一个类似项目的配置库大小约为3G,考虑到备份等操作对空间的需求,至少应该为配置管理库保留10G以上的空间。为了保