TFS 2010分支模型的內部應用程序

這不是一個問題，我沒有任何想法，但我想提出一個模型，看看它是否得到批准或任何人都可以看到它的問題或有更好的建議。他們說，最好仔細選擇你的分支模型，以避免未來的頭痛。TFS 2010分支模型的內部應用程序

因此，我們只有一個版本（最新版本）發佈給客戶的內部應用程序，基本上有兩種開發活動：主要活動正在爲下一版本工作，通常包含新功能和糾正修復和計劃，第二個是沒有計劃的，涉及維護，包括生產中當前版本的修補程序。

經過長期的研究，我們決定去一個主幹線從中我們支了2子分支：發展 & 維護（或修復）。正如本指南中介紹的那樣，每當我們的功能準備好用於下一個版本時，每日開發將發生在我們從中進行反向集成（RI）的分支處開始。在發佈之前，反向積分將停止，並且代碼將在Main分支中穩定下來。從主要釋放後，將有一個從主到開發和維護正向集成（FI）。

的任何修補程序會發生在維護僅依賴於定位點（例如，如果我們想保留它的代碼庫），我們會做一個RI爲主要並從那裏FI到發展。

現在一切都看起來很正常，至少在紙上，所以我想聽聽別人對這個模型的看法。（而不是直接在主要工作）

例如，我們也將考慮讓另一個分支，發佈，代碼，其中穩定釋放到生產環境之前發生的，當然，我們將發佈從這裏到生產並做一個RI到主後跟一個FI到開發 & 維護，但我們不確定這是否會帶來任何好處，或只會增加複雜性？

並假設會有發展功能，將不準備或不希望下一個版本，這意味着我們將不得不做，都涉及到想要的功能變更集的一些「摘櫻桃」，但根據文檔，這不太好。有什麼建議麼？

我再次知道這不是一個簡單而直接的問題，而是一個開放的問題，但我希望能聽到任何有類似經歷的人。預先感謝您的關注。

來源

2012-01-11 Iulian Ilies

聽起來不錯。閱讀此：http://stackoverflow.com/questions/3245304/branching-plan-必須/3246496#3246496 – KMoraz 2012-01-11 23:16:55

@KMoraz：我可以從另一篇文章中提取的是選擇簡單明智，我喜歡這一點。但是，我不確定只有Dev＆Main對我們足夠了。我們需要在發佈之間隔離修補程序的工作。感謝您的鏈接，所有閱讀我可以得到幫助。 – 2012-01-12 19:03:45

您是否閱讀過TFS ALM流浪者分支指導文檔？你提出的看起來很像他們的「標準分支計劃」，儘管他們鼓勵同時擁有一個發行版和「服務包」分支（就像上面的發佈和維護分支一樣）。

http://vsarbranchingguide.codeplex.com/

我已經實現了標準分支計劃在一些客戶並沒有與此有關的一個問題。如果您計劃採用並行工作流（特徵組等），分支指導也有相應的計劃。

要考慮的另一件事可能是一個階梯式模型，您可以在每個版本中創建新的Dev分支，並將舊分支凍結爲發佈版本。這樣可以避免RI，因爲您可以修補舊版本，並在必要時將修補程序FI修復到新的Dev分支。我也在這個模型中工作過，它很棒。

來源

2012-01-11 23:45:00

感謝您的回答。我從codeplex網站下載了內容，儘管我沒有閱讀所有內容，跳過了多團隊，多功能，同步的服務包等。儘管我們沒有真正實施Service Pack，但標準分支計劃看起來不錯。累積修補程序/補丁），因此可能有Realease和Hotfix分支就足夠了。儘管如此，我無法在任何指南中找到與此計劃有關的深層解釋。比如什麼時候做FI＆RI，在產品發佈之前穩定代碼的位置，哪個分支被髮布到哪裏以及在什麼時間點。 – 2012-01-12 17:47:19

是的，他們不會給你所有的東西......這就是顧問的意圖;）......其實我認爲這是因爲這些問題的答案是定性/主觀的。根據我的經驗，答案是「適合你的團隊」。在過去，我曾經在RI's to Main的團隊中工作過，只有當您希望分發一個版本時，其他團隊都會在某個功能準備好進行QA時完成它。一旦你在Release分支中，我總是建議提高bug欄。僅限P1/S1錯誤。所有其他的穩定都應該在某個地方發生。 – 2012-01-12 21:23:07

TFS 2010分支模型的內部應用程序

回答

相關問題