随着软件系统的日益复杂化和用户需求、软件更新的频繁化，配置管理逐渐成为软件生命周期中的重要控制过程，在软件开发过程中扮演着越来越来重要的角色。一个好的配置管理过程能覆盖软件开发和维护的各个方面，同时对软件开发过程进行的宏观管理，即项目管理，起着重要的支持作用。
　　配置管理（即Configuration Management，简称CM）是通过技术或行政手段对软件产品及其开发过程和生命周期进行控制、规范的一系列措施。配置管理的目标是记录软件产品的演化过程，确保软件开发者在软件生命周期中各个阶段都能得到精确的产品配置。良好的配置管理能使软件开发过程有更好的可预测性，使软件系统具有可重复性。配置管理在整个软件研发过程中起着至关重要的作用，但在配置管理的实施过程中有时候会进入一些误区。

误区一：版本控制＝软件配置管理
　　也许很多人不承认自己对于软件配置管理的理解局限在版本控制上，但在具体实施配置管理的过程中，却只见版本控制，而不见真正的配置管理。其实版本控制只是配置管理最基本的层次和功能。当然只有进行了版本控制，其他的功能才可能会逐渐提升，但就一个基本的版本控制功能而言，在部分软件公司中也并不是一个非常正规和完善的过程。

误区二：编码水平最差＝配置管理员
　　配置管理人员是配置管理具体实施的人。可以说公司制定了配置管理的流程和规章只是配置管理实施的基础，而真正配置管理能否实施，能否有效，关键在于从事配置管理的人员。但往往存在一个误区是：在选择配置管理人员的时候，是寻找开发团队中编码水平最差的人。比如张三写代码不行，测试也不行，那就只好去从事配置管理工作了。其实一个SCM 人员的责任相当重大，一个团队所有的代码、文档都由其负责，但往往处于一个相当尴尬的境地，认为一个什么都不懂的人担任，才能保证这些代码文档的安全。

误区三：采用配置管理工具＝有效的配置管理
　　配置管理工具在软件配置管理中起着不可替代的作用。没有工具的支持，实施一个完整合格的配置管理是不可想象的。也许正是因为工具的重要，造成了很多软件公司对于工具的迷信，以为只要部署了配置管理工具，尤其是专业商业工具，就自以为建立了配置管理体系。使用好的工具并不能代表就能实施好配置管理。因为工具就是工具，工具不能代替管理。否则为什么总是说配置“管理”而不单单说配置“工具”呢？一个成功的配置管理工具实施，需要两个方面的条件：一是规范的软件开发流程；二是合格的配置管理参与人员，这里的配置管理参与人员包括了配置管理员、开发人员、项目经理等。无论怎么样，没有流程和规范地使用工具，那么再强的工具也没有灵魂。比如简单的一个check in 操作，不同的人用起来可不一样。有人修改后，进行build，然后check in；有人修改后，进行build，并简单的测试再check in,也有人修改后马上check in，……可看出不同的人使用工具的同一操作会有不同的后果。

　　刚刚起步实施配置管理的时候难免会走入一些误区，这需要我们对软件配置管理有更高和更深层次的理解，才能尽量避免这些问题的出现。我们经过将近两年的项目开发实践，许多开发人员对版本控制的概念有了新的认识，从最初的抵触情绪到后来主动要求要使用配置管理系统，基本形成了软件工程化的开发氛围。但是要做好软件配置管理工作，还需要很长的一段时间去实践，制定出符合自己的流程和规范，配合先进的配置管理工具，使配置管理工作在整个软件研发过程中发挥更大的作用，推动产品更好的发展。

　一、前言

　　对于一个软件企业，开发出满足用户需求的、高质量的软件产品是其追求的目标，而实现这一目标的关键是建立起一个稳定、可控、可重用的软件开发过程。软件企业要想永葆竞争优势就必须不断地改进它的软件开发

　　过程，而要进行软件开发过程改进就需要有明确的、量化的对现状的分析和对未来的预期，这些数据来源于对软件过程的度量，而进行度量的前提和基础就是软件配置管理。所以，软件配置管理工作是以整个软件过程的改进为目标，是为软件项目管理和软件工程的其他领域打好基础，以便于稳步推进整个软件企业的能力成熟度。而做好软件配置管理是迈向软件开发规范化管理的第一步。

　　对于中小型软件开发，软件配置管理的作用不是很明显，但对大型软件开发，由于开发人员众多，程序量大，系统复杂，软件配置管理至关重要。

　　软件配置管理对于软件开发管理是如此重要，它的主要思想和具体内容在于版本控制。版本控制是软件配置管理的核心思想之一，是指对软件开发过程中各种程序代码、配置文件及说明文档等文件变更的管理。版本控制最主要的功能就是追踪文件的变更。它将什么时候、什么人更改了文件的什么内容等信息忠实地记录下来。每一次文件的改变，文件的版本号都将增加。除了记录版本变更外，版本控制的另一个重要功能是并行开发。软件开发往往是多人协同作战，版本控制可以有效地解决版本的同步以及不同开发者之间的开发通讯问题，提高协同开发的效率。并行开发中最常见的不同版本软件的Bug修正问题，就可以通过版本控制中分支与合并的方法有效地解决。

　　二、大型软件系统

　　大型一体化系统软件是为了满足石油勘探开发对地震数据处理与解释日益增长的需要，而开发的大型处理、解释一体化系统，该系统由系统平台和应用系统组成，系统平台包括数据平台、交互框架平台、通用显示工具、可视化显示平台。在这个平台上构建处理系统、解释系统和一体化应用系统。项目计划在两年内完成，预计程序行数400万以上、开发人员200余人。

　　经验表明，软件规模越大生产率越低。而且随着软件规模增大，软件开发成功率也越低，在我们国家，软件业还没有脱离手工作坊的方式。如此大规模的软件开发，已往手工作坊式的管理方式要改变，软件配置管理要创新。与其他的一些软件工程活动不一样，软件配置管理的对象——（软件）配置项，它们不仅是大量人力物力投入的结晶，更是开发经验的积累，是软件组织最宝贵的财富。

　　软件配置管理贯穿于软件开发活动的始终，覆盖了开发活动的各个环节，它的重要作用之一就是要全面的管理保存各个配置项，监控各配置项的状态，并向项目经理及项目长提交配置报告。配置管理工作更强调工具的支持，缺乏良好的配置管理工具的话，要做好配置管理的实施会非常困难。软件配置管理是一项十分繁琐的工作，同时又和整个软件的开发活动紧密地联系在一起，为使软件开发能够始终处于受控之中，就必须建立一套体现软件工程特点的配置管理体系，并依据体系要求选用软件配置管理工具。

　　三、软件配置管理工具

　　Firefly是Hansky公司软件开发管理套件中的重要组件。Firefly可以对大型软件开发的程序代码和相关文档进行管理，具有以下突出的特点：

　　1、本地工作区（Local Workspace）

　　Local Workspace存储从服务器上下载的一个分支的下的文件，开发人员在工作时首先要从服务器上将最新修改的项目文件下载到本地工作区，然后才能对项目文件进行编辑、编译、调试等工作。有了Local Workspace，可以保持本地的工作文件和服务器上的工作文件的同步。同时，还可以比较本地工作区文件与服务器文件的不同，在每次下载和上传时不必将所有的项目文件都传输一遍，从而提高了工作的效率。

　　2、标签（Label）

　　Label采用索引技术提高了操作效率，通过下载Lable的功能为编译、测试提供了便利。

　　3、两种开发模式

　　Firefly支持并行/串行两种开发模式，并且提供向导来检验和解决文件的冲突，使得团队的开发快速、便捷而且高效。

　　4、分支

　　在Firefly中可以方便的建立项目的分支，可以在主分支上建立分支，也可以在次分支上建立分支，还可以在Label的基础上建立分支；建立分支的时候可以选择父分支的一部分文件。

　　在开发主分支的同时有可能同时开发修正Bug的分支，当主分支的开发工作告一阶段后，通常会把Bug修正分支合并到主分支上去，如下图：

　　

　　这种建立和管理项目分支和记录分支间父子关系的功能，避免了由于两方归并所造成的混乱问题，为软件产品的多个版本的同时开发提供了强有力的支持。

　5、变更集

　　Firefly将每一次工作区的检入都视作一个变更集，每一个变更集都作为项目分支的历史被保存下来，管理人员可以通过WEB界面方便的查询分支的历史。

　　6、原子事务

　　利用原子事务的概念，将一个包含多个文件改变的入库操作作为一个事务（Transaction）来对待，全部文件的提交只有成功或者不成功两种情况，没有中间状态（如一部分成功提交，而另一部分提交失败的状态）。这样能够处理一些操作过程中的异常情况，比如提交过程中网络中断等，保证软件系统的一致性，防止其他开发人员取到错误的代码而编译、运行失败。

　　7、本地记录

　　通过Delta操作支持本地版本的记录。在某一工作区中，修改了一个文件，然后通Delta操作，可以在本地记录下一个新的版本。提交到服务器上后，其他人也可以访问这一版本。

　　8、权限控制

　　Firefly采取了类似于NTFS的权限控制体系，不仅能够控制项目分支一级的权限，还可以深入到目录/文件一级进行权限设定，文件的权限缺省从目录继承，还可以手工对特定文件的权限进行调整；并且可以细分权限的等级。这种权限体系可以保证项目所涉及到的开发工作都处于受控的状态下，从而保障项目不受干扰，能够顺利开发。

　　四、建立配置管理体系

　　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的版本。在这个并行开发过程中，创建分支和分支的合并起了非常重要的作用。

　　

　　图3 分支

　　

　　图4 分支及标签

　　产品基线

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

　　与分支对应的本地工作区

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

　　开发工作区

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