作为软件配置管理工作者，差不多都有这样的经验：在认识新朋友时，当别人问起自己所从事的职业，自然回答到，“我从事软件配置管理工作”。接着，十有八九，会被问到下一个问题“什么是软件配置管理？”。总被问到相同的问题，倒还称不上是苦恼，真正的苦恼在于回答这个问题，因为软件配置管理真是不太容易说得清……解释了半天，结果往往是，“你这份工作好玄妙啊。隔行如隔山啊，我是搞不懂了。”

是的，软件配置管理，确实不太好解释。软件开发过程中的其它工作，似乎都比它容易理解。开发工程师在编写源代码；测试工程师在测试，挑毛病；需求分析师跟用户确定需求，并且用精确严谨的语言表达出来……虽说这样说未必严谨，但是至少能够得到一个大致的印象。但是，软件配置管理呢？软件配置管理是什么？

下面是软件配置管理的一个权威定义：

“A discipline applying technical and administrative direction and surveillance to identify and document the functional and physical characteristics of a configuration item, control changes to those characteristics, record and report change processing and implementation status, and verify compliance with specified requirements.”

“一套应用技术上和管理上的指导和监督的方法，用来：识别和记录配置项的功能特征和物理特征；控制这些特征的变更；记录和报告变更的处理和执行的状态；以及验证其符合特定的需求。”

如果你看得一头雾水，别担心，这不是你能力上的问题。大部分人和你的感受相同。这个定义，以及类似的权威定义，都高度抽象。用一两句话，确实很难把握好软件配置管理这个概念。需要更多的描述，才能把它说清楚。事实上，这一整本书，就是在认识和理解软件配置管理。而在这一章中，我们将用一些我们相对熟悉的概念来打比方，做对比，来讲解软件配置管理这个概念。通过这样一种方式，让大家对软件配置管理有一个初步的，但比较正确的认识。

1.1. 与图书管理作对比

软件配置管理，是关于软件资产的管理。什么是软件资产呢？源代码，设计文档，可以运行的程序，这些在软件研发过程中产生的有价值的东西，都是软件资产。软件配置管理就是关于这些内容的管理。那么，具体有什么要管理的呢？让我们把它和图书馆的图书管理做个对比。

它们有一些相似点。首先，图书管理管的是图书资产；软件配置管理管的是软件资产。这两种管理，管的都是信息资产。其次，图书管理，需要把图书进行分类，以便检索，需要将图书存放在合适的地方，以便存取，还要防止虫吃鼠咬；而软件配置管理也类似，需要把软件资产——主要是源代码，放在合适的目录结构里，放在合适的地方存储，防止丢失或者弄乱。再次，在图书馆，要记录谁借出了哪本书，还没还。这是为了保证，图书馆的书不会丢失； 而软件配置管理中也类似，需要记录谁“借”出了什么文件，什么时候“还”的。在这一“借”一“还”的过程中，程序员修改了它，而软件配置管理记录下了这些修改。那么，为什么要记录呢？

因为软件资产与图书资产不同，软件资产在不断变化，不断演进。项目初始的时候，可能只有一份简单的项目计划，而项目结束时，已是可以交付给用户的产品。如果缩小视野，单就某个源代码文件来看，也会看到，通常它会在项目的某个时刻，被某个程序员创建第一个版本，然后，可能有不同的程序员，不断修改它，产生新的版本。软件配置管理关心：是不是这个文件的各个历史版本应该被记录，以便今后翻阅？是不是各次修改的修改者、修改的原因应该被记录，以便将来可以理解当时的情形，理解为什么做出这样的改动？更扣人心弦的是，当两个人同时想要修改一个文件的时候，可能会导致其中一个人的改动丢失，也就是常说的版本覆盖。那么，是让他们一个改完了另一个再改呢，还是让他们同时改，在将来合并？等等。

所以说，软件配置管理是关于不断演进的软件资产的管理。

1.2. 为什么称作配置管理？

机器由零部件组成。例如，汽车一般由底盘、发动机、车身和电器设备四大部分组成。其中，汽车底盘一般包括传动系、转向系、制动系和行驶系。传动系主要由离合器、变速器、传动轴和减速器等部件组成。再往下，基本就是零件了。

机器由正确型号的零部件配置而成。每个零件都有型号、编号。零件组成的部件也有。一直到整个机器，一辆汽车。要保证制造出来的机器是正确的，就要保证选取了所有正确型号的零部件。那么，容易想到，应该有某种列表或文档，标明各零部件型号和组成关系，也就是说，标明配置信息。而当配置有变动的时候，要更新这样的列表或文档。并且，这种变动不能随随便便，是否应该先让总工程师批准？是否应该做相应的测试？这些都属于对配置的管理。

从软件配置管理的视角看，软件也是这么配置起来的。往小了说，各个源代码文件的正确版本配置在一起，编译产生了正确的可运行程序。往大了说，若干软件组件的特定版本，配置构成了特定的软件产品。而有些软件组件，可能参与了不止一个软件产品的配置构成。而当某个软件组件参与不止一个软件产品的配置构成的时候，可能是这个软件组件的同一个版本，也可能是不同版本。看，问题有多复杂！不管理怎么行！

软件配置管理，与对机械系统的配置的管理相比，是有一些自己的特点的。主要有两点：第一，软件更容易发生变化，向前演进。一个程序员，修改一个Bug，可能5分钟就搞定了，于是，5分钟前与5分钟后，已经是不同的版本了。更何况，不止一个程序员在工作。如此快速的、众多的变化，如果靠一个书记员手工记录相关信息，那恐怕比较累。所以需要某种自动化的工具，提供这方面的支持。

第二，软件的耦合性更高。当程序员为某个任务改动源代码的时候，经常要改动不止一个文件。在目录结构上，这些文件可能相距遥远。组件/模块间的接口，往往并不像把鼠标线插到USB口上那么简单。某个模块的变化，常会影响到相关模块 。这个特点，使得在软件领域，需要格外关心整体性。要尽可能早的、尽可能频繁的集成，保证产品作为整体，是可运行的。另一方面，一个模块、一个源文件，可能被几个程序员改动：出于不同的目的，改动不同的位置，甚至相同的位置。因此，版本更容易混乱，或相互覆盖。需要软件配置管理工具提供相应支持，提供便利，同时避免出现问题。

1.3. 其它一些比喻

保险柜

软件配置管理为软件开发提供了一个保险柜。保险柜里，存的都是值钱的东西。存进保险柜，是因为怕自己不小心弄丢，或者被偷走。软件资产也一样，甚至比金戒指之类的更值钱。软件资产也会丢失，特别是源代码。比如，一个软件项目完成后，如果没有进行存储/归档等工作，等再过几个月，想基于版本1.0开发版本2.0的时候，可能会发现1.0的源代码找不着了……无奈，只好从头写。这是自己不小心弄丢的情况。软件资产还有可能被窃取或泄漏。虎视眈眈的竞争对手，无孔不入的商业间谍……所以，一定要把软件资产放进类似保险柜的地方。

岩钉

这是来自攀岩者的经验。系上保险绳，每向上攀一小段，就在岩壁上打个岩钉。这样，即使偶尔失手，也不会从半山坠到谷底，只是向下滑一小段。软件开发也是一样，适当的保存历史版本，可以在失手的时候回退到上一个安全的地方。这里的版本，不仅仅指具体某个文件的版本，也指整个产品的版本。不仅指源文件，也包括需求、设计、测试用例……当我们关心软件产品的部署和运行情况时，版本还意味着，某个软件，上次安装的版本是多少？这次升级到哪个版本？如果升级失败，应该回退到上一个版本。

脚印

一步一个脚印。这有两个含义。首先，先走好这一步，踩实了，踩稳了，再走下一步。软件研发也是这样，需要里程碑；需要基线；需要每个迭代结束时，内部或外部的发布。这些是项目的脚印。在每个脚印处，我们要认真检查，是不是踩实踩稳了。这可能是通过相关人员的评审，领导的审批，可能是通过软件测试，也可能是通过某些检查。

其次，一个个的脚印，就构成了足迹。它告诉我们，我们是如何一路走来的，走的是哪条路。必要的时候，我们可能会回顾。还有可能，我们会回到半路，以便从那里再闯一条新路出去。对应到软件开发，我们就是要保存历史上的版本，已备将来的不时之需。

好了好了，据说所有的类比和比喻都是蹩脚的。软件配置管理是什么？软件配置管理就是软件配置管理。如果再多说几句，那就是：它是关于不断演进的软件资产的管理。这涉及到存储和安全；涉及到记录它演进的历史；涉及到让修改和变更井然有序，避免出现版本丢失、版本覆盖等混乱情况；涉及到保证软件代码集成在一起的质量……让我们在随后的章节里，更细致地学习和研究吧！

组织简介 | 联系我们 |   Copyright 2002 ®  UML软件工程组织 京ICP备10020922号

京公海网安备110108001071号