TFS 2010集合文件夾結構

在我們當前的TFS環境中，我們有2個集合：讓我們稱它們爲「新」和「舊」。舊集合是非結構化的，沒有分支，它只被用作代碼庫。TFS 2010集合文件夾結構

新系列具有以下格式（我們保持它儘可能簡單）：

-NewCollection 
    -Project Name 
     -Dev (branch) 
     -Main (branch) 
     -Support (branch)

目前只有一對夫婦的項目採用這種做法（這一直工作得很好，到目前爲止），所以我們希望將所有剩餘的項目從舊集合移動到新集合。

這是問題所在。我們在舊集合中的很多項目都是WCF服務（大約15或20個），它們持有我們業務邏輯的不同方面。我們的項目引用了這些服務，其中一些服務甚至相互引用。

因爲有這麼多的服務，並且考慮到將來我們希望通過門控簽入等來實現自動構建和部署，那麼更明智的做法是什麼？

結構是這樣的服務：

-NewCollection 
    -Service 1 
     -Dev (branch) 
     -Main (branch) 
     -Support (branch) 
    -Service 2 
     -Dev (branch) 
     -Main (branch) 
     -Support (branch) 
    -Service 3 
     -etc.

或者這樣：

-NewCollection 
    -Services 
     -Dev (branch) 
      -Service 1 
      -Service 2 
      -Service 3 
      -etc. 
     -Main (branch) 
      -Service 1 
      -Service 2 
      -Service 3 
      -etc.

爲什麼我問這個問題的原因是因爲我不知道在配置時，它需要什麼構建等 - 我仍然在學習如何做到這一點，我想以這樣一種方式來規劃集合的結構，以便在不久的將來配置自動構建/部署時不會使我們的生活複雜化。

來源

2013-03-01 Matei

下面是如何爲每個項目使用「主模型」以及如何處理項目間依賴關係的示例：http://stackoverflow.com/a/9846068/600559 – 2013-03-01 17:35:19

感謝您提供有用的評論。對於依賴關係來說這是一個有趣的策略，但是我們將堅持一個扁平結構，因爲我們的依賴關係有時會達到3或4級。我們只有很少的.DLL依賴關係，並且我們保留在源代碼管理的存儲庫中，只是在需要時手動更新。 – Matei 2013-03-05 08:49:35

就我個人而言，我會使用您提到的第一個結構 - 在每個產品下都保留分支。隨着時間的推移，這將只是一種更清潔的方法。

設置構建定義時，您可以指定屬於GET操作的分支/工作區。如果您的文件系統佈局與源代碼控制佈局保持一致，那麼您可以簡單地引用來自每個服務使用者的適當服務接口，就像其他任何項目一樣。這裏有一個例子 - 在這種情況下，我從我自己的解決方案引用Awesomium SDK：

enter image description here

來源

2013-03-01 11:38:28 slugster

我與團隊的其他成員一起完成了選項，我們將爲第一個選項做好準備。其中一個原因是保持整潔，另一個原因是因爲我們的服務規模較大，未來可能需要不同的分支策略，而不僅僅是Dev和Main。所以我們試圖保持我們的選擇對於分支以及時間的推移。 – Matei 2013-03-05 08:47:08

答案分支結構的問題取決於你如何規劃你的版本。

如果你發現你幾乎總是釋放每次1個服務和其他服務是從一個獨立發展的又一個，然後去選擇1

如果你更有可能在被不斷變化的多種服務同一時間，並將它們放在一起，然後我會選擇2.

如果您不確定，或者您的版本可以混合，那麼請選擇2.您的代碼沒有真正的開銷， t打算在分支中改變。

如果您選擇選項1，並且您打算一次更改2或3個服務，則管理分支之間的所有合併將成爲主要開銷。

至於關於構建的問題，不要擔心，無論你選擇哪種佈置策略，你的構建都可以。不過，我想說的是，從經驗來看，擁有在單個分支中構建所需的所有解決方案/依賴關係將會使生活更加容易。

來源

2013-03-01 16:17:56

TFS 2010集合文件夾結構

回答

相關問題