2.2.1.2 多開發(fā)流模式

項(xiàng)目中有多個(gè)不同的開發(fā)流，每個(gè)開發(fā)流都是一個(gè)獨(dú)立的分支，如果項(xiàng)目需要還可以建立多層次的分支，支持并行開發(fā)，適于超過10人，較復(fù)雜的項(xiàng)目。如果項(xiàng)目極復(fù)雜，可以分為多層開發(fā)流與集成流，如圖二。優(yōu)點(diǎn)：可以并行開發(fā)，每個(gè)Stream都相當(dāng)于一個(gè)獨(dú)立的開發(fā)環(huán)境，每個(gè)人之間的工作不會(huì)互相產(chǎn)生干擾；可以通過Policy的設(shè)置更好的進(jìn)行配置管理。

缺點(diǎn)：不同的Stream之間的Deliver與Rebase會(huì)產(chǎn)生問題；在merge時(shí)也有可能會(huì)產(chǎn)生問題，而且對(duì)Word等二進(jìn)制文件的merge支持不好；在修改完成之后，每個(gè)Stream上的修改只有deliver與Rebase才能被其他的stream應(yīng)用，不能及時(shí)反映變化；Policy的設(shè)置較復(fù)雜。

在多開發(fā)流模式下可以根據(jù)需要將某個(gè)stream設(shè)置為只讀模式。

建議：可以根據(jù)需要建立一個(gè)多開發(fā)流模式的Project，但是在初期階段不設(shè)立開發(fā)流，在進(jìn)行詳細(xì)設(shè)計(jì)階段后再建立相應(yīng)的開發(fā)流。

2.2.1.3 Project組模式

Project組模式是以上兩種模式的組合，適用于產(chǎn)品類項(xiàng)目，在這種類型中，設(shè)立一個(gè)主干Project，針對(duì)不同的客戶或不同的變更，在相應(yīng)的baseline上建立新的共享流Project去處理，而不是在多開發(fā)流中的Project新建一個(gè)開發(fā)流。如果其中某個(gè)客戶的要求或變更比較復(fù)雜，也可以建一個(gè)多開發(fā)流的Project進(jìn)行處理。

優(yōu)點(diǎn)：可以根據(jù)任務(wù)的實(shí)際情況靈活處理變更等，而且如果發(fā)現(xiàn)對(duì)所有用戶都需要的變更可以在主干上修改并發(fā)布到各個(gè)子Project上，也可以在一個(gè)子Proejct上修改，經(jīng)驗(yàn)證后再發(fā)布到其他子Project，對(duì)于有長(zhǎng)遠(yuǎn)規(guī)劃的產(chǎn)品非常適合。

缺點(diǎn)：如果在初架構(gòu)師考慮不周，Component劃分不合理在后期會(huì)比較困難；不同Project之間的Deliver需要更復(fù)雜的Policy，需要配置管理工程師極有經(jīng)驗(yàn)。

 2.2.2 Activity的命名準(zhǔn)則

建議對(duì)不同類型的工作可以通過Activity的命名直接區(qū)分，建議如下：

新加功能為：Feature_功能名

變更的執(zhí)行：CR_變更號(hào)
注：如果變更中涉及到文檔的修改，則文檔修改也應(yīng)用此Activity

修改Bug：Bugfix_BUG號(hào)
注：BUG號(hào)來自ClearQuest

文檔：Doc_文檔名
注：在變更及Bugfix中文檔的修改activity應(yīng)用變更的activity

計(jì)劃的更新：Plan_Tracking_時(shí)間
另一建議為選用ClearQuest為缺陷管理工具，并將ClearCase與ClearQuest集成，這樣所有的Activity可以通過ClearQuest獲得。

2.2.3 Deliver與Rebase的準(zhǔn)則

項(xiàng)目中需要明確Deliver與準(zhǔn)則，包括什么情況下可以Deliver，Deliver前是否全部文件都Check in，是否可以向非本項(xiàng)目的Stream進(jìn)行Deliver等，這些需要根據(jù)實(shí)際情況確定，但是為了盡量避免沖突，建議在Deliver前要求進(jìn)行Rebase。

2.2.4 配置存儲(chǔ)的邏輯視圖與物理視圖

項(xiàng)目經(jīng)理、架構(gòu)師與配置管理工程師要一起確定項(xiàng)目配置的邏輯視圖，配置管理工程師要根據(jù)情況確定配置的物理視圖。ClearCase的UCM模式中的Component可以理解為配置的邏輯視圖，而VOB的設(shè)置可以理解為配置的物理視圖。

2.2.4.1 配置存儲(chǔ)的邏輯視圖：Component

Component可以從系統(tǒng)的架構(gòu)導(dǎo)出，如果應(yīng)用RUP或項(xiàng)目有Deploy View或Implementation View則可以從中導(dǎo)出Component。

大多數(shù)從其他配置管理工具切換到ClearCase的項(xiàng)目將所有的代碼作為一個(gè)Component，這樣雖然簡(jiǎn)單，但是失去了使用ClearCase的意義，可以按模塊或3-Tier架構(gòu)來分解代碼，這樣也利于項(xiàng)目組成員理解項(xiàng)目。Component的主要作用是用于重用；設(shè)置Component的另一個(gè)目的是代碼的權(quán)限控制，如果有外包或?qū)嵙?xí)生一同工作，可以將核心代碼設(shè)置為一批Component，將可以由外包或?qū)嵙?xí)生接觸的代碼設(shè)置為一批Component，通過對(duì)Component的權(quán)限進(jìn)行設(shè)置，可以防止惡意獲取或修改代碼的可能性。

文檔可以按以下兩種方式進(jìn)行管理：

    單獨(dú)設(shè)置一個(gè)文檔VOB，所有的文檔都放在一起，優(yōu)點(diǎn)是權(quán)限控制簡(jiǎn)單，可以將文檔提供給其他人員而不用擔(dān)心代碼的泄漏，缺點(diǎn)是代碼與文檔分離，工作中可能會(huì)出現(xiàn)兩者不一致的問題。
    根據(jù)架構(gòu)，同一模塊或Tier的代碼與相應(yīng)和文檔一個(gè)Component中，優(yōu)點(diǎn)是可以保證文檔與代碼的一致性，但是這時(shí)要保證代碼與文檔的安全性要繁瑣一些。