本文是我从事配置管理工作，从事SEPG工作的一点心得和体会，写出来仅与各位同仁进行交流。

所悟之一：配置管理工作关注的焦点是什么？

配置管理，从字面上来看，是由配置和管理两个动词所构成的，没有宾语。初识配置管理时，我感觉这个词太抽象了，为何？就是缺了个宾语，我无法将其与实际项目中任何事物联系起来，到底配置什么，管理什么。

其实，明确了这个宾语，也就回答了这个问题：配置管理关注的焦点就是配置项。

为何配置管理工作内容中首先提及的是"识别配置项"！这是我们工作的核心，管理的对象。在开始配置管理工作之时，在制定配置管理计划之时，我们首先要做的第一件事就是要明确项目中所有配置项。

我们可以细想一下，配置管理中的几项工作哪项与配置项无关？版本控制就是控制配置项的版本；变更控制就是控制配置项的变更；配置审计就是对配置项进行物理审计或功能审计；发布管理就是控制配置项的发布；配置状态发布实际上就是发布配置项目前的状态。

为何我们说：在制定配置管理计划，制定配置管理策略的时候要依据项目需求来定！项目的需求是什么，实际就是对配置项管理的要求！不同的项目配置项不同，不同的项目对配置项的管理级别以及管理方式的要求是不同的。明确了这些，我们才能够考虑项目的配置管理策略，制定项目的配置管理计划，才可以说项目的配置管理工作启动了。

总结：配置管理，我可以这样理解：配置统一工作环境用来支撑配置项管理工作。

所悟之二：配置管理工作中是过程重要还是工具重要？

我在做配置管理工作的时候，被问到的最多问题就是关于配置管理工具的："为何这个工具老是报错？"很少有人向我提及："你制定的配置管理策略在某某方面操作起来有问题！"

我们用的配置管理工具都是比较成熟的产品，为何我们操作起来经常会有异常的问题出现，大家有想过这个问题吗？我认为开发人员想这问题就太简单了。每个软件产品都有内在的业务处理逻辑，业务处理逻辑在配置管理中就是我们要谈及的过程，就是配置管理策略，那么配置管理工具也是软件产品，道理自然一样。一般配置管理工具，如Microsoft Visual SourceSafe，工具将过程已经固化；高级配置管理工具，如ClearCase，工具本身只是为我们提供了一个平台，我们在此基础上可以定制我们想要的过程。不管是工具本身已经固化过程还是我们自己在工具基础上定制过程，只要过程是明确的，我们对过程理解透彻，即使出现问题的时候，你也可以想出：为何会出现这个问题！就我总结，很多问题都是因为对过程的不熟悉，误操作而导致的。以不变的过程应对万变的问题，我认为大部分问题都是可以解决的。

同样，我想到我们在推行质量工程的时候，LSSP（Linkage Standard Software Process）发布之时，在项目组实施之时，大家都惊呼："太多文档！"在预评估的时候，大家对SPI（Software Process Improvement）的期望都会提及："我们需要工具支持！"一样的道理！

我在这里不是全盘否定工具的作用，但是我们可以完全依赖工具吗？试想一下：如果对工具本身的处理过程都不能理解很清楚的人，工具对他真的很有效吗？难道工具真的是我们需要的吗，真的可以帮助我们提高工作效率吗？质量工程中做任何一件事都要考虑投入与产出，工具给我们带来的产出你明确了吗？以上问题你都很肯定的时候，那就是可以使用工具的时候。

总结：我认为，配置管理工作中重要的是过程。过程是本，在大家都很明确过程的时候，工具对过程，对大家工作的支撑作用是会显著的。

所悟之三：基线和Label到底是什么关系？

LSSP发布以后，有太多人问我："Label到底是什么？为何每次都是和基线同时出现？"

配置管理中抽象的概念比较多，基线就是其中之一。基线，顾名思义，是基准线，是项目组是下阶工作的起点。所以，对基线的确立将是非常慎重的一项工作，这将直接影响我们下阶段的工作。

一旦基线确立之后，那么Label就要隆重登场了。Label其实就是基线的实际体现形式。

总结：Label是基线在配置管理工具中的体现形式。通过Label，我们可以获取某一基线配置项的特定版本。

所悟之四：我们为什么要做内部发布？

系统版本发布，我们都很熟悉，不就是系统割接上线吗！配置管理中，我们把这种发布叫做"外部发布"，那么就必然有与其相对的"内部发布"。他们之间到底有什么区别，我们为何又要多出一项工作："内部发布"。

在产品投入正式生产之前，我们需要能够证明：我们的产品是可以顺利割接上线的；我们的产品是可以满足用户需求的。
这些信心从何而来？靠我们平时的演练，靠我们对产品的测试。

内部发布就是模拟系统割接上线，这种演习对于正式的割接是非常有好处的，其实我们的项目组是有在做的，只不过大家没有意识到这就是内部发布。例如：产品Alpha或Beta版本发布。

而且，这样我们可以随时访问产品：测试系统，熟悉系统，最终确认系统是否真正满足用户需求，是否真正好用。
内部发布，是给我们自己多几次机会，从而保证外部发布的成功。

一次总结，一次交流，彼此获益，何乐而不为！