随着国内软件业的崛起和成熟，软件配置管理越来越得到重视。可以说，软件业要想更好的发展，没有软件配置管理的支持是不可能的。手工作坊式的软件开发模式将会成为历史，如何把国外成熟的软件配置管理理论和经验消化吸收，进而应用到国内软件开发中就成为国内软件业迫在眉睫的任务了。
软件配置管理是管理和技术相结合的一门学科。应该说，软件配置管理理论难以理解是其难以实践的原因。本文试从概念和商业模型两个角度来探讨这门对软件开发具有重要意义的领域。
什么是配置管理
在软件开发中，变更是不可避免的。从某种角度上讲，软件开发过程就是一个变更的过程。有些变更是有益的，是具有创造性的，但是，也有些变更是有害的，导致混乱的。正像James
Bach总结的那样：
我们为变更所困扰，因为代码中的一个极小的混乱可能带来产品的大的故障，但是，他也能够修复大的故障或启用奇妙的新能力。我们为变更所困扰，因为某个喜欢恶作剧的单个开发者可能破坏掉项目，但是，一些奇妙的思想也源自那些喜欢恶作剧的人员。
因此，如何管理这些变更是一个软件开发能否成功的关键。简言之，软件配置管理就是管理变更的过程，它贯穿着几乎软件的整个生命周期。成功的配置管理系统可以最大限度的减少对个别“英雄”式人员的依赖。
软件开发过程的输出信息可以分为三个主要的类型：
1 计算机程序（源代码、中间代码和可执行程序）
2 描述计算机程序的文档（针对技术开发者和用户）
3 数据（包含在程序内部或在程序的外部）。
这些项包含了所有的在软件过程中产生的信息，总称为软件配置。该集合中每一个元素称为该软件产品软件配置中的一个配置项（CI, Configuration
Item）。
尽管配置管理（Configuration Management ）这个概念被提出有几十年了，但是，业内还没有一个全面而权威的定义。
具体地说：
配置管理是标识和控制配置项，以维护其完整性、可追溯性以及正确性的学科。
具体来讲，配置管理包含如下内容：
标识：识别产品的结构、产品的构件及其类型，为其分配唯一的标识符，并以某种形式提供对它们的存取。
控制：通过一定的机制控制对配置项的修改
状态报告：记录并报告配置项以及元数据的状态。
配置审计：确认产品的完整性并维护配置项间的一致性。
从上面的描述，我们知道，配置管理的基本单位是配置项。
从“哲学”意义上讲，它记录配置项的三个方面：
从哪里来？此项可归结为WWW的问题，（Who）谁创建的？（When）什么时间创建的？（Why）为什么创建此配置项？
当前在哪里？此项纪录配置项当前的存储位置以及状态。
将到哪里去？通过配置控制来把配置项“组装”到正确的版本中去。
配置项可以是大粒度的，也可以是小粒度的。如果跟踪个别需求，那么不必要把整个需求规格说明文档定义为一个配置项，可以把每个需求定义为配置项；如果把软件开发工具也放入配置管理系统，那么把配置项定义为文件级就不合适了，只需要跟踪开发工具的版本，即把整个配置工具定义为一个配置项就足够了。
简而言之，配置项可以是文件级粒度的，也可以使文件版本级粒度的。当然，粒度越小管理的成本越高，但是配置的精度也就越高。
一个完整的SCM系统要具有三个核心功能：版本控制、变更控制、配置控制以及两个支持功能：状态统计和配置审计。
版本控制
版本，亦称配置标识，是指某一特定对象的具体实例的潜在存在。这里的某一特定对象是指版本维护工具管理的软件组成单元，一般是指源文件；具体实例则是指软件开发人员从软件库中恢复出来的某软件组成单元的具有一定内容和属性的一个真实拷贝。例如，对源文件的每一次修改都生成一个新版本。
版本控制就是对在软件开发过程中所创建的配置对象的不同版本进行管理，保证任何时候都能取到正确的版本以及版本的组合。
当前，这方面典型的工具有如VSS和CVS。
变更控制
变更控制是通过对变更请求（Change Request，简称CR）进行分类、追踪和管理的过程来实现的。
变更的起源有两种：功能变更和缺陷修补（Bug-Fix）。功能变更是为了增加或者删除某些功能。缺陷修补则是对已存在的缺陷进行修补。
对变更进行控制的机构称为变更控制委员会（Change Control Board，简称CCB）。变更控制委员会要定期召开会议，对近期所产生的变更请求进行分析、整理，并做出决定。而且要遵循一定的变更机制。
下面是一个典型的变更机制：
接受
修改配置项
测试
提交
发布新版本或补丁
建立基线
关闭CR
CCB评估
来自用户的CR
拒绝
我们可以随着变更过程的推进，提升配置项的状态。这方面的工具有Bugzilla。
配置控制
配置控制使用户能够通过对适当版本的选择来组成特定属性（配置）的软件系统，这种灵活的“组装”策略使得配置管理系统象搭积木似的使用已有的积木（版本）组装成各种各样、不同功能的模型。
软件产品的每个版本都是一组配置项（源代码、文档、数据）的集合。配置控制就是要保证每个配置的完整性和精确性。
举个例子来说，我们要发布软件的32.6版本，那么我们就要把源代码、文档、数据中所有这个应该包含到这个版本中的正确配置项检出。
在开发过程中，我们在不同阶段要建立各种基线。基线的建立是配置控制功能的典型应用。所以说，基线是具有里程碑意义的一个配置。
一般的商业软件配置管理工具都具有配置控制的功能，只是灵活性和精确性有差别。
状态报告
状态报告要回答所谓4W的问题：
What：发生了什么事？
Who：谁做的此事？
When：此事是什么时候发生的？
Why：为什么做此事？
状态报告还要能够报告所有配置项以及变更请求的状态。
配置审计
配置审计要审查整个配置管理过程是否符合规范，配置项是否与需求一致，记录正确，配置的组成是否具有一致性等等。
由于现在软件行业越来越重视质量，许多项目专门成立质量保证部门专门来进行配置审计。所以现在也可以说，配置审计是一个SQA（软件质量保证）活动。
配置管理的商业模型
配置管理的实施包括两部分：工具和规范。
在软件开发过程自动化的今天，没有工具的支持而实施配置完整的配置管理是不能想象的。因此选择一个符合公司或项目的工具至关重要。在配置管理系统中，我们可归纳出四种模型。当前商业工具一般采用其中一种或几种模型。
我们通过对商业模型的理解可以帮助我们了解某种工具是否适合我们公司或项目。
CICO模型
CICO模型主要关注的是单个文件的版本控制。图显示了一个支持CICO模型的CM系统的工作过程。用户利用库和文件系统来进行工作。文件被版本化并存储到库中，新版本的产生是由库工具控制的。然而，
文件在库中不是可以直接存取的，用户必须去检出（即Check Out）一个文件的版本到工作空间中以便读取它的内容。更改后的文件可以被检入库中（即Check
in）,产生文件的一个新版本。
此模型的代表工具是SCCS和CVS。
组织模型
组织模型由CICO模型自然导出，建立于构件版本图的基础之上，同时依赖于存储库和工作空间的概念，可以通过对构件加锁进行并发控制。组织模型的重点是在CM系统支撑下加强了对创建配置、对有关的历史信息的管理和使用他们作为工作环境的支持。
组织模型中的配置由系统模型和版本选择规则组成。系统模型列出了组成系统的所有的构件。版本选择规则指出了组成配置的每一个构件选择版本。选择规则用于系统模型，选择构件版本，即绑定一构件到某一版本。这个模型的操作方式是：开发员根据模型的构件定义整个系统，并在每一步骤中给每个构件选择合适的版本。版本操作的工作方式如图所示。
CM支持主要关心的是维护系统和其构件的版本历史，并选择符合一致性配置的构件版本。只有在所选构件的版本与所选其它构件版本一致时才认为一个配置版本。
此模型的代表工具是CCC。
长事务模型
长事务模型主要支持包括一系列原子变更的全系统演变和由团队开发员对系统变更的协调。开发员主要操作配置而非单独的构件。事务提交的结果是新配置版本，一系列连续的变更结果生成一系列的配置版本，称为开发路径。
在长事务模型中，开发员主要的工作对象时配置，开发员首先选择系统配置版本，接下来把关注重点放在系统结构上。构件的版本由配置隐式决定。长事务由两个概念组成：工作空间和并发控制方案。工作空间来源于存储库或一个封闭工作空间中的一个固定配置。工作空间由工作配置和一系列已保存的配置组成。工作配置代表构件和系统结构能够被动态更改的配置。提供通过工作空间进行的透明库访问、将高效的库存储技术应用于工作空间和管理派生构件的版本。
此模型的代表系统是NSE。
变更集模型
主要集中于对系统配置的逻辑变更的支持。在这个模型中引入的变更集表示组成逻辑变更的对不同构件修改的集合，它是创建变更的活动完成后对逻辑变更的记录。支持这个模型的CM系统用户可以直接操作变更集。在变更集模型中，配置可描述为由基线和一组变更集组成。
变更传播给其它配置可通过包含各自变更集来进行。开发员使用不同的集成策略将逻辑变更集包含到一个新的系统发行中。这样的好处非常明显，例如，我们现在维护10个不同版本的产品，现在要对所有的版本修改一个缺陷（Bug）。如果相同的工具简单的重复10次显然是不可接受的。而通过变更集把这个逻辑变更从一个版本自由的传到另外一个版本。
开发员可跟踪逻辑变更和确定这些变更是否属于特定配置。这种配置管理的方法，因为其将重点放于逻辑变更上，所以被称作面向变更的配置管理。它不同于现在的其他3种CM模型，因为其它3种CM模型使用的面向版本的方法把重点放在构件和配置版本上。
在单一构件的情况下，变更集是两个文件版本之间区别的集合，通常指的是增量内容。对配置来说，变更集就是两个配置版本之间区别的集合。这组区别就是两个配置版本间的修改构件增量集合，即变更构件集的增量。
面向变更的观点不同于面向版本的观点。这有两点不同，一是逻辑变更的显式表示允许对与单个构件和配置有关的变更集进行跟踪。二是引用单个变更集并有选择地将它们纳入配置管理中的这种能力提供了对系统演化管理的支持，这种演化是基于将逻辑变更传播到维护的系统配置进行的。
此模型的代表工具是UCM和SABLIME。
结束语
配置管理本身无论从理论和实践都在不断丰富和发展。例如，配置管理应用于“知识库”的管理就产生了“内容管理”这一新的领域。配置管理提供的状态报告和数据统计也为软件度量提供了决策依据。配置管理为项目管理提供了各种监控项目进展的视角，为项目经理确切掌握项目进程提供了保证。配置管理也为开发人员提供了一个协作的平台，在此平台上，大家能够更有效率的交流和协作。可以说，配置管理是软件开发的基石！
配置管理近年来在中国得到了极大的认可，可以毫不夸张的说，没有配置管理，就谈不上软件开发，就谈不上软件质量，就谈不上软件业的发展。随着软件业规模的扩大，配置管理的实施不是要不要的问题，而是什么时间、如何实施的问题了。
|