使用ClearCase和ClearQuest改進維護項目的配置管理工作

摘要：針對在實際維護項目配置管理工作中的一個突出問題，即維護項目如何進行配置管理，并可以將配置管理工具有效支持維護項目的發布工作，筆者在實際工作中進行摸索和嘗試。本文是對筆者在維護項目配置管理工作實踐的總結。

關鍵詞：配置管理維護項目變更控制發布管理

    隨著信息化建設的日益成熟，大多數公司都建立了自己內部的信息化平臺，對公司內部進行高效的管理，并能提高工作、溝通效率。

    筆者所在的公司位于國內主要39家銀行應用軟件企業的第一梯隊，屬于IT綜合服務商中的佼佼者。公司目前處理日常工作的信息化平臺（Enterprise Infomation Platform，以下簡稱為EIP平臺），是根據自身的情況特點及工作流程，收集了各個部門的實際使用需求，由公司研發部門自行研發的。公司所有的職能部門都通過EIP平臺處理日常工作。

    隨著公司業務的不斷發展和流程的不斷優化，各職能部門對EIP平臺也不斷提出新的需求，EIP項目需要不斷的完善和改進，以符合公司新的流程及滿足新的需求。因此，EIP項目是一個典型的持續維護型項目。本文就以此項目為例，來說明如何對維護型項目進行配置管理工作。

一、問題的提出

    在使用CVS進行配置管理時，EIP項目經常發生程序更新錯誤，不斷收到業務部門對變更處理不及時的抱怨。統計數據表示項目組從開始處理變更到變更發布，一般需要3周時間。經過集團配置管理員、QA、測試專家、項目經理、開發代表分析發現，主要是由于下面四個原因導致這些問題的產生：

1.        該項目的發布程序，是從開發人員機器上的CVS編輯區取出最新程序，然后完全覆蓋生產環境的程序。由于開發人員不能詳細的、準確的說出當前缺陷或變更修改涉及的源碼，所以開發人員只能使用完全覆蓋的方式來更新生產環境程序。因為開發人員的環境仍在進行新變更的處理，所以這種操作方式極易出現發布到生產環境的程序出現版本錯誤的情況。

2.        沒有控制變更處理順序。開發人員通常是多個變更混在一起處理，如果多個變更修改同一文件時，只能等待這些變更都處理完后才能提交程序并進行生產環境的發布。這就導致了變更更新緩慢的情況。

3.        缺少獨立的發布前測試環節。由于缺少獨立的發布前的確認測試環節，而將程序版本問題在更新到生產環境后才爆發。

4.        一人承擔多個角色。在EIP項目中，一個開發人員承擔著測試人員（進行系統發布前集成測試）、配置管理員（提供發布更新程序）、需求分析員（屬于自己模塊的變更自己決定處理順序）。

二、基本思路

    首選根據公司業務發展需要選取合適的配置管理和變更管理工具；其次對角色進行細分；再次設置合適的并行開發模式；然后規范項目活動類別和顆粒度劃分；最后定義合適的變更控制和發布流程。

三、維護項目配置管理工作

    為了解決公司配置管理中存在的問題，公司在經過對業界的配置管理工具進行對比和試用后，綜合各方面因素后，在2006年引入了IBM Rational ClearCase和ClearQuest，替換CVS和Bugzilla作為集團配置管理和變更管理工具。由于EIP項目在配置管理中存在著眾多問題，所以它率先導入ClearCase和ClearQuest進行項目的配置管理工作。

    在EIP項目配置管理工作存在的問題之一，就是開發人員承擔著過多角色的工作。所以，在引入ClearCase和ClearQuest后，我們為EIP項目進行了角色細分，分配了專職測試人員和配置管理員，定義了專職的需求分析員，明確了項目經理的職責。

l        測試人員負責變更處理完畢的確認及發布確認測試，開發人員不再負責發布確認測試，而只負責單元測試和自測。

l        配置管理員負責提供測試環境的更新程序、生產環境的更新程序。

l        需求管理員作為變更接收人，決策需求變更的處理順序。

l        項目經理負責批準變更的處理。

    考慮到EIP項目的實際情況，我們采用IBM的UCM（統一變更管理）解決方案作為它的配置管理和變更管理解決方案。對EIP項目發布版本錯誤問題產生原因進行分析后，我們采用如下流策略作為該項目的并行開發模式。

原文轉自：http://www.anti-gravitydesign.com