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” - 所以基本上，许多项目中的这些二进制文件的每个“重复”实质上就像是一个“指针”。