[配置管理经验谈]配置管理，我之所悟 by 黄芸
作者：黄芸 来源：bokee.com本文是我从事配置管理工作，从事SEPG工作的一点心得和体会，写出来仅与各位同仁进行交流。
所悟之一：配置管理工作关注的焦点是什么？
配置管理，从字面上来看，是由配置和管理两个动词所构成的，没有宾语。初识配置管理时，我感觉这个词太抽象了，为何？就是缺了个宾语，我无法将其与实际项目中任何事物联系起来，到底配置什么，管理什么。
其实，明确了这个宾语，也就回答了这个问题：配置管理关注的焦点就是配置项。
为何配置管理工作内容中首先提及的是"识别配置项"！这是我们工作的核心，管理的对象。在开始配置管理工作之时，在制定配置管理计划之时，我们首先要做的第一件事就是要明确项目中所有配置项。
我们可以细想一下，配置管理中的几项工作哪项与配置项无关？版本控制就是控制配置项的版本；变更控制就是控制配置项的变更；配置审计就是对配置项进行物理审计或功能审计；发布管理就是控制配置项的发布；配置状态发布实际上就是发布配置项目前的状态。
为何我们说：在制定配置管理计划，制定配置管理策略的时候要依据项目需求来定！项目的需求是什么，实际就是对配置项管理的要求！不同的项目配置项不同，不同的项目对配置项的管理级别以及管理方式的要求是不同的。明确了这些，我们才能够考虑项目的配置管理策略，制定项目的配置管理计划，才可以说项目的配置管理工作启动了。
总结：配置管理，我可以这样理解：配置统一工作环境用来支撑配置项管理工作。
所悟之二：配置管理工作中是过程重要还是工具重要？
我在做配置管理工作的时候，被问到的最多问题就是关于配置管理工具的："为何这个工具老是报错？"很少有人向我提及："你制定的配置管理策略在某某方面操作起来有问题！"
我们用的配置管理工具都是比较成熟的产品，为何我们操作起来经常会有异常的问题出现，大家有想过这个问题吗？我认为开发人员想这问题就太简单了。每个软件产品都有内在的业务处理逻辑，业务处理逻辑在配置管理中就是我们要谈及的过程，就是配置管理策略，那么配置管理工具也是软件产品，道理自然一样。一般配置管理工具，如Microsoft VisualSourceSafe，工具将过程已经固化；高级配置管理工具，如ClearCase，工具本身只是为我们提供了一个平台，我们在此基础上可以定制我们想要的过程。不管是工具本身已经固化过程还是我们自己在工具基础上定制过程，只要过程是明确的，我们对过程理解透彻，即使出现问题的时候，你也可以想出：为何会出现这个问题！就我总结，很多问题都是因为对过程的不熟悉，误操作而导致的。以不变的过程应对万变的问题，我认为大部分问题都是可以解决的。
同样，我想到我们在推行质量工程的时候，LSSP（Linkage Standard Software Process）发布之时，在项目组实施之时，大家都惊呼："太多文档！"在预评估的时候，大家对SPI（Software Process Improvement）的期望都会提及："我们需要工具支持！"一样的道理！
我在这里不是全盘否定工具的作用，但是我们可以完全依赖工具吗？试想一下：如果对工具本身的处理过程都不能理解很清楚的人，工具对他真的很有效吗？难道工具真的是我们需要的吗，真的可以帮助我们提高工作效率吗？质量工程中做任何一件事都要考虑投入与产出，工具给我们带来的产出你明确了吗？以上问题你都很肯定的时候，那就是可以使用工具的时候。
总结：我认为，配置管理工作中重要的是过程。过程是本，在大家都很明确过程的时候，工具对过程，对大家工作的支撑作用是会显著的。
所悟之三：基线和Label到底是什么关系？
LSSP发布以后，有太多人问我："Label到底是什么？为何每次都是和基线同时出现？"
配置管理中抽象的概念比较多，基线就是其中之一。基线，顾名思义，是基准线，是项目组是下阶工作的起点。所以，对基线的确立将是非常慎重的一项工作，这将直接影响我们下阶段的工作。
一旦基线确立之后，那么Label就要隆重登场了。Label其实就是基线的实际体现形式。
总结：Label是基线在配置管理工具中的体现形式。通过Label，我们可以获取某一基线配置项的特定版本。
所悟之四：我们为什么要做内部发布？
系统版本发布，我们都很熟悉，不就是系统割接上线吗！配置管理中，我们把这种发布叫做"外部发布"，那么就必然有与其相对的"内部发布"。他们之间到底有什么区别，我们为何又要多出一项工作："内部发布"。
在产品投入正式生产之前，我们需要能够证明：我们的产品是可以顺利割接上线的；我们的产品是可以满足用户需求的。
这些信心从何而来？靠我们平时的演练，靠我们对产品的测试。
内部发布就是模拟系统割接上线，这种演习对于正式的割接是非常有好处的，其实我们的项目组是有在做的，只不过大家没有意识到这就是内部发布。例如：产品Alpha或Beta版本发布。
而且，这样我们可以随时访问产品：测试系统，熟悉系统，最终确认系统是否真正满足用户需求，是否真正好用。
内部发布，是给我们自己多几次机会，从而保证外部发布的成功。
一次总结，一次交流，彼此获益，何乐而不为！
http://bbs.scmroad.com/viewthread.php?tid=890&extra=page%3D1&frombbs=1 很不错的一篇文档.希望所有软件配置管理员都读一读.
然后大家一起来交流交流感想 想起某个老大的一句话：别人不理解，是因为偶们太超前！
做配置管理，总有这种感觉：
向项目经理们推广配置管理过程，他们总会说这些理论都懂，但没时间！
向技术人员推广配置管理过程，他们又会说只管编程，文档太麻烦，谁爱写谁写！
实施总会遇到阻力。
即使项目失败了、延期了，总结时抱怨都会：需求变更太多、版本没有控制、人员变动影响。。。。。。
但下一个项目照旧：变更不管理；
版本打个label都要催至少三遍（第一遍：发布版本了，代码库中打label了吗？第二遍：label命名不规范啊，看不出是什么项目的什么版本；第三遍：没注释，怎么知道这个版本是实现什么需求的呢？）；
服务器上文档、代码是否为最新版本也无人问津，当有人离职、有人加入时，才知道少这个、找不到那个。。。 原帖由 echo_shu 于 2008-9-22 12:34 发表 http://bbs.chinaunix.net/images/common/back.gif
想起某个老大的一句话：别人不理解，是因为偶们太超前！
做配置管理，总有这种感觉：
向项目经理们推广配置管理过程，他们总会说这些理论都懂，但没时间！
向技术人员推广配置管理过程，他们又会说只管编程， ...
如果遇到这种问题就要找自己的manager谈了.
总之配置管理是一个贯彻公司规章制度的职位,如果公司领导都没那个意识,下边的人是很难做起来的.没有压力,哪来的动力?而国内很多企业的领导,项目经理很少有多少丰富的项目经验的,他们体会不到配置管理带来的好处,或者仅限于表面,还指望他们能推动CM工作么?
如果领导也是那个态度,那么自己要么忍耐,要么就跳槽. 强制做CMO 原帖由 nicozhou 于 2008-10-2 21:39 发表 http://bbs.chinaunix.net/images/common/back.gif
强制做CMO
哈哈哈
你是被迫做CM的？
页:
[1]