Team Foundation服务器源代码pipe理结构

我一直在努力为新一年的Team Foundation Server部署标准化源代码pipe理结构。 我已经开始使用CodePlex上提供的Microsoft Team Foundation Server分支指导文档。

我希望得到一些反馈意见，并回答关于这个build议结构的一些具体问题。 当谈到在TFS中构build源代码控制时，我了解到有太多的“标准”可供select，没有真正的标准。

首先，我将概述和描述决定和用法。 

$/ {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}条目），也可以包含产品或工具套件forms的多个相关项目。 三大容器被称为Development ， Integration和Production 。

在“ Development容器的“中继”中，为“ Source文件夹中构成产品的项目提供了相应的unit testing，并在“ Tests文件夹中提供了相应的unit testing。 大部分的小型开发将出现在树干中，分支可通过Trunk文件夹的兄弟Branches文件夹（作为分支容器）使用。 一个或多个解决scheme文件将存在于Trunk ，允许该级别的分支机构捕获解决scheme，源代码和unit testing。

Integration容器在非TFS实现中通常被称为“主”，仅用于集成来自Development变更集以创build稳定且可testing的构build。 一旦获得可testing产品，它最初是作为Development容器的一个分支而创build的。 这个容器的构build将用于我们的testing环境和负载testing环境。 我们select包含可testing构build的负载testing，以便我们可以监控性能变化，能够快速隔离可能造成任何违规的变更集。

Production用于生产前期生产和生产质量的build设。 一旦build议稳定版本发布，它最初是作为Integration容器的一个分支创build的。 在Releases文件夹中，遵循“按发布分支”结构，在一个地方提供快照和隔离。 （例如，当Release 1.1已准备好预生成版本时，稳定的Integration容器将分支到Production/Releases结构中的新Release 1.1文件夹，随后的RC和RTW / RTM也被提升到此文件夹中。 ）分支结构也存在，如Branches容器中所见。 这允许“修补程序”，通常是修订标记（Major.Minor.Revision）。 该分支是从当前版本创build的，并合并到新版本标记中 – 如Release 1.1.1 。 接受后，Changeset将被反向集成到Development container的Trunk 。

我们认为这种结构在健壮性和复杂性之间是一个公平的平衡。 但是有一些唠叨的问题，我不能在逻辑上适合模型。 他们是：

团队build设 – Development和Integration集装箱最初将作为夜间build设开始，最终转移到持续集成（CI）。 生产容器将被手动build立。

  • 构build定义应该在哪里生存？ 编辑 – 基于几个响应，TeamBuildTypes文件夹已被移动到树干并分支到适当的容器。 但是，这会产生一个新的问题（如下）。

  • 通过将TeamBuildTypes文件夹放在适当的容器中，这是否意味着将在适当的文件夹之间复制所有构build定义？ 例如，拥有开发质量的构build定义以及可testing的构build等，所有这些构build都存在于整个结构的所有TeamBuildType文件夹中。

文档生成 – 我们使用Sandcastle生成文档。 具体来说，我们也使用Sandcastle帮助文件生成器来pipe理输出。 这会以SFHB特定的格式生成项目文件。

  • 应该将生成的文档存储在源代码pipe理结构中吗？

  • 应该为每个集装箱生成文件，还是只对生产前质量和生产质量具有价值？

  • 为了保持快速的本地构build时间，文档创build应该由构build定义拥有吗？

  • SHFB特定文件应该在哪里存在？ 我最初的想法是把它作为Source和Tests文件夹的同行。 我同意推荐，它是Source和Tests的同行。 图改变，以反映这一变化。

第三方二进制文件

  • 应该将二进制文件（控件，库等）存储在源代码控制中吗？

  • 如果是这样，它应该是它自己的团队项目？

一般文件 – 非生成的文件，如要求，devise文件，testing计划等不会反映在源代码pipe理结构中的文件夹。 在与我的开发人员和同行进行了一些研究和讨论之后，使用Team Explorer中内置的Documents文件夹提供了更多的好处，因为它反映了Team Project Portal中的结构，并且一些（业务）用户不需要额外的学习源码控制方面的TFS。

当我得到问题的答案时，我将更新结构以提供更清晰的图像。 我也欢迎任何其他有关潜在变化的意见。 如果我有任何其他问题，我会确保修改这个post。

编辑：

  • 澄清。 Source和“ Tests文件夹也位于“ Integration容器下。

  • Micah和Josh都提到了关于第三方二进制文件的很多观点。 关于这个问题增加了问题。

  • 文档生成可能会很慢。 添加了关于文档创build是否应该由特定团队构buildtypes拥有的问题。

  • 增加与非生成文档相关的解决scheme，如需求，devise文档，testing计划等。

  • 添加了与TeamBuildTypes文件夹有关的构build定义相关的解决scheme。

  • 基于各种反馈，将TeamBuildTypes文件夹移至中继线/分支级别。

我喜欢将Sandcastle文件作为源代码和testing对象的想法，我将添加一个文档文件夹，然后包含sandcastle文件，以及可选的实际文档。

有明确的意见分歧，我相信我会因此而低估（因为我以前一直）。 我会把生成的文档放在TFS中有几个原因：

  1. 在每个版本中，您都希望得到您的文档，使用TFS是一个简单的方法，以确保您的文档保持在正确的位置。
  2. 使用TFS来存储它意味着每个人都会知道去哪里获取文档。

有一件事我不知道我总是与第三方依靠的地方在哪里，可能是他们属于源头，所以他们在每个项目，但如果你想跨项目分享，你可以添加一个新的顶部级别的节点。

编辑

对于我的二进制文件，我通常会结束

$ /第三方/公司/产品/版本/ src目录（可选）

所以例如我有

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

我喜欢添加源代码，我不得不修补CA的源，我不喜欢做的，但是当第三方不修复错误，你必须诉诸这一点。

伟大的布局和解释。 我一直在努力解决完全相同的问题。 我结束了一个非常相似的结构。 矿井变化不大。 

 Development/ Trunk/ Binaries/ -- Shared libraries Source/ Test/ Docs/ -- Documentation TeamBuildTypes/ -- Build definitions
  • 添加二进制文件夹允许您在分支中的所有项目都可以引用共享库的位置
  • 我们把文档放在这里，这样它就可以和它的特定分支一起旅行。
  • 我们的构build定义是在发展层面，因为我们可以将它们分布在所有分支的一个位置，但是它肯定是在分支层面，可能更有意义。

应该将二进制文件（控件，库等）存储在源代码控制中吗？ 如果是这样，它应该是它自己的团队项目？

我认为他们肯定应该受到源代码的控制，但我认为没有理由把他们放在自己的团队项目中。 一个小心的问题是TFS由于某些原因对待二进制文件略有不同。 我有更新源代码pipe理中的二进制文件的问题，但其他机器上的“最新”不会导致更新文件。 有时您需要执行“获取特定版本”并检查该特定文件的“覆盖未更改的文件”选项。

你应该把你的TeamBuilds文件夹放在你的主干下。 这在TFS2005中是不可能的，但是微软在2008年修复了它。

原因是你的版本可能会随着更新的版本（例如：新的打包scheme，不同的testing等）而改变，这可能使得它与旧的维护版本不兼容。 这就是为什么你应该把团队build设和代码版本结合起来。

这样，可以说你释放一个1.0版本，并把它放在发布文件夹。 您可以在Development trunk中使用v2.0编译并发布补丁程序（可能需要修改版本）

对于你的二进制文件 – 显然只有版本控制下的二进制文件才是“第三方”的程序集，而不是作为自动构build的一部分“构build”的。 如果你有自己的库，你有他们的源代码版本控制等 – 你应该看看各种策略，build设和同步等。

然后，我将它们组织为Josh – 然后使用分支将二进制文件“复制”到解决scheme树中.NET项目文件夹的同位体_ExternalReferences文件夹。 这是一个非常有效的服务器端方式，因为TFS版本控制只存储“Deltas” – 所以基本上，在许多项目中，这些二进制文件的每个“重复”基本上就像一个“指针”。

我build议的一件事就是不要使用默认位置来进行团队构build，并将其包含在“可分支”级别，因为在分支时出于各种原因（例如代码升级），您需要将构build脚本分支并同步它。

另外一个新的和更具体的情景指南也刚刚发布在http://www.codeplex.com/TFSBranchingGuideII

    Interesting Posts

    从Visual Studio Team Services中删除团队项目