在TFS 2010中組織源代碼

我們剛剛啓動並運行了TFS 2010。我們將把我們的源碼遷移到TFS中，但是我有一個關於如何組織代碼的問題。在TFS 2010中組織源代碼

TFS 2010有一個項目集合的新概念，所以我決定我們組織內的不同團體將獲得他們自己的團隊。我的團隊開發了許多不同的Web應用程序，我們有幾個共享組件。我們也使用一些第三方組件（如telerik）。

顯然，每個Web應用程序都是自己的項目，但我在哪裏放置共享組件？每個組件是否應該在自己的項目中使用獨立的構建和工作項目？

是否有最佳做法或推薦的方法來做到這一點特定於TFS 2010？

2010-04-21 HitLikeAHammer

對此的最佳實踐是擁有在Main/Trunk文件夾下創建解決方案所需的一切。我們採用以下格式：

"Project 1" 
    "DEV" (Folder) 
     "Feature 1" (Branch) 
     "Main" (Root branch) 
    "Release" (Folder) 
     "Release 1" (Branch) 
    "RTM" (Folder) 
     "Release 1.0" (Branch) 
     "Release 1.1" (Branch)

這樣可以使所有的分支在同一水平，所以你不會有任何疑問，這是一個分支，它是一個文件夾。

這下每個分支的是你的團隊項目的結構，但對於實際的文件夾結構：

Main (Root branch) 
    "Builds" (Folder that contains all of the MSBuild and Workflows for building) 
    "Documents" (Folder that contains version specific documents) 
    "Deployment" (Folder that contains config required for deployment | We use TFS Deployer from Codeplex) 
    "Setup" (Folder contains all of the setup resources) 
    "[Company].[Namespace].*" (Folders that contains a project) 
    "Tools" (Folder for all your nuts and bolts) 
    "Toolname" (Folder for a specific tool or reference library)

的想法是，這是球隊的選擇是否使用外部產品的新版本或參考圖書館。僅僅因爲一個團隊可以升級到NUnit的新版本並不意味着另一個團隊選擇不這樣做，因爲它是幾個星期的工作。

通過一切手段有一箇中央「工具」項目，你總是用最新的和你的團隊從那裏拉動，但沒有外部依賴項更新。它使自動化構建成爲一場噩夢，即使現在不是一個好時機，也能讓開發人員升級。最重要的是，確保您將任何外部依賴關係視爲工具，即使它來自另一個內部團隊。

參考文獻：TFS Deployer

來源

2010-05-06 15:53:29

您是否可以更新結構以指示.sln和.csproj文件的位置？我目前有一個場景，其中每個可部署項目（Windows服務或Web應用程序）都有解決方案，並且每個解決方案都可以依賴於解決方案中的項目（例如，一個解決方案中的接口項目由另一個解決方案中的另一個項目）。你的建議是否迎合了這個？我們目前在構建到已知位置時手動複製可分發程序集，並預先構建我們在依賴項中複製的其他項目並引用副本。 – jamiebarrow 2011-08-03 16:03:51

我有兩個答案：我們做什麼和我爲你建議的。

對於我們來說，我們有一套Web應用程序，它們都擁有很多共享組件。因此，雖然這是大約50個不同的程序集（VS Projects）和5-10個解決方案（取決於你如何看待它），但它們之間存在非常顯着的重疊，這意味着我們想要使用TFS per-dev合併比分支和合並那些重疊的資源。因此，我們實際上將所有這些都保存在一個TFS項目中。下面是我們如何有我們的設置（改爲有意義的名字給你）：

"Official Projects" (Collection) 
    "Production Applications" (Project) 
    "Technology Proof of Concepts" (Project) 
    "Reference Projects" (Project) - this is a simple solution/projects using our architecture to make our architecture easier to understand as people join our team. Other reference apps will go here in the future. 
    "TFS Configuration" (Project) 
"Playground" (Collection) 
    "John Doe" (Project) 
    "Jane Doe" (Project) 
    "Security Team" (Project) 
    "Production Test" (Project)

在我們的設置，我們有正式的公司代碼的地方。另外，我們有一個區域可以讓人們不用擔心會搞亂任何東西，而能夠利用各種與TFS相關的好處。

但是，在你的情況下，如果我正確閱讀各行，我會建議一些不同的東西。我的假設：

每個項目，除了有一些常見的程序集（我在考慮日誌記錄，安全性以及公司範圍內共享的其他實用程序程序集）之外，都是不相關的項目。
共享/常用程序集並不會經常更改，因此您可以使用DLL引用而不是項目引用，因爲您始終使用最新的最新/最新/日版代碼。
（基於TFS的假設，因爲我仍然在學習）您可以跨同一集合中的各個項目進行分支，但是您無法跨集合進行分支。
除了上述共享程序集之外，其他代碼不會在團隊間共享。

因此，與這些假設，我會去像這樣的東西：

"Common Resources" (Collection) 
    "Source" (Project) - everything goes here such as logging assemblies, security assemblies, etc. 
    "Version 1" (Project) - Branch as you "rev" your common assemblies so people have access to older versions. 
    "Version 2" (Project) 
    "Version 3" (Project" 
    etc. 
"Team 1" (Collection) 
    "Project 1" 
    "Project 2" 
    "Project 3" 
    "Project 4" 
    "Project 5" 
"Team 2" (Collection) 
    "Project 1" 
    "Project 2" 
    "Project 3" 
"Team 3" (Collection) 
    "Project 1" 
    "Project 2" 
etc.

這樣做，這樣，你通過DLL引用是指共同的組件。作爲團隊或開發人員，您可以決定何時開始使用較新版本的常規裝配。要做到這一點，您只需在該版本的分支上獲取最新信息，然後添加對其的引用。如果我的假設＃3錯了，那麼希望你能做得比那更好。否則，每個項目都有自己的空間（可以包含不止一個VS解決方案/項目，這是一個好主意），並且您的團隊擁有自己的收藏，以與其他團隊分開。

只要我的$ 0.02值...

來源

2010-04-23 15:51:57 Jaxidian

你是對的，你不能跨集合分支 – 2010-05-06 15:55:12

我不喜歡你的最新版本分支上的最新評論，並添加一個引用。這會在您使用自動化buid時導致問題，並且無法解決。最好在yoru解決方案文件夾中添加一個Tools文件夾，並在那裏共享資源。這可以防止在線後面引用問題，並且不需要分支公共資源。 – 2010-05-06 15:59:51

但是我喜歡你的球隊收藏:)但是當球隊1期望它的盤子太多並且想把項目2交給球隊3時會發生什麼？ – 2010-05-06 16:02:29

使用工作區，它們不是跨團隊集合只有工作，但與大多數版本的技術工作。

來源

2010-08-01 23:08:45 Mike

我們採取了第三方組件的簡單方法，併爲他們創建了一個單獨的項目。然後，當另一個項目需要引用程序集或DLL時，我們將程序集所在的文件夾分支到目標項目的「ThirdParty」文件夾中。

這也爲我們提供了一種機制，可以使用基礎文件夾的前向合併以漸進的方式將升級推出到第三方組件。

來源

2011-04-19 15:24:04

在TFS 2010中組織源代碼

回答

相關問題