问题标签 [team-project]

我有一个客户，他使用一个 TFS 项目仅用于源代码控制，现在想要管理一个完全不同的 TFS 项目中的工作项，使用不同的流程模板，并打算将变更集链接到 TFS 项目中的工作项。

我知道这在 TFS 中是可能的，但不知道这种配置有什么限制或问题。例如构建摘要、报告等。

我更喜欢将代码分支到一个新的 TFS 项目中，并在一个项目中一起管理代码和工作项，但需要知道上述方法是如何叠加的。

我一直致力于为新的一年的 Team Foundation Server 部署标准化源代码控制结构。我首先使用 CodePlex 上提供的Microsoft Team Foundation Server 分支指南文档。

我希望得到一些反馈和对我对拟议结构的一些具体问题的回答。当谈到在 TFS 中构建源代码控制时，我了解到有太多“标准”可供选择，以至于没有真正的标准。

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

一般逻辑是团队项目可以包含单个逻辑项目（没有{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 文件夹移至主干/分支级别。

我们的小型开发工作室正在寻求将我们的项目从 VSS 迁移到 TFS，并且我们正在评估 TFS 与其他项目（还没有扣动扳机）。我们软件商店的性质是，我们在 VSS 中有 100 多个项目，从小型的单人展示项目到大型企业范围的应用程序。

我们正在尝试确定如何在过渡期间构建我们的项目，并且在大多数情况下，决定将所有内容放入一个项目站点/系统中，每个项目都有一个根目录下的子文件夹。

使用这种类型的设置，我们担心我们将失去 TFS 提供的许多功能（错误跟踪、scrum 燃尽、报告、文档存储等），因为所有项目都将位于同一个门户/项目空间中，而且它将很难分离出单个项目票/项目。

有人对此有经验吗？你的解决方案是什么？你坚持使用 TFS 吗？

假设该公司有大量独立的中小型应用程序，这些应用程序在逻辑上可以分为少数几个组。

比如我可以有BMW、Mazda、Honda、Ford....、Kawasaki、Harley、....一共几十个甚至上百个应用。

我想我在 TFS 中有 2 个选项：

1. 为每个应用程序创建一个单独的项目。我最终有很多小项目，可能会受到限制，但好处是我可以将所有工作项、错误、报告等单独分配给每个项目，并且每个项目都有一个门户。

2. 创建一个项目“Cars”和一个项目“Motorcycles”，并为每个项目下的每个应用程序创建一个带有分支的源代码控制树。这将提供更好的结构和更少的开销，但我不能再单独为“本田”和“宝马”单独提供门户和工作项、错误、报告等列表。

我错过了什么吗？有没有办法两者兼得 - 一个单独的工作项列表，每个小项目的错误，而没有创建项目堆的开销，有可能达到项目数量的 TFS 限制？

寻找有关在 TFS 中设置我们的解决方案的一些反馈。现在我们正在使用源安全，这很痛苦。幸运的是，我们终于要去 TFS 了。我们有一系列项目，我正在寻找设置这些项目的“最佳”方式。

核心是构成我们其他应用程序框架的服务器解决方案和客户端解决方案。服务器有几个 Web 服务和一些库的集合，客户端解决方案有几个库和几个客户端应用程序。客户端与服务器交互。

还有一些基于此框架的单独应用程序解决方案。个别应用程序需要框架解决方案中的几个 DLL。这些 DLL 引用经常被淹没，版本有时会不同步。应用程序 1 依赖于框架客户端项目等中的库 DLL。

您将如何在 TFS 中设置这些解决方案以尽量减少您的问题？您将如何在构建框架解决方案时自动执行其中的一些操作？我正在寻找的结果是简化应用程序 1、2 和 3，从框架客户端和服务器解决方案获取 DLL 文件的更新版本，并且它们在框架和单个应用程序的发布计划中尽可能具有相同的版本。

我的第一个想法是有一个团队项目，其中包含框架和每个移动应用程序的区域。框架区域将具有客户端和服务器子区域及其子区域。然后在与框架相同的级别上，每个应用程序都将存在。我不确定这将如何工作以及如何强制其他应用程序自动获取最新的框架 DLL。

• 框架
• --服务器
• --- 服务器 WS
• --- 服务器库
• --- 服务器数据访问
• --客户
• --- 客户端 WS
• --- 客户端库
• --- 客户端数据访问
• 应用 1
• 应用 2
• 应用 3

编辑 20091020：
在与 PM 讨论框架和其中一个应用程序之后，这是他对我们应该如何布置源代码的想法。这对我来说是有道理的，而且看起来确实合乎逻辑。似乎它会使每个应用程序的开发分支及其版本保持相当独立，但它们都在同一个项目中，很容易将应用程序的需求链接回框架中所需的更改等。

对此有何想法？您看到任何优点/缺点？

在 VS.Net 2010 Beta 2 中：创建团队项目时，向导会提供是否配置项目的 Sharepoint 门户的选择。如何以编程方式确定团队项目是否配置了门户。预先感谢您的任何帮助。

我对 TFS 比较陌生，想知道其他人在有很多项目的地方组织 TFS​​ 吗？例如，有谁知道是否可以将 TFS 项目放在文件夹中，或者人们是否使用前缀/后缀？

我在一个团队中，所有成员都在他们的机器上安装了 VS2008，我们有 tortois svn 作为源代码控制系统。在我的机器上安装 VS2010 的情况下，是否有可以与他们一起使用的解决方案？或者我必须安装 VS2008 才能与其他成员一起工作？谢谢。

我试图在 TFS 2010 中找到逻辑上分离项目的最佳方式。目前我们有三个独立的项目：

1. 在服务器上运行的核心框架项目
2. 引用核心框架 dll 的控制台应用程序。
3. 一个还引用核心框架 dll 的 Web 应用程序。

TFS 将项目划分为团队项目。所有这三个都是真正独立的“项目”，但最后两个依赖于框架 .dll 引用。在 Java 世界中，您可以设置依赖管理，其中核心框架将构建并发布到公司的中央存储库，客户端项目可以单独签出，只需引用存储库中的 dll，这样就不会破坏任何项目。

TFS 是否管理依赖项？这三个项目应该设置在单独的团队项目中还是同一个项目中？您可以跨团队项目进行构建吗？

设置团队项目的最佳方式是什么，以便将依赖性问题降到最低，但也进行了分区，以便可以单独处理它们并且构建脚本可以访问 CI 的所有项目？

我们公司决定在我们的开发过程中开始使用 Team Foundation Server 2010。

我无法决定如何构建我们的收藏和团队项目。

我们共有 9 名开发人员，他们都在不同的时间从事不同的项目。

我读到的似乎有一半说要使用尽可能多的集合，而另一半说要限制集合的数量。

在创建/管理多个不一定相互交互的项目时，您的方法是什么？最好将东西放在单独的收藏中，还是将收藏数量保持在较低水平是否明智？任何帮助表示赞赏。