在使用CVS進(jìn)行配置管理時(shí)，EIP項目經(jīng)常發(fā)生程序更新錯誤，不斷收到業(yè)務(wù)部門(mén)對變更處理不及時(shí)的抱怨。統計數據表示項目組從開(kāi)始處理變更到變更發(fā)布，一般需要3周時(shí)間。經(jīng)過(guò)集團配置管理員、QA、測試專(zhuān)家、項目經(jīng)理、開(kāi)發(fā)代表分析發(fā)現，主要是由于下面四個(gè)原因導致這些問(wèn)題的產(chǎn)生：
1.該項目的發(fā)布程序，是從開(kāi)發(fā)人員機器上的CVS編輯區取出最新程序，然后完全覆蓋生產(chǎn)環(huán)境的程序。由于開(kāi)發(fā)人員不能詳細的、準確的說(shuō)出當前缺陷或變更修改涉及的源碼，所以開(kāi)發(fā)人員只能使用完全覆蓋的方式來(lái)更新生產(chǎn)環(huán)境程序。因為開(kāi)發(fā)人員的環(huán)境仍在進(jìn)行新變更的處理，所以這種操作方式極易出現發(fā)布到生產(chǎn)環(huán)境的程序出現版本錯誤的情況。
2.沒(méi)有控制變更處理順序。開(kāi)發(fā)人員通常是多個(gè)變更混在一起處理，如果多個(gè)變更修改同一文件時(shí)，只能等待這些變更都處理完后才能提交程序并進(jìn)行生產(chǎn)環(huán)境的發(fā)布。這就導致了變更更新緩慢的情況。
3.缺少獨立的發(fā)布前測試環(huán)節。由于缺少獨立的發(fā)布前的確認測試環(huán)節，而將程序版本問(wèn)題在更新到生產(chǎn)環(huán)境后才爆發(fā)。
4.一人承擔多個(gè)角色。在EIP項目中，一個(gè)開(kāi)發(fā)人員承擔著(zhù)測試人員（進(jìn)行系統發(fā)布前集成測試）、配置管理員（提供發(fā)布更新程序）、需求分析員（屬于自己模塊的變更自己決定處理順序）。
二、基本思路
首選根據公司業(yè)務(wù)發(fā)展需要選取合適的配置管理和變更管理工具；其次對角色進(jìn)行細分；再次設置合適的并行開(kāi)發(fā)模式；然后規范項目活動(dòng)類(lèi)別和顆粒度劃分；最后定義合適的變更控制和發(fā)布流程。
三、維護項目配置管理工作
3.1 選取合適的配置管理和變更管理工具
為了解決公司配置管理中存在的問(wèn)題，公司在經(jīng)過(guò)對業(yè)界的配置管理工具進(jìn)行對比和試用后，綜合各方面因素后，在2006年引入了IBM Rational ClearCase和ClearQuest，替換CVS和Bugzilla作為集團配置管理和變更管理工具。由于EIP項目在配置管理中存在著(zhù)眾多問(wèn)題，所以它率先導入ClearCase和ClearQuest進(jìn)行項目的配置管理工作。
3.2 角色細分
在EIP項目配置管理工作存在的問(wèn)題之一，就是開(kāi)發(fā)人員承擔著(zhù)過(guò)多角色的工作。所以，在引入ClearCase和ClearQuest后，我們?yōu)镋IP項目進(jìn)行了角色細分，分配了專(zhuān)職測試人員和配置管理員，定義了專(zhuān)職的需求分析員，明確了項目經(jīng)理的職責。
測試人員負責變更處理完畢的確認及發(fā)布確認測試，開(kāi)發(fā)人員不再負責發(fā)布確認測試，而只負責單元測試和自測。
配置管理員負責提供測試環(huán)境的更新程序、生產(chǎn)環(huán)境的更新程序。
需求管理員作為變更接收人，決策需求變更的處理順序。
項目經(jīng)理負責批準變更的處理。
3.3 設置合適的并行開(kāi)發(fā)模式
考慮到EIP項目的實(shí)際情況，我們采用IBM的UCM（統一變更管理）解決方案作為它的配置管理和變更管理解決方案。對EIP項目發(fā)布版本錯誤問(wèn)題產(chǎn)生原因進(jìn)行分析后，我們采用如下流策略作為該項目的并行開(kāi)發(fā)模式。
圖一 EIP項目ClearCase流策略圖
上述流策略中，我們采用三層流架構：開(kāi)發(fā)流、測試流、集成流進(jìn)行項目配置管理工作。其中，
開(kāi)發(fā)流是開(kāi)發(fā)人員日常工作使用的工作空間
測試流是測試人員獲取測試程序的工作空間
延伸閱讀
文章來(lái)源于領(lǐng)測軟件測試網(wǎng) http://kjueaiud.com/
