在使用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流策略图
上述流策略中，我们采用三层流架构：开发流、测试流、集成流进行项目配置管理工作。其中，
开发流是开发人员日常工作使用的工作空间
测试流是测试人员获取测试程序的工作空间
延伸阅读
文章来源于领测软件测试网 https://www.ltesting.net/
