典型的最佳實踐ClearCase項目結構

Question

在開發項目中，交付的代碼可以在到達生產之前在不同階段的不同環境之間進行（例如用於測試部署過程的開發環境，QC的內部測試，預生產和最終生產）。

該開發工作產生了許多候選版本，其中某個版本可以被指定在開發過程中向上移動，直到它達到產品爲止，而且可能會有一些情況，部署在產品上的代碼可能需要熱補丁與目前的內部發展路線（即並行發展）並行。

對於由IBM的Rational ClearCase（CC）保持了一定的UCM項目，什麼是要在「工程資源管理器」中創建的建議的項目結構，以適應以下幾點：

1. 開發商應主要連接和將他們的工作交付給內部開發線（或在CC術語中稱爲開發流）。
2. 一旦交付到此開發流的代碼被認爲是可接受的，技術小組負責人（TTL）可以創建一個基準。這個基線以後可以由部署工程師檢索以部署在本地開發環境中。
3. 如果這個基線被認爲是可接受的，那麼這個基線可以作爲一個整體傳遞給內部測試流以用於進一步的質量控制（QC）測試。
4. 如果這個基線被認爲是可接受的，那麼這個基線可以作爲一個整體交付給前期製作等等，以產生類似於上述內容。
5. 當然，如果接收方不接受這些基線中的任何一個，它可以被拒絕，並且接收方將等待另一個基線被推薦用於它們的流。

注意：部署工程師將始終使用專用的流爲每個環境中去進行編譯/部署活動需要他/她的文件。

因爲我明白回答這個問題可能會很長，但我的問題更多集中在需要在「項目瀏覽器」中創建以滿足上述目標的流和/或視圖的確切類型。

我真的想要提出使用CC的發佈管理的最佳實踐方法，以及如何最好地使用此目的。

我會感謝您的幫助球員和許多感謝所有提前...

Answer 1

經驗法則很簡單：
分支少，效果越好。

我的意思是，如果你曾經做過交付和使用ClearCase之前重訂，你就知道：

• 是
• 多麼痛苦多麼糟糕它與文件的數量（合併1000個文件擴展是相當長的，合併5000個文件是謀殺）

所以拇指真正的規則是：

如果不修改任何文件一個給定的開發階段，不要創建分支。

例如，爲了將代碼推廣到QA，您只能閱讀它（並且啓動一些測試，以便在代碼通過時接受該代碼，或者在代碼失敗時拒絕該代碼），創建一個QA Stream，您將在其中發送代碼：對於不存在的附加值來說太長了。

使用baseline promotion level只要你可以和recommend your promoted baselines。

部署工程師將始終使用專用的流爲每個環境中去進行編譯/部署活動需要他/她的文件。

錯誤...不，如果您沒有任何更改要做。
只有在代碼部署和運行成功時，部署工程師纔會關心基線來自哪裏。