深入理解 ClearCase UCM 依賴

原文連結：http://www.ibm.com/developerworks/cn/rational/r-cn-ucmdependence/

統一變更管理（Unified Change Management，UCM）是 IBM Rational 提出的用於管理軟體開發過程（包括從需求到版本釋出）中所有變更的“最佳實踐”流程。在使用 UCM 的過程中，當一個或多個元素的版本依賴其他一個或多個元素的版本時，使用者在執行遞交（即 deliver）操作會被提示發現依賴。UCM 依賴在 ClearCase 的正常操作中經常被使用者認為是 ClearCase 的缺陷，但實際上它並不是缺陷。ClearCase 出於保護資料的目的而設計了依賴，目的是為了防止由於誤操作導致資料被破壞。

本文詳細介紹了 ClearCase UCM 依賴的產生情況，以及如何解決和應對 UCM 依賴帶來的困擾。

統一變更管理（Unified Change Management，UCM）是 IBM Rational 提出的用於管理軟體開發過程（包括從需求到版本釋出）中所有變更的“最佳實踐”流程。在使用 UCM 的過程中，當一個或多個元素的版本依賴其他一個或多個元素的版本時，使用者在執行遞交（即 deliver）操作會被提示發現依賴。UCM 依賴在 ClearCase 的正常操作中經常被使用者認為是 ClearCase 的缺陷，但實際上它並不是缺陷。ClearCase 出於保護資料的目的而設計了依賴，目的是為了防止由於誤操作導致資料被破壞。

活動依賴

當執行選擇活動的遞交操作時，活動依賴會作為一致性檢查的結果以問題方式出現（見圖一）。

圖一：發現依賴

使用者在使用 ClearCase 時碰到的 UCM 依賴其實都屬於活動依賴，按照依賴產生的原因可以將依賴分為兩種：變更集依賴和基線依賴。

回頁首

變更集依賴

變更集依賴是最常見也是最容易理解的活動依賴。這主要發生在以下兩種場景：

• 使用者在同一流上使用不同的活動對同一個檔案進行操作時很容易產生活動依賴的問題；
• 當使用者在源流上的工作還未結束時，如果執行變基（即 rebase）操作，也可能會出現活動依賴的情況。

在進行並行開發時，當專案組採用 UCM 模式時，由於開發人員同時面對變更、缺陷、任務等各種型別的活動，開發人員不可避免的要面臨活動依賴的情況。

圖二：變更集依賴

在圖二中，由於 Hello.c 的版本 1 在上一次遞交操作已經遞交了，而 Act2 活動和 Act3 活動間包含了 Hello.c 檔案的不同版本，所以你可以執行的操作具體如下：

• 你可以在不遞交 Act3 活動的情況下只遞交 Act2 活動；
• 如果要遞交 Act3 活動，你必須將 Act2 活動一起遞交。因為 Act2 活動包含了 Act3 活動所包含的 Hello.c 版本 4 和上一次遞交版本之間的版本（即版本 2 和 3）。
• 因為 Act2 活動包含了 Prog.c 的版本 6，你可能需要遞交其他和 Prog.c 有依賴的活動。例如，如果 Act4 活動（圖二中沒有顯示）包含 Prog.c 的一個未遞交版本 5，那麼如果要遞交 Act2 活動的話，你必須一起遞交 Act4 活動。

在很多時候，變更集依賴是由自己造成的，而且這種情況非常普遍。如圖二所示， Act3 活動依賴於 Act1 活動和 Act2 活動。因為 Act3 活動的變更集中有一個元素 Hello.c 的 V4 版本是 Act2 活動和 Act1 活動中 Hello.c 檔案版本的繼承者。

還有一種比較罕見的變更集依賴是由於變基操作引起的。如果在源流上的工作未結束前進行了變基操作的話，也可能會出現變更集重疊導致的活動依賴（見圖三）。

圖三：變基操作導致變更集依賴

coreTeam 流上的 Unfinished 活動還沒有準備遞交，變基操作產生的 rebaseA 活動在後續的遞交操作中必須被包含，而使用者在 coreTeam 流做的變基操作使 rebaseA 活動與 Unfinished 活動產生了變更集依賴，因此 Unfinished 活動將阻止後續其他活動的遞交操作。在沒有包括 Unfinished 活動的情況下，使用者將無法執行遞交操作。

回頁首

基線依賴

源流上已存在的基線將會影響這條流上可以選擇遞交的活動。簡單的說，UCM 只能遞交沒有包含在源流中任何基線中的活動。這表現在以下兩種情況：

• 如果要遞交某基線包含的活動，那麼必須將該基線包含的所有活動都一起遞交；
• 一旦一個活動被包含在源流的一條基線中，那麼在該流後續的遞交活動中（包含跨專案的遞交操作），他都必須被包含。

在一些實際使用場景中，有時使用者或者專案管理人員會有意的在開發流上建立基線，並使得這些基線產生依賴關係。這種情況在扁平的流結構中不常見，但是在巢狀的流結構中卻非常普遍（見圖四）。當活動依賴在這種場景中出現時，使用者一般是可以理解的。

圖四：基線依賴

基線除了作為檢查點外，還可以作為開發流執行變基操作的變基點，在圖四的場景中，筆者故意在 coreTeam 流上建立了基線 Core BL1 和 Core BL2。在這個場景中，只有 deliverC 和 Intg 活動符合條件可以執行遞交操作（因為這兩個活動沒有包含在 coreTeam 流現有的基線中）。即使這樣，如果你想只遞交 deliverC 活動或 Intg 活動到 Integration 流的話，你依然會被告知他們依賴 deliverA 和 deliverB 活動（因為 Core BL2 基線還未遞交到 Integration 流）。如果你打算只遞交 deliverB 活動到 Integration 流，那麼 UCM 會告訴你必須包括 deliver A 活動（因為他們在源流上被包含在同一個基線上）。一旦 deliverA 和 deliverB 這兩個活動被遞交到 Integration 流，那麼你就可以選擇遞交 deliverC 或 Intg 活動到 Integration 流（假設他們沒有變更集依賴）。

另一種基線依賴是“遞交基線”依賴。遞交基線是一種特殊的基線，它是在不被人知的情況下，通過 UCM 遞交活動在源流上被祕密建立。因為遞交基線是不可視的，在基線的圖形瀏覽介面預設不顯示遞交基線（可以通過命令列方式檢視），所以許多時候使用者並不知道這 些遞交基線的建立與存在。這些基線影響了使用者的正常操作，同時也不容易被使用者理解。通過遞交操作而建立基線的這個功能是 UCM 眾所周知的功能之一，但是使用者經常碰到因為這些基線的存在而無法執行需要的遞交操作。

遞交基線產生基線依賴的一種場景如圖五所示。如果你想只遞交 deliverB 活動，UCM 會提示 deliverB 活動依賴於 deliverA 活動。從表面現象上看，也就表現為使用者無法只遞交後產生的 deliver 活動，而需要按照 deliver 活動產生的時間順序依次遞交。這是由於從開發流向中間流執行遞交操作時，UCM 會在開發流自動生成一條隱含基線，兩次遞交形成了兩條基線。如果想要再從中間流向最高層流遞交時，你不可以只遞交最後一個 deliver 活動，因為基線的原因，他們會產生依賴的活動關係。如果你要將遞交操作產生的 deliver 活動往上一級流遞交的話，必須將所有依賴的基線都一起遞交。

圖五：遞交基線依賴場景一

當專案允許跨專案或跨流執行遞交操作時，也可能存在遞交基線依賴的情況（見圖六）。

圖六：遞交基線依賴場景二

在這個場景中，UCM 專案中存在兩條平行開發流。開發人員在 Dev1 流上有幾個正在工作的活動。開發人員選擇了 Act1 活動跨流遞交到 Dev2 流。開發人員現在要以預設遞交方式將另一個活動 Act2 遞交到專案的整合流。

UCM 提示 Act2 活動現在依賴 Act1 活動，開發人員從 Dev1 流遞交 Act2 活動到 Integration 流時必須包括 Act1 活動（因為 Act1 活動現在被包含在一個基線裡，且該基線還未遞交）。即使 Act1 和 Act2 活動沒有任何變更集依賴，這種基線依賴的情況是可預料並且是一定會出現的。

出現這種情況是由於從 Dev1 流向 Dev2 流執行遞交操作時，UCM 會在 Dev1 流自動生成一條隱含的遞交基線。這個存在的遞交基線強迫後續從 Dev1 流進行的遞交操作必須包括 Act1 活動。

在這個特殊的案例中，從 Dev1 流到任何目標流的遞交操作都至少必須包括 Act1 活動。換句話說，只有活動沒有被包含在源流的任何基線中才可以作為選擇的活動被單獨遞交，一旦源流上有未遞交的基線，那麼就無法只選擇需要的活動進行遞交 操作，而必須將未遞交的基線一起遞交。後續從 Dev1 流發出的遞交操作都必須包含 Act1 活動，這是由於 Dev1 流發起了一筆到 Dev2 流的遞交操作，導致 Act1 活動包含在 Dev1 流的一條遞交基線中。同樣的，如果從 Dev1 流完成了第二次遞交操作（將 Act1 和 Act2 活動都遞交到 Ingegration 流），假設再從 Dev1 流發出到其他任何目標流的遞交操作，都必須包含 Act1 和 Act2 活動（因為現在 Act1 和 Act2 活動都包含在 Dev1 流的基線中）。

回頁首

解決神祕的活動依賴

解決活動依賴的一個顯而易見的解決方案是將所有工作都遞交，或者是最小化的選擇需要的活動和他的依賴，但顯然這都不是好辦法。

第二種方法是採用每個開發人員一條開發流，而不使用所有開發人員共享一條開發流的方式。這種方式，可以大大減少不同開發人員之間活動依賴的情況，但 是仍不可避免同一個開發人員所承擔開發活動之間依賴的可能。另外，由於每個開發人員使用一條開發流，每個開發人員之間處於彼此隔離狀態，整合工作量較大， 整合時間可能加長，對開發人員使用 ClearCase 技能的要求也較高。

第三個可以選擇的方法是使用每個活動都採用一條流的模式進行工作。這種模型通常可以避免因為採用在各自的流上工作的方式來隔離各個活動帶來的特殊的問題。但是這種模型引入的管理成本較大，並且專案的複雜性將大大增大。

考慮到方法二和方法三在大部分公司實施所需的成本較大，以及需要對專案現有開發模式做較大的改動，實施起來會有較大的困難，在這裡筆者介紹一種相對 簡單的方法。我們可以充分利用 ClearCase 強大的觸發器功能來減少活動發生依賴的可能性。例如，為了不發生因使用不同活動修改同一個檔案而發生的變更集依賴，我們可以在執行檢出操作時，判斷這個元 素當前版本關聯的活動是否已經處於 closed 狀態。如果還沒有處於 closed 狀態，那麼就不允許檢出。通過類似觸發器的建立，我們對開發流的活動依賴進行了限制。但是這種方法僅適用於變更集產生的依賴，對於基線依賴（如遞交基線依 賴）也不能很好的解決，這種情況可以參考下一節。

另外，我們還可以通過制定一定的管理規則，例如，我們可以要求開發人員在開始新 build 的開發時應該先執行變基操作，將公共開發流的穩定版本更新到個人工作空間後，然後才可以在個人工作空間上進行新的開發任務。類似這樣的管理規則，也可以從 一定程度上減少和解決活動依賴。

但是，由於 ClearCase 資料安全的設計機制，要想完全避免活動依賴，可能需要犧牲一定的開發效率（例如上例提到的觸發器設定）。既然我們不能完全避免活動依賴，那麼一旦碰到因為 活動依賴導致我們無法完成需要的操作而影響工作時（如版本釋出），那麼我們可以按照下一節的應對方法來應對活動依賴。

回頁首

遞交基線依賴問題的應對辦法

當你因為之前從源流執行過遞交操作而不能遞交選擇的活動，你可以按照下面的方法來解決這個問題：

1. 在開發流建立一個新的活動；
2. 將初始的 deliver 活動的變更集移動到步驟 1 新建的活動中（見圖七）；

圖七：移動變更集

1. 從源流移走初始的活動（見圖八）；

圖八：刪除活動

1. 嘗試重新遞交選擇的活動。這次遞交操作在沒有 deliver 初始活動變更集的情況下將會成功。即使包含了相同的變更，由於新的活動不屬於任何基線，所以也不再有依賴關係。

除了上述辦法之外，對於活動依賴的困擾，我們可以使用 David E. Bellagio 在《Software Configuration Management Strategies and IBM® Rational® ClearCase® Second Edition A Practical Introduction》中提供的 cset.pl 指令碼來快速解決這個問題。cset.pl 指令碼下載地址：IBM Rational IC Package: CSET.PL。

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/13180590/viewspace-462582/，如需轉載，請註明出處，否則將追究法律責任。