我的同事和我相對需要Clearcase UCM的流式創意。目前,管理層已經爲每個功能軟件包創建了流,每個功能軟件包都定義了接口並位於分層體系結構中。開發人員根據他們正在工作的軟件包創建子流,並嘗試獨立開發他們的代碼,但是他們通常在初始開發期間依賴於其他軟件包。這導致我們的集成小組創建了系統構建,然後開發人員使用這些系統構建一個適當的環境來開發他們的軟件並手動引入依賴關係(即壓縮文件,補丁等)。Clearcase UCM - 如何使用流和組件,如何?
我的觀點是,這是錯誤的,並不是UCM如何使用,但我需要更熟悉UCM的人來確認我的信念。我認爲應該從功能的角度創建流(每個包執行一些功能,多個架構包有助於實現某些客戶功能,稱之爲「ABC」)。然後,將執行功能「ABC」的初始開發的每個架構組件的組件添加到流中。所有功能「ABC」的開發人員現在都可以在流中(或在某些子流中)完成該功能。完成後,每個UCM組件都有一個基準,並且從UCM的角度來看,組件之間不存在「綁定」(有人聲稱這可能由於活動記錄而在UCM內部發生)。
注意:我同意也許你不以這種方式工作,但在最初的開發過程中,接口通常會發生變化,您尚未實現所有函數的所有接口,因此多個組件在一個流中一起工作最有意義。稍後,您可以轉換到「架構軟件包中心」的工作方式,其中每個軟件包與另一個軟件包中的更改無關。
想法?對於這篇長文章感到抱歉,我覺得細節是必要的。