TFS 2010項目結構並獲得最大收益

Question

我們最近決定遷移到TFS 2010.我們還希望改進我們的源代碼管理結構和項目結構。

這裏是隊上商定的結構：

|OurCompanyName (or common root name) 
| 
+--Windows 
+----Applications 
+------App1 
+------App2 
+----Services 
+------WindowsService1 
+------WindowsService2 
| 
+--Web 
+----Applications 
+------WebApp1 
+------WebApp2 
+----Services 
+------WebService1 
+------WebService2 
| 
+--Common 
+----ThirdParty 
+----Libs 
+------DataAccessLib 
+------BusinessLogicLib 
| 
+--Tests 
+----TestProject1 
+----TestProject1 

公共文件夾包含第三方和我們的內部圖書館所使用全幅（應用，應用2，WebApp1 ...等）

我們需要acheive如下：

• 發佈的版本必須依賴於利布斯的最新產品版本。
• 如果測試失敗，則依賴項目不應構建，應通知團隊。
• 簡單分支：開發，生產，版本發佈以及我們如何相應地構建它們。

我已經閱讀了下面的指南Visual Studio TFS Branching Guide 2010，但它只處理它的分支位。

Answer 1

你真的不是在問我可以告訴的問題。但我可以給你一些關於你的目標的反饋/討論。

• 發佈版本必須依賴最新的Libs版本。

發佈版本應該取決於它在開發時使用的任何版本。不是當前版本是什麼。你可能想更深入地瞭解這個要求是什麼以及爲什麼你認爲你需要它。

• 如果測試失敗，則依賴項目不應構建，應通知團隊。

TFS不支持開箱即用的鏈接構建，您可以修改構建模板以添加支持，但它不是一個特別乾淨的解決方案（imo）。

您可以使用內置的tfs警報訂閱自訂訂閱失敗的版本，但每個開發者都可以這樣做。 （除非您訂閱郵件組或創建自定義事件郵件程序）。

再次爲什麼你會自動更新其他項目中的依賴關係？當然你最好使用拉取更新而不是推送，並使用像NuGet這樣的技術來處理你的參考。

• 簡單分支：開發，生產，版本發佈以及我們如何相應地構造它們。

這聽起來像是每次發佈時都簡單分支，這非常簡單。

如果您知道您發佈的變更集，您不必分支，只有在需要時才能分支（例如修復生產缺陷）。它需要更多的工作，因爲您需要在發佈時手動標記代碼（在這一點上，您對分支沒有任何好處），或者有一個自動發佈過程爲您完成。

其他說明

你不」想要使用多個團隊項目集合 - 這增加了在噩夢中，當涉及到管理構建服務器。

您可能需要更新您的圖表以顯示什麼是團隊項目，分支以及什麼是標準文件夾。

Answer 2

在使用了TFS一段時間後，我想提醒一下： 從開發者的角度來看，就像我們開始考慮如何最佳部署項目時一樣。但是，您還應該考慮項目管理要求。

擁有不同的TFS項目，意味着不同的報告數據給經理。

因此，如果App1和WebApp1對於運行項目的人是同一整體項目的一部分，那麼如果您在不同的TFS項目中擁有它們，則表單的問題爲：「我的團隊在此項目上花費了多少小時'將很難回答。 在決定項目結構之前，我會認真研究這個問題。

現在關於你的問題：

• 發佈的版本必須依賴於利布斯

的最新產品發佈貝蒂（上圖）提到這是不好的實踐與實效。如果開發是在Lib v1.0的產品發佈期間發生的，並且在穩定性Lib變爲v2.0的時候會發生什麼？

• 如果測試失敗，則依賴項目不應構建，應通知團隊。

我相信這是你的構建腳本的問題，而不是你的佈局

- 簡單分支

我們試圖實現一個簡單的主線基礎的方法，在這裏我們有一個或多個開發分支（實際取決於您的具體要求）。 有一段時間，當開發代碼被認爲是「穩定的」，即通過基本的單元測試時，它被合併到主線上。開發人員在其開發分支上繼續進行，而主線上的代碼則進行更廣泛的測試。發現的錯誤最初在DEV分支上報告和修復，併合並回主線。一旦MAIN線上的代碼足夠好，穩定將在RELEASE分支上開始。在那之後，錯誤修正發生在RELEASE分支上併合並回MAIN行。請注意，「穩定」，「足夠好」是對組織來說意味着不同事物的價值觀。