集成流是產(chǎn)品穩定版本流，也是獲取項目發(fā)布程序的空間
由于這個(gè)項目屬于彼此之間需要緊密協(xié)作開(kāi)發(fā)的類(lèi)型，所以，我們采用復用流的方式，所有開(kāi)發(fā)人員共享一條開(kāi)發(fā)流。這樣，開(kāi)發(fā)人員在檢入文件時(shí)就可以看到彼此的修改結果，實(shí)現了集成的最大化。但是，由于多個(gè)開(kāi)發(fā)人員共享一個(gè)開(kāi)發(fā)流，如果存在對一個(gè)文件的并發(fā)修改，容易引起沖突；另外，這種方式也容易引起交付依賴(lài)，使得程序在提交時(shí)，必須按照一定次序進(jìn)行提交。
3.4 規范項目活動(dòng)類(lèi)別和顆粒度劃分
采用UCM方式的好處之一，就是項目成員對于配置庫的修改必須有活動(dòng)關(guān)聯(lián)，如果沒(méi)有分配給操作用戶(hù)的活動(dòng)，用戶(hù)就無(wú)法對配置庫進(jìn)行任何修改。這對于EIP這類(lèi)的維護型項目而言，源碼的修改獲得批準是非常重要的。
為了規范公司項目活動(dòng)分類(lèi)，公司在ClearQuest上完善、開(kāi)發(fā)了多個(gè)流程，包括缺陷流程、變更管理流程、任務(wù)流程、不一致問(wèn)題流程、測試管理流程等。同時(shí)，針對每個(gè)流程，我們都定義了相應的批準人員。例如，由缺陷分配人角色進(jìn)行缺陷的分配，由項目經(jīng)理進(jìn)行變更的分配。通過(guò)這種方式，可以保證項目成員處理的活動(dòng)都是得到批準的。
除了規范活動(dòng)類(lèi)別外，我們還規范活動(dòng)的顆粒度劃分。在公司內，我們要求針對每個(gè)case提交一個(gè)活動(dòng)。例如，對于EIP項目來(lái)說(shuō)，不能將業(yè)務(wù)部門(mén)一次提出的十個(gè)變更通過(guò)一個(gè)變更活動(dòng)來(lái)提交，也不能將測試過(guò)程中發(fā)現的多個(gè)缺陷通過(guò)一個(gè)缺陷活動(dòng)提交。通過(guò)對活動(dòng)顆粒度的限制，避免活動(dòng)顆粒度過(guò)大導致活動(dòng)生命周期過(guò)長(cháng)，這就起不到活動(dòng)控制的目的，同時(shí)也不利于項目管理人員掌握項目當前活動(dòng)狀態(tài)。
通過(guò)對活動(dòng)類(lèi)別和顆粒度劃分的規范，項目管理人員就可以利用ClearQuest對各種記錄類(lèi)型數據進(jìn)行分析得到的報表，來(lái)實(shí)時(shí)掌握項目的最新動(dòng)態(tài)，合理分配資源和調度開(kāi)發(fā)活動(dòng)。
3.5 定義合適的變更控制和發(fā)布流程
我們針對EIP項目的特點(diǎn)，定義了符合維護型項目特性的變更控制和發(fā)布流程，流程圖如下：
圖二 變更控制和發(fā)布流程圖
首先，規范維護項目的源碼修改過(guò)程。通過(guò)使用CCRC，開(kāi)發(fā)人員在處理活動(dòng)時(shí)，可以使用CCRC的“處理活動(dòng)”功能，快速切換當前處理的活動(dòng)，使他們可以選擇正確的活動(dòng)進(jìn)行源碼修改。通過(guò)UCM，一個(gè)開(kāi)發(fā)活動(dòng)可以自動(dòng)地同其變更集（封裝了所有用于實(shí)現該活動(dòng)的項目工件）相關(guān)聯(lián)，這樣避免了開(kāi)發(fā)人員手動(dòng)跟蹤所有文件變更。
其次，規范維護項目測試過(guò)程。當開(kāi)發(fā)人員完成活動(dòng)的處理，需要提交測試時(shí)，由項目管理人員提交測試任務(wù)，配置管理員將需要測試對應的活動(dòng)交付（deliver）到測試流，并打一條測試基線(xiàn)。配置管理員使用取基線(xiàn)差程序獲取更新包，并將更新包更新到測試環(huán)境。測試人員在測試環(huán)境上進(jìn)行冒煙測試，確認基本集測試通過(guò)后，然后對此次測試任務(wù)包含的活動(dòng)進(jìn)行驗證。一旦測試通過(guò)，完成該測試任務(wù)后，測試人員提交測試報告給項目成員。如果測試不通過(guò)，則要求開(kāi)發(fā)人員修改，并重新進(jìn)行該測試過(guò)程。
圖三 取基線(xiàn)差程序
最后，規范維護項目發(fā)布過(guò)程。在發(fā)布時(shí)間到達后，項目經(jīng)理提交發(fā)布任務(wù)給配置管理員。配置管理員將測試流上多次確認測試通過(guò)的活動(dòng)集交付（deliver）到集成流，并在集成流上打一條產(chǎn)品基線(xiàn)。配置管理員通過(guò)取基線(xiàn)差程序獲取更新包后，然后更新發(fā)布測試環(huán)境，由測試人員進(jìn)行發(fā)布確認測試。發(fā)布確認測試主要是對系統基本集進(jìn)行驗證。當發(fā)布確認測試通過(guò)后，配置管理員將更新包發(fā)給發(fā)布專(zhuān)員，由發(fā)布專(zhuān)員更新到生產(chǎn)環(huán)境。通過(guò)這種方式，可以保證發(fā)布程序是由配置管理員從集成流獲取，同時(shí)確保發(fā)布程序是經(jīng)過(guò)測試的。
3.6 規避活動(dòng)依賴(lài)并控制變更處理順序
在并行開(kāi)發(fā)章節中我們提到了共享開(kāi)發(fā)流方式很容易引起交付依賴(lài)。在EIP項目中，開(kāi)發(fā)人員同時(shí)面對變更、缺陷、任務(wù)等多個(gè)活動(dòng)，很容易出現活動(dòng)的依賴(lài)。一旦出現活動(dòng)依賴(lài)，配置管理員在提取更新包供測試時(shí)，會(huì )存在一定的困難。如果取文件的最新版本，有可能因最新的文件包含某些不穩定的新增功能而導致編譯失敗。
為了解決這個(gè)問(wèn)題，我們通過(guò)使用觸發(fā)器的方式進(jìn)行開(kāi)發(fā)流活動(dòng)依賴(lài)的限制。當源碼上一版本關(guān)聯(lián)的活動(dòng)未驗證通過(guò)并關(guān)閉時(shí)，則不允許該源碼檢出。這個(gè)方法不僅控制活動(dòng)的依賴(lài)，而且從限制了EIP項目控制變更的處理順序（第一批變更未處理完，不進(jìn)行第二批變更的處理）。
四、小結
采用上述方法，EIP項目杜絕了發(fā)布程序版本混亂的問(wèn)題，而且減少了變更處理周期，保證了發(fā)布進(jìn)度�，F在項目組從開(kāi)始處理變更，測試變更，到該變更發(fā)布，一般只需要1周時(shí)間，工作效率提高了200%，業(yè)務(wù)部門(mén)對該項目的滿(mǎn)意度也增加了。
這里需要提醒的是，新方法雖好，但是在引入新方法初期，一定需要有專(zhuān)人配合、指導項目組使用，以保證新方法成功實(shí)施。在EIP項目在引入該方法初期，項目管理人員不理解，覺(jué)得增加了人力成本（需要多個(gè)角色人員）、環(huán)境投入（需要額外的發(fā)布測試環(huán)境），影響了開(kāi)發(fā)進(jìn)度（文件的檢出修改限制）；開(kāi)發(fā)人員覺(jué)得開(kāi)發(fā)變麻煩了（文件的檢出修改限制）。通過(guò)管理員的耐心解釋和輔導，經(jīng)過(guò)三個(gè)星期的磨合與適應后，EIP項目已完全遵循這種方法進(jìn)行配置管理和發(fā)布管理工作。
通過(guò)上述例子說(shuō)明，采用IBM Rational ClearCase和ClearQuest，實(shí)實(shí)在在的幫助公司的維護型項目提高了配置管理能力，增強了公司的競爭力。
文章來(lái)源于領(lǐng)測軟件測試網(wǎng) http://kjueaiud.com/
