使用ClearCase和ClearQuest改进维护项目的配置管理工作-UML软件工程组织-火龙果软件

UML软件工程组织

使用ClearCase和ClearQuest改进维护项目的配置管理工作

2008-04-25 作者: Judy Shen 来源: Judy Shen的专栏

摘要：针对在实际维护项目配置管理工作中的一个突出问题，即维护项目如何进行配置管理，并可以将配置管理工具有效支持维护项目的发布工作，笔者在实际工作中进行摸索和尝试。本文是对笔者在维护项目配置管理工作实践的总结。

关键词：配置管理维护项目变更控制发布管理

随着信息化建设的日益成熟，大多数公司都建立了自己内部的信息化平台，对公司内部进行高效的管理，并能提高工作、沟通效率。

笔者所在的公司位于国内主要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项目进行了角色细分，分配了专职测试人员和配置管理员，定义了专职的需求分析员，明确了项目经理的职责。

测试人员负责变更处理完毕的确认及发布确认测试，开发人员不再负责发布确认测试，而只负责单元测试和自测。

配置管理员负责提供测试环境的更新程序、生产环境的更新程序。

需求管理员作为变更接收人，决策需求变更的处理顺序。

项目经理负责批准变更的处理。

3.3 设置合适的并行开发模式

考虑到EIP项目的实际情况，我们采用IBM的UCM（统一变更管理）解决方案作为它的配置管理和变更管理解决方案。对EIP项目发布版本错误问题产生原因进行分析后，我们采用如下流策略作为该项目的并行开发模式。

图一 EIP项目ClearCase流策略图

上述流策略中，我们采用三层流架构：开发流、测试流、集成流进行项目配置管理工作。其中，

开发流是开发人员日常工作使用的工作空间

测试流是测试人员获取测试程序的工作空间

集成流是产品稳定版本流，也是获取项目发布程序的空间

由于这个项目属于彼此之间需要紧密协作开发的类型，所以，我们采用复用流的方式，所有开发人员共享一条开发流。这样，开发人员在检入文件时就可以看到彼此的修改结果，实现了集成的最大化。但是，由于多个开发人员共享一个开发流，如果存在对一个文件的并发修改，容易引起冲突；另外，这种方式也容易引起交付依赖，使得程序在提交时，必须按照一定次序进行提交。