Team Foundation Server的源代碼控制結構

Question

我一直在努力規範源控制結構爲我們在新的一年Team Foundation Server的部署。我已經開始使用CodePlex上提供的Microsoft Team Foundation Server Branching Guidance文檔。

我希望能得到一些反饋，並回答幾個我對擬議結構的具體問題。當談到在TFS中構建源代碼控制時，我已經瞭解到有太多的「標準」可供選擇，並沒有真正的標準。

首先，我將概述，並描述決定和使用情況。

$/             
    {Team Project}/        
     {Subproject}/        
      Development/       
       Trunk/        
        Source/ 
        Tests/ 
        Sandcastle/ 
        TeamBuildTypes/ 
         {Build Name}/ 
       Branches/ 
        {Branch Name}/ 
         Source/ 
         Tests/ 
         Sandcastle/ 
         TeamBuildTypes/ 
          {Build Name}/ 

      Integration/ 
       Source/ 
       Tests/ 
       Sandcastle/ 
       TeamBuildTypes/ 
        {Build Name}/ 
      Production/ 
       Releases/ 
        {Release Version}/ 
         Source/ 
         Tests/ 
         Sandcastle/ 
         TeamBuildTypes/ 
          {Build Name}/ 
       Branches/ 
        {Branch Name}/ 
         Source/ 
         Tests/ 
         Sandcastle/ 
         TeamBuildTypes/ 
          {Build Name}/ 

一般的邏輯是，一個團隊項目可以包含一個單一的邏輯項目（其中將不會有{Subproject}條目）或多個相關項目的產品或工具套件的形式。三大容器稱爲Development，Integration和Production。

在Development容器的Trunk中，Source文件夾中包含構成產品的兩個項目都有相應的規定，Tests文件夾中提供了相應的單元測試。大多數未成年人的發展會好發於軀幹，與通過Trunk文件夾的同級Branches文件夾，它作爲一個分支容器分支提供。一個或多個解決方案文件將存在於Trunk之內，允許該級別的分支機構捕獲解決方案，源代碼和單元測試。

Integration容器在非TFS實現中通常被稱爲「主」，僅用於集成來自Development的變更集以創建穩定且可測試的構建。一旦達到可測試產品，它最初是作爲從Development容器的分支創建的。此容器的構建將用於我們的測試環境和負載測試環境。我們選擇包含可測試構建的負載測試，以便我們可以監控性能變化，能夠快速隔離可能導致任何違規行爲的變更集。

Production被用於生產預生產和生產質量的基礎之上。一旦建議發佈穩定版本，它最初是作爲Integration容器的分支創建的。在Releases文件夾中，遵循「按發佈分支」結構，在一個位置提供快照和隔離。 （例如，當Release 1.1已準備好預生成版本時，穩定的Integration容器會分支到Production/Releases結構中的新文件夾Release 1.1後續RC和RTW/RTM也被提升到此文件夾中。）分支結構也存在，如在Branches容器中所見。這允許「修補程序」，通常是修訂標記（Major.Minor.Revision）。該分支從當前版本創建併合並回新版本標記 - 如Release 1.1.1。在接受之後，Changeset將被逆向整合到Development集裝箱的Trunk。

我們覺得這種結構在健壯性和複雜性之間是一個公平的平衡。但是有一些嘮叨的問題，我無法在邏輯上適合模型。它們是：

團隊建設 - 該Development和Integration容器將首先開始了爲每晚構建，最終轉向持續集成（CI）。生產容器將被手動構建。

• 構建定義應該在哪裏生存？編輯 - 基於幾個響應，TeamBuildTypes文件夾已被移動到樹幹並分支到適當的容器。但是，這會產生一個新的問題（如下）。

• 通過將TeamBuildTypes文件夾放在適當的容器中，這是否意味着所有構建定義將在適當的文件夾之間進行復制？例如，具有開發質量的構建定義以及可測試構建等，所有這些構建都存在於整個結構中的所有TeamBuildType文件夾中。

文檔生成 - 我們使用桑德爾卡瑟生成文檔。具體而言，我們也使用Sandcastle Help File Builder來管理輸出。這會生成一個專用於SFHB格式的項目文件。

• 應該將生成的文檔存儲在源代碼管理結構中嗎？

• 應該爲每個容器生成文檔還是隻對生產前質量和生產質量具有價值？

• 爲了保持快速的本地構建時間，文檔創建應該由構建定義擁有嗎？

• SHFB特定文件應該在哪裏存在？我最初的想法是把它作爲同行到Source和Tests文件夾。我同意推薦，它是Source和Tests的同行。圖表已更改以反映此更改。

第三方二進制

• 應的二進制文件（控制，圖書館等）被存儲在源控制？

• 如果是這樣，它應該是它自己的團隊項目嗎？

一般文獻 - 非生成的文檔，例如要求，設計文檔，測試計劃等不打算由源控制結構的文件夾中反映出來。在與我的開發人員和同行進行了一些研究和討論之後，使用Team Explorer中的內置Documents文件夾提供了更多好處，因爲它反映了Team Project Portal中的結構，並且一些（商業）用戶不需要額外的複雜學習源代碼控制方面的TFS。

---

我將更新結構，因爲我得到問題的答案以提供更清晰的圖像。我也歡迎任何其他有關潛在變化的評論。如果我有任何其他問題，我會確保修改這篇文章。

編輯：

• 澄清。 Source和Tests文件夾也位於Integration容器下。

• Micah和Josh都提到了關於第三方二進制文件的好處。問題添加了問題。

• 文檔生成可能會很慢。添加了關於文檔創建是否應由特定團隊構建類型擁有的問題。

• 新增解決涉及非生成的文檔，如需求，設計文檔，測試計劃等

• 新增的分辨率有關TeamBuildTypes文件夾構建defintions。

• 根據各種反饋，將TeamBuildTypes文件夾移至中繼線/分支級別。

Answer 1

我喜歡將Sandcastle文件作爲源代碼和測試對象的想法，我會添加一個文檔文件夾，然後包含sandcastle文件以及可選的實際文檔。

有意見的差異，我敢肯定我會因此而低估（因爲我以前一直）。我會把在TFS生成的文檔，有幾個原因：

1. 你會希望每個版本中您的文檔，並使用TFS是一件容易的形式給出，以確保您的文檔停留在正確的位置。
2. 使用TFS存儲它意味着每個人都知道去哪裏獲得的文件。

有一件事我不明白，我一直掙扎在這裏向第三方依賴關係，這也許是因爲他們屬於降源下，使他們與每一個項目但如果你想分享他們翻過項目你可以添加一個新的頂級節點。

編輯

對於我的二進制文件通常我結了

$ /第三方/公司/產品/版本/ src目錄（可選）

所以，比如我有

$/ThirdParty/ Microsoft/ EntLib/ 3.1 4.0 ComponentArt/ WebUI/ 2008.1/ Src

我喜歡添加源代碼，我不得不修補CA的源代碼，我討厭這樣做，但是當第三方沒有修復這個bug時，您必須訴諸此。

Answer 2

偉大的佈局和解釋。我一直在努力解決完全相同的問題。我結束了一個非常相似的結構。礦井變化不大。

Development/ 
    Trunk/ 
     Binaries/ -- Shared libraries 
     Source/ 
     Test/ 
     Docs/  -- Documentation 
TeamBuildTypes/ -- Build definitions 

• 添加二進制文件夾可以讓你在所有的項目，可以參考共享庫
• 我們把這裏的文件，因此它可以一起旅行與它的特定分支分支都有一個位置。
• 我們的構建定義處於開發階段，因爲我們可以將它們分佈在所有分支的一個位置，但它肯定可能在分支層面，這可能更有意義。

應的二進制文件（對照，庫 等）被存儲在源控制？如果是這樣，它應該是它自己的團隊 項目？

我認爲他們應該一定是源代碼控制的，但我沒有看到任何理由把他們放在他們自己的團隊項目中。需要小心的一個問題是由於某些原因，TFS對待二進制文件略有不同。我遇到過更新源代碼控制中的二進制文件的問題，但其他機器上的「正在獲取最新版本」不會導致文件更新。有時您需要執行「獲取特定版本」並檢查該特定文件的「覆蓋未更改的文件」選項。

Answer 3

有一件事我建議是不使用默認位置爲球隊構建，包括它在「可支」的水平，因爲你分支因各種原因（比如代碼促銷），你會希望你的構建腳本是與它分支並同步。

也是一個新的和更具體的場景指南是剛剛發佈，以及在http://www.codeplex.com/TFSBranchingGuideII

Answer 4

你應該把你的TeamBuilds文件夾你的軀幹之下。這在TFS2005中是不可能的，但是微軟在2008年修復了它...

原因是你的版本可能會隨着更新的版本（例如：新的打包方案，不同的測試等）而改變，這可能會使它與較舊的維護版本。這就是爲什麼你應該將團隊構建與代碼版本結合起來。

這樣，假設你發佈一個版本1.0，並把它的發佈文件夾下。您將能夠建立併發布補丁的V2.0工作在發展幹線，同時（這可能需要修改構建）

Answer 5

爲了您的二進制文件 - 很明顯，只有二進制文件應該是版本控制下的「第三第三方「程序集，您不是」構建「任何自動構建的一部分。如果你有自己的庫，你有他們的源代碼版本控制等 - 你應該看看各種策略的建設和同步等

然後我組織他們像喬希 - 然後使用分支「複製」的二進制文件一個_ExternalReferences文件夾，它是解決方案樹中.NET項目文件夾的同級。這是服務器端的一種非常高效的方式，因爲TFS版本控制只存儲「Deltas」 - 所以基本上，許多項目中的這些二進制文件的每個「重複」實質上就像是一個「指針」。