摘要：针对在实际维护项目配置管理工作中的一个突出问题，即维护项目如何进行配置管理，并可以将配置管理工具有效支持维护项目的发布工作，笔者在实际工作中进行摸索和尝试。本文是对笔者在维护项目配置管理工作实践的总结。
关键词：配置管理 维护项目 变更控制 发布管理
随着信息化建设的日益成熟，大多数公司都建立了自己内部的信息化平台，对公司内部进行高效的管理，并能提高工作、沟通效率。
笔者所在的公司位于国内主要39家银行应用软件企业的第一梯队，属于IT综合服务商中的佼佼者。公司目前处理日常工作的信息化平台（Enterprise Infomation Platform，以下简称为EIP平台），是根据自身的情况特点及工作流程，收集了各个部门的实际使用需求，由公司研发部门自行研发的。公司所有的职能部门都通过EIP平台处理日常工作。
随着公司业务的不断发展和流程的不断优化，各职能部门对EIP平台也不断提出新的需求，EIP项目需要不断的完善和改进，以符合公司新的流程及满足新的需求。因此，EIP项目是一个典型的持续维护型项目。本文就以此项目为例，来说明如何对维护型项目进行配置管理工作。
一、问题的提出
在使用CVS进行配置管理时，EIP项目经常发生程序更新错误，不断收到业务部门对变更处理不及时的抱怨。统计数据表示项目组从开始处理变更到变更发布，一般需要3周时间。经过集团配置管理员、QA、测试专家、项目经理、开发代表分析发现，主要是由于下面四个原因导致这些问题的产生：
1. 该项目的发布程序，是从开发人员机器上的CVS编辑区取出最新程序，然后完全覆盖生产环境的程序。由于开发人员不能详细的、准确的说出当前缺陷或变更修改涉及的源码，所以开发人员只能使用完全覆盖的方式来更新生产环境程序。因为开发人员的环境仍在进行新变更的处理，所以这种操作方式极易出现发布到生产环境的程序出现版本错误的情况。
2. 没有控制变更处理顺序。开发人员通常是多个变更混在一起处理，如果多个变更修改同一文件时，只能等待这些变更都处理完后才能提交程序并进行生产环境的发布。这就导致了变更更新缓慢的情况。
3. 缺少独立的发布前测试环节。由于缺少独立的发布前的确认测试环节，而将程序版本问题在更新到生产环境后才爆发。
4. 一人承担多个角色。在EIP项目中，一个开发人员承担着测试人员（进行系统发布前集成测试）、配置管理员（提供发布更新程序）、需求分析员（属于自己模块的变更自己决定处理顺序）。
二、基本思路
首选根据公司业务发展需要选取合适的配置管理和变更管理工具；其次对角色进行细分；再次设置合适的并行开发模式；然后规范项目活动类别和颗粒度划分；最后定义合适的变更控制和发布流程。
三、维护项目配置管理工作
3.1 选取合适的配置管理和变更管理工具
为了解决公司配置管理中存在的问题，公司在经过对业界的配置管理工具进行对比和试用后，综合各方面因素后，在2006年引入了IBM Rational ClearCase和ClearQuest，替换CVS和Bugzilla作为集团配置管理和变更管理工具。由于EIP项目在配置管理中存在着众多问题，所以它率先导入ClearCase和ClearQuest进行项目的配置管理工作。
3.2 角色细分
在EIP项目配置管理工作存在的问题之一，就是开发人员承担着过多角色的工作。所以，在引入ClearCase和ClearQuest后，我们为EIP项目进行了角色细分，分配了专职测试人员和配置管理员，定义了专职的需求分析员，明确了项目经理的职责。
l 测试人员负责变更处理完毕的确认及发布确认测试，开发人员不再负责发布确认测试，而只负责单元测试和自测。
l 配置管理员负责提供测试环境的更新程序、生产环境的更新程序。
l 需求管理员作为变更接收人，决策需求变更的处理顺序。
l 项目经理负责批准变更的处理。
3.3 设置合适的并行开发模式
考虑到EIP项目的实际情况，我们采用IBM的UCM（统一变更管理）解决方案作为它的配置管理和变更管理解决方案。对EIP项目发布版本错误问题产生原因进行分析后，我们采用如下流策略作为该项目的并行开发模式。
图一 EIP项目ClearCase流策略图
上述流策略中，我们采用三层流架构：开发流、测试流、集成流进行项目配置管理工作。其中，
l 开发流是开发人员日常工作使用的工作空间
l 测试流是测试人员获取测试程序的工作空间
l 集成流是产品稳定版本流，也是获取项目发布程序的空间
由于这个项目属于彼此之间需要紧密协作开发的类型，所以，我们采用复用流的方式，所有开发人员共享一条开发流。这样，开发人员在检入文件时就可以看到彼此的修改结果，实现了集成的最大化。但是，由于多个开发人员共享一个开发流，如果存在对一个文件的并发修改，容易引起冲突；另外，这种方式也容易引起交付依赖，使得程序在提交时，必须按照一定次序进行提交。
3.4 规范项目活动类别和颗粒度划分
采用UCM方式的好处之一，就是项目成员对于配置库的修改必须有活动关联，如果没有分配给操作用户的活动，用户就无法对配置库进行任何修改。这对于EIP这类的维护型项目而言，源码的修改获得批准是非常重要的。
为了规范公司项目活动分类，公司在ClearQuest上完善、开发了多个流程，包括缺陷流程、变更管理流程、任务流程、不一致问题流程、测试管理流程等。同时，针对每个流程，我们都定义了相应的批准人员。例如，由缺陷分配人角色进行缺陷的分配，由项目经理进行变更的分配。通过这种方式，可以保证项目成员处理的活动都是得到批准的。
除了规范活动类别外，我们还规范活动的颗粒度划分。在公司内，我们要求针对每个case提交一个活动。例如，对于EIP项目来说，不能将业务部门一次提出的十个变更通过一个变更活动来提交，也不能将测试过程中发现的多个缺陷通过一个缺陷活动提交。通过对活动颗粒度的限制，避免活动颗粒度过大导致活动生命周期过长，这就起不到活动控制的目的，同时也不利于项目管理人员掌握项目当前活动状态。
通过对活动类别和颗粒度划分的规范，项目管理人员就可以利用ClearQuest对各种记录类型数据进行分析得到的报表，来实时掌握项目的最新动态，合理分配资源和调度开发活动。
3.5 定义合适的变更控制和发布流程
我们针对EIP项目的特点，定义了符合维护型项目特性的变更控制和发布流程，流程图如下：
图二 变更控制和发布流程图
首先，规范维护项目的源码修改过程。通过使用CCRC，开发人员在处理活动时，可以使用CCRC的“处理活动”功能，快速切换当前处理的活动，使他们可以选择正确的活动进行源码修改。通过UCM，一个开发活动可以自动地同其变更集（封装了所有用于实现该活动的项目工件）相关联，这样避免了开发人员手动跟踪所有文件变更。
其次，规范维护项目测试过程。当开发人员完成活动的处理，需要提交测试时，由项目管理人员提交测试任务，配置管理员将需要测试对应的活动交付（deliver）到测试流，并打一条测试基线。配置管理员使用取基线差程序获取更新包，并将更新包更新到测试环境。测试人员在测试环境上进行冒烟测试，确认基本集测试通过后，然后对此次测试任务包含的活动进行验证。一旦测试通过，完成该测试任务后，测试人员提交测试报告给项目成员。如果测试不通过，则要求开发人员修改，并重新进行该测试过程。
图三 取基线差程序
最后，规范维护项目发布过程。在发布时间到达后，项目经理提交发布任务给配置管理员。配置管理员将测试流上多次确认测试通过的活动集交付（deliver）到集成流，并在集成流上打一条产品基线。配置管理员通过取基线差程序获取更新包后，然后更新发布测试环境，由测试人员进行发布确认测试。发布确认测试主要是对系统基本集进行验证。当发布确认测试通过后，配置管理员将更新包发给发布专员，由发布专员更新到生产环境。通过这种方式，可以保证发布程序是由配置管理员从集成流获取，同时确保发布程序是经过测试的。
3.6 规避活动依赖并控制变更处理顺序
在并行开发章节中我们提到了共享开发流方式很容易引起交付依赖。在EIP项目中，开发人员同时面对变更、缺陷、任务等多个活动，很容易出现活动的依赖。一旦出现活动依赖，配置管理员在提取更新包供测试时，会存在一定的困难。如果取文件的最新版本，有可能因最新的文件包含某些不稳定的新增功能而导致编译失败。
为了解决这个问题，我们通过使用触发器的方式进行开发流活动依赖的限制。当源码上一版本关联的活动未验证通过并关闭时，则不允许该源码检出。这个方法不仅控制活动的依赖，而且从限制了EIP项目控制变更的处理顺序（第一批变更未处理完，不进行第二批变更的处理）。
四、小结
采用上述方法，EIP项目杜绝了发布程序版本混乱的问题，而且减少了变更处理周期，保证了发布进度。现在项目组从开始处理变更，测试变更，到该变更发布，一般只需要1周时间，工作效率提高了200%，业务部门对该项目的满意度也增加了。
这里需要提醒的是，新方法虽好，但是在引入新方法初期，一定需要有专人配合、指导项目组使用，以保证新方法成功实施。在EIP项目在引入该方法初期，项目管理人员不理解，觉得增加了人力成本（需要多个角色人员）、环境投入（需要额外的发布测试环境），影响了开发进度（文件的检出修改限制）；开发人员觉得开发变麻烦了（文件的检出修改限制）。通过管理员的耐心解释和辅导，经过三个星期的磨合与适应后，EIP项目已完全遵循这种方法进行配置管理和发布管理工作。
通过上述例子说明，采用IBM Rational ClearCase和ClearQuest，实实在在的帮助公司的维护型项目提高了配置管理能力，增强了公司的竞争力。
参考文档
《第三代配置管理解决方案 统一变更管理（UCM）》 Rational Software，2004
《公司配置及统一变更管理实施方案.doc》 2006
streampolicy.JPG来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/13180590/viewspace-201979/，如需转载，请注明出处，否则将追究法律责任。
转载于:http://blog.itpub.net/13180590/viewspace-201979/
1319
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
