我一直致力于为新的一年的 Team Foundation Server 部署标准化源代码控制结构。我首先使用 CodePlex 上提供的Microsoft Team Foundation Server 分支指南文档。
我希望得到一些反馈和对我对拟议结构的一些具体问题的回答。当谈到在 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容器的主干中，文件夹中包含构成产品的两个项目的规定，Source文件夹中提供了相应的单元测试Tests。大多数次要开发将发生在主干中，可以通过Trunk文件夹的同级Branches文件夹进行分支，该文件夹充当分支容器。一个或多个解决方案文件将存在于 中Trunk，允许该级别的分支捕获解决方案、源代码和单元测试。
该Integration容器在非 TFS 实现中通常称为“主”，仅用于集成变更集Development以创建稳定且可测试的构建。Development一旦获得可测试的产品，它最初是作为容器的一个分支创建的。此容器的构建将用于我们的测试环境和负载测试环境。我们选择将负载测试包含在可测试的构建中，以便我们可以监控性能变化，能够快速隔离可能导致任何违规行为的变更集。
Production用于生产预生产和生产质量构建。Integration一旦推荐发布稳定版本，它最初是作为容器的一个分支创建的。在Releases文件夹中，遵循“按发布分支”结构，在一个地方提供快照和隔离。（例如，当Release 1.1准备好进行预生产构建时，稳定Integration容器会分支到结构中的新Release 1.1文件夹中Production/Releases。后续的 RC 和 RTW/RTM 也会被提升到此文件夹中。）还存在一个分支结构，如Branches容器中所见。这允许“修补程序”，通常是修订标记（Major.Minor.Revision）。分支是从当前版本创建并合并回新的修订标记 - 比如Release 1.1.1. 变更集将在接受后反向集成到Development容器中Trunk。
我们认为这种结构是稳健性和复杂性之间的公平平衡。但是有一些烦人的问题我无法在逻辑上适合该模型。他们是：
团队构建-容器最初将作为夜间构建开始Development，Integration最终转向持续集成 (CI)。生产容器将手动构建。
构建定义应该放在哪里？编辑 - 基于几个响应，TeamBuildTypes 文件夹已移动到主干并分支到适当的容器。然而，这确实导致了一个新问题（如下）。通过将 TeamBuildTypes 文件夹放在相应的容器中，这是否意味着所有构建定义都将在相应的文件夹之间复制？例如，具有开发质量构建以及可测试构建等的构建定义，所有这些都存在于整个结构中的所有 TeamBuildType 文件夹中。
文档生成- 我们使用 Sandcastle 生成文档。具体来说，我们还使用Sandcastle Help File Builder来管理输出。这将生成一个特定于 SFHB 格式的项目文件。
生成的文档是否应该存储在源代码控制结构中？
是否应该为每个容器生成文档，还是只对预生产和生产质量构建有价值？
为了保持快速的本地构建时间，文档创建是否应该由构建定义拥有？
特定于 SHFB 的文件应该放在哪里？我最初的想法是将它作为和文件夹的对等我同意它与Source点Tests。Source和同行的建议Tests。图表已更改以反映此更改。
第三方二进制文件
二进制文件（控件、库等）是否应该存储在源代码管理中？
如果是这样，它应该是它自己的团队项目吗？
通用文档- 非生成文档，例如需求、设计文档、测试计划等，不会反映在源代码控制结构中的文件夹中。经过与我的开发人员和同行的一些研究和讨论，使用 Team Explorer 中的内置 Documents 文件夹提供了更多好处，因为它反映了 Team Project Portal 中的结构，并且一些（业务）用户不需要额外的复杂性来学习TFS 的源代码控制方面。
当我得到问题的答案以提供更清晰的画面时，我将更新结构。我也欢迎与潜在变化相关的任何其他评论。如果我有任何其他问题，我会确保修改这篇文章。
编辑：
澄清。
Source并且Tests文件夹也确实存在于Integration容器下。Micah 和 Josh 都提出了关于第三方二进制文件的重要观点。添加了关于该问题的问题。
文档生成可能很慢。添加了有关文档创建是否应归特定团队构建类型所有的问题。
添加了与非生成文档相关的解决方案，例如需求、设计文档、测试计划等。
为构建定义添加了与 TeamBuildTypes 文件夹相关的分辨率。
根据各种反馈，将 TeamBuildTypes 文件夹移至主干/分支级别。