在使用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流策略圖
上述流策略中，我們采用三層流架構：開發流、測試流、集成流進行項目配置管理工作。其中，
開發流是開發人員日常工作使用的工作空間
測試流是測試人員獲取測試程序的工作空間
延伸閱讀
文章來源于領測軟件測試網 http://www.anti-gravitydesign.com/
