摘要：針對在實際維護項目配置管理工作中的一個突出問題，即維護項目如何進行配置管理，并可以將配置管理工具有效支持維護項目的發(fā)布工作，筆者在實際工作中進行摸索和嘗試。本文是對筆者在維護項目配置管理工作實踐的總結。
隨著信息化建設的日益成熟，大多數(shù)公司都建立了自己內部的信息化平臺，對公司內部進行高效的管理，并能提高工作、溝通效率。
筆者所在的公司位于國內主要39家銀行應用軟件企業(yè)的第一梯隊，屬于IT綜合服務商中的佼佼者。公司目前處理日常工作的信息化平臺(Enterprise Infomation Platform，以下簡稱為EIP平臺)，是根據(jù)自身的情況特點及工作流程，收集了各個部門的實際使用需求，由公司研發(fā)部門自行研發(fā)的。公司所有的職能部門都通過EIP平臺處理日常工作。
隨著公司業(yè)務的不斷發(fā)展和流程的不斷優(yōu)化，各職能部門對EIP平臺也不斷提出新的需求，EIP項目需要不斷的完善和改進，以符合公司新的流程及滿足新的需求。因此，EIP項目是一個典型的持續(xù)維護型項目。本文就以此項目為例，來說明如何對維護型項目進行配置管理工作。
一、問題的提出
在使用CVS進行配置管理時，EIP項目經(jīng)常發(fā)生程序更新錯誤，不斷收到業(yè)務部門對變更處理不及時的抱怨。統(tǒng)計數(shù)據(jù)表示項目組從開始處理變更到變更發(fā)布，一般需要3周時間。經(jīng)過集團配置管理員、QA、測試專家、項目經(jīng)理、開發(fā)代表分析發(fā)現(xiàn)，主要是由于下面四個原因導致這些問題的產(chǎn)生：
1.該項目的發(fā)布程序，是從開發(fā)人員機器上的CVS編輯區(qū)取出最新程序，然后完全覆蓋生產(chǎn)環(huán)境的程序。由于開發(fā)人員不能詳細的、準確的說出當前缺陷或變更修改涉及的源碼，所以開發(fā)人員只能使用完全覆蓋的方式來更新生產(chǎn)環(huán)境程序。因為開發(fā)人員的環(huán)境仍在進行新變更的處理，所以這種操作方式極易出現(xiàn)發(fā)布到生產(chǎn)環(huán)境的程序出現(xiàn)版本錯誤的情況。
2.沒有控制變更處理順序。開發(fā)人員通常是多個變更混在一起處理，如果多個變更修改同一文件時，只能等待這些變更都處理完后才能提交程序并進行生產(chǎn)環(huán)境的發(fā)布。這就導致了變更更新緩慢的情況。
3.缺少獨立的發(fā)布前測試環(huán)節(jié)。由于缺少獨立的發(fā)布前的確認測試環(huán)節(jié)，而將程序版本問題在更新到生產(chǎn)環(huán)境后才爆發(fā)。
4.一人承擔多個角色。在EIP項目中，一個開發(fā)人員承擔著測試人員(進行系統(tǒng)發(fā)布前集成測試)、配置管理員(提供發(fā)布更新程序)、需求分析員(屬于自己模塊的變更自己決定處理順序)。
二、基本思路
首選根據(jù)公司業(yè)務發(fā)展需要選取合適的配置管理和變更管理工具;其次對角色進行細分;再次設置合適的并行開發(fā)模式;然后規(guī)范項目活動類別和顆粒度劃分;最后定義合適的變更控制和發(fā)布流程。
三、維護項目配置管理工作
3.1 選取合適的配置管理和變更管理工具
為了解決公司配置管理中存在的問題，公司在經(jīng)過對業(yè)界的配置管理工具進行對比和試用后，綜合各方面因素后，在2006年引入了IBM Rational ClearCase和ClearQuest，替換CVS和Bugzilla作為集團配置管理和變更管理工具。由于EIP項目在配置管理中存在著眾多問題，所以它率先導入ClearCase和ClearQuest進行項目的配置管理工作。
3.2 角色細分
在EIP項目配置管理工作存在的問題之一，就是開發(fā)人員承擔著過多角色的工作。所以，在引入ClearCase和ClearQuest后，我們?yōu)镋IP項目進行了角色細分，分配了專職測試人員和配置管理員，定義了專職的需求分析員，明確了項目經(jīng)理的職責。
測試人員負責變更處理完畢的確認及發(fā)布確認測試，開發(fā)人員不再負責發(fā)布確認測試，而只負責單元測試和自測。
配置管理員負責提供測試環(huán)境的更新程序、生產(chǎn)環(huán)境的更新程序。
需求管理員作為變更接收人，決策需求變更的處理順序。
項目經(jīng)理負責批準變更的處理。
3.3 設置合適的并行開發(fā)模式
考慮到EIP項目的實際情況，我們采用IBM的UCM(統(tǒng)一變更管理)解決方案作為它的配置管理和變更管理解決方案。對EIP項目發(fā)布版本錯誤問題產(chǎn)生原因進行分析后，我們采用如下流策略作為該項目的并行開發(fā)模式。
上述流策略中，我們采用三層流架構：開發(fā)流、測試流、集成流進行項目配置管理工作。其中，
開發(fā)流是開發(fā)人員日常工作使用的工作空間
測試流是測試人員獲取測試程序的工作空間
集成流是產(chǎn)品穩(wěn)定版本流，也是獲取項目發(fā)布程序的空間
由于這個項目屬于彼此之間需要緊密協(xié)作開發(fā)的類型，所以，我們采用復用流的方式，所有開發(fā)人員共享一條開發(fā)流。這樣，開發(fā)人員在檢入文件時就可以看到彼此的修改結果，實現(xiàn)了集成的最大化。但是，由于多個開發(fā)人員共享一個開發(fā)流，如果存在對一個文件的并發(fā)修改，容易引起沖突;另外，這種方式也容易引起交付依賴，使得程序在提交時，必須按照一定次序進行提交。
浙公網(wǎng)安備 33010802003509號
杭州講師網(wǎng)絡科技有限公司
