交付機制，Rational ClearCase

我們想出了Rational ClearCase UCM模型的流結構。交付機制，Rational ClearCase

Int 
-- Prd 
-- Uat 
-- Dev 
---- Development Stream r1.0

我們最近將代碼庫遷移到了新的設置中。我們有三個不同的代碼庫，即三個物理代碼庫。

遷移過程：

我們首先提出的生產代碼，創建了一個活動，交付活動Integration流，創造了一個基線。
然後，uat代碼創建一個活動，將活動交付給集成流，在合併期間，我們選擇了來自貢獻者2的更改以保留來自uat的現有代碼，創建了基線。開發環境的相同過程。

截止目前，整合流具有最新的基線，即開發基線。
現在我們還有其他兩個流，分別用於prd和uat，這些流將在相應的環境中發佈。

我現在有我的開發流。我創建一個活動並進行一些更改。現在我需要將這些改變推廣到uat環境中。如果我將更改傳遞到集成流，則合併完成，但在開發基線上。我不想將其重新分配給uat，因爲許多開發應用程序將被重新發布到不希望的uat中。

我該如何實現促進對uat環境（uat流）的更改。友善的建議。

來源

2010-04-08 kadaba

看起來你流結構是這樣的：

Int 
    Dev 
    UAT 
    Prd

如果我提交所做的更改集成流，合併完成後，但在發展basline。我不想將其重新分配給uat，因爲許多開發應用程序將被重新發布到不希望的uat中。

流的原理是隔離特定的開發工作：

日常開發的開發
試驗以只讀模式UAT（你不應該碰任何東西，只是在PRD測試並接受或拒絕）
熱修復

詮釋爲噸這裏記錄最新的Prd基線，以便允許另一個項目使用這些基線中的一個作爲起點，避免使用從分支分支（「級聯分支」）製作的基線。

我會建議（而這僅僅是一個命題，許多其他結構是可能的，取決於具體的設置，你需要隔離一個來自另一個開發力度）：

Int 
    Prd 
    Dev 
    UAT

你變基UAT無論您想要測試的Dev基線如何，Dev都可以進行日常開發，而不會混淆正在測試的用戶驗收測試內容
如果基準重新升級爲UAT符合預期，則直接將其交付給prod （可能會出現一些最後一分鐘的修補程序）
當Prd基線設置穩定時，您將其交付給Int（以記錄這是在生產中運行的事實

來源

2010-04-08 06:22:55 VonC

Von，感謝您的回覆。恐怕我明白這一點。我現在會郵寄給你。請看看它。 – kadaba 2010-04-08 07:00:41

@ kabada：這一切都取決於你想在這些不同的流中做什麼。但是爲了澄清這個問題，發佈你當前的流結構（通過更新你的SO問題）將是一個好的開始。 – VonC 2010-04-08 07:12:41

我已郵寄給你，也有更新內容。「Int在那裏記錄最新的Prd基線」 - 現在這就是我所關心的。因爲我在不同的環境中處理不同的發佈流。到目前爲止，我在prd中只有幾個應用程序，在uat中只有很少的應用程序，並且正在開發中。我認爲整合流是一個共同的合併點（即所有交付都會發生在開發流的整合流中）。這種方法對單個版本的代碼來說看起來很合理，但我們已經有三種，因此遇到了這種傳遞機制的問題。 – kadaba 2010-04-08 08:43:50

交付機制，Rational ClearCase

回答

相關問題