|
1.1 目的 1.2 概念
2.1 計劃 配置管理切換計劃的主要內容包括進度、資源等。 項目的規模與所處的階段不同，則配置管理切換所需要的時間也不同。一個20人左右，開發進度約達到計劃的一半，代碼量達到50K左右的項目，從開始計劃到配置管理完全切換到ClearCase，最少需要3-4周時間。如果盲目的追求進度，想在1-2周內切換完成，則可能在切換后產生一系列后遺癥，如版本丟失、版本錯誤甚至可能會有部分項目組成員抵制，從而使項目開發進程中部分工作不能納入配置管理之下。 進度安排建議：根據項目的情況用5-15個工作日進行準備，配置庫的遷移需要5個工作日左右的時間，配置管理工程師要用5-10個工作日的跟進以使項目組成員熟悉并不再需要幫助。 任何計劃都有一個前提：資源，不同的資源會導致不同的進度與成本。在配置管理切換中三類資源非常重要：經過培訓并且有ClearCase經驗的配置管理工程師；經過培訓并了解ClearCase UCM概念的項目經理與架構師；Rational工程師的及時支持。 配置管理工程師在這3-4周時間內要沒有其他的任務的打擾，全部的時間應用于該項目的配置切換；每個項目在配置切換的準備階段如果有Rational工程師的現場支持會少走許多彎路。 為了更好的完成工作，配置管理工程師必須經過系統的ClearCase的培訓，同時為了提高配置管理工程師的能力，建議在內部建立一個獨立的試驗環境，可以讓配置管理工程師從安裝配置Server開始，進行ClearCase的各種功能的操作試驗，以獲得經驗。 2.2 準備 首先，要決定是應用ClearCase UCM還是Base ClearCase，UCM模式是基于Base ClearCase應用Activity管理變更的一種模式。如果項目組全部在UNIX上進行開發，比較熟悉CVS，對命令行及Shell很熟悉，項目團隊配合時間較長，有專職配置管理工程師，建議應用Base ClearCase，但是需要自行開發腳本，以利于項目組成員的使用；跨平臺項目、配置管理工程師是與其他項目共用的、需要對項目的進度與活動有較高的透明度等建議應用UCM模式。本文主要探討UCM模式。 在準備的時候要確定當前項目與其他的項目的關系，以確定PVOB的建立，如果項目和其他項目的關系不是很緊密，建議創建一個獨立的PVOB。因為一般PVOB不占用過多的資源。 2.2.1 配置模式 PVOB建立完成后，要根據項目的實際情況確定項目的開發模式，這里給出一些建議。 2.2.1.1 共享流模式 項目只有一個單獨的集成流，沒有開發流。適用于調研項目或規模較小，且目標單一，不會同時有多個變更存在的項目。比較大的項目也可以在實際項目的初始階段建立一個UCM Project，采用共享流模式，在需求完成后，在這個Project的Component上建立Final基線，在這個基線上建立一個新的多開發流模式的UCM Project進行設計與編碼。 優點：控制簡單，如果設置的是Dynamic View，每個人的修改，其他人可以立即看到，不需要deliver，對有大量文檔的項目較適合；不需要針對Deliver及Rebase設置大量的基線，配置管理人員的工作相對較少；同時項目配置管理的Policy也比較簡單，不需要考慮太多。 缺點：如果同時支持多個不同的客戶或同時有多個變更，這些變更之間互相影響，則會產生開發的混亂。 在Clearcase中共享流模式也支持同時多個用戶對同一文件進行Check out操作，并在Check in時進行歸并。但是如果多人對一個Element進行Check out操作時，只有一個人可以應用Reserved checkout，其他的項目組成員只能進行Unreserved Checkout。Reserved Checkout保證了開發人員是在最新的一個版本上進行Checkout，只有在Reserved Checkout的人Check in之后才可以Check in并進行歸并。Reserved與Unreserved的區別可見圖一。
2.2.1.2 多開發流模式 項目中有多個不同的開發流，每個開發流都是一個獨立的分支，如果項目需要還可以建立多層次的分支，支持并行開發，適于超過10人，較復雜的項目。如果項目極復雜，可以分為多層開發流與集成流，如圖二。優點：可以并行開發，每個Stream都相當于一個獨立的開發環境，每個人之間的工作不會互相產生干擾；可以通過Policy的設置更好的進行配置管理。 缺點：不同的Stream之間的Deliver與Rebase會產生問題；在merge時也有可能會產生問題，而且對Word等二進制文件的merge支持不好；在修改完成之后，每個Stream上的修改只有deliver與Rebase才能被其他的stream應用，不能及時反映變化；Policy的設置較復雜。 在多開發流模式下可以根據需要將某個stream設置為只讀模式。 建議：可以根據需要建立一個多開發流模式的Project，但是在初期階段不設立開發流，在進行詳細設計階段后再建立相應的開發流。
2.2.1.3 Project組模式 Project組模式是以上兩種模式的組合，適用于產品類項目，在這種類型中，設立一個主干Project，針對不同的客戶或不同的變更，在相應的baseline上建立新的共享流Project去處理，而不是在多開發流中的Project新建一個開發流。如果其中某個客戶的要求或變更比較復雜，也可以建一個多開發流的Project進行處理。 優點：可以根據任務的實際情況靈活處理變更等，而且如果發現對所有用戶都需要的變更可以在主干上修改并發布到各個子Project上，也可以在一個子Proejct上修改，經驗證后再發布到其他子Project，對于有長遠規劃的產品非常適合。 缺點：如果在最初架構師考慮不周，Component劃分不合理在后期會比較困難；不同Project之間的Deliver需要更復雜的Policy，需要配置管理工程師極有經驗。
2.2.2 Activity的命名準則 建議對不同類型的工作可以通過Activity的命名直接區分，建議如下： 新加功能為：Feature_功能名 變更的執行：CR_變更號 修改Bug：Bugfix_BUG號 文檔：Doc_文檔名 計劃的更新：Plan_Tracking_時間 2.2.3 Deliver與Rebase的準則 項目中需要明確Deliver與準則，包括什么情況下可以Deliver，Deliver前是否全部文件都Check in，是否可以向非本項目的Stream進行Deliver等，這些需要根據實際情況確定，但是為了盡量避免沖突，建議在Deliver前要求進行Rebase。 2.2.4 配置存儲的邏輯視圖與物理視圖項目經理、架構師與配置管理工程師要一起確定項目配置的邏輯視圖，配置管理工程師要根據情況確定配置的物理視圖。ClearCase的UCM模式中的Component可以理解為配置的邏輯視圖，而VOB的設置可以理解為配置的物理視圖。 2.2.4.1 配置存儲的邏輯視圖：Component Component可以從系統的架構導出，如果應用RUP或項目有Deploy View或Implementation View則可以從中導出Component。 大多數從其他配置管理工具切換到ClearCase的項目將所有的代碼作為一個Component，這樣雖然簡單，但是就失去了使用ClearCase的意義，可以按模塊或3-Tier架構來分解代碼，這樣也利于項目組成員理解項目。Component的主要作用就是用于重用；設置Component的另一個目的是代碼的權限控制，如果有外包或實習生一同工作，可以將核心代碼設置為一批Component，將可以由外包或實習生接觸的代碼設置為一批Component，通過對Component的權限進行設置，可以防止惡意獲取或修改代碼的可能性。 文檔可以按以下兩種方式進行管理：
Rational公司給出了Component及目錄的設置，可以參考。
2.2.4.2 配置的物理視圖 Component只是ClearCase UCM模式的邏輯視圖，而實際的存儲與控制是由VOB實現的，通過對VOB的訪問控制實現對Component的控制。從安全與實用的角度出發，建議每個項目的VOB獨立，不要幾個項目共用一個VOB。如果一個項目非常重要，對代碼等軟件資產的管理要求嚴格，建議將文檔、核心代碼、非核心代碼分別設置為三個VOB，這樣可能對Server的硬件資源較高，但是安全上帶來的好處足以彌補硬件上額外的開支。Component可以是VOB或VOB的一個子目錄，需要注意的是VOB只有第一級子目錄才可以設置為Component。 在不同的PVOB中可以Import同一個VOB或其子目錄作為Component，但是這時一定要注意，并規劃好各分支的關系。 2.2.5 配置庫安全設置 配置模式、項目配置的邏輯視圖與物理視圖確定之后，配置管理工程師要和項目經理一起確定配置庫及配置項的安全設置。ClearCase的安全設置和Winodws、Unix系統相關，在本文只介紹Windows下的設置。 ClearCase中Windows域中有一個特殊用戶clearcase_albd，Clearcase系統要求對所有的VOB與View共享目錄，該用戶均有完全控制權限，所以該用戶的安全非常重要；而且由于在每個客戶端中設置了Atria Location Broker服務，該服務是以域用戶clearcase_albd啟動，所以如果修改clearcase_albd用戶的密碼，需要變更每個客戶端的密碼（見圖）。建議該用戶密碼至少12位，要為無意義的字符串，要包含數字、大小寫字母與特殊字符。
ClearCase的安全設置有三個部分：
以上的所有安全設置都是基于windows域的安全組，項目經理要根據項目的人員分布與代碼保密的原則確定人員的分組，明確不同組的人員的代碼權限，配置管理工程師負責與域管理員聯系建立用戶與組。 從工作的方便性與軟件資產的保護原則出發，建議每個項目設置一個quality組，項目經理、配置管理工程師與質量經理是該組的成員。 在ClearCase的VOB服務器上需要建立一個共享目錄用于存放用戶共同訪問的VOB的物理實體。 該共享目錄的權限設置為所有的開發人員都有讀寫權限。為了保證VOB實體的安全性，在該共享目錄之下要設立另一個目錄用于直接存放VOB的物理實體，對所有的開發人員是讀寫權限，對配置管理工程師、clearcase_albd需要設置為完全控制權限，該部分設置一般不需要進行，在create VOB及應用命令cleartool protectvob時，ClearCase會自動設置。 VOB實體的屬性中包括owner，group與additional group，owner表示誰擁有該VOB，group表明該owner是哪個組的，additional group描述了還有哪些組對該VOB具有操作的權限。如果在配置項中設置了其他組可讀，但是如果用戶的組沒有在group或additional group中則用戶無法獲得配置項，這樣可以保護一些核心代碼等，所以建議核心代碼單獨設置為一個VOB。VOB的權限設置可以通過命令行來進行設置：
具體的使用方法可以用cleartool man protectvob獲取幫助。 配置項的安全設置類同UNIX。需要注意的是在ClearCase中目錄也是作為配置項進行管理的。在使用中要注意的是ClearCase的GUI界面不支持遞歸，所以如果想修改某一目錄及之下所有子目錄的權限設置，請應用命令行進行。
2.2.6 環境的準備 上圖是Rational建議的服務器的配置的邏輯視圖。以下是一些要求：
如果單純從性能考慮，VOB Server最好采用UNIX系統，但是在實際情況中要考慮到易用性等，如果項目組成員大多數采用Windows平臺進行開發，建議還是使用Windows系統做為VOB Server，因為如果采用UNIX VOB Server，如果想在Windows平臺上使用Dynamic View會有一定的困難。 在實際中可以將VOB Server與License Server及Registry Server配置在一臺機器上。這些Server中只有VOB Server與View Server的對配置的要求比較高，而且一個Registry Server上只能啟動一個Windows Region與UNIX Region，所以建議每個項目配置一個Registry Server，配置項目自己的Region。 在實際使用過程中，最初所有的View均保存在項目組成員的機器上，但是在使用中出現一系列問題，如果項目足夠的資源，建議配置一個獨立的View Server，項目組成員的所有Dynamic View要求必須建立在View Server上。 在環境的準備過程中，要考慮到開發人員的開發習慣與測試環境等問題，決定VOB Sever是安裝在Windows平臺還是安裝在Windows平臺。在決定安裝平臺后，要根據開發模式確定是否安裝Web Server，如果項目會有大量的在外支持的工作，并要求在客戶現場修改代碼，建議安裝在辦公網段，這樣可以通過外網進行訪問；如果是產品項目在公司內部研發，沒有遠程修改的需求，建議安裝在實驗網段。 在Server安裝完成后，要根據代碼保密與配置管理等原則等將所有的用戶與用戶組在域中建立，并將網絡安裝包共享給用戶使用，要注意有是在某個域上安裝了ClearCase客戶端后，并不能直接在另一個域上使用，需要修改Atria Location Broker這個服務中啟動用戶與密碼，所以在安裝完成后，不能對clearcase_albd的密碼進行改動，所以clearcase_albd這個用戶設置中一定要注意設置密碼永不過期。如果一個項目組成員想在不同的域并且這些域之間沒有信任的情況下都使用ClearCase，只能安裝兩套操作系統，在每個系統上都安裝ClearCase客戶端。 2.2.7 舊版本的整理與版本的遷移 在服務器安裝完成后，要考慮舊版本的整理，如果只是簡單的將VSS與CVS的全部配置項移到ClearCase中去，就只是將ClearCase當做VSS與CVS使用，使用ClearCase也沒有什么意義，所以要將舊有的配置項進行整理。這項工作應在配置庫的邏輯視圖與物理視圖確定之后就開始，一直持續到版本的遷移。 在整理舊有的配置項時要先將原有的VSS或CVS配置庫進行備份，而后在備份的配置庫進行整理，以防止對工作中的配置庫造成損壞。版本整理的時候可以將文檔與代碼重新按照Component結構設置。 在VSS中為了工作方便，常常將工作庫，受控庫與基線庫分離，而且VSS的分支功能并不是很好，針對不同的客戶修正一般都會新建一個目錄來進行修改，同一個配置項在配置庫中存在多個副本，為配置管理帶來許多人為的不可控因素。 在整理VSS配置庫時，一般情況下文檔部分可以只采用Get last version的方法，取出最新版本，按規定放入Component即可；代碼的處理有所不同，如果所有的代碼在VSS配置庫中只存放在一處，之后在此基礎上設置label，則可以應用命令clearexport_ssafe與clearimport將其導入，在導入結束后將所有的label導入到相應的Component上即可；如果有多處副本只能將每處副本的相應基線應用get last version命令取出，而后將用clearfsimport導入Clearcase，之后在相同目錄下重復以上動作，要注意的是每次clearfsimport后要建立一個基線。 針對一些有長年積累，在VSS上有多個目錄存放不同的版本的項目，不要有必其功于一役的不切實想法，應先整理以前的版本，找出幾個主要版本樹，將各個版本之間的關系理清楚，之后將幾個版本樹按以上的方法導入。 如果源代碼在原項目中是應用CVS進行配置管理，一般情況下，在CVS中沒有副本存在，可以應用clearexport_cvs命令與clearimport命令導入好可。 在應用clearimport時要注意，如java中文件名是區分大小寫的要應用clearimport -p，具體方法可以應用cleartool man clearimport來查看幫助。 2.2.8 客戶端的安裝與培訓 每個項目在安裝時要根據安裝手冊制定本項目自己的安裝手冊，根據項目實際情況修改后發布給項目使用。在所有的客戶端安裝后，項目配置管理工程師要準備培訓材料對項目組成員進行培訓，培訓中要講清楚項目的PVOB、開發模式、Component的設置、分組與權限的設置、Stream的設置、項目配置的Policy、Activity的命名準則、Deliver與Rebase的要求等實際情況，而不是只講共性的一些東西。 2.2.9 試用 如果大部分項目組成員以前沒有過ClearCase的使用經驗且進度允許，則在客戶端安裝及培訓完成后，要在項目組內部進行試用，以讓項目組成員熟悉；最好是ClearCase與VSS或CVS并行使用一周左右時間，然后再將配置管理完成切換到ClearCase。 3.1 一些前提條件 必須在ClearCase的VOB端安裝VSS服務器程序。 3.1.2 用戶權限 對于Visual Source Safe，要以對Visual Source Safe系統中所有工程/文件均具有完全權限的身份操作； 對于ClearCase一側，要ClearCase管理員的身份操作； 因此在遷移時，最好選用同一個帳號(口令亦相同)，同時具有以上兩個權限。 如果你的ClearCase帳號不具有以上權限，請與你的系統管理員聯系。 3.1.3 日期/時間格式 在遷移過程中，ClearCase對時間要求比較嚴格，且用到的是短時間格式，具體設置如下： 1、 打開控制面板的區域設置屬性； 2、 在時間欄中，將時間樣式設為"h:mm:ss tt"； 3、 在日期欄中，將短日期樣式設為"M/d/yy"； 3.1.3.1 環境變量 為方便操作，可添加以下系統環境變量：
設置完畢后，可在命令行界面下運行path查看以上設置是否生效。 3.2 建立VOB
3.3 建立General View 3.4 備份要遷移的VSS配置庫到VOB所在的機器 3.5 設置VSS的工程目錄 3.6 生成遷移所需要的文件
3.7 遷移
確定是否遷移到當前目錄，如果要建立子目錄要注意，用命令行建立的子目錄實際并沒有在VOB中建立，要在Rational explorer中建立子目錄，并確認子目錄的類型為Directory Element才可以。 進入要遷移的目錄后執行clearimport e:\test\exportdata，注意如果是java等代碼要區分大小寫，要加參數clearimport -pcase e:\testexportdata 3.8 后續步驟 |
