Visual Studio TFS 团队项目和集合指南
在 MSDN 杂志 文章，“Visual Studio TFS 分支和合并指南”(msdn.microsoft.com/magazine/gg598921) 中，Visual Studio ALM Rangers 推出了一些新的分支方案和相关指导，可帮助您处理复杂的真实分支和合并环境，以便改进解决方案的一致性和质量以及应用程序生命周期管理 (ALM) 的整体过程。
概括来说，Rangers 就是通过解决功能缺失问题以及消除阻碍产品采用的因素来提倡 Visual Studio 产品组、Microsoft 服务和 Microsoft 最有价值专家 (MVP) 社区之间协作的一组专家。
在本文中，Rangers 提供了组织和配置 Team Foundation Server (TFS) 团队项目和团队项目集合的指南。
阅读完本文后，您能更好地了解以下内容：
- 团队项目集合及其优点
- 有关如何选择将一个或更多团队项目合并到一个团队项目集合中或将它们保留在单独团队项目集合中的注意事项
- 有关如何通过组织团队项目和团队项目集合来提高隔离或改进可伸缩性的注意事项
- 如何存档一个或更多不活动的团队项目
本文将帮助您理解团队项目和团队项目集合组织是如何受下列问题影响的：
- 安全性和 TFS 配置、团队项目集合和团队项目
- 选择过程模板
- 过程模板自定义，包括自定义工作流、工作项类型自定义、自定义报告、自定义查询和自定义过程指南
- 团队组织
- 团队项目组织，包括区域和迭代
- 项目管理注意事项，包括项目里程碑和计划
规划
为了确保所有利益干系人具有有效和可伸缩的 ALM 系统，Visual Studio TFS 规划通常会从建议的基础结构以及团队项目和团队项目集合的架构开始。
Visual Studio 2010 快速参考指南 (vs2010quickref.codeplex.com) 以及 Visual Studio 2010 和 TFS 2010 虚拟机 (VM) 工厂 (rangersvsvmfactory.codeplex.com) Rangers 指南项目提供了概念、指南和快速参考海报，用于支持容量规划并帮助回答有关基础结构应为物理或虚拟基础结构还是两者并存的问题。
虽然您通常先规划和定义团队项目集合，然后再在 TFS 2010 环境中定义团队项目，但是我们会首先介绍团队项目。
Visual Studio 团队项目
在 TFS 2005 和 TFS 2008 中，一个 TFS 服务器可能会承载一个或更多团队项目。 每个团队项目实质上都是一个产物容器，包括源代码（组织在各文件夹、分支文件夹和分支中），并包括一个或更多 Visual Studio 解决方案、Team Build 配置文件、Team Load Test Agent 以及可选的 SharePoint 存储库，该存储库包含项目相关文档以及由团队用来跟踪和执行由过程模板控制的一组工作的安全设置。 不能将团队项目与 Visual Studio .NET 项目混淆，后者包含生成 Microsoft .NET Framework 程序集所需的全部生成和配置设置；一个 Visual Studio .NET 解决方案包含一个或多个 Visual Studio .NET 项目并定义项目依赖关系、生成过程和顺序；或包含一个项目计划，该计划用于从一组要求进行生成。
有关创建和管理团队项目的更多信息，请参见“创建和管理团队项目”MSDN 库页面 (bit.ly/eCP0yX)。
让我们讨论一下将项目计划组织到团队项目中时的注意事项。 团队项目常常包含与开发单个产品或产品系列关联的最大工作单元。 例如，在 Microsoft 产品中，Visual Studio 和 Office 是两个产品系列，每个产品系列都包含在其自身的单独团队项目中（请参见图 1），因为这两个产品系列的开发是按照完全不同的日程表进行的，并具有各自的里程碑和发布计划。
图 1 Visual Studio 和 Office 团队项目
注意配置问题和安全隔离十分重要。 创建新的团队项目过程中最费时的一项工作是对项目进行配置以便它由一个或更多团队使用，主要通过定义安全用户、组和权限来控制对团队项目及其产物的访问。需要针对在正确粒度级别上正确定义安全性的利益对这种配置工作进行平衡，以便让团队中的成员能够完成他们需要 完成的工作。 同时，正确的安全配置可以防止不应该执行某些任务的人员无意间或故意对团队项目及其资产其造成损坏。
对于具有不同里程碑和发布计划的产品系列（如 Visual Studio 和 Office），合理的做法是将每个产品系列组织为独立团队项目以实现安全隔离。 与每个产品系列相关联的开发团队可能是完全分开的，他们不大可能需要和被授予两个团队环境中的参与和生成权限。
对于使用不同方法的项目计划（例如，一个团队选择使用 Microsoft Solutions Framework (MSF) 开发 Agile Software Development 5.0 版，而另一个团队选择使用 Microsoft Solutions Framework (MSF) for Agile Software Development 5.0 版），这就需要两个独立的团队项目，因为一个给定团队项目有且只有一个与之关联的过程模板。
对于需要“区域”和“迭代”的唯一定义的项目计划，建议将团队项目分开，因为一个给定团队项目只定义一个区域和迭代层次结构。 或者，一个团队项目可以使用区域来组织多个功能团队（请参见图 2），这些功能团队共享相同的迭代（请参见图 3）。 另请参见由 Martin Hinshelwood 撰写的文章“使用 Team Foundation Server 2010 创建项目”（在 bit.ly/hSnHGw 上），该文章讨论了使用区域而不是具有许多小型团队项目的方案。
图 2 使用区域来组织单独功能团队的团队项目
图 3 多个功能团队共享迭代层次结构的团队项目
版本控制签出设置（例如，独占签出、签入策略和签入说明）是为某个团队项目定义的，并且这些设置不跨越团队项目边界共享。 如果分开的项目计划需要不同的源代码管理设置，则这些项目计划必须与单独的团队项目相关联。
过程模板自定义包括已自定义（或自定义）工作流、工作项类型 (WIT)、报告和查询。 您可以自定义用于创建新团队项目的过程模板，或自定义由某个团队项目使用的特定过程模板，这种特定过程模板不会跨多个团队项目共享。
共享团队项目产物通常是通过从一个团队项目分支到另一个团队项目实现的。 在前一篇文章中，我们讨论了共享公共代码的各种方法，其中很多方法都涉及到分支。
您可以看到，决定分开的项目或项目计划是可以共享相同的团队项目还是必须与不同的团队项目相关联需要考虑很多因素。 您应考虑各种因素，并做出最适合您的组织的团队项目组织决定。
Visual Studio 团队项目集合
虽然团队项目在一定程度上是相互独立的，但在 TFS 2005 和 TFS 2008 中，某些维护活动（例如，将多个 TFS 服务器合并为一个服务器）在过去是很难实现的。 并且，组织内的独立业务部门只能通过在组织内实现两个或更多 TFS 服务器来取得组织隔离，这就提高了基础结构成本，增加了维护和整体复杂性。
Visual Studio 2010 引入了团队项目集合。 每个 TFS 服务器可以有一个或更多团队项目集合。 反过来，一个团队项目集合包含一个或更多团队项目。 团队项目集合是 TFS 的基本恢复单位。 从备份和还原的角度看，团队项目集合与 SharePoint 站点集合类似。
Visual Studio 2010 快速参考指南项目 (vs2010quickref.codeplex.com) 提供了快速参考海报，可帮助您计划新团队项目集合功能和团队项目。 团队项目集合提供了更具可伸缩性的 TFS 服务器部署。 在 TFS 2010 中，一个团队项目集合大致相当于 TFS 2005 或 TFS 2008 中的一个 TFS 服务器。 有关创建和管理团队项目集合的更多信息，请参见 msdn.microsoft.com\library\dd236915。
将团队项目隔离为独立团队项目集合时的注意事项包括可伸缩性、备份、恢复、安全隔离以及在团队项目间共享信息。
利用通常与数据库环境相关联的可伸缩性和负载平衡基础结构，团队项目集合能够在物理 SQL 服务器和 SQL 服务器实例之间实现负载平衡，从而为 TFS 服务器的可伸缩性提供支持。 如果您能够在 SQL 服务器之间实现负载平衡，就可获益于将团队项目拆分成多个团队项目集合。
如前所述，TFS 的基本恢复单位是团队项目集合。 不能对团队项目单独进行备份或还原。 如果您需要粒度备份和恢复功能（例如，如果您不想恢复一个以上团队项目），则将团队项目隔离为独立的团队项目集合以便进行备份和恢复会使您的组织获益。
如果要以适当的控制程度和粒度正确管理团队项目集合的安全设置，则可能会比较耗时。 在添加新的团队项目集合时，必须考虑用于设置每个集合的初始和后续工作。 如果在一个 TFS 服务器上管理的团队项目的项目团队具有不同的安全要求，则出于安全原因将团队项目隔离为独立的团队项目集合会让您受益。
另一方面，如果在一个 TFS 服务器上管理的团队项目的项目团队不需要安全隔离，则让组织的团队项目位于同一个团队项目集合中会使组织受益（请参见图 4）。
图 4 团队项目集合共享和隔离边界
虽然可以在相同团队项目集合中的团队项目间实现产物（如源代码文件）共享，但这些产物不能跨越团队项目集合边界共享（请参见图 4）。 如果两个团队项目必须共享产物，则他们必须位于同一团队项目集合中。
有关使用团队项目集合来共享和隔离源代码并进行分支和合并的讨论不在本文范围之内。 建议您参考tfsbranchingguideiii.codeplex.com 以了解今后的指南中包含的相关讨论和信息。
团队项目存档策略
定期维护必不可少，因为 TFS 环境从来不能安装在无限制的物理资源上。 管理员需要计划定期维护以存档完整的项目数据并释放服务器上压力，以免开发团队遇到性能问题。
Rangers 升级指南 (vs2010upgradeguide.codeplex.com) 定义了一些可能的策略以作为升级指南的一部分，这些策略与 Microsoft 咨询服务已开发的过程类似（请参见图 5）：
图 5 可能的存档策略
- 首先制作团队项目集合的副本。
- 从新克隆的存档团队项目集合中删除活动的团队项目（使用 TFSDeleteProject 命令行实用工具）。
- 从原始（活动）团队项目集合中删除存档的项目。
- 然后，可以将新的团队项目集合存储至外部介质上（例如，磁带或闪存），再从硬盘将其删除。 如果对系统进行审核，则很容易将存档介质还原。
- 分离新的团队项目集合，以便以后轻松地重新获取该集合。
从概念上看，此策略似乎并不重要，但确实需要一种策略来确定哪些团队项目可以存档，而哪些不能。 请特别注意，在执行 TFSDeleteProject 操作时，会将源代码分支从系统中移除，并且这个事件是可以撤消的。
以下是用于存档策略的建议：
- 为开发团队建立项目收尾策略以清理项目数据并将其存储。 源代码不是唯一需要保存的资料。 项目要求很有趣，但是它们的格式很可能不能重新使用，或者不能从其进行增强。 功能规范需要与以前的功能规范混合才能反映产品在项目完成时处于生产条件下的状态。 随后，可以对该项目的要求进行存档，无需担心数据丢失。 工作项不能像源代码那样从一个团队项目合并至另一个团队项目，因此，需要在项目完成后做出如何存储完成的工作项的决定。
- 向所有团队发送标准要求，通知他们该事件之前有一个挂起的存档操作，并列出针对该存档的所有团队项目。
- 在每个团队项目中建立一个里程碑文件夹以作为完整项目计划的最终项目数据的容器，包括要求列表、最终项目报告以及项目收尾时按正常方法策略存储的全部文档。
实质上，若要成功进行存档，需要保留所有项目数据，而不仅仅是保留源代码。
为了对某个业务部门可能分离为两个或更多管理实体做出响应，需要拆分团队项目集合。 在这种情况下，虽然不会存档任何团队项目，但将部署与用于存档团队项目的方法类似的方法。 第二个团队项目集合必须要像原始团队项目集合那样进行处理，原因在于它现在需要独立于原始团队项目集合的定期维护。
在团队项目集合间移动团队项目不太容易，并且一旦将集合拆分，就不能简单地将其重新合并，因为只能将新的团队项目添加到集合中。 为了合并团队项目集合，需要使用 TFS API 获得自定义代码，以便将项目数据从一个集合复制到另一个集合。
虽然并未建议这样做，但可使用 TFS 集成工具将团队项目合并成团队项目集合中，请参见 TFS 集成工具文档 (bit.ly/9tHWdG)。
在以后的文章中，我们将研究 Rangers 如何使用 Visual Studio ALM 工具来应对分布式敏捷团队管理所带来的挑战。