我们刚刚启动并运行了 TFS 2010。我们将把我们的源代码迁移到 TFS，但我有一个关于如何组织代码的问题。
TFS 2010 具有项目集合的新概念，因此我决定我们组织内的不同组将拥有自己的组。我的团队开发了许多不同的 Web 应用程序，我们有几个共享组件。我们还使用了一些第三方组件(例如 Telerik)。
显然每个 Web 应用程序都是它自己的项目，但我应该将共享组件放在哪里？每个组件都应该在它自己的项目中，并具有单独的构建和工作项吗？
是否有针对 TFS 2010 执行此操作的最佳实践或推荐方法？
最佳答案
最佳实践是在 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
关于tfs - TFS 2010 中的项目结构，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/2684685/