2009-12-03 85 views
1

我的同事和我相對需要Clearcase UCM的流式創意。目前,管理層已經爲每個功能軟件包創建了流,每個功能軟件包都定義了接口並位於分層體系結構中。開發人員根據他們正在工作的軟件包創建子流,並嘗試獨立開發他們的代碼,但是他們通常在初始開發期間依賴於其他軟件包。這導致我們的集成小組創建了系統構建,然後開發人員使用這些系統構建一個適當的環境來開發他們的軟件並手動引入依賴關係(即壓縮文件,補丁等)。Clearcase UCM - 如何使用流和組件,如何?

我的觀點是,這是錯誤的,並不是UCM如何使用,但我需要更熟悉UCM的人來確認我的信念。我認爲應該從功能的角度創建流(每個包執行一些功能,多個架構包有助於實現某些客戶功能,稱之爲「ABC」)。然後,將執行功能「ABC」的初始開發的每個架構組件的組件添加到流中。所有功能「ABC」的開發人員現在都可以在流中(或在某些子流中)完成該功能。完成後,每個UCM組件都有一個基準,並且從UCM的角度來看,組件之間不存在「綁定」(有人聲稱這可能由於活動記錄而在UCM內部發生)。

注意:我同意也許你不以這種方式工作,但在最初的開發過程中,接口通常會發生變化,您尚未實現所有函數的所有接口,因此多個組件在一個流中一起工作最有意義。稍後,您可以轉換到「架構軟件包中心」的工作方式,其中每個軟件包與另一個軟件包中的更改無關。

想法?對於這篇長文章感到抱歉,我覺得細節是必要的。

回答

0
  • 每個功能軟件包
  • 所有開發者功能「ABC」現在流中工作(或者在某些組子流)創建的流來完成該功能

是的,這幾乎是流的兩個UCM正常用法
(唯一非常不好的用法是涉及每個開發人員的一個流,僅用於隔離目的,這將是瘋狂的,因爲specified before

這兩個模式是系統方法組件方法,在this answer詳細。
基本上,您希望在開發的初始階段避免過多的合併或重置,並在開始時保持一個連貫的系統(所有組件都是可寫的)。
然後,當API穩定後,您可以爲每個可寫組件創建一個流。

注意:當您有一組定義好的基準引用所有組件的穩定狀態(只讀),並且您可以部署和測試的位置時,這並不妨礙您建立「系統集成」流你的系統。
這些流保存在一個或多個單獨的「集成」UCM項目上。

0

我同意VonC。我更喜歡功能性的方法。

有一個ClearCase插件可以幫助您爲您的用戶(流,視圖,項目策略)建立環境,無論採取何種方式。只是谷歌關於「clearEnv」