使用 Visual Studio Team Foundation Server 进行 团队开发
本书共分四部分，此为第二部分 包括团队生成指南、源代码管理指南、报告指南和 项目管理指南等四章节
指南：项目管理 索引 区域和迭代 z z z z
使用区域获得更出色的可跟踪性。 使用迭代表示项目中的里程碑。 为尚未分配的方案和任务创建一次单独的迭代。 确定恰当的迭代周期持续时间。
签入策略 z z z z
使用签入策略提高代码质量。 使用签入策略确保开发人员将工作项与签入相关联。 创建签入策略来实施编码标准。 设置通知，在开发人员绕过签入策略时通知您。
过程模板 z z z z
处理仅需要轻量级或非正式过程的项目时，应使用 MSF Agile 过程模板。 处理需要更为正式的过程或需要符合 CMMI 标准时，应使用 MSF CMMI 过程模板。 考虑使用一种最小化的过程模板。 修改现有过程模板来匹配团队的过程。
安全组和权限 z z
创建安全组来授予指定权限集。 将团队成员分配到适当的安全组。
团队项目 z z z z
如果希望在应用程序的版本之间迁移工作项和其他资产，则为每个应用程序创建一个团队项目。 如果希望从各应用程序版本的新工作项和其他资产开始，则每版本创建一个团队项目。 仅授予项目资产的必要权限。 将源代码树的结构设计为支持分支。
工作项 z z z z z z
在项目最初即捕捉方案。 合理定义服务质量需求。 将场景分解为可管理、模块化的开发任务。 为各任务设置验收标准。 将要求和任务链接到方案。 使用 Microsoft Excel 进行工作项的批量编辑。
区域和迭代 z z z z
使用区域获得更出色的可跟踪性。 使用迭代表示项目中的里程碑。 为尚未分配的方案和任务创建一次单独的迭代。 确定恰当的迭代周期持续时间。
使用区域获得更出色的可跟踪性 在团队项目中使用区域来组织项目任务、bug、要求以及其他工作项。还可以设置区域的权限来限制 对各个团队项目部分的访问。 使用区域表示逻辑或物理组件，然后创建子区域来表示特定功能。该结构可以帮助您组织工作项， 并且可以用来提高组件或功能的可跟踪性。 要为项目创建区域 1. 2. 3. 4. 5. 6. 7.
在“团队资源管理器”中单击您的团队项目。 在“团队”菜单中，指向“团队项目设置”，然后单击“区域和迭代”。 在“区域和迭代”对话框中，单击“区域”选项卡。 单击“添加子节点”工具栏按钮。 右击新节点，单击“重命名”，然后键入所需区域名。 单击“区域”节点。 重复第 2、3、4 步，为您的项目结构创建其他区域以及层次结构。
注意，创建太复杂的区域结构，尽管区域允许您分割工作项的权限，但管理这些复杂树的权限有关 联的费用。此外，将此结构/权限复制到其他团队项目也会出现问题。
其他资源 z
有关使用区域的详细信息，请参见本指南中的“如何：在 Visual Studio Team Foundation Server 中 管理项目”。
使用迭代表示项目中的里程碑 使用迭代定义在开发应用程序的过程中，团队重复特殊的主要活动集（如计划、实现或测试）的次 数。此主要活动集应该用可以计量的结果（如功能完成或组件完成）表示项目的里程碑。 要创建迭代 1. 2. 3. 4. 5. 6. 7. 8.
在“团队资源管理器”中单击您的团队项目。 在“团队”菜单中，指向“团队项目设置”，然后单击“区域和迭代”。 在“区域和迭代”对话框中，单击“迭代”选项卡。 单击“添加子节点”工具栏按钮。 右击新节点，单击“重命名”，然后键入迭代名。 单击“迭代”节点。 重复第 2、3、4 步，为您的项目创建已识别的其他迭代。 单击“关闭”。
注意：Microsoft® Solutions Framework (MSF) for Agile Software Development (MSF Agile) 过程模板 包括三个预定义的迭代。根据特定的要求，您可以删除这些迭代、重命名它们（而不是创建新的迭 代），或使它们保持不变。
其他资源 z
有关使用迭代的详细信息，请参见本指南中的“如何：在 Visual Studio Team Foundation Server 中 管理项目”。
为尚未分配的方案和任务创建一次单独的迭代 创建一次单独的迭代，可以向其分配所有尚未分配给任何迭代的方案和任务。这可以帮助您在计划 迭代时轻松识别挂起的方案和任务。
要创建单独的迭代 1. 在“团队资源管理器”中单击您的团队项目。 2. 在“团队”菜单中，指向“团队项目设置”，然后单击“区域和迭代”。 3. 在“区域和迭代”对话框中，单击“迭代”选项卡。 4. 单击“添加子节点”工具栏按钮。 5. 右击新节点，单击“重命名”，然后键入迭代名 Iteration 999。 6. 单击“关闭”。
其他资源 z
有关创建迭代的详细信息，请参见本指南中的“如何：在 Visual Studio Team Foundation Server 中 管理项目”。
确定恰当的迭代周期持续时间 当设置团队项目时，根据您的项目的大小和复杂程度确定相应的迭代周期持续时间。 确定迭代周期持续时间时，请记住以下几个要点： z z
迭代周期应该足够长，以允许团队成员有大量工作可做，还应该至少包含几个不同的方案。. 迭代周期应该足够短，以灵活容纳更改和优先级。
实际上，两周的迭代周期适合于大多数项目。
其他资源 z z
有关迭代周期持续时间的详细信息，请参见本指南中的“如何：在 Visual Studio Team Foundation Server 中管理项目”。 有关迭代周期持续时间的进一步信息，请参见本指南中的“第11章 – 项目管理介绍”。
签入策略 z z z z
使用签入策略提高代码质量。 使用签入策略确保开发人员将工作项与签入相关联。 创建签入策略来实施编码标准。 设置通知，在开发人员绕过签入策略时通知您。
使用签入策略提高代码质量 将代码分析与测试策略相结合，来提高项目的签入质量。例如，使用所提供的测试策略来确保指定 测试预先得到测试并已通过，之后再允许源代码签入 Microsoft Visual Studio® 2005 Team Foundation Server (TFS) 源代码管理。还可以配置代码分析策略，以帮助确保代码符合某些质量标准，从而确 保安全性、性能、可移植性、可维护性和可靠性规则通过。 除了强制编码标准和原则的策略之外，强制这种类型的签入策略可以确保代码符合特定的质量标准。 要为一个团队项目实施代码分析签入策略 1. 2.
在“团队资源管理器”中，右击您的团队项目，指向“团队项目设置”，然后单击“源代码 管理”。 单击“签入策略”选项卡，单击“添加”，然后选择并配置恰当的策略。
其他资源
z
有关创建和使用自定义签入策略的详细信息，请参见本指南中的“如何：为 TFS 创建自定义 签入策略详解”。
使用签入策略确保开发人员将工作项与签入相关联 设置工作项签入策略，以强制开发人员将其签入与工作项关联。 如果生成中断，知道与该生成关联的变更集以及这些变更集关联的工作项是非常重要的，因为只有 这样才能确定负责签入此代码的开发人员以及其工作的项目领域。 设置工作项签入策略，以强制开发人员将其签入与工作项关联 在“团队资源管理器”中，右击您的团队项目，选择“团队项目设置”，然后单击“源代码 管理”。 9. 单击“签入策略”选项卡。 10. 单击“添加”，然后选择并配置“工作项”签入策略。 8.
其他资源 z z
有关签入的详细信息，请参见“如何：签入挂起的更改”，地址为： http://msdn2.microsoft.com/en-us/library/ms181411(VS.80).aspx 有关工作项和变更集的详细信息，请参见“如何：将工作项与变更集相关联”，地址为： http://msdn2.microsoft.com/en-us/library/ms181410(VS.80).aspx
创建签入策略来实施编码标准 您工作的项目可能需要静态代码分析或现有签入策略不包含的编码标准。例如，您的项目可能要求 您的代码永不使用制表符字符，或者所有签入都需要注释。您可以创建新的签入策略来包含这些方 案。 要为一个团队项目实施代码分析签入策略 1. 2. 3. 4. 5.
在“团队资源管理器”中，右击您的团队项目，指向“团队项目设置”，然后单击“源代码 管理”。 单击“签入策略”选项卡，然后单击“添加”。 在“添加签入策略”对话框中，选择“代码分析”，然后单击“确定”。 在“代码分析策略编辑器”中，选择“执行 C/C++ 代码分析 (/analyze)”或“对托管代码执行 代码分析”。如果您的项目包含托管代码和非托管代码的组合，则选择两者。 如果选择托管代码分析，则根据所需的编码标准配置所需的规则设置进行托管代码分析。 这恰好确定了要执行哪些规则。
还可创建自定义签入策略以执行默认情况下不可用的检查。例如，可以拒绝某些代码模式，例如被 禁止的应用程序编程接口 (API) 调用，也可以编写策略，来执行团队的具体编码样式指导原则，例 如应在源代码的什么位置放置花括号。
其他资源 z
有关创建签入策略的详细信息，请参见本指南中的“如何：在 Visual Studio Team Foundation Server 中创建自定义签入策略”。
设置通知，在开发人员绕过签入策略时通知您 Team Foundation Server 版本控制不防碍您重写签入策略。但是，您可以使用以下步骤检测签入策略 是否已被重写：
1. 2.
使用 Team Foundation Server Eventing Service（来自 Team Foundation Core Services API）来连 接签入事件。 编写一个分析变更集详细信息的 Notify 方法，如果已发生重写，则该方法起反作用。
另外，可以手动扫描变更集历史记录，发现策略重写。
其他资源 z
要进一步了解重写签入策略，请参见“如何：重写签入策略”，地址为： http://msdn2.microsoft.com/en-us/library/ms245460(VS.80).aspx
过程模板 z z z z
处理仅需要轻量级或非正式过程的项目时，应使用 MSF Agile 过程模板。 处理需要更为正式的过程或需要符合 CMMI 标准时，应使用 MSF CMMI 过程模板。 考虑使用一种最小化的过程模板。 修改现有过程模板来匹配团队的过程。
处理仅需要轻量级或非正式过程的项目时，应使用 MSF Agile 过程模板 当使用测试驱动的开发 (TDD) 或其他敏捷方法时，应该使用 MSF for Agile Software Development (MSF Agile) 过程模板。这是用于敏捷软件项目的轻量级过程。应该使用此项目模板作为您的首选， 除非您特别需要 MSF for CMMI Software Development (MSF CMMI) 过程模板提供的其他过程改 进功能。 您可以轻松编辑 MSF Agile 过程模板，并且进行修改，使其适合您的过程要求。
其他资源 z z z
有关详细信息，请参见本指南中的“第11章 – 项目管理介绍”。 有关 MSF Agile 过程模板的详细信息，请参见本指南中的“第 13 章 – 用于敏捷软件开发项 目的 MSF”。 有关自定义过程模板的详细信息，请参见本指南中的“如何：在 Visual Studio Team Foundation Server 中自定义过程模板”。
处理需要更为正式的过程或需要符合 CMMI 标准时，应使用 MSF CMMI 过程模板 当使用目标为改进现有过程的正式软件开发过程时，应该使用 MSF for CMMI Software Development (MS CMMI) 过程模板。 您可以轻松编辑和修改此过程模板，使其适合您的过程要求。
其他资源 z z
有关详细信息，请参见本指南中的“第11章 – 项目管理介绍”。 有关自定义模板的详细信息，请参见本指南中的“如何：在 Visual Studio Team Foundation Server 中自定义过程模板”。
考虑使用一种最小化的过程模板 很多团队不需要支持标准团队项目的所有部分。例如，很多团队想使用团队项目（并非 Microsoft Office SharePoint® 门户）的源代码管理部分。可以修改团队项目模板，并且可以删除模板中一些不 需要的部分。修改模板时，将需要保留“组权限和分类”部分，但可以根据需要保留或删除其他部 分。
要创建最小化过程模板，应该使用过程模板管理器将模板下载到本地计算机，编辑模板以删除将不 使用的部分，然后将此模板上载回服务器。
其他资源 z z z z
有关过程模板的详细信息，请参见本指南中的“第13章 – 过程模板介绍”。 有关自定义过程模板的详细信息，请参见本指南中的“如何：在 Visual Studio Team Foundation Server 中自定义过程模板”。 有关自定义过程模板的进一步信息，请参见“自定义过程模板”，地址为： http://msdn2.microsoft.com/en-us/library/ms243782(VS.80).aspx 有关使用最小化过程模板的详细信息，请参见“如何将 TFS 仅用于源代码管理”，地址为： http://blogs.msdn.com/richardb/archive/2007/05/10/how-to-use-tfs-for-source-control-only.aspx
修改现有过程模板来匹配团队的过程 您工作的项目可能并不适合 Microsoft Visual Studio Team System (VSTS) 提供的开箱即用过程模 板。您可能需要另一种工作项类型，或者使用完全不同的处理方法。这种情况下，您应该修改现有 的过程模板。选择最适合您的过程要求的过程模板，然后根据需要修改该模板。 通常，需要自定义过程模板的以下区域： z z z z z z z
组和权限 工作项类型 源代码管理签入说明和策略 区域和迭代 报告 团队门户 过程指南
其他资源 z z
有关详细信息，请参见本指南中的“第13章 – 过程模板介绍”。 有关自定义模板的详细信息，请参见本指南中的“如何：在 Visual Studio Team Foundation Server 中自定义过程模板”。
安全组和权限 z z
创建安全组来授予指定权限集。 将团队成员分配到适当的安全组。
创建安全组来授予指定权限集 在 Team Foundation Server 中创建项目时，无论选择了怎样的过程模板，都会为该项目创建四个默 认组。默认情况下，每个组都具有专门为其定义的一组权限，用于管理这些组的成员被授权执行的 操作。这四个组为： z z z z
项目管理员 贡献者 读者 生成服务。
您可以为团队项目创建安全组以更好地满足组织的安全需要。创建安全组是为一组用户授予团队项 目的指定权限集的有效方法。确保仅为该组授予了必要的最少权限，仅添加了必须属于这个新团队 项目组的用户或小组。
此外，还使用以下原则： z z z z
不要更改默认组的权限（如果执行了此操作，则应该采用相同的方法在每个项目中都执行此 操作） 仅对服务器级别上的成员身份使用 Active Directory (AD) 组 使用 TFS 组进行权限设置（而不是 AD 组） 从不拒绝任何操作（通常，拒绝意味着您使用的分区小于理想分区）；拒绝时，确保您的理 由合情合理
其他资源 z z
有关创建安全组的详细信息，请参见本指南中的“如何：在 Visual Studio Team Foundation Server 中管理项目”。 有关 TFS 权限的详细信息，请参见“Team Foundation Server 权限”，地址为： http://msdn2.microsoft.com/en-us/library/ms252587(VS.80).aspx
将团队成员分配到适当的安全组 确定在该项目上工作的团队成员及其角色，并通过使用现有的团队项目组、服务器级别的组或您创 建的自定义的安全组将这些团队成员分配给 TFS。 当将成员分配给安全组时，只分配那些需要具有对该安全组的可用权限的成员。如有必要，可以创 建具有适当安全权限的自定义安全组，然后将用户分配给这些安全组。
其他资源 z
有关安全组的详细信息，请参见本指南中的“如何：在 Visual Studio Team Foundation Server 中 管理项目”。
团队项目 z z z z z
如果希望在应用程序的版本之间迁移工作项和其他资产，则为每个应用程序创建一个团队项目。 如果希望从各应用程序版本的新工作项和其他资产开始，则每版本创建一个团队项目。 当工作的大型项目跨越多个项目时，每个团队创建一个团队项目。 仅授予项目资产的必要权限。 将源代码树的结构设计为支持分支。
如果希望在应用程序的版本之间迁移工作项和其他资产，则为每个应用程 序创建一个团队项目 如果您不仅想将重用源代码带入下次，也想将工作项和其他 TFS 资产带入下次，可考虑每个应用 程序使用一个团队项目。多个版本的应用程序使用一个团队项目时，所有 TFS 资产都会自动带入 下次发布。当您准备发布新版本的应用程序时，可以在项目内创建一个分支以表示此发布并分离该 代码。 每个应用程序使用一个项目时，请记住以下几个要点： z z z z
强制平行发布以共享工作项体系结构、签入策略和过程指南。 报告更加困难，因为报告默认针对整个项目，必须在发布前添加筛选。 如果您有数以百计的应用程序，每个应用程序都处于自己的项目之中，那么就会遇到 TFS 性 能和伸缩限制的问题。 您将积累下来自多次发布的“累赘”。解决此问题的最简单方法是创建一个新的项目，分支您 要带入该项目中的代码。
其他资源 z
有关使用团队项目的详细信息，请参见“何时使用团队项目”，地址为： http://blogs.msdn.com/ericlee/archive/2006/08/09/when-to-use-team-projects.aspx
如果希望从各应用程序版本的新工作项和其他资产开始，则每版本创建一 个团队项目 如果希望每次发布都从零开始，不将任何工作项及其他 TFS 资产带入下次，可考虑为每次发布使 用一个项目。为各发布使用新项目时，可以修改工作项体系结构、工作流、签入策略和其他资产， 而不会影响旧发布。如果旧发布将由一支独立团队维护（例如维护工程师团队），这支团队将具有 与您的主要开发团队不同的过程和工作流。 每次发布使用一个项目时，请记住以下几个要点： z
z z z
z
z
尽管将源代码从一个项目转移到另一个项目非常容易，但在项目间转移工作项和其他 TFS 资 产非常困难。由于一次只能将一个工作项复制到另一个项目，如果您想复制工作项组，将需要 编写您自己的工具。 如果您有数以百计的应用程序和发布，均处于自己的项目之中，那么就会遇到 TFS 性能和伸 缩限制的问题。 选择一种可长期使用的结构，因为重新设计已有团队项目的结构困难至极。 可在团队项目间轻松共享源代码，如下所示： 将源代码从一个项目分支到另一个项目。 将源代码从另一个项目映射到您的工作区中。 通过使用 MSF Agile 过程模板可以将 Team Foundation Server 缩放为大约 500 个项目，使用 MSF CMMI 过程模板可以将其缩放为 250 个项目。如果您创建自己的过程模板或自定义现有 的过程模板，请记住，工作项体系结构对服务器的可伸缩性影响最大。复杂的体系结构将得到 支持更少项目的服务器。
将必须继续原始项目中的所有区域，也可以在源代码管理中更改权限。
其他资源 z
有关使用团队项目的详细信息，请参见“何时使用团队项目”，地址为： http://blogs.msdn.com/ericlee/archive/2006/08/09/when-to-use-team-projects.aspx
仅授予项目资产的必要权限 创建团队项目时，查看此过程创建的默认安全组，如有必要，创建具有适当权限的安全组。然后将 项目成员分配给适当的组，以确保每个成员只获得了其所需的项目资产权限。
其他资源 z
有关授予权限的详细信息，请参见本指南中的“如何：在 Visual Studio Team Foundation Server 中 管理项目”。
将源代码树的结构设计为支持分支。 创建源代码树结构时，确保它支持分支。对源代码和其他项目资产使用单独的文件夹，以便将来需 要分离开发时，您可以只分支源代码文件夹。还要确保在源代码文件夹内，对每个组件使用单独的
文件夹，以便可以在需要时执行部分分支。 通过使用文件夹隔离其他条目，如共享代码、单元测试、库依赖项等等，以便在根据需要进行分支 时，包括或排除它们。 下面是支持分支的源代码树结构示例： z
Main – 发布产品所需的一切资产的容器 Source – 生成所需的全部内容的容器 Code – 源代码容器 Shared Code – 从其他项目共享的源代码容器 Unit Tests – 单元测试容器 Lib – 二进制依赖项的容器 Docs – 将随产品一起提供的文档的容器 Installer – 安装程序源代码和二进制文件的容器 Builds – Team Build 脚本的容器 Tests – 测试团队测试用例的容器
其他资源 z
有关源代码树结构的详细信息，请参见本指南中的“第 5 章：定义分支和合并战略”。
工作项 z z z z z z
在项目最初即捕捉方案。 合理定义服务质量需求。 将场景分解为可管理、模块化的开发任务。 为各任务设置验收标准。 将要求和任务链接到方案。 使用 Microsoft Excel 进行工作项的批量编辑。
在项目最初即捕捉方案 在项目开始时，创建和捕捉一组项目方案。这有助于您获得项目的完整描述，之后可以用来跟踪进 度。在开发的过程中，可以修改现有方案或添加新方案来表示随着时间的过去您学到的内容。 在项目最初即捕捉方案 1. 2. 3. 4. 5.
使用项目待办事项 (PBL) 文档，它是基于各个股东（包括客户、商务分析师、最终用户以及产 品经理）的输入的要求文档，并且范围遍布项目中的方案。 在团队资源管理器中，展开项目节点，右击“工作项”文件夹，指向“添加工作项”，然后单 击“方案”。 在“新建方案”页面上，输入此方案的详细信息。确保将“迭代”设置为 Iteration 999。 保存新方案。 对项目的所有已识别方案重复上述步骤。
其他资源
z
有关捕捉方案的详细信息，请参见本指南中的“如何：在 Visual Studio Team Foundation Server 中 管理项目”。
合理定义服务质量需求 在迭代周期期间为工作的每个方案定义服务质量 (QoS) 要求。这有助于为方案定义验收标准。QoS 要求的输入来自项目目标、要求以及说明文档（如果可用）。 定义 QoS 要求 1. 2.
右击您的项目的“工作项”文件夹，指向“添加工作项”，然后单击“服务质量要求”。 在“新建服务质量要求”页面上，添加以下细节： a. 将“类型”设置为适当的值，如性能、可伸缩性、压力或安全性。 b. 将“迭代”设置为当前迭代周期。 c. 从“链接”选项卡中，将 QoS 链接到特定的方案，以方便跟踪。
3. 4. 5.
保存新的 QoS 要求。 为每个科目或类型的质量要求创建一个 QoS 要求，请记住，每个方案可以有多个 QoS 要求。 确保为在特定的迭代周期期间工作的所有方案创建 QoS 要求。
重点：以后可以将 QoS 要求分解为测试任务。
其他资源 z z
有关定义 QoS 要求的详细信息，请参见本指南中的“如何：在 Visual Studio Team Foundation Server 中管理项目”。 有关工作项的详细信息，请参见“管理 Team Foundation 工作项“，地址为： http://msdn2.microsoft.com/en-us/library/ms181314(VS.80).aspx
将场景分解为可管理、模块化的开发任务 在迭代计划期间，将您的方案分解为用户题材，然后进一步将用户题材分解为开发任务。确保您创 建的开发任务可管理以及模块化。这些任务不应该持续超过一两天。如果它们比这大，则需要将任 务分解为较小的任务或子任务。这样做可以确定项目的灵活性并提高可管理性。 将方案分解为可管理、模块化的开发任务
1. 2. 3.
将选择的方案分解为开发人员的题材。 将开发人员的题材分解成开发人员的任务。 按照如下方式，捕捉 TFS 中的开发人员任务作为任务工作项： a. 在团队资源管理器中，您的项目节点下，右击“工作项”文件夹，指向“添加工作项”， 然后单击“任务”。 b. 在“新建任务”页面上，添加以下细节： i. 将“科目”设置为“开发”。 ii. 将“迭代”设置为当前迭代周期。 iii. 从“链接”选项卡中，将该任务链接到特定的方案，以方便跟踪。在该选项卡上，您 可以捕捉该任务的描述以及验收标准，验收标准用于确定该任务是否已成功完成。 iv. 将“分配给”字段设置为将在该任务上工作的开发人员。.
c. d. 4.
保存新任务。 对所有已识别的任务重复上述步骤。
对迭代的所有已识别方案重复上述步骤。
其他资源 z z
有关方案的详细信息，请参见本指南中的“如何：在 Visual Studio Team Foundation Server 中管 理项目”。 有关工作项的详细信息，请参见“管理 Team Foundation 工作项“，地址为： http://msdn2.microsoft.com/en-us/library/ms181314(VS.80).aspx
为各任务设置验收标准 开发任务在定义时就应该包括允许开发人员决定该任务何时完成的验收标准。根据您使用的过程模 板，可以采用两种不同的方法执行该任务： z z
MSF Agile – 如果您使用 MSF Agile，并且没有正式的工作项类型要求，那么最好在工作项自 身中包含验收标准作为文本。从无序列表开始并根据需要添加更多详细信息。 MSF CMMI – 如果您使用 MSF CMMI，则可以使用正式的要求为任务定义验收标准。第一步 是定义您的要求。然后创建开发任务，该任务将用于实现这些要求并将该任务链接到这些要求， 以便开发人员可以针对它们进行检查，并且也便于从要求到任务进行跟踪。
最常见的是将验收标准定义为采用最小方案或 QoS 要求的行为用户体验要求。已经达到验收标准 之后，开发人员便可以将该任务标记为完成并移动到下一个任务。
其他资源 z
有关工作项的详细信息，请参见“管理 Team Foundation 工作项“，地址为： http://msdn2.microsoft.com/en-us/library/ms181314(VS.80).aspx
将要求和任务链接到方案 当创建新的工作项（如任务、bug、问题或 QoS 要求）时，确保将这些工作项链接到驱使创建它们 的方案。这有助于确保每个工作项由一个真实的用户方案驱动，并且可以在反复开发的过程中用于 更好地跟踪方案进度。 将新任务、bug、问题或 QoS 工作项链接到方案 1. 2. 3. 4. 5. 6.
在“新建工作项”页面上，单击“链接”选项卡，在“链接”选项卡上，单击“添加”按钮。 在“添加链接”对话框的“链接类型”下，选择“方案”。 单击“浏览”以在您的团队项目中查找方案。 在列表中，选择要链接的方案，然后单击“确定”。 在“注释”框中，键入解释该工作项如何相关的注释。自动填写“描述”框。 单击“确定”。
其他资源
z z
有关详细信息，请参见本指南中的“如何：在 Visual Studio Team Foundation Server 中管理项目”。 有关工作项的详细信息，请参见“管理 Team Foundation 工作项“，地址为： http://msdn2.microsoft.com/en-us/library/ms181314(VS.80).aspx
使用 Microsoft Excel 进行工作项的批量编辑 Team Foundation Server 不支持工作项的批量编辑。因此，您必须分别编辑每个工作项。如果您需要 在短时间内修改大量工作项（例如，在会审会议期间），则考虑使用 Microsoft Office Excel® 来减 轻任务。可以将工作项从 TFS 导出到 Excel，进行修改，然后再将其导回 TFS 以保留您所进行的 任何编辑。
在 Excel 中创建一个工作项列表并编辑该列表 1. 2. 3. 4. 5. 6. 7.
8.
在 Microsoft Office Excel 的“团队”菜单中，单击“新建列表”。 在“连接到 Team Foundation Server”下，选择要连接的服务器，或单击“服务器”来输入服务器 信息。 在“团队项目”下，选择 Team Foundation Server 上要使用的团队项目。 文档将被绑定到此团队项目。 单击“确定”。 选择所需的列表类型。要创建查询列表，请选择“查询列表”选项，然后从“选择查询”下拉 列表中选择一个团队查询。 选择希望在新工作项列表中显示的列。 导入所需工作项。有关详细信息，请参见“如何：在 Microsoft Excel 或 Microsoft Project 中导 入工作项”，地址为：http://msdn2.microsoft.com/en-us/library/ms181676(VS.80).aspx 现在，您便可以编辑工作项，然后通过单击“团队”菜单上的“发布更改”，将更新的工作项 发布到工作项数据库。
其他资源 z
有关使用 Microsoft Office Excel 进行项目管理任务的详细信息，请参见”在 Microsoft Excel 中 使用工作项列表”，地址为：http://msdn2.microsoft.com/en-us/library/ms181694(VS.80).aspx
Team Foundation 项目管理资源 z
有关 MSF 过程模板的详细信息，请参见“过程模板”，地址为： http://msdn2.microsoft.com/en-us/teamsystem/aa718801.aspx
指南：报告 索引 管理 z z
确保用户处于正确的安全组中。 创建报告仪表板，在一个位置查看项目状态和健康指标。
创建 / 自定义 z z z
确保在部署报告时服务器名正确。 创建预定报告快照，可在此后查看。 修改现有报告，以访问其他数据、
查看 z
如果需要最新数据，确保仓库 Web 服务已运行。
管理 z z
确保用户处于正确的安全组中。 创建报告仪表板，在一个位置查看项目状态和健康指标。
确保用户处于正确的安全组中 如果您希望用户能够部署报告，请确保为用户分配该报告服务器的内容管理员角色。内容管理员角 色是预先为在 Web 服务器上部署和管理报告和数据源连接的用户定义的报告服务角色。要使 Microsoft® Visual Studio® 2005 Team Foundation Server (TFS) 用户能够将报告部署到报告服务器， 用户必须是该角色的成员。 要向内容管理员角色中添加用户 1. 2. 3. 4. 5. 6. 7.
打开该项目的报告站点。在“团队资源管理器”中，右击对应于您的团队项目的“报告”条目， 然后选择“显示报告站点”。 在窗口的顶部，单击“属性”选项卡。 在窗口的左侧，单击“安全”。 单击“新建角色分配”。 在“组或用户名：”字段中，输入要添加到内容管理员角色的用户或组的名称 选中“内容管理员”复选框。 单击“确定”。
其他资源
z z z
有关内容管理员角色的详细信息，请参见“内容管理员角色”，地址为： http://technet.microsoft.com/en-us/library/ms159693(SQL.90).aspx 有关数据层中安全角色的详细信息，请参见“保护通过 Analysis Services 访问的安全”，地址 为：http://msdn2.microsoft.com/en-us/library/ms174839.aspx 有关应用程序层中安全角色的详细信息，请参见“保护 Reporting Services”，地址为： http://msdn2.microsoft.com/en-us/library/ms157198.aspx
创建报告仪表板，在一个位置查看项目状态和健康指标 报告仪表板允许您和您的团队在一个页面上快速访问重要的项目信息。用于 Microsoft Solution Framework (MSF) for Agile Software Development (MSF Agile) 项目的默认 Microsoft Office SharePoint® 门户页面包含一个报告以及到其他报告的链接。要为项目信息创建一个储存库，您可以 修改用于 MS Agile 或 MSF for CMMI® (MS CMMI) 项目的门户页面，以在该页面上包含任意多个 报告。 例如，一个有用的报告仪表板可能包含如下报告： z z z z
剩余工作 质量指标 Bug 率 项目速度
可以向 SharePoint 门户页面添加新报告，为希望在该页面上显示的各报告添加一个报告查看器 Web 部件。 要修改团队项目门户并创建一个报告仪表板 1.
使用 SharePoint 和报告服务安装包中附带的 stsadm.exe 工具和 RSWebParts.cab，在您的报告 服务器上安装报告查看器 Web 部件。 z STSADM.EXE 可在如下路径中找到：C:\Program Files\Common Files\Microsoft Shared\web server extensions\60\BIN z RSWebParts.Cab 可在如下路径中找到：C:\ Program Files\Microsoft SQL Server\90\Tools\Reporting Services\SharePoint 示例：STSADM.EXE -o addwppack -filename "C:\ Program Files\Microsoft SQL Server\90\Tools\Reporting Services\SharePoint\RSWebParts.cab" -globalinstall
2. 3. 4. 5. 6. 7. 8. 9. 10.
在“团队浏览器”中，右击您的项目。 单击“显示项目门户”。 单击“修改共享页面”。 指向“浏览”，然后单击“添加 Web 部件”。 单击“虚拟服务器列表”。 在“Web 部件列表”中，选择“报告查看器”。 单击“添加”。 输入报告管理器名称，如 http://<report server>/reports。 输入要显示的报告的路径，如 <my project>/Quality Indicators。
其他资源 z
关于添加报告查看器 Web 部件的详细信息，请参见“使用 SharePoint 2.0 Web 部件查看报表”， 地址为：http://msdn2.microsoft.com/en-us/library/ms159772(SQL.90).aspx
z
关于团队项目门户的详细信息，请参见“使用团队项目门户”，地址为： http://msdn2.microsoft.com/en-us/library/ms242883(VS.80).aspx
创建 / 自定义 z z z
确保在部署报告时服务器名正确。 创建预定报告快照，可在此后查看。 修改现有报告，以访问其他数据、
确保在部署报告时服务器名正确 如果错误地指定了报告服务器的统一资源定位器 (URL) 或目标文件夹名称，则您的报告将无法部署 到报告服务器。当您从 Visual Studio 2005 中部署报告时，请指定应该部署报告的服务器的 URL 以 及该报告所在的团队项目的名称。部署报告的报告服务器的 URL 为 http://TeamServerName/ReportServer，其中 ReportServer 为报告服务器 Web 服务的终点。 在部署属性对话框的 TargetReportFolder 字段中指定团队项目名称。该值区分大小写；如果发生 了大小写错误，则将部署此报告，但此报告不会出现在团队浏览器中您的团队项目的报告列表中。
其他资源 z
有关设置部署属性的详细信息，请参见“如何：设置部署属性（报表设计器）”，地址为： http://technet.microsoft.com/en-us/library/ms155802(SQL.90).aspx
创建预定报告快照，可在此后查看 使用报告历史记录定期构建项目数据的快照。您可以在指定的时间段内查看这些快照，以便更好地 理解趋势，或者记住整个项目持续期间重要的数据点。 要创建一个预定报告快照 1. 2. 3. 4.
从报告门户中打开一个报告。 单击“属性”选项卡。 单击“历史记录”链接。 按照您希望快照运行的时间设置时间表。
设置时间表之后，您便可以在该报告的“历史记录“选项卡上查找快照。还可以在“历史记录”选 项卡上手动创建快照。
修改现有报告，以访问其他数据 可以通过使用随 SQL Server 2005 客户端工具一起提供的 Visual Studio (Business Intelligence Development Studio) 中的 SQL Server 2005 Reporting Services Designer 修改报告。 自定义报告使您能够向现有报告中添加功能，而无需构建新的报告。如果所需的报告与已经存在的 报告类似，则可以自定义现有报告以节省时间。要自定义现有报告，您必须将其从报告服务器中导 出，将其添加到 Visual Studio 中的现有报告项目中，进行更改之后，将其重新部署到报告门户。
注意：尽管可以使用团队报告站点上提供的“报告生成器”，但 Visual Studio 报告方案对此工具的 支持不尽人意，因此不推荐使用。
其他资源 z z z z
有关如何文章的详细信息，请参见本指南中的“如何：在 Visual Studio Team Foundation Server 中 自定义报告”。 有关报告的详细信息，请参见本指南中的“第15章 – 报告介绍”。 有关解释如何使用报告项目的详细教程，请参见“Reporting Services 教程”，地址为： http://msdn2.microsoft.com/en-us/library/ms170246.aspx 要阅读有关编辑报告的 Microsoft MSDN® 文章，请参见“如何：在报表设计器中编辑报告”， 地址为：http://msdn2.microsoft.com/en-us/library/ms244655(VS.80).aspx
查看 z
如果需要最新数据，确保仓库 Web 服务已运行。
如果需要最新数据，确保仓库 Web 服务已运行 如果您想确保您的报告具有最新的数据，请手动运行仓库 Web 服务。默认情况下，仓库 Web 服 务每小时运行一次，为您的报告生成数据。如果您想运行报告并且想确保您的报告包含最新数据， 则可以手动运行该服务。 要手动运行仓库服务 打开 Internet Information Services (IIS) 管理器。 选择“Team Foundation Server 网站”。 在该网站内，打开 Warehouse\v1.0 目录。 将显示一个页面，其中具有仓库上可用操作的列表。 4. 右击 warehousecontroller.asmx，然后单击“浏览”。 5. 单击“运行”，然后单击“调用”。 这将打开另一个浏览器窗口，其中显示了运行请求的状态。它应该显示值 true。 6. 回到第一个浏览器窗口并导航回操作页面。 7. 选择 GetwareHouseStatus，然后单击“调用”。 这将显示仓库 Web 服务的当前状态。值 idle 表示仓库已经运行。其他值显示服务的状态。 1. 2. 3.
其他资源 z
有关仓库疑难解答的详细信息，请参见“数据仓库疑难解答”，地址为： http://msdn2.microsoft.com/en-us/library/ms244674(vs.80).aspx
Team Foundation 报告资源 z
有关报告的详细信息，请参见“Team Foundation Server 报告”，地址为 http://msdn2.microsoft.com/en-us/library/ms194922(VS.80).aspx
指南：源代码管理 索引 使用版本控制 z z z z z z
考虑使用命令行工具。 使用 Microsoft® Visual Studio® 2005 Team Foundation Power Tools (TFPT) 对更改取消搁置。 使用 Team Foundation Power Tools 来回滚变更。 使用 Team Foundation Power Tools 脱机工作。 使用 Team Foundation Power Tools 来获得变更集。 使用 Team Foundation Power Tools 来删除挂起的编辑。
管理 z z
关闭维护分支上的继承权限。 拒绝尚不信任的开发人员的签入权限，使其无法更改您的源代码。
分支 / 标签 / 合并 z z z z z z z z z z z z z z z
使用标签来标记需要返回的生成。 使用分支来分离所支持的发布。 按合并路径计划您的分支结构。 在高级别分支，包括配置和源文件。 分支深度不要过大。 除非必要，否则不要进行分支。 尽可能避免使用 baseless 合并。 首选完全合并，而非“摘樱桃”式合并。 经常合并。 总是为新团队项目创建一个顶级文件夹，作为主分支使用。 考虑在合并前使用候选或预览切换成双重检验。 当重命名是合并的一部分时，请密切注意该工具推荐的路径。 在解决合并冲突时，必须谨慎。 一次签入一个合并的结果。 在合并后、签入前生成并运行测试。
签入策略 z z z z z z z
仅在准备共享代码时签入代码。 使用搁置集备份或共享挂起的更改。 每个签入解决一个工作项。 使用签入策略来实施编码标准。 使用签入策略来实施代码质量把关。 检测一个策略在何时被重写。 制定计划来避免冲突。
签出、获取和锁定 z z z
在进行更改前获得最新源代码。 谨慎使用 lock 命令。 在锁定文件时要与同一团队中的伙伴沟通。
依赖项 z z z z
尽可能使用项目引用。 只在必要的情况下使用文件引用。 对于项目和文件引用，请使用 copy local = true。 在引用 Web 服务时使用动态 URL。
分布式 / 远程开发 z z z z z z
确保为代理获得了大小合理的磁盘驱动器。 创建一个预定任务，定期拉取最新文件。 定期监控代理性能计数器和事件日志。 根据文件大小和带宽配置 executionTimeout。 如果代理长时间停止响应，则禁用代理。 考虑采用工作区掩蔽来减少不必要的文件传输。
迁移 z z
使用 VSS 转换器迁移到 Team Foundation Server 源代码管理。 从其他源代码管理系统迁移到 Team Foundation Server 源代码管理。
项目 / 工作区管理 z z z z z z z z z z z
使用工作区而非分支来分离单独的开发人员。 通过使用源代码管理而不是使用 Microsoft Windows® 资源管理器删除和重命名文件。 仅在解决方案打开时进行删除和重命名。 如果希望在应用程序的版本直接移动资产，则为每个应用程序创建一个团队项目。 如果希望每个应用程序版本都从零开始，则为每个版本创建一个团队项目。 使用分支来共享需要集成测试的代码和二进制文件。 避免工作区映射来支持跨项目依赖项。 在团队项目的根级别创建工作区映射。 使用共享计算机上的惟一本地文件夹路径。 考虑仅映射部分源代码树。 将源代码树的结构设计为支持分支。
搁置 z z z
使用搁置共享挂起的更改，以便进行查看或移交。 使用搁置将挂起的更改备份到服务器。 如果被较高优先级的工作打断，则可使用搁置。
使用版本控制 z z z z z z
考虑使用命令行工具。 使用 Team Foundation Power Tools 使用 Team Foundation Power Tools 使用 Team Foundation Power Tools 使用 Team Foundation Power Tools 使用 Team Foundation Power Tools
对更改取消搁置。 来回滚变更。 脱机工作。 来获得变更集。 来删除挂起的编辑。
考虑使用命令行工具 对于无法从 Visual Studio 中执行的操作，或者您需要计划操作，请考虑使用命令行工具，如与 Team Foundation Server (TFS) 一起提供的 Team Foundation Power Tools (Tfpt.exe)。也可以单独下载来获 得 Tfpt.exe 工具。可以通过使用 Windows Task Scheduler 使用这些命令行工具计划操作。
要确保设置相应的路径和其他环境变量，请从 Visual Studio 2005 命令提示符窗口中运行 Tf.exe， 或者运行 Vsvars32 批处理文件，该文件通常位于 DriveLetter:\Program Files\Microsoft Visual Studio 8\Common7\Tools 中。Tf.exe 工具支持大多数源代码管理命令，包括 Checkin、Checkout、Get、 History、Shelve、Branch、Merge、Label、Status、Undelete 和 Undo。 下面是您可能想使用 Tf.exe 通过命令行中执行的常见操作： z z z z z
将文件从服务器同步到本地计算机上 – tf get 向服务器添加一个文件 – tf add 签出一个文件以便更改 – tf checkout 签入挂起的更改 – tf checkin 从服务器检索特定变更集 – tf get /version
某些操作您只能通过命令行执行： z z z z z
删除另一个用户的工作区 – tf workspace /delete 撤销另一个用户的签入 – tf undo 取消另一个用户的锁定 – tf lock 定义标签范围 – tf label 执行 baseless 合并 – tf merge
其他资源 z z
有关详细信息，请参见“演练：通过命令行使用 Team Foundation 源代码管理” （位于 Microsoft MSDN® 网站上），地址为：http://msdn2.microsoft.com/en-us/library/zthc5x3f.aspx 有关只能通过命令行执行的命令的详细信息，请参见“只能通过命令行执行的操作（Team Foundation 源代码管理）”，地址为： http://msdn2.microsoft.com/en-us/library/ms194957(VS.80).aspx
使用 Team Foundation Power Tools 对更改取消搁置 Team Foundation Power Tools (TFPT) 提供无法从 Visual Studio 中获得的版本控制功能。例如，您可 以使用 TFPT 帮助支持脱机工作或执行回滚操作以便撤销变更集的签入。如果您需要对更改取消搁 置，请考虑使用 TFPT。 TFS 支持的取消搁置操作不允许将搁置的更改和本地更改合并到一起。通过使用 TFPT 取消搁置变 更集中的更改，如果本地工作区中的项目具有的挂起的更改是编辑，搁置的更改也是编辑，则 TFPT 可以用三方合并合并这些更改。 在命令行中键入 Tfpt.exe 即可运行此命令。
其他资源 z z
要下载 Team Foundation Power Tools，请访问： http://www.microsoft.com/downloads/details.aspx?familyid=7324C3DB-658D-441B-8522-689C557 D0A79&displaylang=en 要浏览关于 Team Foundation Power Tools 的论坛讨论，请参见： http://forums.microsoft.com/MSDN/ShowForum.aspx?ForumID=930&SiteID=1
使用 Team Foundation Power Tools 来回滚变更 如果您需要回滚更改，请考虑使用 TFPT。TFS 不直接支持撤销变更集的签入功能。通过使用 TFPT rollback 命令，您可以尝试撤销在指定变更集中所做的任何更改并不是所有的更改都可以回滚，但 回滚适合于大多数方案。
在命令行中键入 Tfpt.exe 即可运行此命令。
其他资源 z z
要下载 Team Foundation Power Tools，请访问： http://www.microsoft.com/downloads/details.aspx?familyid=7324C3DB-658D-441B-8522-689C557 D0A79&displaylang=en 要浏览关于 Team Foundation Power Tools 的论坛讨论，请参见：
使用 Team Foundation Power Tools 脱机工作 TFS 天生不支持脱机工作。如果您想脱机工作，必须遵守以下严格的工作流程： 1. 2. 3. 4.
手动删除只读标记。 编辑文件。 添加或删除文件 运行 TFPT 联机命令。
下面详细介绍每个步骤。 重点：脱机时不可重命名任何文件。 1.
手动删除只读标记。 默认地，工作区中所有尚未签出的文件都会标记为只读，当在没有连接服务器的情况下工作时， 必须先手动删除文件中的只读标记，然后才能编辑或删除文件。要执行该操作，请右击 Windows 资源管理器中的文件，单击“属性”，清除“只读”复选框，然后单击“确定”。也可以使用 DOS 命令 attrib –r。
2. 编辑文件。 现在即可编辑那些已删除了只读标记的文件。 3. 添加或删除文件。 现在即可添加或删除那些已删除了只读标记的文件。不要重命名文件，因为 TFPT online 工具无法区分重命名操作和与添加操作成对的删除操作。 注意：您必须指定 Tfpt online 命令的选项来查看删除，因为这是非常耗时的操作。
4. 运行 TFPT 联机命令。 重新联机时，可以在命令行中键入 TFPT online，运行 TFPT 联机命令。此命令扫 描工作区中的可写文件，并确定哪些更改应在服务器上挂起。如果您删除了任何文 件，请使用 /delete 切换。这将告诉该工具在本地工作区中扫描删除的文件。该工 具随后即显示一个联机窗口，您可从中选择在工作区内挂起哪些更改。
其他资源 z z
要下载 Team Foundation Power Tools，请访问： http://www.microsoft.com/downloads/details.aspx?familyid=7324C3DB-658D-441B-8522-689C557 D0A79&displaylang=en 要浏览关于 Team Foundation Power Tools 的论坛讨论，请参见： http://forums.microsoft.com/MSDN/ShowForum.aspx?ForumID=930&SiteID=1
使用 Team Foundation Power Tools 来获得变更集 如果您需要获得变更集，请考虑使用 TFPT。TFPT GetCS 命令使您能够在该变更集版本时获得变
更集中列出的所有项目。如果一位同事已经签入您在工作区中所需的更改，但您没有将整个工作区 更新到最新版本，则该命令非常有用。 在命令行中键入 Tfpt.exe 即可运行此命令。
其他资源 z z
要下载 Team Foundation Power Tools，请访问： http://www.microsoft.com/downloads/details.aspx?familyid=7324C3DB-658D-441B-8522-689C557 D0A79&displaylang=en 要浏览关于 Team Foundation Power Tools 的论坛讨论，请参见： http://forums.microsoft.com/MSDN/ShowForum.aspx?ForumID=930&SiteID=1
使用 Team Foundation Power Tools 来删除挂起的编辑 如果您需要从文件中删除挂起的编辑，请考虑使用 TFPT。TFPT Undo Unchanged 命令从尚未实际 编辑的文件中删除挂起的编辑。如果您签出了大量文件进行编辑，但实际上只对少量文件进行了更 改，则该命令非常有用。您可以通过运行 TFPT UU 工具撤销对未更改的文件的编辑，该工具将本 地工作区中的文件的无用信息与服务器上的无用信息相比较，以便确定该文件实际是否已经进行了 编辑。 在命令行中键入 Tfpt.exe 即可运行此命令。
其他资源 z z
要下载 Team Foundation Power Tools，请访问： http://www.microsoft.com/downloads/details.aspx?familyid=7324C3DB-658D-441B-8522-689C557 D0A79&displaylang=en 要浏览关于 Team Foundation Power Tools 的论坛讨论，请参见： http://forums.microsoft.com/MSDN/ShowForum.aspx?ForumID=930&SiteID=1
管理 z z
关闭维护分支上的继承权限。 拒绝尚不信任的开发人员的签入权限，使其无法更改您的源代码。
关闭维护分支上的继承权限 分支位于维护中之后，例如，发布了一个版本的软件之后，您便可以管理继承的权限以锁定树。执 行该操作之后，您便可以根据需要授予各个用户 PendChange 和 Checkin 权限，以便进行热修复。
其他资源 z
有关删除权限的详细信息，请参见“如何：移除对源代码管理文件的访问权限”，地址为： http://msdn2.microsoft.com/en-us/library/ms400718(VS.80).aspx
拒绝尚不信任的开发人员的签入权限，使其无法更改您的源代码 您可以拒绝不信任的开发人员（如新来的雇员或实习人员）对源代码树的签入权限。在关闭继承之 前，应确保设置了全部需要的权限（包括您自己的账户的权限）。代替直接签入，他们可以进行挂 起的更改，然后搁置这些更改。然后非常有经验的开发人员可以取消搁置更改、查看更改，然后将 更改签入。
其他资源 z
有关删除权限的详细信息，请参见“如何：移除对源代码管理文件的访问权限”，地址为： http://msdn2.microsoft.com/en-us/library/ms400718(VS.80).aspx
分支 / 标签 / 合并 z z z z z z z z z z z z z z z
使用标签来标记需要返回的生成。 使用分支来分离所支持的发布。 按合并路径计划您的分支结构。 在高级别分支，包括配置和源文件。 分支深度不要过大。 除非必要，否则不要进行分支。 尽可能避免使用 baseless 合并。 首选完全合并，而非“摘樱桃”式合并。 经常合并。 总是为新团队项目创建一个顶级文件夹，作为主分支使用。 考虑在合并前使用候选或预览切换成双重检验。 当重命名是合并的一部分时，请密切注意该工具推荐的路径。 在解决合并冲突时，必须谨慎。 一次签入一个合并的结果。 在合并后、签入前生成并运行测试。
使用标签来标记需要返回的生成 使用标签标记每日生成，以便您可以轻松查看和检索特殊生成所使用的文件集。Team Build 自动向 与其创建的每个生成关联的文件集指定标签。Team Build 标签遵循格式“ReleaseType_Build#”，例 如，“Releasex86_20070226.1”。 尽管对每个团队生成进行了加上了标签，但您可能想为要返回的生成创建自己的标签，如： z z
内部里程碑，例如，alpha release 在分支或外部依赖项集成之后创建的生成
您应该使用标签命名约定，这使得在以后更容易查找该生成以及了解它表示的内容。使用能明确知 道它们所表示内容的标签。例如，使用约定，如“AlphaBuild_20070112”表示由“LabelName_Date” 组成。 当您向需要提供维护的客户发布生成时，请使用分支而不使用标签分离在该版本上的将来的维护工 作。随后，您可以合并分支与其包含的任何修复，返回到您主源代码树。 要定位现有标签，请在“文件”菜单上，指向“源代码管理”，然后单击“查找标签”。找到标签 之后，您可以从“查找标签”对话框中修改或删除该标签。
其他资源 z z
有关详细信息，请参见“使用标签”，地址为 http://msdn2.microsoft.com/en-us/library/ms181439(VS.80).aspx 有关标签的详细信息，请参见“如何：应用标签”，地址为： http://msdn2.microsoft.com/en-us/library/ms181440(VS.80).aspx
使用分支来分离所支持的发布 创建一个包含用来生成支持的发布生成的源代码的分支。这允许您将修复和更新应用于支持的软件 发布版本，而不会影响您的源代码库的后续开发，该开发继续沿着主要分支进行。 您继续沿着与支持的发布分支并行的主要分支开发下一版本的应用程序。在发布下一版本的产品之 前，可以将对支持的发布分支所进行的任何稳定性更改合并到主要分支中。
下面是一个分支结构的示例，在创建了维护分支后，您的分支结构看起来可能就是这样： z
z
Main – 集成分支 源代码 其他资产文件夹 Releases – 维护分支的容器 Release 1 – 维护分支 源代码
其他资源 z z z z
有关分支与合并的简介，请参见“分支与合并入门”，地址为： http://msdn2.microsoft.com/en-us/library/aa730834(VS.80).aspx 有关分支的详细信息，请参见“如何：分支文件和文件夹”，地址为： http://msdn2.microsoft.com/en-us/library/ms181425(VS.80).aspx 有关合并的详细信息，请参见“如何：合并文件和文件夹”，地址为： http://msdn2.microsoft.com/en-us/library/ms181428(VS.80).aspx 有关如何在 Visual Studio 2005 中进行分支与合并的详细信息，请参见“对 Team Foundation 源 代码管理进行分支和合并”，地址为： http://msdn2.microsoft.com/en-us/library/ms181423(VS.80).aspx
按合并路径计划您的分支结构 通过使用源代码管理资源管理器，您只能沿着现有分支路径进行合并。可以沿着命令行中的其他路 径进行 baseless 合并，但是这种类型的合并是不明智的，它会导致多个合并冲突以及将来合并中的 其他冲突。 执行合并时始终牢记以下事项： z z
沿层次结构合并，从父到子或从子到父，得到比在层次结构中交叉合并更少的冲突。 分支层次结构基于分支父级和分支子级，可能与磁盘中源代码的物理结构有所不同。例如： z 物理结构： Development – 开发分支 Main – 集成分支 Releases – 发布分支的容器 z Release 1 – 发布分支 z 逻辑结构： Main z 开发 z Release 1
其他资源 z z z z
有关分支与合并的简介，请参见“分支与合并入门”，地址为： http://msdn2.microsoft.com/en-us/library/aa730834(VS.80).aspx 有关分支的详细信息，请参见“如何：分支文件和文件夹”，地址为： http://msdn2.microsoft.com/en-us/library/ms181425(VS.80).aspx 有关合并的详细信息，请参见“如何：合并文件和文件夹”，地址为： http://msdn2.microsoft.com/en-us/library/ms181428(VS.80).aspx 有关如何在 Visual Studio 2005 中进行分支与合并的详细信息，请参见“对 Team Foundation 源
代码管理进行分支和合并”，地址为： http://msdn2.microsoft.com/en-us/library/ms181423(VS.80).aspx
在高级别分支，包括配置和源文件 进行分支的级别必须足够高，在此级别上创建的分支仍然可编译。例如，在以下源代码树中： z z
z z z
Main – 为发布产品所需的一切资产的容器 Source - 生成所需的全部内容的容器 Code – 源代码容器 Shared Code – 从其他项目共享的源代码容器 Unit Tests – 单元测试容器 Lib – 二进制依赖项的容器 Docs – 将随产品一起提供的文档的容器 Installer – 安装程序源代码和二进制文件的容器 Tests – 测试团队测试用例的容器
在源文件夹级别分支以确保新分支包含所有源和配置文件。
其他资源 z z z z
有关分支与合并的简介，请参见“分支与合并入门”，地址为： http://msdn2.microsoft.com/en-us/library/aa730834(VS.80).aspx 有关分支的详细信息，请参见“如何：分支文件和文件夹”，地址为： http://msdn2.microsoft.com/en-us/library/ms181425(VS.80).aspx 有关合并的详细信息，请参见“如何：合并文件和文件夹”，地址为： http://msdn2.microsoft.com/en-us/library/ms181428(VS.80).aspx 有关如何在 Visual Studio 2005 中进行分支与合并的详细信息，请参见“对 Team Foundation 源 代码管理进行分支和合并”，地址为： http://msdn2.microsoft.com/en-us/library/ms181423(VS.80).aspx
分支深度不要过大 分支深度不要过大，因为这将会增加将子分支中的更改合并到最上面父分支所需的时间。例如，在 以下分支结构中： z Development – 开发分支的容器 开发分支 子分支 z 次级子分支 z Main – 集成分支 源代码 其他资产文件夹 当沿着分支层次结构执行时，合并会导致冲突减少。因此，如果您想将次级子分支中的更改合并到 主要分支中，则首先需要与子分支和开发分支合并，然后才能合并到主要分支中。每次合并都需要 时间来完成、解决冲突、构建和测试，它等于合并时间乘以在分支结构中创建的分支级别。
其他资源 z z z
有关分支与合并的简介，请参见“分支与合并入门”，地址为： http://msdn2.microsoft.com/en-us/library/aa730834(VS.80).aspx 有关分支的详细信息，请参见“如何：分支文件和文件夹”，地址为： http://msdn2.microsoft.com/en-us/library/ms181425(VS.80).aspx 有关合并的详细信息，请参见“如何：合并文件和文件夹”，地址为：
z
http://msdn2.microsoft.com/en-us/library/ms181428(VS.80).aspx 有关如何在 Visual Studio 2005 中进行分支与合并的详细信息，请参见“对 Team Foundation 源 代码管理进行分支和合并”，地址为： http://msdn2.microsoft.com/en-us/library/ms181423(VS.80).aspx
不必要时不要进行分支 除非开发团队需要同时在同一组文件上工作，否则不要进行分支。如果不确定，则可以标记一个生 成，然后从该生成中创建一个分支。合并分支可能非常昂贵，尤其当它们之间存在大量更改时更是 如此。 合并要求一名或多名开发人员执行合并并解决冲突。应全面测试合并后的源代码，可能毁掉生成的 糟糕合并决策并不罕见。 跨分支层次结构进行合并尤为困难，需要您手动处理许多在其他合并方式中会自动处理的冲突。
其他资源 z z z z
有关分支与合并的简介，请参见“分支与合并入门”，地址为： http://msdn2.microsoft.com/en-us/library/aa730834(VS.80).aspx 有关分支的详细信息，请参见“如何：分支文件和文件夹”，地址为： http://msdn2.microsoft.com/en-us/library/ms181425(VS.80).aspx 有关合并的详细信息，请参见“如何：合并文件和文件夹”，地址为： http://msdn2.microsoft.com/en-us/library/ms181428(VS.80).aspx 有关如何在 Visual Studio 2005 中进行分支与合并的详细信息，请参见“对 Team Foundation 源 代码管理进行分支和合并”，地址为： http://msdn2.microsoft.com/en-us/library/ms181423(VS.80).aspx
尽可能避免使用 baseless 合并 尽可能避免使用 baseless 合并。当执行 baseless 合并时，TFS 没有描述正在合并的分支中的文件 和文件夹的关系的信息。这通常导致更多合并冲突，并且可能导致将来合并中发生更多冲突。 设计分支树结构时应考虑合并，应使您只需沿层次结构合并（在分支树中上下移动），而不需要横 跨层次结构。跨层次结构进行分支会强迫您使用 baseless 合并。 执行合并时始终牢记以下事项： z z
沿层次结构合并，从父到子或从子到父，得到比在层次结构中交叉合并更少的冲突。 分支层次结构基于分支父级和分支子级，可能与磁盘中源代码的物理结构有所不同。例如： z 物理结构： Development – 开发分支 Main – 集成分支 Releases – 发布分支的容器 z Release 1 – 发布分支 z 逻辑结构： Main z 开发 z Release 1
其他资源 z
有关分支与合并的简介，请参见“分支与合并入门”，地址为： http://msdn2.microsoft.com/en-us/library/aa730834(VS.80).aspx
z z z
有关分支的详细信息，请参见“如何：分支文件和文件夹”，地址为： http://msdn2.microsoft.com/en-us/library/ms181425(VS.80).aspx 有关合并的详细信息，请参见“如何：合并文件和文件夹”，地址为： http://msdn2.microsoft.com/en-us/library/ms181428(VS.80).aspx 有关如何在 Visual Studio 2005 中进行分支与合并的详细信息，请参见“对 Team Foundation 源 代码管理进行分支和合并”，地址为： http://msdn2.microsoft.com/en-us/library/ms181423(VS.80).aspx
首选完全合并，而非“摘樱桃”式合并 不要选择各个更改在分支之间进行合并（“摘樱桃”式合并），而是选择一次选择整个分支。在分 支中选择要与其他分支合并的各个更改非常方便。但是，如果“摘樱桃”式变更集落在将来合并范 围的中间，该变更集将重新被合并，从而可能导致其他合并冲突。 这尤其适用于通过命令行运行的 /discard 合并。如果丢弃的变更集落在将来合并范围的中间，则可 以拾取此丢弃的变更集。
其他资源 z z z z
有关分支与合并的简介，请参见“分支与合并入门”，地址为： http://msdn2.microsoft.com/en-us/library/aa730834(VS.80).aspx 有关分支的详细信息，请参见“如何：分支文件和文件夹”，地址为： http://msdn2.microsoft.com/en-us/library/ms181425(VS.80).aspx 有关合并的详细信息，请参见“如何：合并文件和文件夹”，地址为： http://msdn2.microsoft.com/en-us/library/ms181428(VS.80).aspx 有关如何在 Visual Studio 2005 中进行分支与合并的详细信息，请参见“对 Team Foundation 源 代码管理进行分支和合并”，地址为： http://msdn2.microsoft.com/en-us/library/ms181423(VS.80).aspx
经常合并 消除分支之间的延迟，尤其在团队在同一b版本上工作，但位于其自己的分离的分支中时更是如此。 这确保了更改之间的一致性。 合并计划取决于分支结构的复杂性以及开发团队的各个需求。例如，在中等复杂的分支结构（如下 所示）中，开发分支可能每天要合并到主要分支，并且每两天都将合并返回集成分支中的更改。 z
z z z
Development – 分离开发分支的文件夹 External – 外部依赖项分支 Team 1 – 团队分支 Team 2 – 团队分支 z Feature A – 功能分支 z Feature B – 功能分支 z Feature C – 功能分支 Main – 集成分支 Releases – 发布分支的文件夹 Release 2 – 发布分支 Safe Keeping – 保护分支的文件夹 Release 1 – 保护分支
其他资源 z z
有关分支与合并的简介，请参见“分支与合并入门”，地址为： http://msdn2.microsoft.com/en-us/library/aa730834(VS.80).aspx 有关分支的详细信息，请参见“如何：分支文件和文件夹”，地址为：
z z
http://msdn2.microsoft.com/en-us/library/ms181425(VS.80).aspx 有关合并的详细信息，请参见“如何：合并文件和文件夹”，地址为： http://msdn2.microsoft.com/en-us/library/ms181428(VS.80).aspx 有关如何在 Visual Studio 2005 中进行分支与合并的详细信息，请参见“对 Team Foundation 源 代码管理进行分支和合并”，地址为： http://msdn2.microsoft.com/en-us/library/ms181423(VS.80).aspx
总是为新团队项目创建一个顶级文件夹，作为主分支使用 通过在您的团队项目下创建文件夹（通常名为 Main）启动任何新的团队项目。将主要分支的所有 源放置在此文件夹中。当需要创建新的分支时，可以直接从 Main 文件夹进行分支。 以下示例显示了典型的分支结构： z
z
z
Development – 分离开发分支的文件夹，从 Main 进行分支 Feature A Source Feature B Source Main – 集成分支 源代码 其他资产文件夹 Releases – 发布分支的文件夹，从 Main 进行分支 Release 1 – 维护分支 Source
其他资源 z z z z
有关分支与合并的简介，请参见“分支与合并入门”，地址为： http://msdn2.microsoft.com/en-us/library/aa730834(VS.80).aspx 有关分支的详细信息，请参见“如何：分支文件和文件夹”，地址为： http://msdn2.microsoft.com/en-us/library/ms181425(VS.80).aspx 有关合并的详细信息，请参见“如何：合并文件和文件夹”，地址为： http://msdn2.microsoft.com/en-us/library/ms181428(VS.80).aspx 有关如何在 Visual Studio 2005 中进行分支与合并的详细信息，请参见“对 Team Foundation 源 代码管理进行分支和合并”，地址为： http://msdn2.microsoft.com/en-us/library/ms181423(VS.80).aspx
考虑在合并前使用候选或预览切换成双重检验 在执行合并之前，使用候选或预览切换以对合并结果进行双重检验。尽管只能通过命令行使用该选 项，但是执行合并命令时知道合并的文件以及版本会非常有帮助。例如，这有助于确保合并的范围 大于期望的范围，并且确保您了解合并命令的影响。对于较大的合并，合并报告还可以帮助您区分 个人或团队的工作。 要预览合并结构，请使用具有 merge 命令的 Tf.exe 命令行工具以及预览或候选切换。例如： Tf merge main/source development/feature/source /preview 预览切换显示合并的预览，候选切换打印源中尚未合并到目录中的所有变更集的列表。该列表包括 尚未合并的变更集 ID 以及有关该变更集的其他基本信息。
其他资源
z z z z
有关分支与合并的简介，请参见“分支与合并入门”，地址为： http://msdn2.microsoft.com/en-us/library/aa730834(VS.80).aspx 有关分支的详细信息，请参见“如何：分支文件和文件夹”，地址为： http://msdn2.microsoft.com/en-us/library/ms181425(VS.80).aspx 有关合并的详细信息，请参见“如何：合并文件和文件夹”，地址为： http://msdn2.microsoft.com/en-us/library/ms181428(VS.80).aspx 有关如何在 Visual Studio 2005 中进行分支与合并的详细信息，请参见“对 Team Foundation 源 代码管理进行分支和合并”，地址为： http://msdn2.microsoft.com/en-us/library/ms181423(VS.80).aspx
当重命名是合并的一部分时，请密切注意该工具推荐的路径。 当重命名是合并的一部分时，请密切注意该工具推荐的路径并进行适当更改。所有重命名都标记为 冲突。当合并重命名时，TFS 使用的合并算法尝试计算最佳目标路径。在某些情况下，默认的目标 路径不是所需的路径，因此您应该始终在提交合并的文件之前进行双重检验。
其他资源 z z z z
有关分支与合并的简介，请参见“分支与合并入门”，地址为： http://msdn2.microsoft.com/en-us/library/aa730834(VS.80).aspx 有关分支的详细信息，请参见“如何：分支文件和文件夹”，地址为： http://msdn2.microsoft.com/en-us/library/ms181425(VS.80).aspx 有关合并的详细信息，请参见“如何：合并文件和文件夹”，地址为： http://msdn2.microsoft.com/en-us/library/ms181428(VS.80).aspx 有关如何在 Visual Studio 2005 中进行分支与合并的详细信息，请参见“对 Team Foundation 源 代码管理进行分支和合并”，地址为： http://msdn2.microsoft.com/en-us/library/ms181423(VS.80).aspx
在解决合并冲突时，必须谨慎 当合并时必须谨慎，因为很容易犯错误，从而导致生成不稳定。合并文件时： z z z z
在提交合并之前，对合并的代码进行双重检验。 测试在回到源代码管理中进行检验之前，您是否可以编译所得到的合并文件。 在回到源代码管理中检验合并的文件之前，验证关联的单元测试是否运行以及是否成功。 确保您了解其他开发人员所做更改的本质。如果您怀疑合并的某些行，请告诉进行其他更改的 开发人员，以便您确保它们的作用并再次查看合并的影响。
完成合并后，编译所得到的源代码，并运行单元测试来测试主要中断。
其他资源 z
有关解决合并冲突的详细信息，请参见“解决冲突”，地址为： http://msdn2.microsoft.com/en-us/library/ms181432(VS.80).aspx
一次签入一个合并的结果 在执行涉及相同文件的第二个合并之前，签入一个合并的结果。执行第一个合并之后，编译代码并 确保单元测试成功，然后签入挂起的更改。然后开始第二个合并并重复此过程。 这有助于降低复杂程度，并且通过保持合并分离还能使您撤销更改（如果需要）。
其他资源 z
有关分支与合并的简介，请参见“分支与合并入门”，地址为：
z z z
http://msdn2.microsoft.com/en-us/library/aa730834(VS.80).aspx 有关分支的详细信息，请参见“如何：分支文件和文件夹”，地址为： http://msdn2.microsoft.com/en-us/library/ms181425(VS.80).aspx 有关合并的详细信息，请参见“如何：合并文件和文件夹”，地址为： http://msdn2.microsoft.com/en-us/library/ms181428(VS.80).aspx 有关如何在 Visual Studio 2005 中进行分支与合并的详细信息，请参见“对 Team Foundation 源 代码管理进行分支和合并”，地址为： http://msdn2.microsoft.com/en-us/library/ms181423(VS.80).aspx
在合并后、签入前生成并运行测试 执行合并之后，确保在签入合并的文件之前，编译该代码并运行关联的测试。执行此操作可以避免 由于合并导致生成不稳定。 在您的工作区中合并的结果最初是分离的，并且在签入挂起的更改之前，无法上载到服务器。
其他资源 z z z z
有关分支与合并的简介，请参见“分支与合并入门”，地址为： http://msdn2.microsoft.com/en-us/library/aa730834(VS.80).aspx 有关分支的详细信息，请参见“如何：分支文件和文件夹”，地址为： http://msdn2.microsoft.com/en-us/library/ms181425(VS.80).aspx 有关合并的详细信息，请参见“如何：合并文件和文件夹”，地址为： http://msdn2.microsoft.com/en-us/library/ms181428(VS.80).aspx 有关如何在 Visual Studio 2005 中进行分支与合并的详细信息，请参见“对 Team Foundation 源 代码管理进行分支和合并”，地址为： http://msdn2.microsoft.com/en-us/library/ms181423(VS.80).aspx
签入策略 z z z z z z z
仅在准备共享代码时签入代码。 使用搁置集备份或共享挂起的更改。 每个签入解决一个工作项。 使用签入策略来实施编码标准。 使用签入策略来实施代码质量把关。 检测一个策略在何时被重写。 制定计划来避免冲突。
仅在准备共享代码时签入代码 仅在完全经过单元测试并且准备与团队的其他人共享时，才能将更新的代码签入源代码管理中。对 尚未完成的中间工作使用搁置集。 当您签入代码时，该代码将用作下一个预定生成的一部分。任何不完善的代码都可能导致生成不稳 定。此外当签入代码时，执行 get latest 操作的任何其他开发人员都将拾取您的更改。如果它们不 完善或测试不适当，则它们将引起您的同事的问题。
其他资源 z
有关签入的详细信息，请参见“如何：签入挂起的更改”，地址为： http://msdn2.microsoft.com/en-us/library/ms181411(VS.80).aspx
使用搁置集备份或共享挂起的更改
使用搁置集备份包含您尚未准备签入的挂起的更改的文件。还可以使用搁置集共享代码以便查看代 码，或者可以终止其他开发人员的开发任务。通过使用搁置集，您可以将挂起的更改上载到服务器， 而无需签入部分完成的工作，从而导致生成不稳定。 要搁置挂起的变更集，请通过右击“解决方案资源管理器”中的解决方案，然后单击“查看挂起的 更改”首先查看更改。选择您希望搁置的文件，然后单击“搁置”。键入搁置集名，以及表示搁置 集用途的注释，然后单击“搁置”。 检索搁置集 1. 在“文件”菜单上，指向“源代码管理”，然后单击“取消搁置”。 2. 在“所有者姓名”文本框中，键入搁置集创建者的姓名（例如，Contoso\JimB 或只是 JimB）， 然后单击“查找”。 3. 在“结果”窗格中，选择您要取消搁置到工作区中的搁置集，然后单击“详细信息”。 4. 当您从 TFS 源代码管理服务器中检索时，如果您想删除搁置集，请清除“将搁置集保存在服 务器上”选项。只要版本与工作区中已挂起的更改不冲突，Team Foundation Server 就会将每个 搁置的版本还原到目标工作区中，作为挂起的更改。 5. 如果您不想让工作项和签入说明与还原的搁置集关联，也可以清除“还原工作项和签入说明” 选项。当出现“详细信息”对话框时，选择要取消搁置到工作区中的搁置集或搁置集项，然后 单击“取消搁置”。
其他资源 z
有关详细信息，请参见“如何：搁置和取消搁置挂起的更改”，地址为： http://msdn2.microsoft.com/en-us/library/ms181404(VS.80).aspx
每个签入解决一个工作项 解决一个工作项之后，签入挂起的更改并更新工作项状态。该操作实际发挥以下作用： z z
它提供源代码管理数据库中一致的记录，可以用来对每个工作项进行查看更改，或将来停止工 作项（如果需要）。 确保在签入之间不会等待太久。签入之间等待的时间越长，越有可能发生冲突，这需要进行手 动合并和其他测试。
其他资源 z z z
有关签入的详细信息，请参见“如何：签入挂起的更改”，地址为： http://msdn2.microsoft.com/en-us/library/ms181411(VS.80).aspx 有关工作项和变更集的详细信息，请参见“如何：将工作项与变更集相关联”，地址为： http://msdn2.microsoft.com/en-us/library/ms181410(VS.80).aspx 有关查看工作项详细信息的详细信息，请参见“如何：在‘挂起的更改’窗口中查看工作项详 细信息”，地址为：http://msdn2.microsoft.com/en-us/library/ms245467(VS.80).aspx
使用签入策略来实施编码标准 使用签入策略在开发团队中实施编码标准。签入策略有助于确保所有签入 TFS 源代码管理的源代 码符合定义的编码标准。 TFS 附带的代码分析签入策略使您能够确保在签入之前已经在代码上运行静态代码分析。您可以微 调代码分析策略以检查很多不同的规则。例如，可以检查监管设计、互操作性、可维护性、移动性、 命名约定、可靠性等方面的规则。 要为一个团队项目实施代码分析签入策略
1. 2. 3. 4. 5.
在“团队资源管理器”中，右击您的团队项目，指向“团队项目设置”，然后单击“源代码管 理”。 单击“签入策略”选项卡，然后单击“添加”。 在“添加签入策略”对话框中，选择“代码分析”，然后单击“确定”。 在“代码分析策略编辑器”中，选择“执行 C/C++ 代码分析 (/analyze)”或“对托管代码执行 代码分析”。如果您的项目包含托管代码和非托管代码的组合，则选择两者。 如果选择“对托管代码执行代码分析”，则根据所需的编码标准为托管代码分析配置所需的规 则设置。这恰好确定了要执行哪些规则。
还可创建自定义签入策略，执行默认不可用的签入。例如，可以拒绝某些代码模式，例如被禁止的 应用程序编程接口 (API) 调用，也可以编写策略，来执行团队的具体编码样式指导原则，例如应在 源代码的什么位置放置花括号。
其他资源 z z z z z
有关创建和使用自定义签入策略的详细信息，请参见本指南中的“如何：为 TFS 创建自定义 签入策略详解”。 要了解如何自定义签入策略，请参见“演练：自定义签入策略和签入说明”，地址为： http://msdn2.microsoft.com/en-us/library/ms181281(VS.80).aspx 要查看拒绝签入的选定模式的示例代码，请参见“拒绝某些模式的签入策略”，地址为： http://blogs.msdn.com/jmanning/archive/2006/02/02/523125.aspx 要查看对签入实施注释的示例代码，请参见“示例签入策略：确保注释非空”，地址为： http://blogs.msdn.com/jmanning/archive/2006/01/21/515858.aspx 要了解如何注册新签入策略，请参见“我创建了一条新的签入策略！如何添加？”，地址为： http://blogs.msdn.com/jmanning/archive/2006/02/07/526778.aspx
使用签入策略来实施代码质量把关 将代码分析与测试策略相结合，来实施代码质量把关。例如，使用所提供的测试策略来确保指定测 试预先得到测试并已通过，之后再允许源代码签入 TFS 源代码管理。还可以配置代码分析策略， 以帮助确保代码符合某些质量标准，从而确保安全性、性能、可移植性、可维护性和可靠性规则通 过。 除了强制编码标准和原则的策略之外，强制这种类型的签入策略可以确保代码符合特定的质量标准。 为一个团队项目实施代码分析签入策略 1. 在“团队资源管理器”中，右击您的团队项目，指向“团队项目设置”，然后单击“源代码管 理”。 2. 单击“签入策略”选项卡，单击“添加”，然后选择并配置恰当的策略。
其他资源 z z z z z
有关创建和使用自定义签入策略的详细信息，请参见本指南中的“如何：为 TFS 创建自定义 签入策略详解”。 要了解如何自定义签入策略，请参见“演练：自定义签入策略和签入说明”，地址为： http://msdn2.microsoft.com/en-us/library/ms181281(VS.80).aspx 要查看拒绝签入的选定模式的示例代码，请参见“拒绝某些模式的签入策略”，地址为： http://blogs.msdn.com/jmanning/archive/2006/02/02/523125.aspx 要查看对签入实施注释的示例代码，请参见“示例签入策略：确保注释非空”，地址为： http://blogs.msdn.com/jmanning/archive/2006/01/21/515858.aspx 要了解如何注册新签入策略，请参见“我创建了一条新的签入策略！如何添加？”，地址为： http://blogs.msdn.com/jmanning/archive/2006/02/07/526778.aspx
检测一个策略在何时被重写 Team Foundation 版本控制不防碍您重写策略。但是，您可以使用以下步骤检测策略是否已被重写： z z
使用 Team Foundation Eventing Service（来自 Team Foundation Core Services API）来连接签入 事件。 编写一个分析变更集详细信息的 Notify 方法，如果已发生重写，则该方法起反作用。
另外，可以手动扫描变更集历史记录来发现策略重写。
其他资源 z z z
要进一步了解重写签入策略，请参见“如何：重写签入策略”，地址为： http://msdn2.microsoft.com/en-us/library/ms245460(VS.80).aspx 要了解有关 Team Foundation Eventing Service 的详细信息，请参见“Eventing Service”，地址 为：http://msdn2.microsoft.com/en-us/library/bb130154(vs.80).aspx 要了解违反策略时如何接收电子邮件消息的信息，请参见： http://blogs.infosupport.com/marcelv/archive/2005/10/18/1635.aspx
制定计划来避免冲突 指定计划来避免让多个开发人员同时在同一源代码文件的同一区域工作。执行此操作可以避免冲突， 这些冲突可能很难正确解决。尽管自动冲突解决方案可以解决很多冲突，但是您应该避免让两个或 多个开发人员使用相同的方法或者在相同的代码行上工作。相同代码行上的冲突需要手动冲突解决 方案，这会使合并操作更复杂。有效的团队沟通是关键。 开始在一个文件上工作之前，确保从源代码管理中获得最新版本，并查看是否其他人已将该文件签 出，然后再开始工作。如果有一个同事已经签出了该文件，请询问您的同事他或她工作的内容，然 后决定您是否可以等待他们完成更改，或者在同一个文件上继续并行工作是否安全，因为您使用该 文件内单独的源代码区域中单独的功能。 查看其他人是否已签出文件 1.
在 Visual Studio 的“团队资源管理器”中，双击“源代码管理”。
2. 浏览到包含要签入源代码管理文件夹层次结构的文件的文件夹。 将列出所有挂起的更改以及拥有这些更改的用户的用户名。 要检查人们当前已挂起了哪些文件，请从 Visual Studio 2005 命令提示符窗口中运行以下命令。 Tf status /format:detailed /user:* 当您开始在源文件上工作，并且知道其他人也在该文件上并行工作时，请让其他团队成员知道您正 在该文件工作以及您将更新的内容。
其他资源 z z
有关在工作区中查看挂起更改的详细信息，请参见“如何：查看和管理工作区中所有挂起的更 改”，地址为：http://msdn2.microsoft.com/en-us/library/ms181400(VS.80).aspx 有关在其他工作区中查看挂起更改的详细信息，请参见“如何：查看其他工作区中的挂起的更 改”，地址为：http://msdn2.microsoft.com/en-us/library/ms181401(VS.80).aspx
签出、获取和锁定 z z z
在进行更改前获得最新源代码。 谨慎使用锁定命令。 在锁定文件时要与同一团队中的伙伴沟通。
在进行更改前获得最新源代码 要确保您具有正在处理的项目最新版本的所有源文件，请首先运行 get latest 命令，然后再签出文 件进行编辑。不执行此操作的危险是，以后将文件签入服务器时，根据非最新源文件本地生成代码 会增加代码引起生成问题的可能性。 要获得与特定团队项目关联的文件集的最新副本，请右击“源代码管理资源管理器”中的团队项目， 然后单击“获得最新版本”。如果在工作区中当前存在具有挂起的编辑的可写文件，则该命令不会 改写这些文件。通过从映射到当前工作区的目录中运行 Tf get /all 命令，可以通过命令行运行相同 的命令。
其他资源 z
有关 Get 命令的详细信息，请参见 MSDN 网站上的“Get 命令”，地址为： http://msdn2.microsoft.com/en-us/library/fx7sdeyf(VS.80).aspx
谨慎使用 lock 命令 谨慎使用 lock 命令，因为当您在文件上工作时锁定文件可能导致开发过程中的瓶颈，方法是阻止 其他人同时工作在同一文件上。如果您担心存在冲突，从而导致手动合并操作更复杂，则应该只在 进行编辑时锁定文件。只要可能，应首选共享签出，即在签出文件时选择锁定类型“None”。 以下是适合使用锁定来避免冲突的常见情况： z z
修改二进制文件格式，如无法轻松合并的图像或文档。 对文件进行了非常广泛的更改，以至于使用同一文件的任何其他开发人员非常有可能对相同行 进行更改。
如果想避免任何冲突的可能，请使用签出锁定，这会阻止其他人签出以及签入同一文件。如果您锁 定文件，请通知团队成员您锁定文件的时间，并告诉他们您这样做的原因以及您在该文件上可能花 费的时间。还要让他们知道您去除锁定以及再次签入更改的时间。 指定签出文件进行编辑时的锁定类型，也可以显式锁定文件。 要在签出时锁定文件 1. 2. 3.
在“源代码管理资源管理器”中右击该文件，然后单击“签出进行编辑”。 指定锁定类型：无、签出或签入。 要显式锁定文件，请右击该文件，单击“锁定”，然后选择“签出”或“签入”锁定类型。
请注意，与 Microsoft Visual Source Safe® (VSS) 行为不同，签出文件不会不言明的获得最新版本。 在锁定文件之前，通过单击“获得最新版本”确保工作区中的是最新版本。
其他资源 z
有关锁定的详细信息，请参见“如何：锁定和取消锁定文件夹或文件”，地址为： http://msdn2.microsoft.com/en-us/library/ms181420(VS.80).aspx
z
有关锁定类型的详细信息，请参见： http://msdn2.microsoft.com/en-us/library/ms181419(VS.80).aspx
在锁定文件时要与同一团队中的伙伴沟通 如果您锁定源文件，请让您的团队成员知道以便他们可以围绕该文件的不可用性计划他们的工作。 解释您需要独占的锁定文件的原因以及可能保留锁定的时间。如果其他开发人员需要在同一源文件 上工作，则锁定文件可能会在开发周期中潜在地引入瓶颈。 如果您担心存在冲突，从而导致手动合并操作更复杂，则应该只在进行编辑时锁定文件。只要可能， 应首选共享签出，即在签出文件时选择锁定类型“None”。 要从源代码管理资源管理器中锁定文件，请右击该文件，单击“锁定”，然后选择“签出”或“签 入”锁定类型。
其他资源 z
有关锁定类型的详细信息，请参见： http://msdn2.microsoft.com/en-us/library/ms181419(VS.80).aspx
依赖项 z z z z
尽可能使用项目引用。 只在必要的情况下使用文件引用。 对于项目和文件引用，请使用 copy local = true。 在引用 Web 服务时使用动态 URL。
尽可能使用项目引用 只要可能，您都应该使用项目引用，因为它们有以下优点： z z z z
z
它们适用于已加载解决方案和项目集的所有开发工作站。这是因为项目全局唯一标识符 (GUID) 被放置在项目文件中，它唯一标识当前解决方案上下文中引用的项目。 它们使 Visual Studio 生成系统能够跟踪项目依赖项并确定正确的项目生成顺序。 它们帮助您避免在特殊计算机上丢失引用的程序集的可能性。 它们自动跟踪项目配置更改。例如，当使用调试配置生成时，任何项目引用是指调试由引用的 项目生成的程序集，而它们是指在发布配置中发布程序集。这意味着您可以在项目之间自动从 调试切换到发布生成，而无需重置引用。 它们使 Visual Studio 能够检测并阻止循环依赖。
如果程序集已经位于您的解决方案的项目集之内，则可以使用项目引用。如果程序集位于您的解决 方案的项目集之外，并且仍然想使用项目引用，则可以将原始项目的依赖项分支到您的项目中。当 您想拾取新版本的依赖项时，请执行从原始项目到您的分支的合并。
其他资源 z z
有关项目和文件引用的详细信息，请参见“项目引用”，地址为： http://msdn2.microsoft.com/en-us/library/ez524kew(VS.80).aspx 有关添加引用的详细信息，请参见“如何：在 Visual Studio 中添加或移除引用”，地址为： http://msdn2.microsoft.com/en-us/library/wkze6zky(VS.80).aspx
只在必要的情况下使用文件引用 如果您由于需要引用当前解决方案的项目集之外的程序集而无法使用项目引用，并且不希望创建从
原始项目到您的项目的分支，则必须设置文件引用。
其他资源 z
有关项目和文件引用的详细信息，请参见“项目引用”，地址为： http://msdn2.microsoft.com/en-us/library/ez524kew(VS.80).aspx
对于项目和文件引用，请使用 copy local = true 每个引用都有关联的 copy local 属性。当初始添加引用时，Visual Studio 确定该属性的初始设置 （true 或 false）。如果发现引用的程序集位于全局程序集缓存 (GAC) 中，则设置为 false，否则设 置为 true。 您不应该更改此默认设置。 在 copy local 设置为 true 的情况下设置引用时，Visual Studio 生成系统将任何引用的程序集（以 及任何依赖的下游程序集）复制到客户端项目的输出文件夹中。例如，如果您的客户端引用一个名 为 Lib1 的程序集，并且 Lib1 依赖于 Lib2 和 Lib3，则在生成时 Visual Studio 会自动将 Lib1、 Lib2 和 Lib3 复制到您的项目的本地输出文件夹中。
其他资源 z
有关项目和文件引用的详细信息，请参见“项目引用”，地址为： http://msdn2.microsoft.com/en-us/library/ez524kew(VS.80).aspx
在引用 Web 服务时使用动态 URL 如果您调用一个 Web 服务，则必须首先向您的项目中添加一个 Web 引用。这将生成一个代理类， 可通过它与 Web 服务交互。该代理代码最初包含用于此 Web 服务的静态统一资源定位器 (URL)， 例如，http://localhost or http://SomeWebServer。 重点：对于当前解决方案中要在计算机上执行的 Web 服务，始终使用 http://localhost 而不使用 http://MyComputerName，以确保引用在所有计算机上仍然有效。 嵌入到代理中的静态 URL 通常不是您在产品或测试环境中所需的 URL。通常，随着您的应用程序 从开发到测试到生产，所需的 URL 也会随之改变。有三个选项可解决此问题： z z
z
创建该代理类的实例时，可通过编程方式设置 Web 服务 URL。 一个避免代理中硬编码 URL 的更灵活的方法是将此 Web 服务引用的“URL 行为”属性设置 为“动态”。这是首选方法。当将此属性设置“动态”时，代码便添加到代理类中，以从应用 程序配置文件（对于 Web 应用程序，为 Web.config，对于 Windows 应用程序，为 SomeApp.exe.config）的自定义配置部分中检索 Web 服务 URL。 还可以通过使用 WSDL.exe 命令行工具并指定 /urlkey 切换来生成代理。其工作方式类似于设 置“URL 行为”属性，因为它向代理中添加代码，以检索 Web 服务 URL，但在这种情况下， URL 存储在应用程序配置文件的 <applicationSettings> 部分中。
动态 URL 方法还使您能够提供一个用户配置文件，该文件可重写主应用程序配置文件。这允许单 独的开发人员（以及测试团队的成员）临时将 Web 服务引用重定向到其他位置。
其他资源 z
有关详细信息，请参见本指南中的“第 6 章 - 在 Visual Studio Team System 中管理源代码管 理依赖项”。
分布式 / 远程开发
z z z z z z
确保为代理获得了大小合理的磁盘驱动器。 创建一个预定任务，定期拉取最新文件。 定期监控代理性能计数器和事件日志。 根据文件大小和带宽配置 executionTimeout。 如果代理长时间停止响应，则禁用代理。 考虑采用工作区掩蔽来减少不必要的文件传输。
确保为代理获得了大小合理的磁盘驱动器 务必遵循 TFS 安装指南中的硬件建议，尤其确保获得具有足够容量的硬盘驱动器。代理可以使用 在存储空间数量上设置的最大限制来缓存文件。达到该限制时，将删除缓存中的旧文件以释放一些 存储空间，以便该空间可以用于缓存新请求的文件。清理是根据最后访问文件的时间来删除文件。 将首先删除最长时间不使用的那些文件。
其他资源 z
要进一步了解 Team Foundation Server Proxy，请参见 MSDN 网站上的“Team Foundation Server Proxy 和源代码管理”，地址为：http://msdn2.microsoft.com/en-us/library/ms252490(VS.80).aspx
创建一个预定任务，定期拉取最新文件 运行预定任务，定期为代理服务器检索最新文件。这有助于确保可以在代理缓存中使用最新版本的 文件，并且确保后续请求这些文件的客户端导致缓存命中。
其他资源 z
要进一步了解 Team Foundation Server Proxy，请参见 MSDN 网站上的“Team Foundation Server Proxy 和源代码管理”，地址为：http://msdn2.microsoft.com/en-us/library/ms252490(VS.80).aspx
定期监控代理性能计数器和事件日志 定期监控代理性能计数器和 Windows 事件日志，查看是否有错误和警告，以便获得代理运行方式 的最佳图片。确保启用了代理缓存，并监视缓存的性能。 应该观察以下性能计数器： z z z z z
当前缓存大小 缓存命中总数 – 计数和百分比 下载请求总数 缓存中的文件总数 缓存缺失总数 – 计数和百分比
在安装代理时注册这些性能计数器。代理性能计数器是多实例的，这意味着在 Proxy.config 文件中 配置的每个应用程序层都有一组计数器。通过收集该数据，了解在运行代理服务器时的性能。 请注意，TFS 代理服务器将缓存性能统计信息保存到一个名为 ProxyStatistics.xml 的可扩展标记语 言 (XML) 文件中，您可以更改保存这些统计信息的时间间隔。ProxyStatistics.xml 文件位于代理安 装目录中的 App_Data 文件夹中。
其他资源 z
要进一步了解 Team Foundation Server Proxy，请参见 MSDN 网站上的“Team Foundation Server Proxy 和源代码管理”，地址为：http://msdn2.microsoft.com/en-us/library/ms252490(VS.80).aspx
根据文件大小和带宽配置 executionTimeout
如果您知道将通过低带宽（< 3 兆位/秒 [Mbps]）的网络下载大量文件，请将 Web.config 中的 executionTimeout 配置设置为相应的值。执行该操作可减少超时的可能性。默认值为 1 小时，如此 处所示： <httpRuntime executionTimeout="3600"/>。
其他资源 z
要进一步了解 Team Foundation Server Proxy，请参见 MSDN 网站上的“Team Foundation Server Proxy 和源代码管理”，地址为：http://msdn2.microsoft.com/en-us/library/ms252490(VS.80).aspx
如果代理长时间停止响应，则禁用代理 如果代理长时间停止响应，则禁用客户端上的代理。执行该操作可防止徒劳的重新连接。默认情况 下，每隔 5 分钟进行这些尝试。
其他资源 z
要进一步了解 Team Foundation Server Proxy，请参见 MSDN 网站上的“Team Foundation Server Proxy 和源代码管理”，地址为：http://msdn2.microsoft.com/en-us/library/ms252490(VS.80).aspx
考虑采用工作区掩蔽来减少不必要的文件传输 考虑使用工作区掩蔽来隐藏特定的工作区使其无法查看，并且防止不必要的文件传输。掩蔽不仅仅 可以隐藏指定的工作区文件夹使其无法查看，而且还提高性能带宽并且通过阻止当前不需要的文件 夹和文件复制到本地工作区来节约本地磁盘空间。尽管您可以掩蔽工作区中的现有文件夹映射，但 最好是创建专门用于掩蔽的新文件夹映射。 要掩蔽工作区中的文件夹 1. 2. 3. 4. 5.
在 Visual Studio 的“文件”菜单上，指向“源代码管理”，然后单击“工作区”。 在“管理工作区”对话框中，选择要应用掩蔽的工作区，然后单击“编辑”。 在“编辑工作区”对话框的“工作文件夹”列表中，突出显示位于“源代码管理文件夹”和本 地文件夹下的要掩蔽的文件夹映射，或者创建一个新映射。 单击“状态”列并将设置从“活动”更改为“掩蔽”。 请注意，您只能掩蔽活动映射的 TFS 源代码管理文件中的文件夹。 单击“确定”关闭“编辑工作区”，然后单击“关闭”关闭“管理工作区”。
请注意，在对整个工作区执行另一个 get 操作之前，您的文件不会在本地消失。
其他资源 z
要进一步了解 Team Foundation Server Proxy，请参见 MSDN 网站上的“Team Foundation Server Proxy 和源代码管理”，地址为：http://msdn2.microsoft.com/en-us/library/ms252490(VS.80).aspx
迁移 z z
使用 VSS 转换器迁移到 Team Foundation Server 源代码管理。 从其他源代码管理系统迁移到 Team Foundation Server 源代码管理。
使用 VSS 转换器迁移到 Team Foundation Server 源代码管理
Team Foundation Server 附带一个 VSS 转换器工具，该工具允许您将 Visual SourceSafe 数据库中的 文件、文件夹、版本历史、标签和用户信息迁移到 Team Foundation Server 版本控制。 该转换器具有对于理解非常重要的某些限制，例如： z z z z
关于文件共享的历史记录信息不会保留。Team Foundation Server 不支持共享。共享文件的迁移 结果就是将该文件复制到目标文件夹。 关于分支的历史记录信息不会保留。 Team Foundation Server 不支持固定 (pinning)。被固定的文件是通过创建两个标签迁移的。 时间戳与迁移过程中不保留的操作相关联。
其他资源 z
有关迁移文件的详细信息，请参见本指南中的“如何：将源代码从 Visual Source Safe 迁移到 Team Foundation Server”。
从其他源代码管理系统迁移到 Team Foundation Server 源代码管理 可以手动从要迁移出的原版本控制系统中导出文件，再将其导入 Team Foundation Server 版本控制 中。如果您需要保存迁移的版本控制系统中的文件历史记录或其他属性，则可以使用位于 http://www.codeplex.com/MigrationSyncToolkit 上的 TFS 迁移和同步工具包编写您自己的迁移工 具。 Microsoft 目前正在研发一种 ClearCase 转换器。当这种转换器准备就绪时，将在 TFS 迁移博客上 发布，博客地址为：http://blogs.msdn.com/tfs_migration Component Software 已经创建了一种与 GNU RCS、CS-RCS、GNU CVS、Subversion (SVN) 和 Visual SourceSafe (VSS) 兼容的转换器。
其他资源 z z z
有关 TFS 迁移的详细信息，请参见 MSDN 网站上的“TFS 迁移博客”，地址为： http://blogs.msdn.com/tfs_migration 要从 CodePlex 下载 TFS 迁移和同步工具包，请访问： http://www.codeplex.com/MigrationSyncToolkit 有关 Component Software 转换器的详细信息，请参见： http://www.componentsoftware.com/Products/Converter/
项目 / 工作区管理 z z z z z z z z z z z
使用工作区而非分支来分离单独的开发人员。 通过使用源代码管理而不是使用 Windows 资源管理器删除和重命名文件。 仅在解决方案打开时进行删除和重命名。 如果希望在应用程序的版本直接移动资产，则为每个应用程序创建一个团队项目。 如果希望每个应用程序版本都从零开始，则为每个版本创建一个团队项目。 使用分支来共享需要集成测试的代码和二进制文件。 避免工作区映射来支持跨项目依赖项。 在团队项目的根级别创建工作区映射。 使用共享计算机上的惟一本地文件夹路径。 考虑仅映射部分源代码树。 将源代码树的结构设计为支持分支。
使用工作区而非分支来分离单独的开发人员 要将您的工作与团队中其他成员的工作分开，请使用其他工作区并且不创建新的分支。使用主要工
作区包含团队中其他成员使用的文件和文件夹的引用（即包含共享源代码）并且创建另一个工作区， 以维护您要分离的文件和文件夹。您可能想分离这些文件，以便发生其他情况时与工作并行发展特 定的文件。例如，这可以用于危险的挂起更改或试验性更改。通过使用另一个工作区，可以降低其 他分支和合并的复杂程度。 要创建一个辅助工作区 1. 2. 3. 4.
5.
在“源代码管理资源管理器”中，单击“工作区”下拉列表，然后单击“工作区”。 在“管理工作区”对话框中，单击“添加”。 在“添加工作区”对话框中，输入新的工作区名称（如 MyIsolatedWork）并提供作为有关该 工作区用途的将来提示的注释。 在“工作文件夹”列表中，将工作区状态设置为“活动”，标识要包含在该工作区中的源代码 管理文件夹（这可能是团队项目根文件夹或任何子文件夹），并且指定您自己的计算机上的本 地文件夹路径以包含工作区中的文件。 单击“确定”，再单击“关闭”来创建一个独立的工作区。
要为在独立工作区中开始工作而检索最新源代码集 1. 2.
在“源代码管理资源管理器”中，确保“工作区”下拉列表中选中了您的独立工作区名称。 选择您的团队项目根文件夹（如果您只需源代码树的一部分，则选择子文件夹），右击，然后 单击“获得最新版本”。
这会将文件夹结构和最新的文件集从源代码管理服务器复制到计算机上映射到新工作区的本地目 录。
其他资源 1. 2.
有关创建工作区的详细信息，请参见“如何：创建工作区”，地址为： http://msdn2.microsoft.com/en-us/library/ms181384(VS.80).aspx 有关编辑工作区的详细信息，请参见“如何：编辑工作区”，地址为： http://msdn2.microsoft.com/en-us/library/ms245466(VS.80).aspx
通过使用源代码管理而不是使用 Windows 资源管理器删除和重命名文件 如果您需要删除或重命名已经添加到源代码管理中的文件，则应该使用源代码管理资源管理器或通 过命令行使用 Tf.exe 来删除或重命名它们。不要使用 Windows 资源管理器删除或重命名文件，因 为这样做会使您的本地工作区文件与服务器上的源代码管理文件不同步。 要使用源代码管理资源管理器删除文件或文件夹 1. 2. 3.
在“源代码管理资源管理器”中，选择文件或文件夹。 右击选择的文件或文件夹，然后单击“删除”。 一个表示该项目已删除图标将出现在左侧，并且状态“删除”出现在“挂起更改”列下。下次 您签入该文件时该项目将被删除。
注意：无法删除存在其他挂起更改的项目。例如，无法删除签出的文件。 如果您需要对多个文件或文件夹执行操作，则 Tf move、delete 和 rename 命令特别有用。使用源 代码管理资源管理器，您只能一次移动、重命名或删除一个文件或文件夹。
其他资源 z
有关 Tf delete 命令的详细信息，请参见 MSDN 网站上的“Delete 命令”，地址为： http://msdn2.microsoft.com/en-us/library/k45zb450(VS.80).aspx
z
有关 Tf rename 命令的详细信息，请参见 MSDN 网站上的“Rename 命令”，地址为： http://msdn2.microsoft.com/en-us/library/a79bz90w(VS.80).aspx
仅在解决方案打开时进行删除和重命名 在解决方案打开时仅在解决方案资源管理器内删除和重命名文件。不要直接在磁盘上执行此操作。 该方法可确保当您下次签入挂起的更改时，保持 TFS 源代码管理同步。
其他资源 z z
有关 Tf delete 命令的详细信息，请参见 MSDN 网站上的“Delete 命令”，地址为： http://msdn2.microsoft.com/en-us/library/k45zb450(VS.80).aspx 有关 Tf rename 命令的详细信息，请参见 MSDN 网站上的“Rename 命令”，地址为： http://msdn2.microsoft.com/en-us/library/a79bz90w(VS.80).aspx
如果希望在应用程序的版本直接移动资产，则为每个应用程序创建一个团 队项目 如果您不仅想将源代码带入下次，也想将工作项和其他 TFS 资产带入下次，可考虑每个应用程序 使用一个团队项目。多个版本的应用程序使用一个团队项目时，所有 TFS 资产都会自动带入下次 发布。当您准备发布新版本的应用程序时，可以在项目内创建一个分支以表示此发布并分离该代码。 如果您选择每个应用程序使用一个项目，请记住以下弱点： z z z z
强制平行发布共享工作项体系结构、签入策略和过程指南。 报告更加困难。因为报告默认针对整个项目，必须在发布前添加筛选。 如果您有数以百计的应用程序，每个应用程序都处于自己的项目之中，那么就会遇到 TFS 性 能和伸缩限制的问题。 您将积累下来自多次发布的“累赘”。解决此问题的最简单方法是创建一个新的项目，分支您 要带入该项目中的代码。
其他资源 z
有关使用团队项目的详细信息，请参见“何时使用团队项目”，地址为： http://blogs.msdn.com/ericlee/archive/2006/08/09/when-to-use-team-projects.aspx
如果希望每个应用程序版本都从零开始，则为每个版本创建一个团队项目 如果希望每次发布都从零开始，不将任何工作项及其他 TFS 资产带入下次，可考虑为每次发布使 用一个项目。为各发布使用新项目时，可以修改工作项体系结构、工作流、签入策略和其他资产， 而不会影响旧发布。如果旧发布将由一支独立团队维护（例如维护工程师团队），这支团队将具有 与您的主要开发团队不同的过程和工作流。 当每个发布使用一个项目时，请记住以下事项： z
z z z
z
尽管将源代码从一个项目转移到另一个项目非常容易，但在项目间转移工作项和其他 TFS 资 产非常困难。由于一次只能复制一个工作项到另一个项目，因此如果您想复制工作项组，将需 要编写您自己的工具。 如果您有数以百计的应用程序和发布，均处于自己的项目之中，那么就会遇到 TFS 性能和伸 缩限制的问题。 选择一种可长期使用的结构，因为重新设计已有团队项目的结构困难至极。 可在团队项目间轻松共享源代码，如下所示： 将源代码从一个项目分支到另一个项目。 将源代码从另一个项目映射到您的工作区中。 通过使用 Microsoft Solution Framework (MSF) for Agile Software Development (MSF Agile) 过程
模板可以将 Team Foundation Server 缩放为大约 500 个项目，使用 MSF CMMI 过程模板可以 将其缩放为 250 个项目。如果您创建自己的过程模板或自定义现有的过程模板，请记住，工作 项体系结构对服务器的可伸缩性影响最大。复杂的体系结构将得到支持更少项目的服务器。
其他资源 z
有关使用团队项目的详细信息，请参见“何时使用团队项目”，地址为：
使用分支来共享需要集成测试的代码和二进制文件 管理共享代码或二进制文件涉及两个步骤： 1. 2.
确定存储依赖项的位置。 将依赖项分支到您的项目中。
1. 确定存储依赖项的位置。 用于存储的选项：
如果特殊团队明确拥有共享依赖项，则将其存储在该团队的团队项目中。 如果共享依赖项没有明确的所属权，可专门为该共享代码创建一个团队项目。
2. 将依赖项分支到您的项目中。 存储依赖项之后，将共享源或二进制文件分支到您的项目中。每次您执行从共享到消费项目的合并 时，您将拾取最新的源。这允许您按定期计划拾取更改以及在影响您的主源代码树之前执行集成测 试。
其他资源 z z z z
有关分支与合并的简介，请参见“分支与合并入门”，地址为： http://msdn2.microsoft.com/en-us/library/aa730834(VS.80).aspx 有关分支的详细信息，请参见“如何：分支文件和文件夹”，地址为： http://msdn2.microsoft.com/en-us/library/ms181425(VS.80).aspx 有关合并的详细信息，请参见“如何：合并文件和文件夹”，地址为： http://msdn2.microsoft.com/en-us/library/ms181428(VS.80).aspx 有关如何在 Visual Studio 2005 中进行分支与合并的详细信息，请参见“对 Team Foundation 源 代码管理进行分支和合并”，地址为： http://msdn2.microsoft.com/en-us/library/ms181423(VS.80).aspx
避免工作区映射来支持跨项目依赖项 通常，您应该避免跨团队项目的依赖项，并尝试保留同一团队项目下的所有相关/依赖的解决方案/ 项目。这会减少对生成脚本自定义的需要。如果您有依赖项，请使用项目引用来定义它，或者将共 享项目中的依赖项分支到您的项目中。应避免使用文件引用，因为文件引用管理起来更困难。但当 并行开发依赖项目并且您需要实时更改时例外。在这种情况下，您可以考虑使用工作区映射。但是， 如果依赖代码造成太多中断的更改，您仍然可以在这种情况下使用分支以创建分隔缓冲区。
其他资源 z z
有关创建工作区的详细信息，请参见“如何：创建工作区”，地址为： http://msdn2.microsoft.com/en-us/library/ms181384(VS.80).aspx 有关编辑工作区的详细信息，请参见“如何：编辑工作区”，地址为： http://msdn2.microsoft.com/en-us/library/ms245466(VS.80).aspx
在团队项目的根级别创建工作区映射 对于新的团队项目，将团队项目根 ($/MyTeamProject) 映射到本地驱动器上具有相同名称的文件夹，
例如，C:\TeamProjects。由于映射是累积的，因此整个本地文件夹结构是自动创建的，并且将与源 代码管理中的结构完全相同。
其他资源 z z
有关创建工作区的详细信息，请参见“如何：创建工作区”，地址为： http://msdn2.microsoft.com/en-us/library/ms181384(VS.80).aspx 有关编辑工作区的详细信息，请参见“如何：编辑工作区”，地址为： http://msdn2.microsoft.com/en-us/library/ms245466(VS.80).aspx
使用共享计算机上的惟一本地文件夹路径 一台计算机的两名用户无法共享相同的工作区映射。例如，您和您的同事无法将同一个团队项目 ($/MyTeamProject) 映射到本地计算机的同一文件夹。但是在“我的文档”下创建映射（尽管这会导 致比较长的位置路径）或在本地计算机上建立一个团队文件夹命名约定（例如， C:\TeamProjects\User1、C:\TeampProjects\User2 等等）。
其他资源 z z
有关创建工作区的详细信息，请参见“如何：创建工作区”，地址为： http://msdn2.microsoft.com/en-us/library/ms181384(VS.80).aspx 有关编辑工作区的详细信息，请参见“如何：编辑工作区”，地址为： http://msdn2.microsoft.com/en-us/library/ms245466(VS.80).aspx
考虑仅映射部分源代码树 要提高性能并减小磁盘大小要求，则只为您的开发项目映射需要的文件。通常，将只需要与将使用 的解决方案关联的文件和项目。
其他资源 z z
有关创建工作区的详细信息，请参见“如何：创建工作区”，地址为： http://msdn2.microsoft.com/en-us/library/ms181384(VS.80).aspx 有关编辑工作区的详细信息，请参见“如何：编辑工作区”，地址为： http://msdn2.microsoft.com/en-us/library/ms245466(VS.80).aspx
将源代码树的结构设计为支持分支 您的源代码树结构包含文件夹结构、文件结构和分支结构的组合。在主分支内，以下文件夹和文件 结构已证明适用于多种规模的团队： z
Main – 为发布产品所需的一切资产的容器 Source - 生成所需的全部内容的容器 Code – 源代码容器 Shared Code – 从其他项目共享的源代码容器 Unit Tests – 单元测试容器 Lib – 二进制依赖项的容器 Docs – 将随产品一起提供的文档的容器 Installer – 安装程序源代码和二进制文件的容器 Tests – 测试团队测试用例的容器
从 Main 中创建的任何分支将此文件夹和文件结构复制到新的分支，例如： z
Development – 开发分支 Source - 生成所需的全部内容的容器 Code – 源代码容器
z
Shared Code – 从其他项目共享的源代码容器 Unit Tests – 单元测试容器 Lib – 二进制依赖项的容器 Main – 集成分支 Source - 生成所需的全部内容的容器 Code – 源代码容器 Shared Code – 从其他项目共享的源代码容器 Unit Tests – 单元测试容器 Lib – 二进制依赖项的容器 Docs – 将随产品一起提供的文档的容器 Installer – 安装程序源代码和二进制文件的容器 Tests – 测试团队测试用例的容器
其他资源 z z
有关创建工作区的详细信息，请参见“如何：创建工作区”，地址为： http://msdn2.microsoft.com/en-us/library/ms181384(VS.80).aspx 有关编辑工作区的详细信息，请参见“如何：编辑工作区”，地址为： http://msdn2.microsoft.com/en-us/library/ms245466(VS.80).aspx
搁置 z z z
使用搁置共享挂起的更改，以便进行查看或移交。 使用搁置将挂起的更改备份到服务器。 如果被较高优先级的工作打断，则可使用搁置。
使用搁置共享挂起的更改，以便进行查看或移交 如果您想与远程团队成员一起讨论或查看您正在进行的工作代码，请使用搁置。代替将代码发邮件 给您的团队成员，您可以搁置该代码，然后让远程同事从搁置架中检索文件。 同样，如果您想将部分完成的工作传递给其他开发人员来完成，则可以使用搁置来移交代码。
其他资源 z
有关搁置挂起更改的详细信息，请参见“如何：搁置和取消搁置挂起的更改”，地址为： http://msdn2.microsoft.com/en-us/library/ms181404(VS.80).aspx
使用搁置将挂起的更改备份到服务器 如果在一天快结束时您还没有完成工作，但想确保在服务器上备份当前工作，请使用搁置。通过搁 置当前更改，将更改应用于 TFS 服务器并且可以在明天由您或其他人检索。
其他资源 z
有关搁置挂起更改的详细信息，请参见“如何：搁置和取消搁置挂起的更改”，地址为： http://msdn2.microsoft.com/en-us/library/ms181404(VS.80).aspx
如果被较高优先级的工作打断，则可使用搁置 如果您正处于对源代码集进行更改的中途，则当分配新的较高优先级的工作时（例如需要紧急 bug 修复），请使用搁置。此时，您需要回到该代码的稳定版本，但您不想丢失更改。执行该操作之前， 您可以搁置您的代码以便以后轻松检索。
其他资源
z
有关搁置挂起更改的详细信息，请参见“如何：搁置和取消搁置挂起的更改”，地址为： http://msdn2.microsoft.com/en-us/library/ms181404(VS.80).aspx
源代码管理资源 z
有关“Team Foundation Server 源代码管理”的详细信息，请参见“Team Foundation 源代码管 理”，地址为：http://msdn2.microsoft.com/en-us/library/ms181237(VS.80).aspx
实践总览团队生成 索引 管理 z z z z
如何保护生成服务器 如何删除一个生成 如何删除一个生成类型 如何将工作项与生成相关联
签入策略 z z
如何使用签入策略来提高签入质量 如何使用签入策略将工作项与生成相关联
连续集成生成 z z z
如何自动运行连续集成 (CI) 生成 如何确定您是否需要滚动式生成 如何确定滚动式生成时间间隔
自定义 z z z z
如何修改生成号 如何设置工作区映射来获取和生成该树的子集 如何生成在其他团队项目中具有依赖项的项目。 如何更改生成配置（发布/调试）
部署 z z
如何设置生成服务器 如何确定您是否需要多个生成服务器
概述 z z z z z z z z z z z z z z z
如何使用 Team Build 生成设置和部署 ASP.NET 应用程序 如何使用 Team Build 生成 Microsoft® .NET 1.1 应用程序 如何使用 Team Build 生成设置和部署项目 如何创建团队生成 如何创建多种生成类型 如何为一个引用了其他项目中程序集的项目创建团队生成 如何订阅生成的 e-mail 事件 如何在生成失败时接收通知 如何启动一次生成 如何验证生成是否成功 如何查看生成输出 如果更改生成服务器位置 如何更改生成输出位置 如何确定哪个变更集是生成的一部分 如何更改报告的生成质量
项目 z z z
如何使用单解决方案战略 如何使用分区解决方案战略 如何使用多解决方案战略
报告 z z z z z z z
如何查看生成质量 如何查看一个生成的所有签入 如何查看一个生成的已关闭工作项或 bug 如何查看一个生成的开放工作项或 bug 如何跟踪从生成到生成的速度 如何跟踪一个生成的测试用例的通过/失败结果 如何查看生成状态（BVT 结果）
预定生成 z z
如何自动运行每夜生成 如何决定项目的生成频率和类型
测试驱动的开发 z z z z
如何创建“hello world”验收测试 如何将自动测试作为生成的一部分运行 如何将代码分析作为生成的一部分运行 如何获得使生成失败的失败测试
管理 z z z z
如何保护生成服务器 如何删除一个生成 如何删除一个生成类型 如何将工作项与生成相关联
如何保护生成服务器 要保护生成服务器 1. 2. 3. 4.
将生成服务部署在单独服务器上，而不是与 Microsoft Visual Studio® 2005 Team Foundation Server (TFS) 应用程序层或数据层共享服务器。 授予生成过程对生成目录的读/写访问权限。确保运行生成的帐户能够访问此目录。 授予生成过程对生成丢弃网络共享的读/写访问权限。确保运行生成的帐户能够访问此共享。 确保用于运行团队生成的帐户是团队项目的“生成服务”组的成员。
要提高 Team Foundation Server 安全性，您应该在其自己的计算机上而不是在应用程序层或数据层 上安装生成服务器。某些部署或生成步骤可能需要提高权限，例如，创建一个虚拟目录以部署 Web 应用程序需要在生成服务器上具有管理权限。这意味着运行生成的 Microsoft Windows® 帐户需要 具有这些权限。如果生成计算机位于应用程序层上，则这可能会出现安全风险。同样，如果生成计 算机位于数据层上，则生成帐户可以访问和更改该层上的数据库。 注意：出于安全的原因，不要向 SERVER\ Service Accounts 组中添加运行团队生成的帐户。.该组的 成员具有 TFS 中的完全管理权限。
其他资源 z
有关 TFS 组和权限的详细信息，请参见“Team Foundation Server 默认组、权限和角色”，地 址为：http://msdn2.microsoft.com/en-us/library/ms253077(VS.80).aspx
如何删除一个生成 要删除生成，请使用 TFSBuild 命令行工具。指定 TFS 服务器的地址、团队项目的名称、生成名称； 例如： z TfsBuild delete http://mytfsserver:8080 myproject build20070606.4
其他资源 z z
有关删除已完成的生成的详细信息，请参见“如何：删除已完成的生成”，地址为： http://msdn2.microsoft.com/en-us/library/aa337656(VS.80).aspx 有关 delete 命令的详细信息，请参见“Delete 命令 (Team Foundation Build)”，地址为： http://msdn2.microsoft.com/en-us/library/ms244360(VS.80).aspx
如何删除一个生成类型 您无法通过使用团队资源管理器删除团队生成类型。应该从源代码管理中删除生成类型。 删除现有的生成类型 1. 2. 3. 4. 5. 6. 7. 8.
打开“源代码管理资源管理器”。 在“源代码管理资源管理器”中，展开您的团队项目文件夹。 展开 TeamBuildTypes 文件夹。 右击代表您要删除的团队生成类型的团队生成文件夹，然后单击“删除”。 再次右击团队生成文件夹，然后单击“签入挂起的更改…” 打开“团队资源管理器”。 右击团队生成文件夹，然后单击“刷新”。 展开团队生成文件夹并确认团队生成已被删除。
其他资源 z
有关 Team Build 的详细信息，请参见“Team Foundation Build 概述”，地址为： http://msdn2.microsoft.com/en-us/library/ms181710(vs.80).aspx
如何将工作项与生成相关联 使用“签入”对话框将工作项与签入相关联。这将自动将这些工作项与下一个生成相关联。 要将工作项与生成相关联 1. 2. 3. 4.
更改您要包含在生成中并且将与工作项关联的代码。 签入挂起的更改。 在“签入”对话框中，单击“工作项”。 选择您要与该签入关联的工作项。
自从上次成功生成以来发生的所有变更集将与下一个生成相关联。下一个生成之后，Team Build 将 在生成的关联变更集中列出此变更集，并且将包括正在与变更集关联的选定工作项。
其他资源 z
有关签入挂起的更改的详细搁信息，请参见“如何：签入挂起的更改”，地址为： http://msdn2.microsoft.com/en-us/library/ms181411(VS.80).aspx
签入策略 z z
如何使用签入策略来提高签入质量 如何使用签入策略将工作项与生成相关联
如何使用签入策略提高签入质量 将代码分析与测试策略相结合，来提高签入质量。例如，使用默认的测试签入策略来确保指定测试 预先得到测试并已通过，之后再允许源代码签入 TFS 源代码管理。还可以配置代码分析策略，以 帮助确保代码符合某些质量标准，从而确保安全性、性能、可移植性、可维护性和可靠性规则通过。 要为一个团队项目实施代码分析签入策略 1. 2. 3.
在“团队资源管理器”中，右击您的团队项目，选择“团队项目设置”，然后单击“源代码管 理” 单击“签入策略”选项卡。 单击“添加”，然后选择并配置代码分析和测试策略。
其他资源 z z z z z
有关创建和使用自定义签入策略的详细信息，请参见本指南中的“如何：为 TFS 创建自定义 签入策略详解”。 要了解如何自定义签入策略，请参见“演练：自定义签入策略和签入说明”，地址为： http://msdn2.microsoft.com/en-us/library/ms181281(VS.80).aspx 要查看拒绝签入的选定模式的示例代码，请参见“拒绝某些模式的签入策略”，地址为： http://blogs.msdn.com/jmanning/archive/2006/02/02/523125.aspx 要查看对签入实施注释的示例代码，请参见“示例签入策略：确保注释非空”，地址为： http://blogs.msdn.com/jmanning/archive/2006/01/21/515858.aspx 要了解如何注册新签入策略，请参见“我创建了一条新的签入策略！如何添加？”，地址为： http://blogs.msdn.com/jmanning/archive/2006/02/07/526778.aspx
如何使用签入策略将工作项与生成关联 使用签入策略强制每个签入具有关联的工作项。开发人员使用“签入”对话框将工作项与签入相关 联。这将自动将这些工作项与下一个生成相关联。 设置工作项签入策略，以强制开发人员将其签入与工作项关联 1. 在“团队资源管理器”中，右击您的团队项目，选择“团队项目设置”，然后单击“源代码管 理”。 2. 单击“签入策略”选项卡。 3. 单击“添加”，然后选择并配置“工作项”签入策略。
其他资源 z z
有关创建和使用自定义签入策略的详细信息，请参见本指南中的“如何：为 TFS 创建自定义 签入策略详解”。 要了解如何自定义签入策略，请参见“演练：自定义签入策略和签入说明”，地址为： http://msdn2.microsoft.com/en-us/library/ms181281(VS.80).aspx
连续集成生成 z z z
如何自动运行连续集成 (CI) 生成 如何确定您是否需要滚动式生成 如何确定滚动式生成时间间隔
如何自动运行连续集成生成 尽管 Visual Studio 2005 Team Foundation Server 不提供开箱即用的连续集成 (CI) 解决方案，但它为 您提供实现自己的 CI 解决方案的框架。 设置 CI 生成解决方案 1. 2. 3.
创建并测试您的生成。确保团队生成类型适当并且您可以运行它，而不会发生错误。 安装连续集成加载项。从 http://msdn2.microsoft.com/en-us/library/ms364045(VS.80).aspx 中安装 CI 加载项。 配置连续集成加载项。确保 CI Web 应用程序虚拟根在 TFSAppPool 应用程序池中运行。通 过添加以下项来更新 CI Web 应用程序 Web.config 文件，以便它适合您的团队服务器和团队 生成： <add key="1" value="TeamServer=http://TFSRTM:8080;TeamProjectName=AdventureWorks;BuildType=Test Build"/>
4.
5. 6.
注册 CheckinEvent 事件。通过使用以下命令行，使用 BisSubscribe.exe 工具注册签入事件： Bissubscribe /eventType CheckinEvent /address http://TFSRTM:8080/ci/notify.asmx /deliveryType Soap /domain http://TFSRTM:8080 测试 CI 生成。通过完成签入来测试生成。等待几分钟以便生成完成，然后查看生成页，看生 成是否成功完成。 设置电子邮件警报。设置警报，以便当生成完成时通知有关各方。从团队项目上下文菜单中， 打开“项目警报”对话框，然后选中“生成完成警报”复选框。
有关详细信息以及扩展的步骤，请参见本指南中的“如何：使用 Visual Studio Team Foundation Server 设置连续集成生成”。
其他资源 z z z
z z
有关详细信息，请参见本指南中的“第 8 章 – 使用 Team Build 设置连续集成生成”。 有关设置 CI 生成的详细信息，请参见本指南中的“如何：使用 Visual Studio Team Foundation Server 设置预定生成”。 有关如何使用 Visual Studio Team System CI 解决方案的详细信息，请参见“使用 Team Foundation Build 的连续集成”，地址为： http://msdn2.microsoft.com/en-us/library/ms364045(VS.80).aspx 要下载 Visual Studio Team System CI 解决方案 MSI，请访问： http://download.microsoft.com/download/6/5/e/65e300ce-22fc-4988-97de-0e81d3de2482/ci.msi 有关 TFS 中的敏捷开发和 CI 的详细信息，请参见“扩展 Team Foundation Server 来实现连续 集成”，地址为：http://msdn.microsoft.com/msdnmag/issues/06/03/TeamSystem/default.aspx
如何确定您是否需要滚动式生成 每次签入之后立即生成是最简单的 CI 战略，通常为您提供最快速的反馈。然而，如果签入的速度 足够快，拥塞生成服务器，则应使用滚动式生成方法，在指定签入次数或指定时间段后生成。要弄 清是否需要使用滚动式生成，先确定以下几个方面： z z z
以分钟计算的团队生成长度 以分钟计算的平均签入频率 确定签入发生频率的时间窗口
如果生成的长度大于签入的平均频率，生成将连续运行，因为第一个生成要等到下一次签入发生时 才会完成，而这次签入又会启动另一次生成。如果在每个生成完成之前继续签入，这会影响生成服 务器的性能，并且将阻止启动其他生成（如预定生成）。查看签入发生频率的时间窗口并确定 CI 生
成是否会影响预定生成的发送以及是否影响其他重要的团队生成。
其他资源 z
有关详细信息，请参见本指南中的“第 8 章 – 使用 Team Build 设置连续集成生成”。
如何确定滚动式生成时间间隔 确定滚动式生成时间间隔对于确保有效的生成过程至关重要。您将希望及时生成，同时不会使生成 过程过载。 要确定理想的滚动式生成时间间隔，用生成的长度除以签入的平均频率。例如，如果您拥有一个需 要 10 分钟的生成，并且您平均每 5 分钟签入一次，则应该设置签入时间间隔为两次签入，超时期 限为 10 分钟。这样有助于确保完成此生成之后，再开始下一个生成。如果您注意到生成服务器上 的负载过多，则可以增加这些值。
其他资源 z
有关详细信息，请参见本指南中的“第 8 章 – 使用 Team Build 设置连续集成生成”。
自定义 z z z z
如何修改生成号 如何设置工作区映射来获取和生成该树的子集 如何生成在其他团队项目中具有依赖项的项目。 如何更改生成配置（发布/调试）
如何修改生成号 要在编译的程序集中自定义生成号，您需要生成一个替换生成号，然后将其写入到 assemblyinfo 源 文件中。 要自定义显示在团队生成界面中的生成号属性，您需要重写 BuildNumberOverride 目录中的 $(BuildNumber) 属性。
要在程序集以及团队生成界面中自定义生成号 1. 2.
重写 BuildNumberOverride 目标中的 $(BuildNumber)。 重写 BeforeCompile 目标以编写 AssemblyInfo.cs 或 .vb 文件。
示例 <Target Name="BuildNumberOverrideTarget"> <Message Importance="High" Text="$(BuildNumber)" />
<ConvertTFSBuildNumberToSolutionBuildNumber MajorAndMinorVersion="1.0" TFSBuildNumber="$(BuildNumber)" TFSLastBuildNumber="$(LastBuildNumber)"> <Output TaskParameter="SolutionBuildNumber" PropertyName="SolutionBuildNumber" /> <Output TaskParameter="TFSBuildNumber" PropertyName="BuildNumber" /> </ConvertTFSBuildNumberToSolutionBuildNumber> <Message Importance="High" Text="$(SolutionBuildNumber)" /> <Message Importance="High" Text="$(BuildNumber)" /> </Target>
<Target Name="BeforeCompile"> <Message Importance="High" Text="$(SolutionBuildNumber)" /> <CreateItem Include="$(SolutionRoot)\**\AssemblyInfo.cs"> <Output TaskParameter="Include" ItemName="AssemblyInfoFiles"/> </CreateItem> <CreateItem Include="$(SolutionRoot)\**\AssemblyInfo.vb"> <Output TaskParameter="Include" ItemName="AssemblyInfoFiles"/> </CreateItem> <RewriteFileVersions AssemblyInfoFiles="@(AssemblyInfoFiles)" AssemblyVersionNumber="$(SolutionBuildNumber)" AssemblyFileVersionNumber="$(SolutionBuildNumber)" AssemblyInformationalVersionNumber="$(SolutionBuildNumber)" /> </Target>
其他资源 z
z
z
有关修改程序集版本控制的其他方法，请参见 Aaron Halberg 的博客帖子“Team Build 和 AssemblyInfo 任务”，地址为： http://blogs.msdn.com/aaronhallberg/archive/2007/06/08/team-build-and-the-assemblyinfo-task.aspx 在上面的博客帖子中引用的 AssemblyInfo 任务现在位于 GotDotNet 上。您可以在 http://www.gotdotnet.com/Community/UserSamples/Details.aspx?SampleGuid=5C455590-332C-433 B-A648-E368B9515580 上找到它 有关自定义 Team Foundation Build 的详细信息，请参见“自定义 Team Foundation Build”，地 址为：http://msdn2.microsoft.com/en-us/library/ms400688(VS.80).aspx
如何设置工作区映射来获取和生成该树的子集 工作区映射文件定义生成服务器检索的源代码管理文件夹。执行生成并不总是需要签出所有文件。 您可以更改工作区定义以减少包含的文件夹数量，或者可以掩蔽不需要的文件，以便它们不会作为 生成的一部分被检索到。 例如，新项目的默认映射是 $/TeamProject。如果所有源文件都位于 $/TeamProject/foo/bar/foobar/sources 下，则应该只映射该目录 掩蔽文件和文件夹 1. 2. 3.
从源代码管理签出 WorkspaceMapping.xml。 为该文件添加恰当的掩蔽项。 签入 WorkspaceMapping.xml。
WorkspaceMapping.xml 文件将如下所示： <Mappings> <InternalMapping ServerItem="$/MyTeamProject" LocalItem="c:\projects\teamproject” Type="Map" /> <InternalMapping ServerItem="$/MyTeamProject/documentation" Type="Cloak" /> </Mappings>
其他资源 z z
有关掩蔽工作区中的文件夹的详细信息，请参见“如何：掩蔽或取消掩蔽工作区中的文件夹”， 地址为：http://msdn2.microsoft.com/en-us/library/ms181378(VS.80).aspx 有关使 Team Build 忽略文件夹的详细信息，请参见“如何使‘Team Build’跳过获取特定文件
z
夹？”，地址为：http://blogs.msdn.com/manishagarwal/archive/2005/10/13/480584.aspx 有关 WorkspaceMapping 体系结构的详细信息，请参见“WorkspaceMapping.xml 文件的体系结 构”，地址为： http://blogs.msdn.com/buckh/archive/2007/02/28/schema-for-the-workspacemapping-xml-file.aspx
如何生成在其他团队项目中具有依赖项的项目 Team Build 不支持跨团队项目的生成解决方案。要支持该功能，必须自定义 TFSBuild.proj 文件以 从生成所依赖的其他项目中签出所需的代码。 要生成一个对其他团队项目有依赖项的项目，您需要将该项目中的源或程序集放置到生成服务器的 工作区中。要执行该操作，需要编辑 TFSBuild.proj 文件以添加程序集或解决方案引用，并重写 BeforeGet 事件以从具有依赖项的每个团队项目中获得程序集或源。 要生成在其他团队项目上具有依赖项的项目 1. 2.
从“源代码管理资源管理器”签出 TFSBuild.proj 脚本。 在 PropertyGroup 部分下添加以下配置设置： <!-- to be added under PropertyGroup --> <TfCommand>$(TeamBuildRefPath)\..\tf.exe</TfCommand> <SkipInitializeWorkspace>true</SkipInitializeWorkspace> SkipInitializeWorkSpace 允许您跳过对在生成机器上删除和重新创建工作区的默认任务的调用。 新属性用在自定义的目标 BeforeGet 中（见下文）。
3.
将以下配置设置添加到映射团队项目和解决方案的 ItemGroup 项中。确保为生成机器提供了正 确的本地路径。多个映射无法共享相同的本地文件夹，将会在 CreateWorkspace 任务中导致 MappingConflictException 异常。 <ItemGroup> <!-- add one entry for every solution you reference --> <SolutionToBuild Include="$(SolutionRoot)\DependentApp\DependentApp.sln" /> <SolutionToBuild Include="$(SolutionRoot)\YourApp\YourApp.sln" /> </ItemGroup> <ItemGroup> <!-- add one entry for every Team Project you reference --> <Map Include="$/YourApp/YourApp"> <LocalPath>$(SolutionRoot)\YourApp</LocalPath> </Map> <Map Include="$/DependentApp/DependentApp"> <LocalPath>$(SolutionRoot)\DependentApp</LocalPath> </Map> </ItemGroup>
4.
重写 BeforeGet 事件，检索各团队项目的工作区。 <Target Name="BeforeGet"> <DeleteWorkspaceTask TeamFoundationServerUrl="$(TeamFoundationServerUrl)" Name="$(WorkspaceName)" /> <Exec WorkingDirectory="$(SolutionRoot)" Command="&quot;$(TfCommand)&quot; workspace /new $(WorkSpaceName) /server:$(TeamFoundationServerUrl)"/> <Exec WorkingDirectory="$(SolutionRoot)"
Command="&quot;$(TfCommand)&quot; workfold /unmap /workspace:$(WorkSpaceName) &quot;$(SolutionRoot)&quot;"/> <Exec WorkingDirectory="$(SolutionRoot)" Command="&quot;$(TfCommand)&quot; workfold /map /workspace:$(WorkSpaceName) /server:$(TeamFoundationServerUrl) &quot;%(Map.Identity)&quot; &quot;%(Map.LocalPath)&quot;"/> </Target>
5.
签入生成脚本，并运行生成。
其他资源 z
有关详细信息，请参见 Manish Agarwal 的博客条目“在团队生成中处理多个团队项目”，地址 为：http://blogs.msdn.com/manishagarwal/archive/2005/12/22/506635.aspx
如何更改生成配置（发布/调试） 要更改现有生成中的配置，需要修改 TFSBuild.proj 中的 <ConfigurationToBuild> 标记。 更改生成配置 1. 2. 3. 4. 5. 6. 7. 8.
打开“源代码管理资源管理器”。 在“源代码管理资源管理器”中，展开您的团队项目文件夹。 展开 TeamBuildTypes 文件夹。 选择您希望为其进行代码分析的团队生成文件夹。 从源代码管理签出 TFSBuild.proj 文件。可能首先需要对该文件夹执行 Get Latest Version 操 作。 在“源代码管理资源管理器”中，双击 TFSBuild.Proj 来打开它。 将 <ConfigurationToBuild> 标记修改为新的生成配置。 保存 TFSBuild.proj，将其重新签入源代码管理。
其他资源 z
有关自定义 Team Foundation Build 的详细信息，请参见“自定义 Team Foundation Build”，地 址为：http://msdn2.microsoft.com/en-us/library/ms400688(VS.80).aspx
部署 z z
如何设置生成服务器 如何确定您是否需要多个生成服务器
如何设置生成服务器 独立于 TFS 的安装来安装生成服务器。由于生成服务器需要能够编译代码、运行测试并执行代码 分析，因此必须安装生成过程所需的所有工具。 要设置生成服务器 1.
安装 Visual Studio。 z 如果您想确保具有任何生成方案所需的所有工具，请安装整个 Team Suite。 z 如果您想运行 Team Build，但不需要运行测试用例，请安装 Visual Studio Team Developer Edition。 z 如果您想运行自动测试用例作为生成过程的一部分，请安装 Visual Studio Team Test Edition。
2. 3.
在 Team Foundation Server DVD 上，打开 \build 文件夹。 运行“安装”向导。
用来运行生成服务器的帐户： z 必须对 TFS 计算机具有“本地登录”权限。 z 不应该是 TFS 计算机上的本地管理员帐户。 z 对域上的 Microsoft Active Directory® 应该标记“帐户区分大小写并且无法委派”。
其他资源 z
您可以从 http://www.microsoft.com/downloads/details.aspx?familyid=e54bf6ff-026b-43a4-ade4-a690388f310e &displaylang=en 下载 Team Foundation Server 安装指南。
如何确定您是否需要多个生成服务器 如果您拥有多个生成类型，而所有这些类型都在一个生成服务器上执行，则生成服务器可能会过载。 如果发生这种情况，应该考虑在不同的生成服务器上执行不同的生成类型。 一个生成可能要花很长时间执行，尤其在此生成是针对大型项目时更是如此。如果您使用连续集成 或时常发生的预定生成，则生成服务器可能无法跟上生成的生成数量。您可以安装多个生成服务器， 以分发负载。为每个服务器分配不同的生成类型以使生成负载比较平均。
概述 z z z z z z z z z z z z z z z
如何使用 Team Build 生成设置和部署 ASP.NET 应用程序 如何使用 Team Build 生成 .NET 1.1 应用程序 如何使用 Team Build 生成设置和部署项目 如何创建团队生成 如何创建多种生成类型 如何为一个引用了其他项目中程序集的项目创建团队生成 如何订阅生成的 e-mail 事件 如何在生成失败时接收通知 如何启动一次生成 如何验证生成是否成功 如何查看生成输出 如果更改生成服务器位置 如何更改生成输出位置 如何确定哪个变更集是生成的一部分 如何更改报告的生成质量
如何使用 Team Build 生成设置和部署 ASP.NET 应用程序 如果您想生成一个仅包含 ASP.NET Web 应用程序的解决方案，则必须确保选择适当的配置。创建 生成类型、选择配置和平台时，确保将平台设置为 .NET 并且确保“配置”设置为“调试”： 要生成一个仅包含 ASP.NET Web 应用程序项目的解决方案 1. 2. 3. 4. 5.
运行“新团队项目生成类型创建向导”。 为生成设定名称。 选择仅包含 ASP.NET Web 应用程序的解决方案。 选择恰当的配置。 单击“平台”下拉列表，然后选择 .NET 作为平台。
6. 7. 8.
指定该生成类型的位置信息。 选择测试和代码分析规则，以便运行。 选择“完成”保存生成类型。
如果您生成一个既包含 ASP.NET Web 应用程序也包含其他 .NET 项目的解决方案，则必须将平台 类型设置为“混合平台”。 要生成一个既包含 ASP.NET Web 应用程序也包含其他 .NET 项目的解决方案 1. 2. 3. 4. 5. 6. 7. 8.
运行“新团队项目生成类型创建向导”。 为生成设定名称。 选择仅包含 ASP.NET Web 应用程序和其他项目的解决方案。 选择恰当的配置。 单击“平台”下拉列表，然后选择“混合”作为平台。 指定该生成类型的位置信息。 选择测试和代码分析规则，以便运行。 选择“完成”保存生成类型。
您将发现位于 {BuildType}\{Configuration Name}\{Platform}\_PublishedWebsites 下的目标位置中的 已编译二进制文件。 Team Build 天生不支持将 Web 应用程序部署到 Internet Information Services (IIS)。如果您想将应用 程序作为团队生成的一部分部署到 IIS，则您有两个选择：您可以：向生成类型中添加自定义步骤， 或者可以使用“Web 部署项目”。 如果您刚刚开始团队项目，请检查“Web 部署项目”选项，以查看您是否可以在开发中使用该选项。 如果您已经有现有网站，则使用“Web 部署项目”可能会干扰应用程序开发。因此，考虑使用 MSBuild 生成后步骤。在这两种情况下，必须确保用于运行生成的服务帐户是本地管理员组的成员才能允许 其在 IIS 中创建一个虚拟目录。 要使用生成后步骤部署 Web 应用程序 1. 2. 3. 4. 5.
从 http://www.codeplex.com/sdctasks 上的 Codeplex 中下载 SDC 任务库 签出将用于部署 Web 应用程序的团队生成类型。 从下载的 zip 文件中将文件 Microsoft.Sdc.Tasks.dll 解压缩到签出生成类型的文件夹中。 将 DLL 添加到源代码管理中并将其签入。 修正 TFSBuild.proj 文件以便生成将文件复制到正确的目录中，然后按照如下方式将该目录创 建为虚拟目录： a. 添加指定已编译 Web 应用程序的位置的 <PropertyGroup> 元素： <PropertyGroup> <WebBinariesLocation>$(SolutionRoot)\..\Binaries\.NET\Release\_PublishedWebSites\MyWeb Site</WebBinariesLocation> </PropertyGroup>
添加向 CreateVirtualDirectory 和 DeleteVirtualDirectory 任务中添加引用的两个 UsingTask 元素： <UsingTask TaskName="Microsoft.Sdc.Tasks.Web.WebSite.CreateVirtualDirectory" AssemblyFile="Microsoft.Sdc.Tasks.dll" /> <UsingTask TaskName="Microsoft.Sdc.Tasks.Web.WebSite.CreateVirtualDirectory" AssemblyFile="Microsoft.Sdc.Tasks.dll" /> b.
c. 添加 AfterCompile 目标以创建虚拟目录并将文件复制到该目录中： <Target Name="AfterCompile">
<MakeDir Directories="C:\Deploy\MyWebsite" /> <CreateVirtualDirectory VirtualDirectoryName="MyWebSite" Path="C:\Deploy\Website" /> <DeleteVirtualDirectory VirtualDirectoryName="MyWebSite" /> <Exec Command="xcopy / ye $(WebBinariesLocation) C:\Deploy\MyWebsite"/> </Target>
6.
保存该文件并将其提交到源代码管理储存库。
如果您运行团队生成，那么现在将生成 Web 应用程序、创建虚拟目录、将 Web 应用程序复制到 该目录。 要使用 Web 部署项目 1. 2. 3. 4. 5. 6. 7. 8. 9. 10.
下载并将 Visual Studio 2005 Web 部署项目安装到您的客户端计算机上。 下载并将 Visual Studio 2005 Web 部署项目安装到您的生成服务器上。 打开包含 Web 应用程序的解决方案。 单击“生成”菜单，然后选择“添加 Web 部署项目…” 指定部署项目的名称和位置。 在“解决方案资源管理器”中，右击“Web 部署项目”然后选择“属性页”。 在对话框中，选择团队生成应该生成（调试或发布）的“配置”。 在“部署”部分中，选中“为输出文件夹创建 IIS 虚拟目录”复选项，然后指定虚拟目录名称。 单击“确定”。 将解决方案更改签入到源代码管理中。
如果您运行包含该解决方案的团队生成，则将生成 Web 应用程序并在生成此 Web 应用程序的目 录中创建一个虚拟目录。这将为生成目录}\{团队项目名称}\{生成类型}\Binaries\{配置名称}\{平 台}\_PublishedWebSite\{Web 部署项目名称。
其他资源 z z
z z
要下载 SDC 任务，请访问 http://www.codeplex.com/sdctasks 有关使用 Team Build 生成 ASP.NET 应用程序的详细信息，请参见“TN_1600：使用 Team Build 生成 ASP.NET 应用程序”，地址为： http://msdn2.microsoft.com/en-us/teamsystem/aa718894.aspx 有关使用“Web 部署项目“的详细信息，请参见”TN_1601：Team Build 和 Web 部署项目”， 地址为：http://msdn2.microsoft.com/en-us/teamsystem/aa718895.aspx 有关生成 Web 部署项目的详细信息，请参见“Visual Studio 2005 Web 部署项目”，地址为： http://msdn2.microsoft.com/en-us/asp.net/aa336619.aspx
如何使用 Team Build 生成 .NET 1.1 应用程序 由于 MSBuild 不直接支持 .NET 1.1，因此 Team Build 也不支持 .NET 1.1。Microsoft 已经在支持 生成 .NET 1.1 应用程序的名为 MSBuild Extras (MSBee) 的 CodePlex 上发布了一个项目。 要生成 .NET 1.1 应用程序，您需要将您的项目文件升级到 .NET 2.0 项目文件。还需要编辑 Team Build 项目文件，以便它使用 .NET 1.1 工具而不是 .NET 2.0 工具生成。 要使用 Team Build 生成 .NET 1.1 应用程序 1. 2. 3.
将 .NET 1.1 解决方案升级到 .NET 2.0。您可以通过在 Visual Studio 2005 中打开解决方案，然 后运行转换向导，或者通过运行 devenv [projectname] /upgrade 来执行该操作 确保您的生成服务器上已安装 .NET 1.1 Software Development Kit (SDK)。 从 http://www.codeplex.com/MSBee 下载并安装 MSBuild Extras
4. 5. 6. 7.
从 http://blogs.msdn.com/gautamg/attachment/578915.ashx 下载 BuildingFx11inTB.targets 从将生成 .NET 1.1 项目的源代码管理中签出生成类型。 将 BuildingFx11inTB.targets 复制到包含生成类型的目录中，并将该文件签入到源代码管理中。 编辑 TFSBuild.proj 文件： a.
b.
导入 BuildingFx11inTB.targets 文件： <Import Project="$(MSBuildProjectDirectory)\BuildingFx11inTB.targets" /> 添加一个定义 CSharp 目标的属性： <PropertyGroup> <AdditionalPropertiesForBuildTarget>CustomAfterMicrosoftCommonTargets=$(ProgramFiles) \MSBuild\MSBee\MSBuildExtras.Fx1_1.CSharp.targets</AdditionalPropertiesForBuildTarget> </PropertyGroup>
8.
将 TFSBuild.proj 签入源代码管理。
其他资源 z z
有关 MSBuild Extras 的详细信息，请参见“MSBuild Extras - Toolkit for .NET 1.1 "MSBee”， 地址为：http://www.codeplex.com/MSBee 有关使用 MSBuild Extras 生成 .NET 1.1 应用程序的详细信息，请参见“使用 Team Build 生 成 .NET 1.1 应用程序”，地址为：http://blogs.msdn.com/gautamg/archive/2006/04/19/578915.aspx
如何使用 Team Build 生成设置和部署项目 Team Build 默认情况下不支持设置项目。使用自定义的生成后步骤编译设置项目，并按照如下方式 将二进制文件复制到生成目标位置。 1. 测试生成。 确保您要用于设置项目的 Team Build 正常工作。如果没有正常工作，请修复它，然后继续。 提示：大多数生成包括主要项目生成以及设置生成。如果您仅为设置项目创建一个新的团队生成， 请执行该操作，然后移动到第 2 步。 2. 确保默认情况下生成设置项目。 1. 在“解决方案资源管理器”中，右击您需要创建团队生成的安装程序项目。 2. 单击“属性”。 3. 单击“配置管理器...” 4. 选择您要生成的生成配置，例如，调试、发布。 5. 选中用于安装程序项目的“生成”复选框。 3. 确保项目文件中的所有生成路径都是相对路径。 1. 打开安装程序项目的解决方案文件夹。 2. 在编辑器中而不是在 Visual Studio 中打开 .vdproj 文件。 3. 签出 .vdproj 文件以便进行编辑。 4. 搜索以下条目之一：SccLocalPath、SccAuxPath、OutputFileName 和 SourcePath。 5. 确保每个条目的目录都是相对路径，而不是绝对路径。（当创建设置项目时，这是默认设 置。）绝对路径从驱动器号开始。项目路径从正斜线 (‘\\’) 开始或者什么都没有。 6. 如果您发现绝对路径，请将其更换为相对路径。不要修改任何常量表达式。这些之后由安 装程序进行扩展，例如：
"OutputFileName" = "8:c:\\temp\\SetupProject.msi" 将被替换为 "OutputFileName" = "8:debug\\SetupProject.msi" 提示：相对路径将直接位于项目文件夹中。
7.
提示：当创建路径时，始终使用正斜线 ( '\\' )，因为它将通过代码解码为一个正斜线 ( '\' )。 如果您必须进行更改，请反向签入 .vdproj 文件。
4. 向您的团队生成中添加编译后任务。 打开您要用于设置项目的团队生成。 从源代码管理签出此生成类型。 a. 您会发现此生成类型位于源代码管理中的团队项目下名为 TFSBuild.proj 的 TeamBuildTypes 文件夹的子文件夹中。 b. 可能首先需要对该文件夹执行 Get Latest Version 操作。 3. 在“源代码管理资源管理器”中，双击 TFSBuild.Proj 来打开它。 注意：从“团队资源管理器”中查看生成类型将不能正常工作，因为这将打开生成文件的 一个只读副本。 4. 向文件结尾最后一个 </ItemGroup> 标记和最后一个 </Project> 标记之间添加以下代 码： <Target Name="AfterCompile"> <Exec Command="&quot;C:\Program Files\Microsoft Visual Studio 8\Common7\IDE\devenv&quot; &quot;C:\Documents and Settings\darren\My Documents\Visual Studio 2005\Projects\HelloWorldTest\HelloWorldTestInstaller\HelloWorldTestInstaller.vdproj &quot; /Build &quot;Debug&quot;"/> <Copy SourceFiles="C:\Documents and Settings\darren\My Documents\Visual Studio 2005\Projects\HelloWorldTest\HelloWorldTestInstaller\Debug\HelloWorldTestInstaller. msi" DestinationFolder="$(OutDir)" /> <Copy SourceFiles="C:\Documents and Settings\darren\My Documents\Visual Studio 2005\Projects\HelloWorldTest\HelloWorldTestInstaller\Debug\setup.exe" DestinationFolder="$(OutDir)" /> </Target> 5. 检查过去代码中的路径，以确保它们适合您的生成服务器。 提示：使用命令行测试 exec 命令标记中的路径。当在命令行上测试时将每个 &quot; 替换 为引号，例如： 1. 2.
"C:\Program Files\Microsoft Visual Studio 8\Common7\IDE\devenv" "C:\Documents and Settings\darren\My Documents\Visual Studio 2005\Projects\HelloWorldTest\HelloWorldTestInstaller\HelloWorldTestInstaller.vdproj" /Build "Debug"
提示：也使用命令行测试 SourceFiles 路径。 5. 测试生成更改。 1. 2. 3.
在“团队资源管理器”中，右击生成类型，然后单击“生成团队项目”。 查看生成摘要，以确定生成是通过还是失败。 如果生成失败，则创建到生成日志的链接。失败的常见原因包括： a. Exec 命令路径不正确。 b. 权限未设置为允许将输出文件复制到生成目录。确保 tfsservice 用户帐户具有从二进制 文件夹复制以及复制到生成文件夹的权限。二进制文件夹是在生成解决方案之后放置 msi 文件的位置。生成文件夹是在 <BuildDirectoryPath> 标记中的 tfs.proj 中指定的。
权限未设置为允许生成安装程序。确保 tfsserver 用户帐户具有读取 .vdproj 文件和安 装程序项目的源文件以及与安装程序关联的应用程序的权限。还要确保 tfsserver 用户 帐户具有向输出目录中写入二进制文件的权限，例如，调试或发布。 d. 生成配置不正确。确保使用 exec 命令为项目指定的生成配置存在。例如，您的项目可 能具有“调试|任何 CPU”，而不是“调试”。您可以通过在“解决方案资源管理器” 中查看解决方案属性来检查该项。 4. 如果生成日志没有为您提供足够的信息，请为 exec 命令创建一个输出文件并查看该日志 以获得详细信息。例如： c.
<Exec Command="&quot;C:\Program Files\Microsoft Visual Studio 8\Common7\IDE\devenv&quot; &quot;C:\Documents and Settings\darren\My Documents\Visual Studio 2005\Projects\HelloWorldTest\HelloWorldTestInstaller\HelloWorldTestInstaller.vdproj&quot; /Build &quot;Debug&quot; > c:\temp\output.txt"/>
其他资源 z
有关详细信息，请参见“演练：配置 Team Foundation Build 以生成 Visual Studio 设置项目”， 地址为：http://msdn2.microsoft.com/en-us/library/ms404859(VS.80).aspx
如何创建团队生成 您可以在“团队资源管理器”中从 Team Builds 文件夹中创建一个新的团队生成。 要创建团队生成 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12.
打开“团队资源管理器”。 展开您希望为之创建生成的团队项目。 右击树中的 Team Builds 文件夹。 选择“新团队项目生成类型…” 为新团队生成类型指定名称，然后单击“下一步”。 选择希望生成的项目，应包括内含有单元测试的项目。 选择生成配置（例如，发布或调试），然后单击“下一步”。 指定生成服务器的名称，例如，TFSRTM 指定生成服务器上的本地生成目录，例如，c:\builds 指定生成输出的目标位置，例如，\\TFSRTM\NightlyBuilds，然后单击“下一步”。 单击“运行测试”复选框，选择希望与生成关联的测试列表，然后单击“下一步”。 单击“完成”即可创建新的团队生成类型。
如何创建多种生成类型 要创建多种生成类型，例如，用于客户的发布或用于测试团队的调试，请为您感兴趣的每种生成类 型使用单独的团队生成。 要创建团队生成 13. 14. 15. 16. 17. 18. 19. 20.
打开“团队资源管理器”。 展开您希望为之创建生成的团队项目。 右击树中的 Team Builds 文件夹。 选择“新团队项目生成类型…” 为新团队生成类型指定名称，然后单击“下一步”。 选择希望生成的项目，应包括内含有单元测试的项目。 选择生成配置（例如，发布或调试），然后单击“下一步”。 指定生成服务器的名称，例如，TFSRTM
21. 22. 23. 24.
指定生成服务器上的本地生成目录，例如，c:\builds 指定生成输出的目标位置，例如，\\TFSRTM\NightlyBuilds，然后单击“下一步”。 单击“运行测试”复选框，选择希望与生成关联的测试列表，然后单击“下一步”。 单击“完成”即可创建新的团队生成类型。
如何为一个引用了其他项目中程序集的项目创建团队生成 要生成一个对其他团队项目有依赖项的项目，您需要将该项目中的源或程序集放置到生成服务器的 工作区中。要执行该操作，需要编辑 TFSBuild.proj 文件以添加程序集或解决方案引用，并重写 BeforeGet 事件以从所需的每个团队项目中获得程序集或源。 要生成引用其他团队项目的程序集的项目 1. 2.
从“源代码管理资源管理器”签出 TFSBuild.proj 脚本。 在 PropertyGroup 部分下添加以下配置设置： <!-- to be added under PropertyGroup --> <TfCommand>$(TeamBuildRefPath)\..\tf.exe</TfCommand> <SkipInitializeWorkspace>true</SkipInitializeWorkspace>
3.
SkipInitializeWorkSpace 允许您跳过对在生成机器上删除和重新创建工作区的默认任务的调用。 新属性用在自定义的目标 BeforeGet 中（见下文）。 将以下配置设置添加到映射团队项目和解决方案的 ItemGroup 项中。确保为生成机器提供了正 确的本地路径。多个映射无法共享相同的本地文件夹，将会在 CreateWorkspace 任务中导致 MappingConflictException 异常。
<ItemGroup> <!-- add one entry for every solution you reference --> <SolutionToBuild Include="$(SolutionRoot)\DependentApp\DependentApp.sln" /> <SolutionToBuild Include="$(SolutionRoot)\YourApp\YourApp.sln" /> </ItemGroup> <ItemGroup> <!-- add one entry for every Team Project you reference --> <Map Include="$/YourApp/YourApp"> <LocalPath>$(SolutionRoot)\YourApp</LocalPath> </Map> <Map Include="$/DependentApp/DependentApp"> <LocalPath>$(SolutionRoot)\DependentApp</LocalPath> </Map> </ItemGroup>
4.
重写 BeforeGet 事件，检索各团队项目的工作区。 <Target Name="BeforeGet"> <DeleteWorkspaceTask TeamFoundationServerUrl="$(TeamFoundationServerUrl)" Name="$(WorkspaceName)" /> <Exec WorkingDirectory="$(SolutionRoot)" Command="&quot;$(TfCommand)&quot; workspace /new $(WorkSpaceName) /server:$(TeamFoundationServerUrl)"/> <Exec WorkingDirectory="$(SolutionRoot)" Command="&quot;$(TfCommand)&quot; workfold /unmap /workspace:$(WorkSpaceName) &quot;$(SolutionRoot)&quot;"/> <Exec
WorkingDirectory="$(SolutionRoot)" Command="&quot;$(TfCommand)&quot; workfold /map /workspace:$(WorkSpaceName) /server:$(TeamFoundationServerUrl) &quot;%(Map.Identity)&quot; &quot; %(Map.LocalPath)&quot;"/> </Target>
5.
签入生成脚本，并运行生成。
其他资源 z
有关详细信息，请参见“在团队生成中处理多个团队项目”，地址为： http://blogs.msdn.com/manishagarwal/archive/2005/12/22/506635.aspx
如何订阅生成的 e-mail 事件 可以创建一个新的项目警报，以便订阅生成的 e-mail 事件。 设置生成电子邮件警报 1. 2. 3.
在“团队资源管理器”中右击相关的团队项目。 选择“项目警报”。 选择您喜欢接收的每个警报选项，并输入一个电子邮件地址以便进行通知。
其他资源 z
有关项目警报的详细信息，请参见“设置警报”，地址为： http://msdn2.microsoft.com/en-us/library/ms181334(VS.80).aspx
如何在生成失败时接收通知 您可以创建一个新的具有筛选器的项目警报，以仅在生成失败时接收电子邮件。 要创建一个在生成失败时通知您的项目警报 1. 2.
创建并测试您的生成。确保团队生成类型适当并且您可以运行它，而不会发生错误。 注册 BuildCompletionEvent 事件。使用 BisSubscribe.exe 工具注册 BuildCompletionEvent 事件，并使用一个筛选器指明您只希望在生成失败时获得电子邮件通知，方法是使用以下命令 行语句： bissubscribe /eventType BuildCompletionEvent /address myemail@domain.com /deliveryType EmailPlaintext /server tfsserver1 /filter "TeamProject = 'MyTeamProject' AND CompletionStatus=‘Failed’“
3.
测试生成。通过签入无法编译的代码、执行生成并确保收到电子邮件通知来测试生成。
其他资源 z z
有关筛选生成完成事件的详细信息，请参见“如何筛选生成完成事件”，地址为： http://blogs.msdn.com/jpricket/archive/2006/09/05/how-to-filter-the-build-completion-event.aspx 有关 BuildCompletionEvent 筛选器的详细信息，请参见“非常有用的 BuildCompletionEvent 筛 选器”，地址为： http://blogs.msdn.com/jpricket/archive/2006/09/05/useful-buildcompletionevent-filters.aspx
如何启动生成 您可以在“团队资源管理器”中从 Team Builds 文件夹中启动生成类型。
要手动启动生成 1. 2. 3. 4. 5.
打开“团队资源管理器”。 展开您希望为之启动生成的团队项目。 展开树中的 Team Builds 文件夹。 右击您要启动的“团队生成”类型。 选择“生成团队项目”。
如何验证生成是否成功 您可以通过“团队资源管理器”从“生成”窗口检查生成状态。 要验证生成是否成功 1. 2. 3. 4.
打开“团队资源管理器”。 展开您希望查看结果的团队项目。 展开树中的 Team Builds 文件夹。 双击您要查看结果的团队生成类型。
如何查看生成输出 您可以通过“团队资源管理器”从“生成”窗口查看生成输出。 要查看生成输出 1. 2. 3. 4. 5. 6. 7.
打开“团队资源管理器”。 展开您希望查看生成输出的团队项目。 展开树中的 Team Builds 文件夹。 双击您要查看生成输出的团队生成类型。 双击您要查看输出的生成编号的团队生成结果条目。 如果您想查看生成输出文件夹，请单击“生成名称”链接。 如果想查看生成日志，请单击“日志”链接。
如何更改生成服务器位置 要更改现有的团队生成的生成服务器位置，请修改 TFSBuild.proj 中的 <BuildMachine> 标记。 要更改现有团队生成类型的生成服务器位置 1. 2. 3. 4. 5. 6. 7. 8.
打开“源代码管理资源管理器”。 在“源代码管理资源管理器”中，展开您的团队项目文件夹。 展开 TeamBuildTypes 文件夹。 选择您希望为其进行代码分析的团队生成文件夹。 从源代码管理签出 TFSBuild.proj 文件。可能首先需要对该文件夹执行 Get Latest Version 操 作。 在“源代码管理资源管理器”中，双击 TFSBuild.Proj 来打开它。 修改 <BuildMachine> 标记以指向新的服务器。 保存 TFSBuild.proj，将其重新签入源代码管理。
其他资源
z
有关自定义 Team Foundation Build 的详细信息，请参见“自定义 Team Foundation Build”，地 址为：http://msdn2.microsoft.com/en-us/library/ms400688(VS.80).aspx
如何更改生成输出位置 要更改现有团队生成的生成输出位置，请修改 TFSBuild.proj 中的 <DropLocation> 标记。 要更改现有团队生成类型的生成服务器位置 1. 2. 3. 4. 5. 6. 7. 8.
打开“源代码管理资源管理器”。 在“源代码管理资源管理器”中，展开您的团队项目文件夹。 展开 TeamBuildTypes 文件夹。 选择您希望为其进行代码分析的团队生成文件夹。 从源代码管理签出 TFSBuild.proj 文件。可能首先需要对该文件夹执行 Get Latest Version 操 作。 在“源代码管理资源管理器”中，双击 TFSBuild.Proj 来打开它。 修改 <DropLocation> 标记以指向新的位置。 保存 TFSBuild.proj，将其重新签入源代码管理。
其他资源 z
有关自定义 Team Foundation Build 的详细信息，请参见“自定义 Team Foundation Build”，地 址为：http://msdn2.microsoft.com/en-us/library/ms400688(VS.80).aspx
如何确定哪个变更集是生成的一部分 您可以通过“团队资源管理器”查看与“生成”窗口中每个生成关联的变更集。 要查看与生成关联的变更集 1. 2. 3. 4. 5. 6. 7.
打开“团队资源管理器”。 展开您希望查看变更集的团队项目。 展开树中的 Team Builds 文件夹。 双击您要查看变更集的团队生成类型。 双击您要查看变更集的生成编号的团队生成结果条目。 展开“关联的变更集”项目。 如果您想查看有关特殊变更集的详细信息，请单击 ID 链接。
如何更改报告的生成质量 您可以通过“团队资源管理器”从“生成”窗口更改生成质量。 要更改生成质量 1. 2. 3. 4. 5.
打开“团队资源管理器”。 展开您希望更改生成质量的团队项目。 展开树中的 Team Builds 文件夹。 双击您要更改生成质量的团队生成类型。 在“生成质量”下拉列表中，选择您要设置生成质量的生成，然后设置生成质量值。
项目 z
如何使用单解决方案战略
z z
如何使用分区解决方案战略 如何使用多解决方案战略
如何使用单解决方案战略 如果您在一个小型系统上工作，那么可考虑使用单独一个 Visual Studio 解决方案来包容所有项目。 这种战略能简化开发，因为在打开解决方案时，所有代码都是可用的。这种战略也简化了引用的设 置，原因在于所有引用都处于该解决方案内的项目之间。您可能仍然需要使用文件引用来引用您的 解决方案之外的第三方程序集（如购买的组件）。
其他资源 z
有关详细信息，请参见本指南的“第 3 章 – 在源代码管理中设计项目和解决方案的结构”。
如何使用分区解决方案战略 如果您在一个大型系统上工作，那么可考虑使用多个 Visual Studio 解决方案，每个方案代表应用程 序中的一个子系统。开发人员可以使用这些解决方案在较小的系统部分上工作，而不需要跨所有项 目加载所有代码。您应该设置您的解决方案结构，以便将具有依赖项的任何项目组合在一起。这使 您能够使用项目引用而非文件引用。如果您想使用它来生成整个应用程序，请考虑创建包含所有项 目的主解决方案文件。 使用多个解决方案时，应为所有项目采用平面文件结构。典型示例是具有 Microsoft Windows Forms 项目、ASP.NET 项目、Windows 服务以及由某些或所有这些项目共享的一组类库项目的应用程序。 可以为所有项目使用如下平面结构： z
/Source z /WinFormsProject z /WebProject z /WindowsServiceProject z /ClassLibrary1 z /ClassLibrary2 z /ClassLibrary3 z Web.sln z Service.sln z All.sln
通过保持结构为平面，您可以获得很大的灵活性并且能够使用解决方案提供项目的不同视图。围绕 解决方案文件设计物理文件夹结构很难更改，尤其当您认识到需要重用其他解决方案中的类库时更 是如此。 注意：如果您使用 Team Build（它依赖于 MSBuild）生成，则可以创建不包括所有引用的项目的解 决方案结构。只要首先已经生成了整个解决方案，并从每个解决方案中生成二进制输出，那么 MSBuild 将能够遵循超出您的解决方案范围之外的项目引用并成功生成。采用这种方法创建的解决 方案将不能从 Visual Studio 生成命令中生成，该方法只能使用与 Team Build 和 MSBuild。
其他资源 z
有关详细信息，请参见本指南的“第 3 章 – 在源代码管理中设计项目和解决方案的结构”。
如何使用多解决方案战略 如果您在非常大的解决方案（需要很多项目）上工作，则可能会与解决方案的伸缩性限制发生冲突。 在这种情况下，应该将您的应用程序分为多个解决方案，而不是为整个应用程序创建一个主解决方 案，因为每个解决方案内的所有引用都是项目引用。每个解决方案之外的项目的引用（例如，另一
个子解决方案中的第三方库或项目的引用）为文件引用。这就意味着，不存在任何“主”解决方案。 相反，必须使用了解生成解决方案顺序的脚本。与多解决方案结构相关联的维护任务之一就是确保 开发人员不会无意中在解决方案间创建循环引用。这种结构需要复杂的生成脚本，以及依赖项关系 的显式映射。在这种结构中，应用程序不可能完全在 Visual Studio 内生成。而应使用 TFS Team Build。
其他资源 z
有关详细信息，请参见本指南的“第 3 章 – 在源代码管理中设计项目和解决方案的结构”。
报告 z z z z z z z
如何查看生成质量 如何查看一个生成的所有签入 如何查看一个生成的已关闭工作项或 bug 如何查看一个生成的开放工作项或 bug 如何跟踪从生成到生成的速度 如何跟踪一个生成的测试用例的通过/失败结果 如何查看生成状态（BVT 结果）
如何查看生成质量 您可以通过“团队资源管理器”从“生成”窗口中查看生成质量。 查看生成质量 1. 2. 3. 4.
打开“团队资源管理器”。 展开您希望查看生成质量的团队项目。 展开树中的 Team Builds 文件夹。 双击团队生成类型以查看生成质量。
如果您使用 Microsoft Solutions Framework (MSF) for CMMI® Process Improvement (MSF CMMI) 过 程模板，则可以查看生成报告以便查看生成质量以及有关测试结果的其他信息、代码覆盖率以及代 码改动。 要在 MSF CMMI 中查看生成质量 1. 2. 3.
在 Team Explorer 中展开您的团队项目。 右击“报告”，然后单击“显示报告站点”。 在报告站点中，选择“生成报告”。
如何查看一个生成的所有签入 您可以通过“团队资源管理器”查看与“生成”窗口中每个生成关联的签入。 要查看与生成关联的签入 1. 2. 3. 4. 5. 6. 7.
打开“团队资源管理器”。 展开您希望查看生成的签入的团队项目。 展开树中的 Team Builds 文件夹。 双击要查看生成的签入的团队生成类型。 双击要查看生成的签入的团队生成结果条目。 展开“关联的变更集”项目以查看与该生成关联的所有签入 如果您想查看有关特殊变更集（其代表一个签入）的详细信息，请单击 ID 链接。
如何查看一个生成的已关闭工作项或 bug 您可以通过“团队资源管理器”查看“生成”窗口中每个生成已关闭的工作项和 bug。 要查看与生成关联的工作项 1. 2. 3. 4. 5. 6.
打开“团队资源管理器”。 展开您希望查看工作项的团队项目。 展开树中的 Team Builds 文件夹。 双击您要查看工作项的团队生成类型。 双击您要查看工作项的生成编号的团队生成结果条目。 展开“关联的工作项”项目。
如何查看一个生成的开放工作项或 bug 如果您使用 MSF CMMI 过程模板，则可以查看“开放的问题和阻塞的工作项趋势”报告以查看在 给定的时间内打开、解决以及关闭的工作项。但是，由于该报告按日期提供信息，而不是按生成提 供信息，因此您需要根据产生生成的日期，将结果转换为生成。 要看一个生成的开放工作项或 bug 1. 2. 3.
在 Team Explorer 中展开您的团队项目。 右击“报告”，然后“显示报告站点”。 在报告站点中，选择“开放的问题和阻塞的工作项趋势”报告。
如何跟踪从生成到生成的速度 您可以使用“速度”报告跟踪进度以及从生成到生成所完成工作项的速率。该报告可用于 SF CMMI 和MSF for Agile Software Development (MSF Agile)。 跟踪从生成到生成的速度 1. 2. 3.
在 Team Explorer 中展开您的团队项目。 右击“报告”，然后“显示报告站点”。 在报告站点中，选择“速度报告”。
如何跟踪一个生成的测试用例的通过/失败结果 您可以使用“质量指标”报告来跟踪给定时间内通过和失败的测试用例的数量。该报告按日期提供 信息，而不按生成提供信息。因此，您需要根据产生生成的日期将结果转换为生成。此报告可用于 MSF CMMI 和 MSF Agile。 要跟踪一个生成的测试用例的通过/失败 1. 2. 3.
在 Team Explorer 中展开您的团队项目。 右击“报告”，然后“显示报告站点”。 在报告站点中，选择“质量指标”报告。
如何查看生成状态（BVT 结果） 如果您使用 MSF CMMI 过程模板，则可以查看生成报告以便查看 BVT 结果。 要查看生成状态 1.
在“团队资源管理器中”中，展开您的团队项目节点。
2. 3.
右击“报告”，然后“显示报告站点”。 在报告站点中，选择“生成报告”。
预定生成 z z
如何自动运行每夜生成 如何决定项目的生成频率和类型
如何自动运行每夜生成 TFS 中的 Team Build 功能不支持通过用户界面设置预定生成。但您可以使用 Microsoft Windows Task Scheduler 运行 TFSBuild 命令工具以在预定的时间启动生成。 要创建预定生成 1.
创建如下 TFSBuild 命令行： TfsBuild start <<TeamFoundationServer>> <<TeamProject>> <<BuildTypeName>>
2. 3.
将该命令行放置在一个批处理文件中。 创建一个 Windows 任务计划，按照所需时间间隔运行这个批处理文件。
有关详细信息以及扩展的步骤，请参见本指南中的“如何：使用 Visual Studio Team Foundation Server 设置预定生成”。
其他资源 z
有关详细信息，请参见本指南中的“第 9 章 – 使用 Team Build 设置预定生成”。
如何决定项目的生成频率和类型 当创建预定生成时，生成频率是所要进行的最重要的决定之一。 如果您在有足够的签入从而在一个小时之内造成大量更改的项目上工作，并且不想使用连续集成 (CI) 生成，则可以选择每小时生成频率。每小时生成为开发人员提供快速反馈，而且测试人员以及 其他团队成员也可以使用它来请求他们的反馈。 如果您在有足够的签入从而在一天之内造成大量更改的项目上工作，则可以选择每天预定生成频率， 因为它每天早上可以合并前一天的更改为您的测试和开发团队提供新的生成，从而准备好进行测试。 如果您在生成时间可能持续很多天的复杂的大型项目上工作，则应该选择每周生成。这能确保您的 测试团队将在每周开始时具有一个合并上一周更改的生成，并且已准备好进行测试。
其他资源 z z
有关设置预定生成的详细信息，请参见本指南中的“如何：使用 Visual Studio Team Foundation Server 设置预定生成”。 有关详细信息，请参见本指南中的“第 9 章 – 使用 Team Build 设置预定生成”。
测试驱动的开发 z z z z
如何创建“hello world”验收测试 如何将自动测试作为生成的一部分运行 如何将代码分析作为生成的一部分运行 如何获得使生成失败的失败的测试
如何创建“hello world”验收测试 “hello world”验收测试一个简单的测试，您可以使用它来证明您可以创建单元测试并且可以使它们 与您的生成过程相结合。 要创建与生成关联的测试列表，必须安装 Visual Studio Test Edition 或 Visual Studio Team Suite。为 在生成服务器上运行自动测试，该生成服务器上必须安装有 Visual Studio Developer Edition、 Visual Studio Test Edition 或 Visual Studio Team Suite。 要创建“hello world”测试 在“测试”菜单上，单击“新建测试…” 单击“单元测试”，然后单击“确定”。 为您的测试项目输入名称，然后单击“创建”。 编译新的项目。 将该项目签入源代码管理。 在 Visual Studio 中打开单元测试解决方案的情况下，在“测试”菜单上，单击“创建新的测试 列表...” 7. 在“创建新的测试列表”对话框中指定测试列表的名称，然后单击“确定”。 8. 在“测试管理器”中，单击“所有加载的测试”节点。 9. 将可用测试中的测试拖放到树中的测试列表节点中。 10. 将修改的单元测试项目 VSMDI 文件签入源代码管理中。 1. 2. 3. 4. 5. 6.
当您创建一个新的团队生成时，您创建的测试列表可用，并且可以作为生成过程的一部分自动运行。
其他资源 z z
有关自动运行版本验证测试 (BVT) 的详细信息，请参见“如何：配置和运行生成验证测试 (BVT)”，地址为：http://msdn2.microsoft.com/en-us/library/ms182465(VS.80).aspx 有关如何在没有 Visual Studio Test Edition 或 VSMDI 文件的条件下运行自动生成测试的 详细信息，请参见“如何在没有测试元数据文件和测试列表（.vsmdi 文件）的生成中运行 测试”，地址为： http://blogs.msdn.com/buckh/archive/2006/11/04/how-to-run-tests-without-test-metadata-files-and-tes t-lists-vsmdi-files.aspx
如何将自动测试作为生成的一部分运行 您可以在每次生成之后运行自动测试以自动获得有关生成质量的反馈。要运行自动测试，生成服务 器上必须具有 Visual Studio Developer Edition 以及 Visual Studio Test Edition，或者可以安装整个 Team Suite。Developer Edition 对于运行生成来说是必需的，而 Test Edition 对于设置测试以及可以 运行的测试列表是必需的。. 要将自动测试作为过程的一部分运行 1. 2. 3. 4. 5. 6. 7.
创建您希望为该生成运行的一个或多个自动测试。 在“测试”菜单上，单击“创建新的测试列表…” 使用测试管理器将测试分组为新测试列表，方法是将测试视图中的测试拖放到测试管理器的测 试列表中。 创建一个新的团队生成类型。 选中该复选框来运行自动测试。 选择在其中创建测试和测试列表的测试项目 选中您希望运行的测试列表。
其他资源 z z
有关自动运行版本验证测试 (BVT) 的详细信息，请参见“如何：配置和运行生成验证测试 (BVT)”，地址为：http://msdn2.microsoft.com/en-us/library/ms182465(VS.80).aspx 有关如何在没有 Visual Studio Test Edition 或 VSMDI 文件的条件下运行自动生成测试的 详细信息，请参见“如何在没有测试元数据文件和测试列表（.vsmdi 文件）的生成中运行 测试”，地址为： http://blogs.msdn.com/buckh/archive/2006/11/04/how-to-run-tests-without-test-metadata-files-and-tes t-lists-vsmdi-files.aspx
如何将代码分析作为生成的一部分运行 要打开生成类型的代码分析，可以在创建新的团队生成类型时，选中“新团队项目生成类型创建向 导”中的“代码分析”复选框，也可以在创建生成类型之后，修改 TFSBuild.proj 文件。 要在 TFSBuild.proj 文件中启用代码分析 z z
如果您让所有项目都运行代码分析，则无论项目设置如何，请将 <RunCodeAnalysis> 标记更 改为 Always。 如果您想在每个项目上根据项目设置来运行代码分析，请将 <RunCodeAnalysis> 标记更改为 “默认值”。
其他资源 z z
有关作为生成的一部分的自动代码分析的详细信息，请参见本指南中的“如何：在 Visual Studio Team Foundation Server 中使用 Team Build 自动运行代码分析”。 有关代码分析工具的详细信息，请参见“代码分析工具使用准则”，地址为： http://msdn2.microsoft.com/en-us/library/ms182023(VS.80).aspx
如何获得使生成失败的失败的测试 生成由于编译错误失败时，会创建一个工作项来跟踪失败，该生成被标记为失败。然而，如果一次 自动测试失败，生成并不会失败。测试失败将转换成一个警告，生成继续。 您可能希望在关联的自动测试失败时使生成失败。还可能希望自动生成一个工作项来跟踪失败。 要在测试失败时使生成失败 1. 2. 3.
打开 Program Files\MSBuild\Microsoft\VisualStudio\v8.0\TeamBuild 中的 Microsoft.TeamFoundation.Build.targets 文件。 签出进行编辑并且打开希望在测试失败时失败的 Team Build Type 的 TFSBuild.proj 文件。 将 RunTestWithConfiguration 目标从 Microsoft.TeamFoundation.Build.targets 复制到 TFSBuild.proj 文件结尾，位于结尾的 </Project> 标记之前。
4. 将 ContinueOnError 属性从 true 更改为 false。 注意：将有两项测试工具任务。修改端对端任务，以便仅修改生成服务器上生成的 行为。当生成位于开发人员的桌面上时，使用桌面生成任务。 或者，如果您想在测试失败时，使所有团队生成类型都失败，则可以直接修改 Microsoft.TeamFoundation.Build.targets。此更改将修改所有团队生成类型的行为。 上面建议的解决方案实施起来非常简单，但不能保证继续为将来版本的 Visual Studio 工作。如果您 想实施一个在升级之后保证继续工作的解决方案，请参见 Aaron Hallberg 的博客条目“在 Team Build 中确定测试是否通过”，地址为： http://blogs.msdn.com/aaronhallberg/archive/2006/09/21/determining-whether-tests-passed-in-team-build.a
spx
其他资源 z z
有关设置生成以在测试失败时创建一个工作项的详细信息，请参见“在 TeamBuild 中创建测试 失败的工作项”，地址为：http://blogs.msdn.com/nagarajp/archive/2005/10/14/481290.aspx 有关在 Visual Studio 升级后必须继续工作的解决方案的详细信息，请参见“在 Team Build 中确定测试是否通过”，地址为： http://blogs.msdn.com/aaronhallberg/archive/2006/09/21/determining-whether-tests-passed-in-team-b uild.aspx
团队生成资源 z
有关 Team Foundation Build 的概述，请参见“Team Foundation Build 概述”，地址为： http://msdn2.microsoft.com/en-us/library/ms181710(vs.80).aspx
实践总览项目管理 索引 签入策略 z z z
如何设置签入策略来提高代码质量 如何设置签入策略来确保开发人员将工作项与签入相关联 如何设置签入策略来执行编码标准
项目管理 z z z z z z z z z z z z
如何使用 Microsoft Project 管理您的项目 如何使用 Microsoft Excel 管理您的项目 如何创建最小化过程模板 如何自定义过程模板 如何在过程模板内自定义工作项类型 如何自定义现有团队项目内的工作项类型 如何创建迭代 如何创建区域 如何添加签入事件通知 如何设置报告仪表板 如何在源代码管理储存库内创建文件夹 如何从 Team Foundation Server 中删除项目
签入策略 z z z
如何设置签入策略来提高代码质量 如何设置签入策略来确保开发人员将工作项与签入相关联 如何设置签入策略来执行编码标准
如何设置签入策略来提高代码质量 将代码分析与测试策略相结合，来实施代码质量的标准。例如，使用 VSTS 所提供的开箱即用的测 试策略来确保指定测试预先执行并已通过，之后再允许源代码签入 Microsoft® Visual Studio® 2005 Team Foundation Server (TFS) 源代码管理。还可以配置代码分析策略，以帮助确保代码符合某些质 量标准，从而确保安全性、性能、可移植性、可维护性和可靠性规则通过。 除了强制编码标准和原则的策略之外，强制这种类型的签入策略可以确保代码符合特定的质量标准。 要为一个团队项目实施代码分析签入策略 1. 2. 3.
在“团队资源管理器”中，右击您的团队项目，指向“团队项目设置”，然后单击“源代码管 理”。 单击“签入策略”选项卡。 单击“添加”，然后选择并配置“工作项”签入策略。
其他资源 z z z z z
有关创建和使用自定义签入策略的详细信息，请参见本指南中的“如何：为 TFS 创建自定义 签入策略详解”。 要了解如何自定义签入策略，请参见“演练：自定义签入策略和签入说明”，地址为： http://msdn2.microsoft.com/en-us/library/ms181281(VS.80).aspx 要查看拒绝签入的选定模式的示例代码，请参见“拒绝某些模式的签入策略”，地址为： http://blogs.msdn.com/jmanning/archive/2006/02/02/523125.aspx 要查看对签入实施注释的示例代码，请参见“示例签入策略：确保注释非空”，地址为： http://blogs.msdn.com/jmanning/archive/2006/01/21/515858.aspx 要了解如何注册新签入策略，请参见“我创建了一条新的签入策略！如何添加？”，地址为： http://blogs.msdn.com/jmanning/archive/2006/02/07/526778.aspx
如何设置签入策略来确保开发人员将工作项与签入相关联 配置开箱即用的“工作项”签入测试，以便强制开发人员将工作项与签入相关联。该关联有助于保 持对源代码和跟踪 bug 和任务的工作项所做更改之间的可跟踪性。 要配置工作项签入策略，以强制开发人员将签入与工作项关联 1. 2. 3.
在“团队资源管理器”中，右击您的团队项目，选择“团队项目设置”，然后单击“源代码管 理”。 单击“签入策略”选项卡。 单击“添加”，然后选择并配置“工作项”签入策略。
其他资源 z z
有关创建和使用自定义签入策略的详细信息，请参见本指南中的“如何：为 TFS 创建自定义 签入策略详解”。 要了解如何自定义签入策略，请参见“演练：自定义签入策略和签入说明”，地址为： http://msdn2.microsoft.com/en-us/library/ms181281(VS.80).aspx
如何设置签入策略来执行编码标准 Team Foundation Server 附带的代码分析签入策略使您能够在代码签入时自动对代码运行静态代码 分析，以确保符合相关的规则。您可以微调代码分析策略以检查很多不同的规则。例如，可以检查 监管设计、互操作性、可维护性、移动性、命名约定、可靠性等方面的规则。 要为一个团队项目实施代码分析签入策略 z z z z z
在“团队资源管理器”中，右击您的团队项目，指向“团队项目设置”，然后单击“源代码管 理”。 单击“签入策略”选项卡，然后单击“添加”。 在“添加签入策略”对话框中，选择“代码分析”，然后单击“确定”。 在“代码分析策略编辑器”中，选择“执行 C/C++ 代码分析 (/analyze)”或“对托管代码执行 代码分析”。如果您的项目包含托管代码和非托管代码的组合，则选择两者。 如果选择管理代码分析，则根据所需的编码标准配置所需的规则设置进行托管代码分析。这恰 好确定了要执行哪些规则。
还可创建自定义签入策略，执行默认不可用的签入。例如，可以拒绝某些代码模式，例如被禁止的 API 调用，也可以编写策略，来执行团队的具体编码样式指导原则，例如应在源代码的什么位置放置花 括号。
其他资源 z z z z z
有关创建和使用自定义签入策略的详细信息，请参见本指南中的“如何：为 TFS 创建自定义 签入策略详解”。 要了解如何自定义签入策略，请参见“演练：自定义签入策略和签入说明”，地址为： http://msdn2.microsoft.com/en-us/library/ms181281(VS.80).aspx 要查看拒绝签入的选定模式的示例代码，请参见“拒绝某些模式的签入策略”，地址为： http://blogs.msdn.com/jmanning/archive/2006/02/02/523125.aspx 要查看对签入实施注释的示例代码，请参见“示例签入策略：确保注释非空”，地址为： http://blogs.msdn.com/jmanning/archive/2006/01/21/515858.aspx 要了解如何注册新签入策略，请参见“我创建了一条新的签入策略！如何添加？”，地址为： http://blogs.msdn.com/jmanning/archive/2006/02/07/526778.aspx
项目管理 z z z z z z z z z z z z
如何使用 Microsoft Project 管理您的项目 如何使用 Microsoft Excel 管理您的项目 如何创建最小化过程模板 如何自定义过程模板 如何在过程模板内自定义工作项类型 如何自定义现有团队项目内的工作项类型 如何创建迭代 如何创建区域 如何添加签入事件通知 如何设置报告仪表板 如何在源代码管理储存库内创建文件夹 如何从 Team Foundation Server 中删除项目
如何使用 Microsoft Project 管理您的项目 使用 Microsoft Office Project 创建和安排任务、布置依赖项、负载平衡资源以及估计结束日期。可 以使用这些功能来跟踪您的项目。 要跟踪项目，需要执行以下高级别的步骤： z 创建一个项目计划。 z 创建一组任务、安排它们，并将它们发布到 Team Foundation Server。 z 这些任务显示在相应开发人员的工作项队列中。 z 通过设置工作项状态，团队成员在他们的任务上工作，并在“团队资源管理器”中报告他 们的进度。 z 刷新项目计划以获得最新信息。这使您能够跟踪 Microsoft Project 中项目的进度。 要向 TFS 发布项目计划 1. 2. 3. 4. 5. 6. 7.
如果您创建一个新的项目计划，请设置任务、持续时间、资源分配、依赖项以及其他详细信息， 就像使用 Microsoft Office Project 通常所执行的操作一样。 在 Microsoft Office Project 的“团队”菜单中，单击“选择团队项目”。 选择适合您的团队项目的 Team Foundation Server。 选择您的团队项目。 单击“确定”。 在“工作项类型”列中，为您要发布到 TFS 的每个工作项设置工作项类型。 在“同步”列中，对于您不想发布到 TFS 的摘要任务，请选择“不发布”。
8.
9.
如果您具有已分配给多个资源的任何任务，请将它们划分为可以分配给一个资源的单独的任务。 （目前，Team Foundation Server 不支持将一个工作项分配给多个资源。）您可以将单独的任务 组合成一个摘要任务，以获得自动计算的优势。 要组合多组任务，请在 TFS 中创建一组区域，然后通过设置“区域”列来组合任务。有关 TFS， 请参见“如何：修改团队项目区域”，地址为： http://msdn2.microsoft.com/en-us/library/ms181479(VS.80).aspx 在“工作项”工具栏上，选择“发布”将项目计划发布到 TFS。
其他资源 z z z
有关详细信息，请参见“在 Microsoft Project 中使用工作项”，地址为 http://msdn2.microsoft.com/en-us/library/ms244368(VS.80).aspx 有关详细信息，请参见“如何：在 Microsoft Excel 或 Microsoft Project 中导入工作项”，地址 为：http://msdn2.microsoft.com/en-us/library/ms181676(VS.80).aspx 有关详细信息，请参见“在 Microsoft Excel 和 Microsoft Project 中跟踪团队项目”，地址为： http://msdn2.microsoft.com/en-us/library/ms244373(VS.80).aspx
如何使用 Microsoft Excel 管理您的项目 使用 Microsoft Office Excel® 存储、排序、筛选和管理要求、方案、问题、bug、风险以及工作项。 有两种方法创建工作项列表。第一个方法是从“团队资源管理器”中，选择工作项查询并创建一个 新的数据绑定电子数据表。新的电子数据表包含一个工作项列表，该列表是用查询中的数据进行填 充的。还可以通过使用加载项选择一个项目，然后导入工作项来从 Excel 中创建一个工作项列表。 要使用 Excel 创建一个工作项列表 1. 2. 3. 4. 5. 6. 7.
8.
在 Microsoft Office Excel 的“团队”菜单中，单击“新建列表”。 在“连接到 Team Foundation Server”下，选择要连接的服务器，或单击“服务器”来输入服务器 信息。 在“团队项目”下，选择 TFS 服务器上要使用的团队项目。文档将被绑定到此团队项目。 单击“确定”。 选择所需的列表类型。要创建查询列表，请选择“查询列表”选项，然后从“选择查询”下拉 列表中单击一个团队查询。 选择希望在新工作项列表中显示的列。 导入所需工作项。 有关详细信息，请参见“如何：在 Microsoft Excel 或 Microsoft Project 中导入工作项”，地址 为：http://msdn2.microsoft.com/en-us/library/ms181676(VS.80).aspx 现在，您应该保存电子数据表，或者通过单击“团队”菜单上的“发布更改”将新工作项发布 到工作项数据库。
其他资源 z z z
有关详细信息，请参见“在 Microsoft Excel 中使用工作项”，地址为： http://msdn2.microsoft.com/en-us/library/ms181694(VS.80).aspx 有关详细信息，请参见“如何：创建工作项列表”，地址为： http://msdn2.microsoft.com/en-us/library/ms181695(VS.80).aspx 有关详细信息，请参见“如何：在 Microsoft Excel 或 Microsoft Project 中导入工作项”，地址 为：http://msdn2.microsoft.com/en-us/library/ms181676(VS.80).aspx
如何创建最小化过程模板 如果除了源代码管理之外，您不需要支持任何项目管理相关的 TFS 功能，那么最小化过程模板可 能就足够了。要创建最小化过程模板，应该使用过程模板管理器将模板下载到本地计算机，编辑模 板以删除将不使用的部分，然后将此模板上载回服务器。 创建仅支持源代码管理的自定义项目模板 在“团队资源管理器”中，右击服务器名称，单击“Team Foundation Server 设置”，然后单击 “过程模板管理器”。 2. 选择您要编辑的模板，然后选择“下载”。 3. 从您保存模板的文件夹中，打开 Process Template.xml 进行编辑。 4. 通过编辑 <name> 元素将此过程的名称更改为您选择的名称。 5. 在 <plugins> 部分中，删除用于报告、门户以及工作项跟踪的插件。 6. 在 <groups> 部分中，删除用于报告、门户以及工作项跟踪的组。 7. 在 VersionControl 组中，找到 <dependencies> 部分，然后删除 WorkItemTracking 依赖项。 8. 在保存模板的文件夹中，删除报告、Windows Sharepoint Services 以及工作项跟踪文件夹。 9. 保存所有更改。 10. 在“团队资源管理器”中，右击服务器名称，单击“Team Foundation Server 设置”，然后单击 “过程模板管理器”。 11. 选择“上载”，然后选择您要上载的模板。 1.
上载修改的过程模板之后，可以通过使用此模板创建新的团队项目。
其他资源 z z z
有关详细信息，请参见本指南的“第13章 – 过程模板介绍”。 有关详细信息，请参见本指南中的“如何：在 Visual Studio Team Foundation Server 中自定义过 程模板”。 有关详细信息，请参见“自定义过程模板”，地址为： http://msdn2.microsoft.com/en-us/library/ms243782(VS.80).aspx
如何自定义过程模板 自定义过程模板以更改默认的工作项类型、安全设置、源代码管理设置以及在创建新的团队项目以 符合您组织的过程要求时设置报告。 要自定义过程模板
1. 2. 3. 4. 5.
查看开箱即用的过程模板并选择最适合您的组织过程的模板。 下载所选的过程模板。 自定义过程模板并根据需要更改工作项类型、安全设置以及源代码管理设置。 将自定义模板上载到 TFS。 验证所做的更改是否适合您的过程要求。
要实现前面的过程，有两种方法： z
z
手动自定义 XML 文件。尽管这是一个手动过程，因此容易出现错误，但是它使您能够自定义 具有微小控制程度的过程模板。有关详细信息，请参见“自定义过程模板”，地址为： http://msdn2.microsoft.com/en-us/library/ms243782(VS.80).aspx 使用 Microsoft Visual Studio 2005 Team Foundation Server Power Tool 可用的过程模板编辑 器工具。最新版本的 TFS Power Tool 提供用于查看和自定义过程模板的图形工具。当连接到
TFS 时，可以使用该工具自定义活动项目上的工作项类型定义和全局列表。有关详细信息，请 参见本指南中的“如何：在 Visual Studio Team Foundation Server 中自定义过程模板”。
其他资源 z z z
有关详细信息，请参见本指南的“第13章 – 过程模板介绍”。 有关详细信息，请参见本指南中的“如何：在 Visual Studio Team Foundation Server 中自定义过 程模板”。 有关详细信息，请参见“自定义过程模板”，地址为： http://msdn2.microsoft.com/en-us/library/ms243782(VS.80).aspx
如何在过程模板内自定义工作项类型 使用过程编辑器工具（可用于最新版本的 TFS Power Tool）自定义工作项类型。可以从 http://msdn2.microsoft.com/en-us/vstudio/aa718351.aspx 中下载 TFS Power Tool。 要自定义工作项类型 1.
2.
3. 4. 5. 6.
按照如下方式，下载最符合您的要求的过程模板： a 在 Visual Studio 的“团队”菜单上，选择“Team Foundation Server 设置”。 b 单击“过程模板管理器”。 c 在“过程模板管理器”对话框中，选择打算修改的过程模板，然后单击“下载”。 d 在“下载过程模板”对话框中，选择本地驱动器中您希望保存模板的文件夹位置，然后单 击“保存”。 按照如下方式，在过程编辑器中打开过程模板： a 在 Visual Studio 中，单击“团队”菜单。 b 单击“过程编辑器”，然后单击“打开过程模板”。 c 在“打开过程模板文件集”对话框中，浏览找到已下载的过程模板，然后单击“打开”。 Visual Studio 便加载 ProcessTemplate.xml 文件。 d 设置您自定义的方法的“名称”。 在“过程模板资源管理器”中，单击“工作项跟踪”。 在右窗格中，单击“类型定义”选项卡。 要创建新工作项，单击右窗格的工具栏中的“添加”即可。 在“新建工作项类型”对话框中，输入工作项类型的名称，然后从“复制自”下拉列表中选择 现有的工作项类型。 创建新的工作项类型，并且该类型位于右窗格中“类型定义”选项卡上“项目列表”中。
要保存更改，请在“文件”菜单上，单击“保存”。 选择向新的工作项类型或现有工作项类型添加属性或字段，或者删除属性或字段。 在“类型定义”选项卡上，右击要编辑的工作项类型，然后单击“打开”。 所选择的工作项类型便在新的 Visual Studio 窗口中打开。 10. 根据需要添加或删除属性。 7. 8. 9.
其他资源 z z z
要下载 TFS Power Tool，请访问：http://msdn2.microsoft.com/en-us/vstudio/aa718351.aspx 有关工作项的详细信息，请参见本指南中的“第12章 – 工作项介绍”。 有关使用过程编辑器工具自定义工作项类型的详细信息，请参见本指南中的“如何：在 Visual Studio Team Foundation Server 中自定义过程模板”。
如何自定义现有团队项目内的工作项类型
有两种方法编辑现有的工作项类型：可以使用命令行或使用过程模板编辑器工具（TFS Power Tool 的 一部分）。 要通过命令行编辑工作项类型，请使用安装“团队资源管理器”的计算机上“%programfiles%\Program Files\Microsoft Visual Studio 8\Common7\IDE”中的 witexport 和 witimport 工具。 从项目中导出工作项类型、编辑并重新导入该类型 1.
按照如下方式运行 witexport 以导出工作项类型： witimport /f task.xml /t http://TFSServer:8080 /p MyTeamProject
2.
编辑工作项类型定义。
3.
按照如下方式运行 witimport 以导入更改的类型： witexport /f task.xml /t http://TFSServer:8080 /p MyTeamProject /n Task
前面的命令行显示如何将 MyTeamProject 项目中的“任务”工作项类型导出到名为 TFSServer 的 服务器。 使用过程模板编辑器工具编辑工作项类型： 1.
按照如下方式导出要编辑的工作项类型： a 在 Visual Studio 中的“团队”菜单上，选择“过程编辑器”，然后单击“工作项类型”， 然后选择“导出 WIT”。 b 在“连接到 Team Foundation Server”对话框中，输入服务器的 URL。 c 在“选择工作项类型”对话框中，选择要导出的工作项类型。 d 保存工作项类型。 e 保存您还想编辑的任何全局列表。 f 编辑工作项类型，然后保存您的编辑。
2.
按照如下方式导入已编辑的工作项类型： a 在 Visual Studio 中的“团队”菜单上，选择“过程编辑器”，然后单击“工作项类型”， 然后选择“导入 WIT”。 b 在“连接到 Team Foundation Server”对话框中，输入服务器的 URL。 c 在“导入工作项类型”对话框中，浏览到已编辑的工作项类型，然后选择您要导入更改的 工作项类型的团队项目。 d 单击“确定”可导入新的工作项类型定义。
其他资源 z z z z
要下载 TFS Power Tool，请访问：http://msdn2.microsoft.com/en-us/vstudio/aa718351.aspx 有关使用过程编辑器工具自定义工作项类型的详细信息，请参见本指南中的“如何：在 Visual Studio Team Foundation Server 中自定义过程模板”。 有关使用 witimport 的信息，请参见“witimport”，地址为： http://msdn2.microsoft.com/en-us/library/ms253163(VS.80).aspx 有关使用 witexport 的信息，请参见“witexport”，地址为： http://msdn2.microsoft.com/en-us/library/ms253051(VS.80).aspx
如何创建迭代 迭代用来组合工作项，因此会影响工作项的创建、工作项查询以及报告。
要创建迭代 1. 2. 3. 4. 5. 6. 7. 8.
在“团队资源管理器”中单击您的团队项目。 在“团队”菜单中，指向“团队项目设置”，然后单击“区域和迭代”。 在“区域和迭代”对话框中，单击“迭代”选项卡。 单击“添加子节点”工具栏按钮。 右击新节点，单击“重命名”，然后键入迭代名。 单击“迭代”节点。 重复第 2、3、4 步，为您的项目创建已识别的其他迭代。 单击“关闭”。
注意：Microsoft Solution Framework (MSF) for Agile Software Development (MS Agile) 过程模板包括 三个预定义的迭代。您可以删除这些迭代、重命名它们（而不是创建新的迭代），或只是使它们保 持不变。
其他资源 z
有关详细信息，请参见“演练：创建新团队项目”，地址为： http://msdn2.microsoft.com/en-us/library/dhedaeb2(VS.80).aspx
如何创建区域 创建区域来将团队项目工作组织到项目子区域中。例如，可以将项目工作组合为区域，如 UI、应用 程序和数据库。创建完区域之后，可以向这些区域分配方案和工作项。 您可以从单根级别的区域开始，然后随着项目的成熟，根据需要创建区域。 为项目创建区域 1. 2. 3. 4. 5. 6. 7.
在“团队资源管理器”中单击您的团队项目。 在“团队”菜单中，指向“团队项目设置”，然后单击“区域和迭代”。 在“区域和迭代”对话框中，单击“区域”选项卡。 单击“添加子节点”工具栏按钮。 右击新节点，单击“重命名”，然后键入所需区域名。 单击“区域”节点。 重复第 2、3、4 步创建其他区域。采用这种方法，您可以为您的项目结构创建一个层次结构。
其他资源 z
有关详细信息，请参见“演练：创建新团队项目”，地址为： http://msdn2.microsoft.com/en-us/library/dhedaeb2(VS.80).aspx
如何添加签入事件通知 使用位于 TFS 服务器上的 %programfiles%\Microsoft Visual Studio 2005 Team Foundation Server\TF Setup\BisSubscribe.exe 中的 bissubscribe 工具订阅签入通知。 要设置签入事件通知 1. 2.
打开命令提示符并更改为以下位置：C:\Program Files\Microsoft Visual Studio 2005 Team Foundation Server\TF Setup\ 如果您想设置电子邮件通知，请使用以下命令：
bissubscribe /eventType CheckinEvent /address someone@domain.com /deliveryType EmailHtml /domain http://TFSRTM:8080 3.
如果您想设置 Web 服务通知，请使用以下命令： bissubscribe /eventType CheckinEvent /address http://TFSRTM:8080/ci/notify.asmx /deliveryType Soap /domain http://TFSRTM:8080
4.
如果获得任何错误或想确认已正确注册，请执行以下操作： a 打开 SQL Server Management Studio。 b 打开 tfsIntegration 数据库。 c 查看 tbl_subscription 表。
tbl_subscription 表列出已订阅的所有事件。通过查看此表，您应该能够找到用于您订阅的事件的条 目。您可以通过从表中删除条目来取消订阅任何已注册的事件。还可以通过运行 bissubscribe，将 其传递给 /unsubscribe 命令行参数以及事件的 id 来取消订阅事件，如下所示： bissubscribe /delete/id [id] /server http://TFSRTM:8080
其他资源 z z z
有关详细信息，请参见本指南中的“如何：在 Visual Studio Team Foundation Server 中设置连续 集成生成”。 有关详细信息，请参见“使用 bissubscribe 向 CheckinEvent 订阅中添加路径筛选器”，地址为： http://blogs.msdn.com/buckh/archive/2006/09/29/checkinevent-path-filter.aspx 有关详细信息，请参见“使用团队生成的连续集成”，地址为： http://blogs.msdn.com/khushboo/archive/2006/01/04/509122.aspx
如何设置报告仪表板 修改团队项目门户 Microsoft Office SharePoint® 站点，以便创建一个可以在一个位置中提供各种项 目信息的报告仪表板。 例如，一个有用的报告仪表板可能包含如下报告： z z z z
剩余工作 质量指标 Bug 率 项目速度
可以向 SharePoint 门户页面添加新报告，方法是为希望在该页面上显示的各报告添加一个报告查看 器 Web 部件。 修改团队项目门户并创建一个报告仪表板 1.
2.
使用 Microsoft Office SharePoint 和报告服务安装包中附带的 stsadm.exe 工具和 RSWebParts.cab，在您的报告服务器上安装报告查看器 Web 部件。 a. STSADM.EXE 可在如下路径中找到：C:\Program Files\Common Files\Microsoft Shared\web server extensions\60\BIN b. RSWebParts.Cab 可在如下路径中找到：C:\ Program Files\Microsoft SQL Server\90\Tools\Reporting Services\SharePoint 示例：STSADM.EXE -o addwppack -filename "C:\ Program Files\Microsoft SQL Server\90\Tools\Reporting Services\SharePoint\RSWebParts.cab" -globalinstall 在“团队资源管理器”中，右击您的项目，然后单击“显示项目门户”。
3. 4. 5. 6. 7. 8.
单击“修改共享页面”，指向“浏览”，然后单击“添加 Web 部件”。 单击“虚拟服务器列表”。 从“Web 部件列表”中，选择“报告查看器”。 单击“添加”。 输入报告管理器名称，如 http://<report server>/reports。 输入要显示的报告的路径，如 <my project>/Quality Indicators。
其他资源 z z
关于添加报告查看器 Web 部件的详细信息，请参见“使用 SharePoint 2.0 Web 部件查看报表”， 地址为：http://msdn2.microsoft.com/en-us/library/ms159772(SQL.90).aspx 关于团队项目门户的详细信息，请参见“使用团队项目门户”，地址为： http://msdn2.microsoft.com/en-us/library/ms242883(VS.80).aspx
如何在源代码管理储存库内创建文件夹 可以使用团队资源管理器在源代码管理储存库中创建文件夹，或者在客户端上的工作区中创建文件 夹结构，然后签入挂起的更改。 要在服务器上创建文件夹结构 1. 2. 3. 4. 5.
在“团队资源管理器”中，展开您的团队项目。 双击团队项目下的“源代码管理”。 在“源代码管理资源管理器”中选择根节点，右击“本地路径：”窗格，然后单击“新建文件 夹”。 键入根文件夹的名称，然后按 Enter。 重复第 3 步和第 4 步，在源代码管理储存库中创建所需的文件夹。
在客户端上创建文件夹结构 1. 2.
在本地计算机上创建一个工作区映射。 根据项目需要创建文件夹结构。 第一次签入挂起的更改时，会将文件夹结构复制到服务器。
其他资源 z z
有关创建工作区的详细信息，请参见“如何：创建工作区”，地址为： http://msdn2.microsoft.com/en-us/library/ms181384(VS.80).aspx 有关创建源代码树的详细信息，请参见本指南中的“如何：在 Visual Studio Team Foundation Server 中创建源代码树”。
如何从 Team Foundation Server 中删除项目 您无法通过团队资源管理器删除项目。相反，必须使用 TfsDeleteProject 命令行工具。您可以在安 装了“团队资源管理器”的计算机上的 Program Files\Microsoft Visual Studio 8\Common7\IDE 中找 到该工具。 从团队 TFS 中删除项目 1. 2.
打开命令提示符并切换到以下位置： C:\Program Files\Microsoft Visual Studio 2005 Team Foundation Server\TF Setup\ 按照如下方式运行 TfsDeleteProject 以删除该项目：
TfsDeleteProject /server:TfsServer TeamProjectName
其他资源 z
有关删除项目的详细信息，请参见“TFSDeleteProject”，地址为： http://msdn2.microsoft.com/en-us/library/ms181482(VS.80).aspx
Team Foundation 项目管理资源 z
有关 MSF 过程模板的详细信息，请参见“过程模板”，地址为： http://msdn2.microsoft.com/en-us/teamsystem/aa718801.aspx
实践总览报告 索引 管理 z z
如何设置报告仪表板 如何设置报告权限
创建 / 自定义 z z z z z z
如何自定义现有报告 如何在 Visual Studio 中创建新报告 如何在 Excel 中创建新报告 如何创建一个预定报告快照 如何创建报告订阅 如何向现有过程模板中添加新报告
查看 z z z z z z z z z z z z
如何分析一个项目的状态 如何分析应用程序的质量 如何查看剩余工作 如何查看生成状态 如何查看 bug 和测试结果 如何查看一次迭代中的预定工作与实际工作的对比情况 如何确定最后编辑文件的所有者 如何发现一名开发人员做出的全部代码更改 如何发现对一个文件进行的所有代码更改 如何发现与一个特定工作项相关的所有代码更改 如何生成代码改动 (churn) 指标 如何生成工作区指标，如文件数量、代码行数和项目数量
管理 z z
如何设置报告仪表板 如何设置报告权限
如何设置报告仪表板 修改团队项目 Microsoft® Office SharePoint® 门户站点，以便创建一个可以在一个位置中提供各种 项目信息的报告仪表板。 例如，一个有用的报告仪表板可能包含如下报告： z z z
剩余工作 质量指标 Bug 率
z
项目速度
可以向 SharePoint 门户页面添加新报告，方法是为希望在该页面上显示的各报告添加一个报告查看 器 Web 部件。 要修改团队项目门户并创建一个报告仪表板 使用 SharePoint 和报告服务安装包中附带的 stsadm.exe 工具和 RSWebParts.cab，在您的报告 服务器上安装报告查看器 Web 部件。 z STSADM.EXE 可在如下路径中找到：C:\Program Files\Common Files\Microsoft Shared\web server extensions\60\BIN z RSWebParts.Cab 可在如下路径中找到：C:\ Program Files\Microsoft SQL Server\90\Tools\Reporting Services\SharePoint z 示例：STSADM.EXE -o addwppack -filename "C:\ Program Files\Microsoft SQL Server\90\Tools\Reporting Services\SharePoint\RSWebParts.cab" -globalinstall 2. 在“团队浏览器”中，右击您的项目。 3. 单击“显示项目门户”。 4. 单击“修改共享页面”。 5. 指向“浏览”，然后单击“添加 Web 部件”。 6. 单击“虚拟服务器列表”。 7. 在“Web 部件列表”中，选择“报告查看器”。 8. 单击“添加”。 9. 输入报告管理器名称，如 http://<report server>/reports。 10. 输入要显示的报告的路径，如 <my project>/Quality Indicators。 1.
其他资源 z z
关于添加报告查看器 Web 部件的详细信息，请参见“使用 SharePoint 2.0 Web 部件查看报表”， 地址为：http://msdn2.microsoft.com/en-us/library/ms159772(SQL.90).aspx 关于团队项目门户的详细信息，请参见“使用团队项目门户”，地址为： http://msdn2.microsoft.com/en-us/library/ms242883(VS.80).aspx
如何设置报告权限 您可以修改报告权限以确定可以编辑或查看报告的人。您必须是 Microsoft SQL Server™ 报告服务 内容管理器角色的成员才能设置报告权限。 为团队项目中的所有报告设置权限 1. 2. 3. 4. 5. 6. 7.
在“团队资源管理器”中，展开您的团队项目节点。 右击“报告”，然后“显示报告站点”。 单击“属性”选项卡。 单击“安全性”。 单击“编辑项安全性”。 如果希望编辑一个已为该报告定义的角色安全性，可单击“编辑”。 如果希望为一个未列出的角色定义安全性，可单击“新角色分配”。
为单个报告设置权限 1. 2. 3. 4.
在“团队资源管理器”中，展开您的团队项目节点。 右击“报告”，然后“显示报告站点”。 在报告站点上，选择要设置权限的报告。 单击“属性”选项卡。
5. 6. 7. 8.
单击“安全性”。 单击“编辑项安全性”。 如果希望编辑一个已为该报告定义的角色安全性，可单击“编辑”。 如果希望为一个未列出的角色定义安全性，可单击“新角色分配”。
其他资源 z
有关设置报告权限的详细信息，请参见“如何：为报告设置权限”，地址为： http://msdn2.microsoft.com/en-us/library/ms181645(VS.80).aspx
创建 / 自定义 z z z z z z
如何自定义现有报告 如何在 Visual Studio 中创建新报告 如何在 Excel 中创建新报告 如何创建一个预定报告快照 如何创建报告订阅 如何向现有过程模板中添加新报告
如何自定义现有报告 可以使用在 Visual Studio (Business Intelligence Development Studio) 中随 SQL Server 2005 客户端 工具一起提供的 SQL Server 2005 Reporting Services Designer 修改报告。通常，修改现有报告比创 建新报告要容易一些。 在 TFS 中自定义现有报告 1.
2.
3.
创建报告项目，如下所示： a 在 Visual Studio 中，单击“文件”，单击“新建”，然后单击“项目”。 b 选择“商业智能项目”类型。 c 选择“报表服务器项目”模板。 d 设置项目的名称和位置，然后单击“确定”。 按照如下方式导出要自定义的报告： a 右击您的团队项目，然后单击“显示项目门户”。 b 在门户网站左侧的“快速启动”栏中，单击“报告”。 c 单击希望自定义的报告。 d 单击“属性”。 e 选择“编辑”。 f 将报告 .rdl 文件保存到在第 1 步中创建的报告项目文件夹中。 添加数据源，如下所示： a 要创建仓库数据源： i. 在“Visual Studio 解决方案资源管理器”中，右击“共享数据源”，然后单击“添加 新数据源”。 ii. 在“常规”选项卡的“名称”文本框中键入 TfsReportDS iii. 在“类型”组合框中选择 Microsoft SQL Server。 iv. 单击“编辑”。 v. 填入数据层服务器名称。 vi. 选择 TFS Warehouse 数据库。 vii. 单击“确定”按钮两次即可添加数据源。
要创建 OLAP 数据源： i. 在“解决方案资源管理器”中，右击“共享数据源”，然后单击“添加新数据源”。 ii. 在“常规”选项卡的“名称”文本框中键入 TfsOlapReportDS iii. 在“类型”组合框中选择 Microsoft SQL Server Analysis Services。 iv. 单击“编辑”。 v. 填入数据层服务器名称。 vi. 选择 TFS Warehouse 数据库。 vii. 单击“确定”按钮两次即可添加数据源。 按照如下方式，向您的项目中添加报告： a 在“解决方案资源管理器”中，右击“报告”，然后单击“添加->现有项目”。 b 浏览到您在第 2 步中导出的 rdl 文件。 按照如下方式，修改报告： a 在“数据窗格”中修改查询语句。 b 将新的措施或成员拖动到“数据窗格”中。 c 在“布局窗格”中修改报告布局。
b
4.
5.
注意：尽管可以使用团队报告站点上提供的“报告生成器”，但 Visual Studio 报告方案对此工具的 支持不尽人意，因此不推荐使用。
其他资源 z
有关详细信息，请参见本指南中的“如何：在 Visual Studio Team Foundation Server 中自定义报 告”。
如何在 Visual Studio 中创建新报告 可以使用在 Visual Studio (Business Intelligence Development Studio) 中随 SQL Server 2005 客户端 工具一起提供的 SQL Server 2005 Reporting Services Designer 创建报告。 如果现有报告都不可以修改为符合您要求的报告，请创建一个新报告。通常，修改现有报告比创建 新报告要容易一些。 在 TFS 中创建新报告 1.
2.
创建报告项目，如下所示： a 在 Visual Studio 中，单击“文件”，单击“新建”，然后单击“项目”。 b 选择“商业智能项目”类型。 c 选择“报表服务器项目”模板。 d 设置项目的名称和位置，然后单击“确定”。 添加数据源，如下所示： a 要创建仓库数据源： i. 在“Visual Studio 解决方案资源管理器”中，右击“共享数据源”，然后单击“添加 新数据源”。 ii. 在“常规”选项卡的“名称”文本框中键入 TfsReportDS iii. 在“类型”组合框中选择 Microsoft SQL Server。 iv. 单击“编辑”。 v. 填入数据层服务器名称。 vi. 选择 TFS Warehouse 数据库。 vii. 单击“确定”按钮两次即可添加数据源。 b 创建联机分析处理 (OLAP) 数据源： i. 在“解决方案资源管理器”中，右击“共享数据源”，然后单击“添加新数据源”。 ii. 在“常规”选项卡的“名称”文本框中键入 TfsOlapReportDS
3.
4.
iii. 在“类型”组合框中选择 Microsoft SQL Server Analysis Services。 iv. 单击“编辑”。 v. 填入数据层服务器名称。 vi. 选择 TFS Warehouse 数据库。 vii. 单击“确定”按钮两次即可添加数据源。 创建新报告，如下所示： a 在“解决方案资源管理器”中，右击“报告”，指向“添加”，然后单击“新建项目”。 b 选择“报告”模板。 c 命名该报告，然后单击“确定”。 按照如下方式，修改报告： a 如果“报表设计器”未自动打开，可在“解决方案资源管理器”中双击报告，从而打开报 告以供修改。 b 在“数据集”下拉列表中，选择“<新数据集...>”。 c 命名该数据集，例如，TestDataSet。 d 选择 TFSOlapReportDS（共享）。 e 单击“确定”。 f 单击“生成”旁边的省略号 (...) 按钮（就在“数据集”下拉列表下方），然后选择“Team System”。
您现在可以通过将测量数据和维数从“数据集”树中拖动到查询窗格和筛选器窗格中来修改报告。 单击“布局”选项卡可以修改报告的布局。单击“预览”选项卡可以预览报告。 注意：尽管可以使用团队报告站点上提供的“报告生成器”，但 Visual Studio 报告方案对此工具的 支持不尽人意，因此不推荐使用。
其他资源 z
有关详细信息，请参见本指南中的“如何：为 Visual Studio Team Foundation Server 创建自定义 报告”。
如何在 Excel 中创建新报告 可以通过将 Microsoft Office Excel® 直接连接到 TFS 报告 OLAP 多维数据集来创建 Ad-Hoc 报 告。使用 Excel，您可以采用数据透视表或数据透视图的形式显示报告数据。 要创建 Excel 数据透视表报告 1. 确保安装了 Microsoft SQL Server 2005 Analysis Services 9.0 OLE DB 供应者。要安装此程序， 请访问： http://www.microsoft.com/downloads/details.aspx?FamilyID=d09c1d60-a13c-4479-9b91-9e8b9d835c dc 2. 启动 Excel。 3. 选择要添加数据透视表报告的工作表。 4. 在“数据”菜单中选择“数据透视表和数据透视图报告”。 5. 选择“外部数据源”。 6. 单击“下一步”。 7. 单击“获取数据”。 8. 单击“OLAP 多维数据集”选项卡。 9. 选择“<新数据源>”，然后单击“确定”。 10. 为数据源输入名称。 11. 选择 Microsoft SQL Server 2005 Analysis Services 9.0 OLE DB 供应者 12. 单击“连接”。 13. 选择“分析服务器”。 14. 输入报告服务器的名称，例如，TFSRTM。
15. 16. 17. 18. 19.
单击“下一步”。 选择“TFSWarehouse”，然后单击“完成”。 选择要从中生成报告的多维数据集（例如，代码改动、工作项和测试结果），然后单击“确定”。 再次单击“确定”，返回“数据透视表和数据透视图向导”。 单击“完成”，将数据透视表添加到工作表上。
使用“数据透视表字段列表”将列和测量数据拖放到数据透视表中。例如，要查看服务器上每个团 队项目的行计数： 1. 2. 3.
选择上面第 17 步中的“代码改动”多维数据集。 将 TeamProject.TeamProject 拖动到数据透视表的“列字段”部分中。 将“汇总行”拖动到数据透视表的“数据项”部分中。
其他资源 z z
有关使用 Excel 创建 Ad-Hoc 报告的详细信息，请参见“使用 Microsoft Excel 生成 Team Foundation Server 报告”，地址为：http://msdn2.microsoft.com/en-us/library/ms244713(VS.80).aspx 要安装 Microsoft SQL Server 2005 Analysis Services 9.0 OLE DB 供应者，请访问： http://www.microsoft.com/downloads/details.aspx?FamilyID=d09c1d60-a13c-4479-9b91-9e8b9d835c dc
如何创建一个预定报告快照 您可以使用预定报告快照更好地理解一段时间内的趋势，或者记住整个项目持续时间内重要的数据 点。 创建一个预定报告快照 1. 2. 3. 4. 5.
在“团队资源管理器”中，右击对应于您的团队项目的“报告”，然后单击“显示报告站点”。 打开报告站点中的一个报告。 单击“属性”选项卡。 单击“历史记录”链接。 按照您希望快照运行的时间设置时间表。
设置时间表之后，您便可以在该报告的“历史记录“选项卡上查找快照。还可以在“历史记录”选 项卡上手动创建快照。
如何创建报告订阅 可以使用报告订阅生成报告并将报告导出到文件共享以供将来使用。可以设置订阅重写旧报告，或 者在一段时间内生成一组报告以查看项目数据的快照。 创建报告订阅 1. 2. 3. 4.
在“团队资源管理器”中，右击对应于您的团队项目的“报告”，然后单击“显示报告站点”。 打开报告站点中的一个报告。 单击“安全性”选项卡。 单击“新建订阅”以创建报告订阅。
如何向现有过程模板中添加新报告 您可以使用过程编辑器工具（它可用于最新版本的 Team Foundation Server Power Tool）向现有过程 模板中添加新报告。可以从 http://msdn2.microsoft.com/en-us/vstudio/aa718351.aspx 下载 Team
Foundation Server Power Tool。 添加新报告 1.
2.
3. 4. 5. 6. 7. 8.
按照如下方式，下载最符合您的要求的过程模板： a 在 Visual Studio 中，单击“团队”，然后选择“Team Foundation Server 设置”。 b 单击“过程模板管理器”。 c 在“过程模板管理器”对话框中，选择打算修改的过程模板，然后单击“下载”。 d 在“下载过程模板”对话框中，选择本地驱动器中的文件夹位置，然后单击“保存”。 按照如下方式，在过程编辑器中打开过程模板： a 在 Visual Studio 中，单击“团队”菜单。 b 单击“过程编辑器”，然后单击“打开过程模板”。 c 在“打开过程模板文件集”对话框中，浏览找到已下载的过程模板，然后单击“打开”。 将在 Visual Studio 中打开 ProcessTemplate.xml 文件。 d 设置您要应用自定义的方法的“名称”。 在“过程模板资源管理器”中，单击“报告”。 在工具栏上单击“添加”。 在“报告”对话框中的“报告详细信息”选项卡上输入报告名称。 浏览找到您希望在“文件名”字段中添加的 .rdl 文件。 保持其他字段不变，并且不对“属性”和“参数”选项卡上的数据进行任何更改。 在“数据源”选项卡上，输入恰当的数据源。 TFS 附带的用于过程模板的默认数据源为 /TfsOlapReportDS and /TfsReportDS。 单击“确定”。
其他资源 z z
可以从 http://msdn2.microsoft.com/en-us/vstudio/aa718351.aspx 下载 Team Foundation Server Power Tool。 有关使用过程编辑器工具自定义工作项类型的详细信息，请参见本指南中的“如何：在 Visual Studio Team Foundation Server 中自定义过程模板”。
查看 z z z z z z z z z z z z
如何分析一个项目的状态 如何分析应用程序的质量 如何查看剩余工作 如何查看生成状态 如何查看 bug 和测试结果 如何查看一次迭代中的预定工作与实际工作的对比情况 如何确定最后编辑文件的所有者 如何发现一名开发人员做出的全部代码更改 如何发现对一个文件进行的所有代码更改 如何发现与一个特定工作项相关的所有代码更改 如何生成代码改动 (churn) 指标 如何生成工作区指标，如文件数量、代码行数和项目数量
如何分析一个项目的状态 可以使用“速度”报告分析项目的状态。 要查看应用程序状态
1. 2.
在“团队资源管理器”中，展开您的团队项目节点，右击“报告”，然后单击“显示报告站点”。 在报告站点中，选择“速度报告”。
此报告显示了团队完成工作的速度，还显示了每天的变更速率。
如何分析应用程序的质量 可以使用“质量指标”报告分析应用程序的质量。 要分析应用程序的质量 1. 2.
在“团队资源管理器”中，展开您的团队项目节点，右击“报告”，然后选择“显示报告站点”。 在报告站点中，选择“质量指标报告”。
这份报告将测试结果、bug、代码覆盖率和代码改动收集到一份报告中，您可利用这份报告来跟踪项 目的健康情况。
如何查看剩余工作 可以使用“剩余工作”报告查看剩余工作。 要查看剩余工作 1. 2.
在“团队资源管理器”中，展开您的团队项目节点，右击“报告”，然后选择“显示报告站点”。 在报告站点中，选择“剩余工作报告”。
此报告显示一段时间内剩余、已解决和已关闭的工作。计划剩余工作的未来趋势使您能够预测代码 完成的时间点。
如何查看生成状态 如果您使用 Microsoft Solution Framework (MSF) for CMMI® (MS CMMI) 过程模板，则可以查看生 成报告以便查看 BVT 结果。 要查看生成状态 1. 2. 3.
在“团队资源管理器中”中，展开您的团队项目节点。 右击“报告”，然后单击“显示报告站点”。 在报告站点中，选择“生成报告”。
这份报告提供了可用生成的列表，包括生成质量和其他详细信息。
如何查看 bug 和测试结果 可以使用“Bug 优先级”报告查看 bug。此报告显示发现的高优先级 bug 的速率以及低优先级 bug 的速率。 可以使用“质量指标”报告在一个报告中查看测试结果、bug、代码覆盖率以及代码改动。 要查看“Bug 优先级”或“质量指标”报告 1. 2. 3.
在“团队资源管理器中”中，展开您的团队项目节点。 右击“报告”，然后单击“显示报告站点”。 选择“Bug 优先级”报告查看 bug，或选择“质量指标”报告查看测试结果。
如何查看一次迭代中的预定工作与实际工作的对比情况 可以使用“计划外工作”报告查看预定的工作以及实际工作的对比情况。此报告绘制了总工作与剩 余工作的对比图并且将计划的工作与计划外的任务区分开来。 要查看“计划外工作”报告 1. 2. 3.
在“团队资源管理器中”中，展开您的团队项目节点。 右击“报告”，然后单击“显示报告站点”。 在报告站点中，选择“计划外工作报告”。
如何确定最后编辑文件的所有者 可以使用“源代码管理资源管理器”中的源文件历史记录来确定最后编辑文件的所有者。 要确定最后编辑文件的人 1. 2. 3.
在“源代码管理资源管理器”中，选择感兴趣的文件。 右击该文件，然后单击“查看历史记录”。 在“历史记录”窗格中，查看更改历史记录，包括所有者。
其他资源 z
有关“源代码管理资源管理器”的详细信息，请参见“使用源代码管理资源管理器”，地址为： http://msdn2.microsoft.com/en-us/library/ms181370(VS.80).aspx
如何发现一名开发人员做出的全部代码更改 可以使用“TF History”命令查找特定开发人员在项目中所做的所有代码更改。 例如，以下命令显示了用户 Mario 所做的所有更改： tf history $/ /r
/user:Mario
在前面的示例中，$/ 用于搜索整个储存库。可以将其替换为 $/TeamProjectName 以将搜索限制于特 定的团队项目。
其他资源 z
有关 TF History 命令的详细信息，请参见“History 命令”，地址为： http://msdn2.microsoft.com/en-us/library/yxtbh4yh(VS.80).aspx
如何发现对一个文件进行的所有代码更改 可以使用“源代码管理资源管理器”中的源文件历史记录来确定对文件所做的更改。 要确定对文件所做的所有更改 1. 2. 3.
在“源代码管理资源管理器”中，选择感兴趣的文件。 右击该文件，然后单击“查看历史记录”。 在“历史记录”窗格中，查看更改历史记录以查看应用于该文件的所有更改。
其他资源
z
有关“源代码管理资源管理器”的详细信息，请参见“使用源代码管理资源管理器”，地址为： http://msdn2.microsoft.com/en-us/library/ms181370(VS.80).aspx
如何发现与一个特定工作项相关的所有代码更改 如果签入时工作项与一组代码更改相关联，则可以从该工作项的“链接”选项卡查看这些更改。 要查看与工作项关联的代码更改 1. 2. 3.
打开所讨论的工作项。 单击“链接”选项卡。如果某个变更集与该工作项关联，则会在该工作项的“链接”窗格中列出 该变更集。 双击链接的变更集以查看签入的文件和注释。
其他资源 z
有关变更集的详细信息，请参见“使用源代码管理变更集”，地址为 http://msdn2.microsoft.com/en-us/library/ms181408(VS.80).aspx
如何生成代码改动 (churn) 指标 可以使用“质量指标”报告查看代码改动的详细信息。 要查看“质量指标”报告 1. 2. 3.
在“团队资源管理器中”中，展开您的团队项目节点。 右击“报告”，然后单击“显示报告站点”。 选择“质量指标”报告。
这份报告将测试结果、bug、代码覆盖率和代码改动收集到一份报告中，您可利用这份报告来跟踪项 目的健康情况。 还可以使用 Excel 生成有关代码改动的报告。要了解详细信息，请参见本文档中的“如何在 Excel 中 创建新报告”。
如何生成工作区指标，如文件数量、代码行数和项目数量 可以通过将 Excel 直接连接到 TFS 报告 OLAP 多维数据集创建有关各种工作区指标的报告。使用 Excel，您可以采用数据透视表或数据透视图的形式显示报告数据。 要创建 Excel 数据透视表报告 1.
2. 3. 4. 5. 6. 7.
确保安装了 Microsoft SQL Server 2005 Analysis Services 9.0 OLE DB 供应者。要安装此程序， 请访问： http://www.microsoft.com/downloads/details.aspx?FamilyID=d09c1d60-a13c-4479-9b91-9e8b9d835c dc 启动 Excel。 选择要添加数据透视表报告的工作表。 在“数据”菜单中选择“数据透视表和数据透视图报告”。 选择“外部数据源”。 单击“下一步”。 单击“获取数据”。
8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19.
单击“OLAP 多维数据集”选项卡。 选择“<新数据源>”，然后单击“确定”。 为数据源输入名称。 选择 Microsoft SQL Server 2005 Analysis Services 9.0 OLE DB 供应者 单击“连接”。 选择“分析服务器”。 输入报告服务器的名称，例如，TFSRTM。 单击“下一步”。 选择“TFSWarehouse”，然后单击“完成”。 选择从中生成报告的“代码改动”多维数据集，然后单击“确定”。 再次单击“确定”，返回“数据透视表和数据透视图向导”。 单击“完成”，将数据透视表添加到工作表上。
可以使用“数据透视表字段列表”将列和测量数据拖放到数据透视表中。 要查看服务器上每个团队项目的文件计数 1. 2. 3.
将 TeamProject.TeamProject 拖动到数据透视表的“页字段”部分中。 将“File Name.FilePath”拖动到数据透视表的“行字段”部分中。 使用数据透视表“页字段”部分中的“团队项目”下拉列表筛选每个团队项目。 请注意，所显示的行数。这将为您提供文件计数。
要查看服务器上每个团队项目的行计数 1. 2.
将 TeamProject.TeamProject 拖动到数据透视表的“列字段”部分中。 将“汇总行”拖动到数据透视表的“数据项”部分中。
要查看服务器的团队项目计数 z
将 TeamProject.TeamProject 拖动到数据透视表的“行字段”部分中。 请注意，所显示的行数。这将为您提供项目计数。
其他资源 z z
有关使用 Excel 创建 Ad-Hoc 报告的详细信息，请参见“使用 Microsoft Excel 生成 Team Foundation Server 报告”，地址为：http://msdn2.microsoft.com/en-us/library/ms244713(VS.80).aspx 要安装 Microsoft SQL Server 2005 Analysis Services 9.0 OLE DB 供应者，请访问： http://www.microsoft.com/downloads/details.aspx?FamilyID=d09c1d60-a13c-4479-9b91-9e8b9d835c dc
Team Foundation 报告资源 z
有关报告的详细信息，请参见“Team Foundation Server 报告”，地址为 http://msdn2.microsoft.com/en-us/library/ms194922(VS.80).aspx
实践总览源代码管理 索引 使用版本控制 z z z
如何从非 Visual Studio 客户端使用版本控制 如何自动化常规版本控制任务 如何脱机工作
管理 z z z z
如何将一名新开发人员添加到项目中 如何从项目中移除一名已经离开的开发人员 如何在源代码树中授予权限 如何将 Team Foundation Server 版本控制移动到其他服务器
分支 / 标签 / 合并 z z z z z z z z z z z z z
如何使用标签 如何分支 如何计划分支结构 如何使用分支来为发布提供支持 如何使用分支来维护早先的发布 如何使用分支来稳定开发和生成过程 如何使用分支稳定功能开发 如何使用分支稳定跨团队的开发 如何使用分支分隔外部依赖项 如何使旧发布退役 如何执行合并 如何执行 baseless 合并 如何解决合并冲突
生成 z
如何使用 TFS 执行连续集成生成
签入和签入策略 z z z z z z z
如何使用源代码管理变更集 如何在签入之前执行编码标准 如何重写签入策略 如何撤销签入 如何解决冲突 如何避免冲突 如何创建自定义签入策略
签出、获取和锁定 z z
如何将您的计算机与 TFS 同步 如何为编辑准备文件
代码共享 z z
如何共享代码 如何管理共享的二进制文件
依赖项 z z
如何管理 Web 服务依赖项 如何管理数据库依赖项
分布式 / 远程开发 z z
如何通过 Internet 访问 TFS 如何优化 TFS 版本控制代理性能
迁移 z z
如何从 Visual SourceSafe 迁移源代码 如何从其他版本控制系统迁移源代码
项目 / 工作区管理 z z z z
如何选择一个或多个团队项目 如何组织源代码树 如何定义工作区映射 如何使用工作区来隔离计算机上的代码更改
安全性 z
如何保证开发人员工作站和 TFS 之间通道的安全
搁置 z z
如何使用搁置来备份挂起的工作 如何使用搁置来与团队成员共享代码
使用版本控制 z z z
如何从非 Visual Studio 客户端使用版本控制 如何自动化常规版本控制任务 如何脱机工作
如何从非 Visual Studio 客户端使用版本控制 通过使用以下方法之一可以从其他客户端访问 Microsoft® Visual Studio® 2005 Team System (VSTS) Team Foundation Server (TFS) 版本控制： z Microsoft Source Code Control Interface (MSSCCI) 集成 z 第三方集成 z 客户集成
MSSCCI 集成 通过使用 MSSCCI 供应者，以下客户端可以直接使用 TFS 版本控制： z z z
Microsoft Visual Studio .NET 2003 Microsoft Visual C++® 6 SP6 Microsoft Visual Basic® 6 SP6
z z z z z z
Microsoft Visual FoxPro® 9 SP1 Microsoft Access™ 2003 SP2 Microsoft SQL Server™ Management Studio Sparx Systems Enterprise Architect 61 Sybase PowerBuilder 105 Toad for SQL Server 2.0
在 Visual Studio 2005 中，MSSCCI 供应者与 TFS 版本控制在以下方面行为有所不同： z 签出还执行 GetLatest 操作。 z 为签出应用独占的签入锁。 z “从源代码管理打开”和“保存到源代码管理”行为与在 Microsoft Visual SourceSafe® (VSS) 中 的行为相同。 可以从 Microsoft MSDN® 下载 MSSCCI 供应者，地址为： http://www.microsoft.com/downloads/details.aspx?FamilyId=87E1FFBD-A484-4C3A-8776-D560AB1E61 98&displaylang=en Microsoft 不支持 MSSCCI 供应者。如果有问题，请参考 MSDN 论坛，地址为： http://forums.microsoft.com/MSDN/ShowForum.aspx?ForumID=22&SiteID=1
第三方集成 以下客户端具有其他厂商提供的集成解决方案： z z z z
Eclipse Linux 客户端 Apple Macintosh 客户端 HTML Web 客户端
如果您想从 Eclipse IDE、Linux 或 Macintosh 客户端访问 TFS 版本控制，请考虑从 http://www.teamprise.com/ 安装 Teamprise 如果您想以只读方式从 Internet 访问 TFS 版本控制，请考虑使用 Team System Web Access，地址 为：http://msdn2.microsoft.com/en-us/teamsystem/bb676728.aspx
客户集成 目前，其他客户端没有可用的集成解决方案。可以通过命令行访问 TFS 版本控制或生成您自己的 集成解决方案。 要进一步了解如何使用 TFS 版本控制，请参见“演练：通过命令行使用 Team Foundation 源代码 管理”（位于 MSDN 网站上），地址为：http://msdn2.microsoft.com/en-us/library/zthc5x3f(VS.80).aspx 可以使用控制脚本和命令文件来自动使用命令行。要了解有关使用控制脚本和命令文件的详细信息， 请参见“Team Foundation 源代码管理脚本和命令文件”（位于 MSDN 网站上），地址为： http://msdn2.microsoft.com/en-us/library/1az5ay5c(VS80).aspx
其他资源 z z
要从 MSDN 下载 MSSCCI 供应者，请访问： http://www.microsoft.com/downloads/details.aspx?FamilyId=87E1FFBD-A484-4C3A-8776-D560AB 1E6198&displaylang=en 如果您想从 Eclipse IDE、Linux 或 Macintosh 客户端访问 TFS 版本控制，请考虑从
z z z z
http://www.teamprise.com/ 安装 Teamprise 如果您想从 Internet 访问 TFS 版本控制，请考虑安装 Team System Web Access，地址为： http://msdn2.microsoft.com/en-us/teamsystem/bb676728.aspx 要进一步了解如何使用 TFS 版本控制，请参见“演练：通过命令行使用 Team Foundation 源 代码管理”，地址为：http://msdn2.microsoft.com/en-us/library/zthc5x3f(VS.80).aspx 要了解有关使用控制脚本和命令文件的详细信息，请参见“Team Foundation 源代码管理脚本和 命令文件”，地址为：http://msdn2.microsoft.com/en-us/library/1az5ay5c(VS80).aspx 要进一步了解 TFS 版本控制可扩展性，请参见“演练：版本控制对象模型”，地址为： http://msdn2.microsoft.com/en-us/library/bb187335(VS.80).aspx
如何自动化常规版本控制任务 要使常规版本控制任务自动化，请使用 Team Foundation 命令行工具 (tf.exe)。借助该工具，您可以 执行通过“源代码管理资源管理器”可以执行的所有操作，包括源代码管理操作（添加、签入、签 出、获取、锁定、标签以及更多操作）、分支、搁置、工作区操纵以及常规管理任务。 使用命令行工具的主要原因包括自动重复性操作以及预定操作在指定的时间运行或通过使用 Microsoft Windows® Task Scheduler 按指定的事件运行。以下命令也只能通过命令行使用： z z z z z
删除其他用户的工作区 撤销其他用户的签出 解除其他用户的锁定 定义标签范围 执行 baseless 合并
要确保设置相应的路径和其他环境变量，请从 Visual Studio 2005 命令提示符窗口中运行此命令行 工具，或者运行 Vsvars32 批处理文件，该文件通常位于 DriveLetter:\Program Files\Microsoft Visual Studio 8\Common7\Tools 中。 Tf.exe 作为 TFS 客户端的一部分安装，并且默认情况下位于以下文件夹中： C:\Program Files\Microsoft Visual Studio 8\Common 7\IDE。 要运行此命令行工具，必须使用 /s 切换指定服务器名称。以下命令显示了如何在名为 YourTFSServer 的服务器上查看源代码管理中的文件： tf.exe dir /s:YourTFSServer
其他资源 z z
有关详细信息，请参见“演练：通过命令行使用 Team Foundation 源代码管理”（位于 MSDN 网站上），地址为：http://msdn2.microsoft.com/en-us/library/zthc5x3f(VS.80).aspx 有关详细信息，请参见“MSDN Team Foundation 源代码管理命令行参考”，地址为： http://msdn2.microsoft.com/en-us/library/cc31bk2e(VS.80).aspx
如何脱机工作 TFS 版本控制天生不支持脱机工作。 要脱机工作，需要使用以下严格的工作流程： 1.
手动删除只读标记。默认地，工作区中所有尚未签出的文件都会标记为只读，当在没有连接服 务器的情况下工作时，必须先手动删除文件中的只读标记，然后才能编辑或删除文件。要执行 该操作，请右击 Windows 资源管理器中的文件，单击“属性”，清除“只读”复选框，然后
2. 3.
4.
单击“确定”。也可以使用 DOS 命令 attrib –r 编辑文件。现在即可编辑那些已删除了只读标记的文件。 添加或删除文件。现在即可添加或删除那些已删除了只读标记的文件。不要重命名文件，因为 TFPT 联机工具无法区分重命名操作和与添加操作成对的删除操作。 注意：您必须指定 TFPT 联机命令的选项来查看删除，因为这是非常耗时的操作。 运行 TFPT 联机命令。重新联机时，可以在命令行中键入 TFPT online，运行 TFPT 联机命令。 此命令扫描工作区中的可写文件，并确定哪些更改应在服务器上挂起。如果您删除了任何文件， 请使用 /delete 切换。这将告诉该工具在本地工作区中扫描删除的文件。该工具随后即显示一 个联机窗口，您可从中选择在工作区内挂起哪些更改。
重点：脱机时不可重命名任何文件。
其他资源 z z
要从 MSDN 下载 TFPT 工具，请访问： http://www.microsoft.com/downloads/details.aspx?FamilyID=7324C3DB-658D-441B-8522-689C557 D0A79&displaylang=en 要了解有关 Visual Studio Team Foundation Power Tool 的详细信息，请参见“Power Toy： tfptexe”，地址为：http://blogs.msdn.com/buckh/archive/2005/11/16/493401.aspx
管理 z z z z
如何将一名新开发人员添加到项目中 如何从项目中移除一名已经离开的开发人员 如何在源代码树中授予权限 如何将 Team Foundation 版本控制移动到其他服务器
如何将一名新开发人员添加到项目中 要向项目中添加新的开发人员，请授予此开发人员对团队项目以及关联的 Microsoft Office SharePoint® 项目站点的相应访问权限。要使此开发人员能够查看报告，请授予此开发人员的帐户对 SQL Server Reporting Services 的访问权限。 要授予团队项目的访问权限 1. 2. 3. 4.
使用是 Team Foundation 管理员应用程序组成员的帐户登录 Visual Studio。 将所需的项目添加到团队资源管理器中（如果其尚未列出）。 右击团队项目，指向“团队项目设置”，然后单击“组成员身份”。 选择“项目\贡献者”，单击“属性”，然后将新的开发人员的帐户添加到此组中。
注意：贡献者组中的成员身份提供了开发人员需要的一组典型的权限，包括在团队项目内添加、修 改和删除项目以及执行生成的能力。 授予 SharePoint 项目站点的访问权限 1. 2. 3. 4. 5. 6.
使用是 SharePoint 管理员站点组的成员的帐户访问团队项目站点。默认情况下，名为 YourProject 的项目的项目站点位于 http://server/sites/YourProject/default.aspx 单击“站点设置”。 在“管理”标题下，单击“管理用户”。 单击“添加用户”。 采用 domain\useraccount 格式输入新开发人员的帐户的帐户名称，选择“贡献者”，然后单击 “下一步”。 输入开发人员的电子邮件地址，并且可以选择键入欢迎此开发人员访问此站点的消息。
7.
单击“完成”。
注意：贡献者组中的成员身份提供了开发人员需要的一组典型的权限，包括在团队项目内添加、修 改和删除项目以及执行生成的能力。如果您需要限制对团队项目中的特定 Visual Studio 解决方案或 特定文件夹的访问权限，则还可以在文件夹或文件级别上分配权限。 授予对 SQL Server Reporting Services 的访问权限 1. 2. 3. 4. 5. 6.
使用管理员帐户登录 SQL Server Reporting Services 管理网站。该网站地址为 http://server/reports。 单击团队项目名。 单击“属性”选项卡。 单击“安全性”选项卡。 单击“新角色分配”。 输入您的开发人员的 Windows 帐户名，选择“浏览者”，然后单击“确定”。
注意：“浏览者”组的成员身份使开发人员能够查看和订阅报告。
其他资源 z z
有关详细信息，请参见“Team Foundation Server 默认组、权限和角色”（位于 MSDN 网站上）， 地址为：http://msdn2.microsoft.com/en-us/library/ms253077.aspx 有关详细信息，请参见“源代码管理安全权限”（位于 MSDN 网站上），地址为： http://msdn2.microsoft.com/en-us/library/ms181761.aspx
如何从项目中移除一名已经离开的开发人员 如果一名开发人员离开了您的项目，应确保删除该开发人员的工作区。该操作不仅仅有助于确保 项目的安全性，而且还删除此开发人员的挂起的任何更改并且撤销此开发人员进行的任何锁定。 注意：如果团队项目已经打开了独占锁定，则不撤销更改将无法撤销锁定。 要弄清此开发人员锁定了哪些文件，可运行如下命令： tf workspaces /owner:domain\devuser /computer:* /server:servername 要删除工作区并删除锁定，请运行以下命令： tf workspace /delete workspacename;domain\devuser /s:servername 接下来，从安全组中删除此开发人员的帐户。要执行此操作，请在以下三个位置进行更改： z
z
z
TFS 团队项目 – 使用是 Team Foundation 管理员应用程序组成员的帐户登录 Visual Studio。 使用“团队资源管理器”，右击该项目，指向“团队项目设置”，单击“组成员身份”，然后 从相关组（通常为“贡献者”）中删除此开发人员的帐户。 SharePoint 团队项目站点 – 使用管理员帐户登录团队站点，地址为： http://server/sites/yourprojectname/default.aspx。单击“站点设置”、“管理用户”，然后删除此 开发人员帐户。 SQL Server Reporting Services – 使用管理员帐户登录 SQL Server Reporting Services 管理网 站。该网站地址为 http://server/reports。单击您的团队项目名称，单击“属性”选项卡，单击“安 全性”选项卡，然后删除此开发人员的帐户。
其他资源 z z z
有关在开发人员离开项目后进行清理的详细信息，请参见“如何：在用户离开时清理文件”， 地址为：http://msdn2.microsoft.com/en-us/library/ms194958(VS.80).aspx 有关 Workspace 命令的详细信息，请参见“Workspace 命令”，地址为： http://msdn2.microsoft.com/en-us/library/y901w7se(VS.80).aspx 有关查找挂起的更改的详细信息，请参见“我如何知道谁签出或锁定了文件？”，地址为： http://blogs.vertigosoftware.com/teamsystem/archive/2006/07/24/3125.aspx
如何在源代码树中授予权限 可以在源代码树内设置文件或文件夹的权限，方法是在“源代码管理资源管理器”中右击文件或文 件夹，单击“属性”，单击“安全性”选项卡，选择要更改权限的用户或组，然后编辑权限。还可 以通过对源代码管理使用“权限”切换以及 tf.exe 命令行工具来设置权限。 尽管您可以对特定文件夹和文件应用源代码管理权限，但是默认情况下您的源代码树中的权限会从 应用于项目文件夹的权限中继承。如果您的开发人员是“项目\贡献者”应用程序组的成员，则他们 将能够读取、签出、签入、标签和锁定源文件。如果您需要为团队项目中的文件夹或源文件的子集 提供受限制的访问权限，例如，使开发人员只能在团队项目内的某些源文件上工作，您可以在文件 夹或文件级别设置权限。
其他资源 z z z
有关授予权限的详细信息，请参见“Team Foundation Server 默认组、权限和角色” （位于 MSDN 网站上），地址为：http://msdn2.microsoft.com/en-us/library/ms253077.aspx 有关授予权限的详细信息，请参见“源代码管理安全权限”，地址为： http://msdn2.microsoft.com/en-us/library/ms181761.aspx 有关 tf permission 命令的详细信息，请参见“Permission 命令”，地址为： http://msdn2.microsoft.com/en-us/library/0dsd05ft(VS.80).aspx
如何将 Team Foundation 版本控制移动到其他服务器 Team Foundation Server 不支持将服务器从一个位置复制到另一个位置，也不支持镜像。您可以备份 和还原完整的服务器，将现有服务器硬件移动到新的域或者升级到双服务器部署。但不可以执行部 分移动，例如，移动服务器中的某些项目，而保留其他项目。 Team Foundation Server 支持以下三种移动类型： z
z
z
备份还原 – 当您需要将 Team Foundation Server 移动到新的计算机时，使用此移动类型。有关 具体步骤，请参见“如何：将 Team Foundation Server 从一个硬件配置移动到另一个硬件配置”， 地址为：http://msdn2.microsoft.com/en-us/library/ms404869(VS.80).aspx 环境 – 当您需要将 Team Foundation Server 移动到新的域或工作组时，使用此移动类型。有关 具体步骤，请参见“如何：将 Team Foundation Server 从一个环境移动到另一个环境”，地址 为：http://msdn2.microsoft.com/en-us/library/ms404883(VS.80).aspx 单服务器到双服务器 – 当您需要从单服务器部署移动到双服务器部署时，使用此移动类型。有 关具体步骤，请参见“如何：从单服务器部署移动到双服务器部署”，地址为： http://msdn2.microsoft.com/en-us/library/ms404854(VS.80).aspx
移动 Team Foundation Server 时始终牢记以下考虑事项： z z
更改 TFS 应用程序层服务器名称要求所有 TFS 客户端必须连接到新的服务器名称。 如果服务器名称发生更改，则所有查询绑定的 Microsoft Office 文档将不再工作。文档被绑定 到创建它们的服务器。这包括在项目“文档”节点中在创建项目时自动创建的所有查询绑定的
z z z
Microsoft Office 文档。 如果服务器名称发生更改，则任何嵌入的与文档的链接将指向未知的服务器名称。 本地帐户位于原始 TFS 上。您必须决定是否重新创建这些帐户作为移动的 TFS 上的本地帐 户，或者作为移动的 Team Foundation Server 的新域中的域帐户。 域帐户位于原始 TFS 上，但是您可以将 TFS 移动到不信任原始域的域。您必须决定是否重新 创建这些帐户作为移动的 TFS 上的本地帐户，或者作为移动的 Team Foundation Server 的新域 中的域帐户。
移动之后，测试您的服务器以确保在转换过程中没有发生什么严重的破坏。测试应该检查以下区域： z z
所有资产是否正确移动？查看源代码树、工作项以及团队页面以确保它们都处于适当的位置。 用户帐户是否仍然可以操作？尝试使用几个不同的帐户类型登录以确保它们仍然工作。
其他资源 z
有关移动 TFS 的详细信息，请参见 http://msdn2.microsoft.com/en-us/library/ms404879(VS.80).aspx
分支 / 标签 / 合并 z z z z z z z z z z z z z
如何使用标签 如何分支 如何计划分支结构 如何使用分支来为发布提供支持 如何使用分支来维护早先的发布 如何使用分支来稳定开发和生成过程 如何使用分支稳定功能开发 如何使用分支稳定跨团队的开发 如何使用分支分离外部依赖项 如何使旧发布退役 如何执行合并 如何执行 baseless 合并 如何解决合并冲突
如何使用标签 使用标签将一组分解和文件夹组织在一起，供未来操作使用。可以为分支、合并、区分或获取文件 使用标签。标签提供了一个可在此后执行上述操作之后时返回的记号。 将标签应用于文件或文件夹 1. 2.
在“源代码管理资源管理器”中，右击文件或文件夹，然后单击“应用标签”。 在“选择项目版本”对话框中，修改您选择文件或文件夹，选择要标记的文件或文件夹的版本， 然后单击“确定”以应用标签。
应用标签时，考虑以下事项： z z z z z
标签是标记，您一次只能应用一个版本的文件或文件夹。 您可以将多个标签应用于一个版本的文件或文件夹。 通过使用“源代码管理资源管理器”应用的标签会自动应用于在其中创建它们的团队项目的根 文件夹。在同一个范围内不能创建具有同一名称的两个标签。 标签是未制定版本的对象，因此它们没有关联的历史记录。 标签是即刻应用的，因此不需要签入。
z z
Team Build 自动向与其创建的每个生成关联的文件集指定标签。 不能将标签应用于删除的项目，这意味着按标签合并将不会拾取删除的文件。
要查找现有标签 1. 2.
在“文件”菜单上，指向“源代码管理”，指向“标签”，单击“查找标签”，然后导航到该 标签。 找到标签之后，您可以从“查找标签”对话框中修改或删除该标签。
其他资源 z z
有关使用标签的详细信息，请参见“使用标签”，地址为 http://msdn2.microsoft.com/en-us/library/ms181439(VS.80).aspx 有关应用标签的详细信息，请参见“如何：应用标签”，地址为： http://msdn2.microsoft.com/en-us/library/ms181440(VS.80).aspx
如何分支 要创建分支，请使用“源代码管理资源管理器”，或通过命令行使用 tf branch 命令。 要从“源代码管理资源管理器”中分支，请右击包含您的项目源代码的顶级文件夹，单击“分支”， 然后用表明此分支的用途的文件夹名称指定目标文件夹位置，例如 MyProject_Release1.0_Branch。 要通过命令行分支，请从 Visual Studio 2005 命令提示符中使用 tf branch 命令，例如： tf branch C:\MyProject $/MyProject_Release1.0_Branch 仅当执行并行部署时需要提供分离时才使用分支。当使用分支时，将必须最终将更改合并到主要分 支中，并且由于合并导致费用并且要求您管理冲突，因此除非您需要提供分支的文件分隔，否则不 要分支。如果需要可以在以后标记生成和分支。
其他资源 z z z z
有关分支与合并的简介，请参见“分支与合并入门”，地址为： http://msdn2.microsoft.com/en-us/library/aa730834(VS.80).aspx 有关分支的详细信息，请参见“如何：分支文件和文件夹”，地址为： http://msdn2.microsoft.com/en-us/library/ms181425(VS.80).aspx 有关合并的详细信息，请参见“如何：合并文件和文件夹”，地址为： http://msdn2.microsoft.com/en-us/library/ms181428(VS.80).aspx 有关如何在 Visual Studio 2005 中进行分支与合并的详细信息，请参见“对 Team Foundation 源 代码管理进行分支和合并”，地址为： http://msdn2.microsoft.com/en-us/library/ms181423(VS.80).aspx
如何计划分支结构 分支是能够分隔的机制，它们用于允许多个开发人员在分隔中的同一文件上工作。要计划您的分支 方法，请评估常见的分支方案并根据团队大小、组成、发布计划以及生成稳定性要求来选择战略。 常见分支方案包括： z z z z
发布 – 稳定要发布的代码的分支。您可以在发布前分支，从而避免需要锁定主要分支。 维护 – 维护此前发布的生成的分支。 功能 – 分隔可能使项目其余部分不稳定的功能开发的分支。 团队 – 分隔子团队的分支，以便它们可以工作，而不容易受到中断的更改，或者它们可以面向 独特的里程碑工作。它们与功能分支非常相似。
除非分支对于开发团队是必要的，否则不要进行分支。分支会引入额外的源代码树维护及合并任务。 大多数在较短的发布周期上工作的开发团队（例如，Line-of-Business [LOB] 应用程序）从不需要分 支。在较长发布周期上工作的开发团队（例如，打包的 Independent Software Vendor [ISV] 应用程序） 很可能作为开发过程的一部分来部署分支。
其他资源 z z z z
有关分支与合并的简介，请参见“分支与合并入门”，地址为： http://msdn2.microsoft.com/en-us/library/aa730834(VS.80).aspx 有关分支的详细信息，请参见“如何：分支文件和文件夹”，地址为： http://msdn2.microsoft.com/en-us/library/ms181425(VS.80).aspx 有关合并的详细信息，请参见“如何：合并文件和文件夹”，地址为： http://msdn2.microsoft.com/en-us/library/ms181428(VS.80).aspx 有关如何在 Visual Studio 2005 中进行分支与合并的详细信息，请参见“对 Team Foundation 源 代码管理进行分支和合并”，地址为： http://msdn2.microsoft.com/en-us/library/ms181423(VS.80).aspx
如何使用分支来为发布提供支持 如果您准备好了在发布前文档生成，那么就使用发布分支。 下面是一个分支结构的示例，在创建了发布分支后，您的分支结构看起来可能就是这样： z
z
Main – 集成分支 Source 其他资产文件夹 Releases – 发布分支的容器 Release 1 – 发布分支 Source
在处理发布分支时，始终牢记以下建议： z z z
z z
何时分支 – 当您准备好进行发布时，将所有内容集成到主要分支中，然后创建可以用来在发布 之前稳定应用程序的发布分支。 何时不分支 – 如果每个发布使用一个 TFS 项目，则可以使用新的项目继续开发，而不是使用 当前项目中的分支。 分支权限： 发布之前 – 向所有开发人员分配读/写权限。 发布之后 – 向工作在热修复上的开发人员分配读/写权限，向其他人分配只读权限。 分支中的生成频率 – 生成按需执行。 分支中的测试关注点 – 非正式认可的发布。
如果以修复和必要的更改为目标，则应该使用发布分支，以便在发布之前使生成稳定。开发下一版 本的应用程序将与您的开发分支或主要（集成）分支并行的，以便它们可以获得在发布之前使更改 稳定的优势。创建最后发布生成之后，您可以将发布分支中的更改合并回开发和主要（集成）分支 中。
其他资源 z
有关分支与合并的简介，请参见“分支与合并入门”，地址为： http://msdn2.microsoft.com/en-us/library/aa730834(VS.80).aspx
z z z
有关分支的详细信息，请参见“如何：分支文件和文件夹”，地址为： http://msdn2.microsoft.com/en-us/library/ms181425(VS.80).aspx 有关合并的详细信息，请参见“如何：合并文件和文件夹”，地址为： http://msdn2.microsoft.com/en-us/library/ms181428(VS.80).aspx 有关如何在 Visual Studio 2005 中进行分支与合并的详细信息，请参见“对 Team Foundation 源 代码管理进行分支和合并”，地址为： http://msdn2.microsoft.com/en-us/library/ms181423(VS.80).aspx
如何使用分支来维护早先的发布 使用维护分支支持以前发布的生成。这与用于发布的分支非常相似，但此时随时间维护该分支，以 便支持此发布。 下面是一个分支结构的示例，在发布了应用程序并维护分支以支持此发布之后，您的分支结构看起 来可能就是这样： z
z
Main – 集成分支 Source 其他资产文件夹 Releases – 发布分支的容器 Release 1 – 维护分支 Source 其他资产文件夹
在处理维护分支时，始终牢记以下建议： z z z z z
何时分支 – 发布之后，用发布文件夹中的分支支持此发布。 何时不分支 – 如果您从不需要维护发布，则可以使用标签标记旧的发布生成并继续在主要分支 中工作。 分支权限 – 向工作在热修复上的开发人员分配读/写权限，向其他人分配只读权限。 分支中的生成频率 – 生成按需执行。 分支中的测试关注点 – 非正式认可的发布。
应该使用维护分支支持较旧版本的应用程序。可以选择将这些更改合并到主要（集成）分支中，或 使它们特定于维护分支。
其他资源 z z z z
有关分支与合并的简介，请参见“分支与合并入门”，地址为： http://msdn2.microsoft.com/en-us/library/aa730834(VS.80).aspx 有关分支的详细信息，请参见“如何：分支文件和文件夹”，地址为： http://msdn2.microsoft.com/en-us/library/ms181425(VS.80).aspx 有关合并的详细信息，请参见“如何：合并文件和文件夹”，地址为： http://msdn2.microsoft.com/en-us/library/ms181428(VS.80).aspx 有关如何在 Visual Studio 2005 中进行分支与合并的详细信息，请参见“对 Team Foundation 源 代码管理进行分支和合并”，地址为： http://msdn2.microsoft.com/en-us/library/ms181423(VS.80).aspx
如何使用分支来稳定开发和生成过程 您应该对活动的开发使用“开发”分支，对集成生成使用“主要”分支，从而避免生成中断。 下面是一个分支结构的示例，在创建了“开发”分支后，您的分支结构看起来可能就是这样：
z z
Development – 开发分支 Source Main – 集成分支 Source 其他资产文件夹
在处理开发分支时，始终牢记以下建议： z z z
z
z
何时分支 – 如果您创建每日生成并且在生成稳定性和集成方面有问题，请创建主要和开发分支 为您的每日生成提供更多可预测性。还应该考虑更严格的签入策略以提高签入质量。 何时不分支 – 如果您仅创建连续集成 (CI) 生成，或者可以预测每日生成已经非常稳定，则不 需要额外进行集成分支。 分支权限： 对于负责合并和集成的开发人员，“主要”分支应该是读/写权限，而对于其他人，则为只 读权限。 “开发”分支应该对每个人都是读/写权限。 分支中的生成频率： 在“主要”分支上每天生成。 在开发分支上生成连续集成。 关于分支的测试关注点： 在“主要”分支上执行集成、性能和安全测试。 在“开发”分支上执行功能和快速反馈测试。
将“主要”分支用作集成已经签入到开发分支中的更改的集结地。在“开发”分支中执行所有活动 的开发，然后将非中断的更改集成到“主要”分支中。
其他资源 z z z z
有关分支与合并的简介，请参见“分支与合并入门”，地址为： http://msdn2.microsoft.com/en-us/library/aa730834(VS.80).aspx 有关分支的详细信息，请参见“如何：分支文件和文件夹”，地址为： http://msdn2.microsoft.com/en-us/library/ms181425(VS.80).aspx 有关合并的详细信息，请参见“如何：合并文件和文件夹”，地址为： http://msdn2.microsoft.com/en-us/library/ms181428(VS.80).aspx 有关如何在 Visual Studio 2005 中进行分支与合并的详细信息，请参见“对 Team Foundation 源 代码管理进行分支和合并”，地址为： http://msdn2.microsoft.com/en-us/library/ms181423(VS.80).aspx
如何使用分支稳定功能开发 使用功能分支改进各功能之间中断更改的集成和稳定性。 下面是一个分支结构的示例，在创建了发布分支后，您的分支结构看起来可能就是这样： z
Development – 功能分支的容器 z Feature A – 功能分支 Source z Feature B – 功能分支 Source z Feature C – 功能分支 Source
z
Main – 集成分支 z Source z 其他资产文件夹
在处理功能分支时，始终牢记以下建议： z
z z z z
何时分支 – 功能团队通常具有源文件重叠，从而增加了潜在的生成中断和签入冲突的机会。如 果您遇到了这些问题，请考虑对每个功能使用功能分支以提供功能分隔。您可以为较小的团队 创建这些主要分支，或者为较大团队创建了团队分支。 何时不分支 – 如果您仅创建 CI 生成，或者可以预测每日生成非常稳定，则可能不需要额外进 行功能分支。 分支权限 – 向工作在功能分支上的开发人员分配读/写权限，向其他人分配只读权限。 分支的生成频率 – 在此分支上执行连续集成生成。 分支中的测试关注点 – 执行功能和快速反馈测试。
使用功能分支以允许并行开发每个功能。在功能分支中执行所有活动开发，然后将代码集成到主要 分支中。
其他资源 z z z z
有关分支与合并的简介，请参见“分支与合并入门”，地址为： http://msdn2.microsoft.com/en-us/library/aa730834(VS.80).aspx 有关分支的详细信息，请参见“如何：分支文件和文件夹”，地址为： http://msdn2.microsoft.com/en-us/library/ms181425(VS.80).aspx 有关合并的详细信息，请参见“如何：合并文件和文件夹”，地址为： http://msdn2.microsoft.com/en-us/library/ms181428(VS.80).aspx 有关如何在 Visual Studio 2005 中进行分支与合并的详细信息，请参见“对 Team Foundation 源 代码管理进行分支和合并”，地址为： http://msdn2.microsoft.com/en-us/library/ms181423(VS.80).aspx
如何使用分支稳定跨团队的开发 使用团队分支改进各团队之间中断更改的集成和稳定性。 下面是一个分支结构的示例，在创建了功能分支后，您的分支结构看起来可能就是这样： z
z
Development – 团队分支的容器 z Team 1 – 团队分支 Source z Team 2 – 团队分支 Source Main – 集成分支 z Source z 其他资产文件夹
在处理团队分支时，始终牢记以下建议： z z z z
何时分支 – 如果您的开发团队在文件和组件上有重叠，请使用团队分支分隔每个团队的工作。 还可以选择在团队分支下创建功能分支。 何时不分支 – 如果您的源代码树是按组件组织的，并且相信团队之间将不会有中断界面的更改 或大量的签入冲突，则可能不需要团队分支。 分支权限 – 向工作在团队上的开发人员分配读/写权限，向其他人分配只读权限 分支的生成频率 – 在此分支上执行连续集成生成。
z
分支中的测试关注点 – 执行功能和快速反馈测试。
应该使用团队分支以允许团队并行完成开发任务。这对于将团队从源自其他团队的中断更改分隔， 或允许团队面向独特的里程碑工作非常有用。应该在团队分支中执行所有活动开发，然后将其集成 到主要分支中。还可以选择在每个团队分支下创建功能分支。
其他资源 z z z z
有关分支与合并的简介，请参见“分支与合并入门”，地址为： http://msdn2.microsoft.com/en-us/library/aa730834(VS.80).aspx 有关分支的详细信息，请参见“如何：分支文件和文件夹”，地址为： http://msdn2.microsoft.com/en-us/library/ms181425(VS.80).aspx 有关合并的详细信息，请参见“如何：合并文件和文件夹”，地址为： http://msdn2.microsoft.com/en-us/library/ms181428(VS.80).aspx 有关如何在 Visual Studio 2005 中进行分支与合并的详细信息，请参见“对 Team Foundation 源 代码管理进行分支和合并”，地址为： http://msdn2.microsoft.com/en-us/library/ms181423(VS.80).aspx
如何使用分支分离外部依赖项 使用外部分支改进各外部依赖项之间中断更改的集成和稳定性。 下面是一个分支结构的示例，在创建了“外部”分支后，您的分支结构看起来可能就是这样： z z
External – 外部分支 z Source Main – 集成分支 z Source z 其他资产文件夹
在处理外部分支时，始终牢记以下建议： z z z z z
何时分支 – 当您具有外部依赖项，而这些依赖项可能造成项目中中断更改时。如果您的依赖项 正在进行界面更改或将影响您的代码的大量逻辑更改，则创建外部分支来分隔这些更改。 何时不分支 – 当您的外部依赖项稳定或者您相信它们不会引入中断更改时。 分支权限 – 对于负责外部依赖集成的开发人员分配读/写权限，而对于其他人分配只读权限。 分支中的生成频率 – 生成按需执行。 分支中的测试关注点 – 集成测试。
您应该使用外部分支作为一个独立位置来测试外部依赖项中的更改，然后将其集成到主要分支中。 这对于将开发团队从外部依赖项（如标题和库）所造成的中断更改分隔非常有用。
其他资源 z z z z
有关分支与合并的简介，请参见“分支与合并入门”，地址为： http://msdn2.microsoft.com/en-us/library/aa730834(VS.80).aspx 有关分支的详细信息，请参见“如何：分支文件和文件夹”，地址为： http://msdn2.microsoft.com/en-us/library/ms181425(VS.80).aspx 有关合并的详细信息，请参见“如何：合并文件和文件夹”，地址为： http://msdn2.microsoft.com/en-us/library/ms181428(VS.80).aspx 有关如何在 Visual Studio 2005 中进行分支与合并的详细信息，请参见“对 Team Foundation 源
代码管理进行分支和合并”，地址为： http://msdn2.microsoft.com/en-us/library/ms181423(VS.80).aspx
如何使旧发布退役 当发布文件夹中的发布分支足够旧，以至于您不再需要支持它时，请在其中创建一个 Safe Keeping 文件夹，用来存储旧发布。下面是一个分支结构的示例，在创建了 Safe Keeping 文件夹后，您的分 支结构看起来可能就是这样： z
z
z
Main – 集成分支 z Source z 其他资产文件夹 Releases – 发布分支的容器 z Release 2 – 维护分支 Source 其他资产文件夹 Safe Keeping – 保护分支的容器 z Release 1 – 保护分支 Source 其他资产文件夹
将分支从发布文件夹移动到 Safe Keeping 文件夹的目的是减少发布文件夹中的混乱，而不必删除旧 发布。这并不是一个新的分支，而是将旧分支移动到新的文件夹。
其他资源 z z z z
有关分支与合并的简介，请参见“分支与合并入门”，地址为： http://msdn2.microsoft.com/en-us/library/aa730834(VS.80).aspx 有关分支的详细信息，请参见“如何：分支文件和文件夹”，地址为： http://msdn2.microsoft.com/en-us/library/ms181425(VS.80).aspx 有关合并的详细信息，请参见“如何：合并文件和文件夹”，地址为： http://msdn2.microsoft.com/en-us/library/ms181428(VS.80).aspx 有关如何在 Visual Studio 2005 中进行分支与合并的详细信息，请参见“对 Team Foundation 源 代码管理进行分支和合并”，地址为： http://msdn2.microsoft.com/en-us/library/ms181423(VS.80).aspx
如何执行合并 使用 merge 命令将一个分支的修改合并到另一个分支中。要执行合并，可以使用源代码管理资源管 理器中的合并功能，或使用 tf merge 命令行。可以按变更集、标签、日期或版本进行合并。要开始 合并，右击源代码管理资源管理器中的分支然后单击“合并”。源代码管理合并向导允许选择要与 之合并的目标分支。 由于分支结构的不同，可能需要沿分支层次结构向上、向下合并更改，或在层次结构进行交叉合并。 对于在层次结构中交叉合并，所执行的是 baseless 合并，且必须使用 tf merge 命令行，因为不能 用 Visual Studio 来执行此操作。baseless 合并允许合并没有分支/合并关系的文件和文件夹。进行 baseless 合并后，合并关系就已经存在，并且将来的合并也不再是 baseless 合并。用户仍需通过命 令行执行合并，但合并冲突的数量将减少。 当执行合并时，要记住以下事项： z z
沿层次结构合并，从父到子或从子到父，得到比在层次结构中交叉合并更少的冲突。 分支层次结构基于分支父级和分支子级，可能与我们在源代码管理资源管理器中看到的物理结 构有所不同，例如： 物理结构： Development – 开发分支 Main – 集成分支 Releases – 发布分支的容器 z Release 1 – 发布分支 逻辑结构： Main z 开发 z Release 1
其他资源 z z
关于合并的更多信息，请参见“理解合并”，地址为 http://msdn2.microsoft.com/en-us/library/ms181427(VS.80).aspx 关于详细说明如何执行一次合并的演练，请参见“如何：合并文件和文件夹”，地址为： http://msdn2.microsoft.com/en-us/library/ms181428(VS.80).aspx
如何执行 baseless 合并 要执行 baseless 合并，可使用从 Visual Studio 2005 命令揭示使用 tf merge /baseless 命令。 例如，以下命令行将执行从源代码分支到目标代码分支的 baseless 合并。/recursive 开关用于执行 指定分支路径中所有文件和文件夹的递归合并： tf merge /baseless <<source path>> <<target path>> /recursive
示例 tf merge /baseless c:\data\proj1 c:\data proj2 /recursive 对互相之间没有直接分支关系的项进行合并的过程称为 baseless 合并。例如，我们可能想要将两个 互为兄弟的发布分支之间的更改进行合并，但不向上合并到父分支。baseless 合并只能通过命令行 使用，而不能从 Visual Studio 执行。 当执行 baseless 合并时，TFS 没有关于分支中文件之间的关系的任何信息。例如，文件的重命名将 被看作从分支中删除一个文件并创建一个新文件。由于此原因，用户必须执行比常规合并更多的手 动冲突解决。但是，用户只需执行一次冲突解决。执行 baseless 合并之后，TFS 记录历史记录并建 立文件夹/文件之间的关系。 baseless 合并只能通过命令行创建。甚至在第一次 baseless 合并之后，当两个分支之间已建立关系 时，将来的合并将必需通过命令行创建。
其他资源 z z z
关于 merge 命令语法的更多解释，请参见“Merge 命令”，地址为： http://msdn2.microsoft.com/en-us/library/bd6dxhfy(VS.80).aspx 关于合并的更多信息，请参见“理解合并”，地址为 http://msdn2.microsoft.com/en-us/library/ms181427(VS.80).aspx 关于详细说明如何执行一次合并的演练，请参见“如何：合并文件和文件夹”，地址为： http://msdn2.microsoft.com/en-us/library/ms181428(VS.80).aspx
如何解决合并冲突 要解决合并冲突，使用 Visual Studio 合并工具。如果在合并期间检测到冲突，可以自动或手动解决 冲突。如果选择手动解决冲突，即可在合并工具中保留源更改、保留目标更改或解决冲突。 在分支间合并更改、将文件获取到工作区或签入文件的新版本时，可能需要解决冲突。有三种类型 的冲突： z
版本 – 文件沿不同的路径发展演进。这可能是文件编辑、重命名、删除或撤销删除操作的结 果。
z z
文件名冲突 – 两个或两个以上的项尝试占用相同的路径。 本地改写 – 仅在获取操作过程中出现，如果用户正在尝试改写一个本地可编辑文件。
大多数冲突都可自动解决，只有版本冲突可能需要手动合并操作。手动合并在以下方案中最为常见： z 在两个分支中编辑过的文件，而且更改针对的是同一行代码。 z 执行 baseless 合并，此时 TFS 不了解分支文件关系。 合并工具显示各冲突的细节，并允许选择希望在最终合并后文件中保留的更改。用户可选择保留源 更改或目标更改，合并这二者的更改，或通过直接键入到文件中来手动修改最终版本。
解决了文件中的所有冲突后，将最终版本保存为要签入目标分支中的挂起的更改。 进行合并时要格外小心，因为很容易发生一些导致生成不稳定的错误。完成合并后，编译所得到的 源代码，并运行单元测试来测试主要中断。
其他资源 z
关于移除冲突的更多信息，请参见“如何：解决冲突”，地址为： http://msdn2.microsoft.com/en-us/library/ms181433(VS.80).aspx
生成 z
如何使用 TFS 来执行连续集成生成
如何使用 TFS 来执行连续集成生成 要在每次签入文件时都执行连续集成并重新生成项目，必须使用 Web 服务来触发生成过程。用户 可订阅 Web 服务来签入事件，以便每次签入文件时触发生成过程。要触发生成，还需要使用相应 的生成类型，以便确定生成什么配置、执行哪些生成后的步骤和测试，以及使用什么目标位置等。
其他资源 z
要从 Microsoft 下载用于触发生成过程的 Web 服务，请访问： http://download.microsoft.com/download/6/5/e/65e300ce-22fc-4988-97de-0e81d3de2482/ci.msi
签入策略 z z z z z z z
如何使用源代码管理变更集 如何在签入之前执行编码标准 如何重写签入策略 如何撤销签入 如何解决冲突 如何避免冲突 如何重写自定义签入策略
如何使用源代码管理变更集 变更集将一组与给定签入相关的更改组织到一起。用户需要在变更集上执行的常见操作如下： z z z z z
签入与工作项关联的变更集 为变更集加标签 查看变更集的细节 更改变更集的细节 回滚变更集
签入与工作项关联的变更集
1. 2. 3. 4. 5.
在 Visual Studio 的“视图”菜单上指向“其他窗口”，再单击“挂起的更改”。 输入适当的注释来反映出变更的性质。 单“工作项”图标以显示相关工作项的列表。 通过选择工作项然后指定签入操作“关联”或“解决”（如果签入意味着工作项已解决）来更 新它们。 单击“签入”将变更集签入到源代码管理服务器中。
为变更集加标签 1. 2. 3.
在 Visual Studio 中的源代码管理资源管理器中，右击团队项目文件夹，然后单击“应用标签”。 在“版本”下拉列表中选择“变更集”，键入“变更集编号”，然后单击“确定”。 在“应用标签”对话框中，键入标签名称和注释，然后单击“确定”。
查看变更集细节 z
使用 tf changeset 命令。 以下命令通过显示“变更集细节”对话框显示了有关变更集编号 1234 的细节： tf changeset 1234 利用该对话框，用户可以查看包含变更集源文件、签入注释和说明、相关的工作项以及当变更 集被签入到服务器中时所生成的任何策略警告。
更改变更集细节 z
使用 tf changeset 命令更改与变更集相关的注释和/或说明。 以下命令显示变更集 1234 的“变更集细节”对话框，并更新所显示的注释字段，以使用户能 够更改注释： tf changeset /comment:"This is a much better comment than the last one." 1234 以下命令更新与变更集 1234 相关的代码检查器和安全检查器的说明： tf changeset /notes:"Code Reviewer"="C Davis";"Security Reviewer"="F Smith" 1234
要回滚变更集并从源代码管理服务器移除更改，可使用 Team Foundation Power Tool。 使用 Team Foundation Power Tool 来回滚变更集： z
使用 Tfpt rollback 命令。 以下命令回滚变更集编号 1234。
TFPT rollback /changeset:1234 此命令将显示回滚变更集窗口。用户可以选择变更集中所包括的文件进行回滚。
其他资源 z z z
z
关于 tf changeset 命令的更多信息，请参见“Changeset 命令”，地址为： http://msdn2.microsoft.com/en-us/library/w51xa47k(VS.80).aspx 关于检索变更集的更多信息，请参见“如何：从变更集检索文件的旧版本”，地址为： http://msdn2.microsoft.com/en-us/library/ms181416(VS.80).aspx-{}要从 MSDN 下载 Team Foundation Power Tool (TFPT)，请访问： http://www.microsoft.com/downloads/details.aspx?FamilyID=7324C3DB-658D-441B-8522-689C557 D0A79&displaylang=en 要进一步了解 Team Foundation Power Tool，请参见“Power Toy：tfptexe”，地址为： http://blogs.msdn.com/buckh/archive/2005/11/16/493401.aspx
如何在签入之前执行编码标准 使用 TFS 签入策略，以确保所有代码签入到服务器中的所有代码均满足所需的编码标准。 默认的可用签入策略如下： z z z
代码分析 – 需要在签入前运行代码分析。 测试策略 – 需要在签入前完成签入测试。 工作项 – 需要将一个或多个工作项与签入关联。
默认的代码分析签入策略为托管和未托管的代码提供了代码分析检查。托管代码以静态方式分析代 码，以确保代码遵守标准的 .NET 设计规则、全局化规则、互操作规则、命名规则、性能规则、安 全规则等。如何用户需要扩展代码分析，可以开发自己的代码分析规则。 配置代码分析签入策略 1. 2. 3. 4. 5.
在团队资源管理器中，右击团队项目，指向“团队项目设置”，然后单击“源代码管理”。 单击“签入策略”选项卡，然后单击“添加”。 在“签入策略”列表中，选择“代码分析”，然后单击“确定”。 通过选择相应的复选框来指定想要执行的代码分析类型。如果选择“对托管代码执行代码分析”， 则从“托管代码分析的规则设置”列表中选择所需的规则。 单击“确定”两次。
重点：虽然以上过程可以确保开发人员每次在签入源文件时都执行已设置的策略，但他们总是可以 在签入时重写策略。如果要监视此过程以管理这种情况，则可以为策略重写事件添加检测点（hook）。
用户可以创建自定义签入策略来执行特定于项目的质量网关，例如，如果希望执行以下策略： z z z z
用户应在签入时添加注释。 用户应在签入代码之前运行额外的验收测试。 用户不使用 C# 中特定的 pragma 指令来取消 XML 文档警告。 在编译期间确保将项目配置为生成 XML 文档。
要在“添加签入策略”对话框中添加自定义策略插件，可使用 Visual Studio Team Foundation Server 软 件开发工具包（SDK）中提供的扩展功能。
其他资源 z z z z z z
关于创建和使用自定义签入策略的更多信息，请参见本指南中的“如何：在 Visual Studio Team Foundation Server 中创建自定义签入策略”。 要了解如何自定义签入策略，请参见“演练：自定义签入策略和签入说明”，地址为： http://msdn2.microsoft.com/en-us/library/ms181281(VS.80).aspx 要查看拒绝签入选定模式的示例代码，请参见“拒绝某些模式的签入策略”，地址为： http://blogs.msdn.com/jmanning/archive/2006/02/02/523125.aspx 要查看对签入实施注释的示例代码，请参见“示例签入策略：确保注释非空”，地址为： http://blogs.msdn.com/jmanning/archive/2006/01/21/515858.aspx 要了解如何注册新签入策略，请参见“我创建了一条新的签入策略！如何添加？”，地址为： http://blogs.msdn.com/jmanning/archive/2006/02/07/526778.aspx 关于代码分析工具的更多信息，请参见“代码分析工具使用准则”，地址为： http://msdn2.microsoft.com/en-us/library/ms182023(VS.80).aspx
如何重写签入策略 要重写签入策略，选择“策略失败”对话框中的“重写策略失败并继续签入”。任何拥有签入权限 的用户均可以重写签入策略。 如果想要检测团队成员对签入策略的重写，可以使用 Team Foundation Eventing Service 为签入事件 设置检查点。
其他资源 z z z
要进一步了解重写签入策略，请参见“如何：重写签入策略”，地址为： http://msdn2.microsoft.com/en-us/library/ms245460(VS.80).aspx 要了解关于 Team Foundation Eventing Service 的更多信息，请参见 “Eventing Service”，地址 为：http://msdn2.microsoft.com/en-us/library/bb130154(vs.80).aspx 要了解如何使用 TFS 对象模型来替代事件以检测策略重写，请参见 James Manning 在 MSDN 上的博客，地址为：http://blogs.msdn.com/jmanning/archive/2005/11/04/489193.aspx
如何撤销签入 要撤消文件的签入，使用 Team Foundation Power Tools（TFPT）的 rollback 命令将文件恢复到先
前版本。rollback 命令允许一次性回滚整个变更集，但用户也可以选择回滚变更集中的个别文件。 这项功能在需要撤消对错误签入的某个文件的更改时很有用，或者用于更改导致严重的集成生成问 题的情况。 撤消文件签入并恢复到先前版本 1.
通过命令行窗口（在路径中包含 \program files\microsoft team foundation server power tools 文件 夹）运行以下命令： TFPT rollback filename.cs 注意：如果知道要撤消的变更集编号，可以像下面这样在命令行提供变更集编号： TFPT rollback filename.cs /changeset:54
rollback 命令需要确保本地工作区保持最新状态。单击“是”来响应回滚变更集消息。此时用 户的工作区被来自服务器的文件更新。 3. 如果用户未在命令行指定变更集编号，则将显示“查找变更集”对话框。输入搜索标准，或简 单地单击“查找”，然后定位并选择包含要回滚签入的变更集，然后单击“回滚”。 4. 将显示“回滚变更集”对话框。由于变更集可能包含多个签入，因此用户应选择要撤消签入的 文件，然后单击“回滚”。 注意：如果用户在命令行指定了文件名，则只有命令集中的这个文件被选中。 2.
当使用 TFPT rollback 命令撤消签入时，应注意以下几点： z
z
z
z
工作区位置 – TFPT 按以下方式定位工作区：如果用户指定了文件路径作为参数来过滤回滚， 则文件路径将用于查找工作区。如果用户未指定文件路径，则将使用本地目录来识别工作区（在 本地目录被映射的情况下）。确保工具定位到正确的工作区的最简单方法是从本地映射的目标 来运行命令。 挂起的更改 – 用户不能回滚包含正在挂起的更改的变更集。如果用户强行尝试，工具将报错。 在这种情况下，用户必须将挂起的更改移动到搁置集，然后在运行 rollback 命令之前撤消或签 入所有挂起的更改。 合并场景 – 如果用户正在撤消刚刚签入的文件，可能不需要合并更改，因为在这段时间内其他 人有可能已经更新了该项。但是，如果希望撤消某个签入，而它又不是对文件所做的最新更改， 则需要进行三路合并（three-way）。服务器上的当前版本，即用户工作区中的版本和要回滚的 版本必须合并到一起。如果没有冲突，则将从文件中提取出要回滚的版本的更改，并且该版本 之后的任何更改都将被保留。 解决冲突 – 如果需要执行合并，将显示合并窗口。要解析合并，选择要合并的项然后单击“合 并”。最初将尝试自动合并，如果失败，将调用合并工具来解析合并。“自动合并所有项”按 钮将尝试自动对合并列表中的每个项执行合并，但它不会调用合并工具。
其他资源 z
要从 MSDN 下载 TFPT 工具，请访问： http://www.microsoft.com/downloads/details.aspx?FamilyID=7324C3DB-658D-441B-8522-689C557
z
D0A79&displaylang=en 要了解关于 TFPT 的更多信息，请参见“Power Toy：tfptexe”，地址为： http://blogs.msdn.com/buckh/archive/2005/11/16/493401.aspx
如何解决冲突 要解决合并冲突，使用 Visual Studio 合并工具。如果在合并期间检测到冲突，可以采用自动或手动 方式解决冲突。如果选择手动解决冲突，那么即可在合并工具中保留源更改、保留目标更改或解决 冲突。 在分支间合并更改、将文件获取到工作区或签入文件的新版本时，可能需要解决冲突。有三种类型 的冲突： z
版本 – 文件沿不同的路径发展演进。这可能是文件编辑、重命名、删除或撤销删除操作的结 果。
z z
文件名冲突 – 两个或两个以上的项尝试占用相同的路径。 本地改写 – 仅在获取操作过程中出现，如果您正在尝试改写一个本地可编辑文件。
大多数冲突都可自动解决，版本冲突是惟一可能导致手动合并操作的冲突类型。手动合并在以下方 案中最为常见： z z
在两个分支中编辑过的文件，而且更改针对的是同一行代码。 执行 baseless 合并，此时 TFS 不了解分支文件关系。
合并工具为您显示各冲突的细节，并允许选择希望在最终合并后文件中保留的更改。用户可以选择 保留源更改或目标更改、合并这二者的更改，或通过直接键入到文件中来手动修改最终版本。 解决了文件中的所有冲突后，将最终版本保存为要签入到目标分支中的挂起的更改。 合并时要注意，因为很容易出现可能导致生成不稳定的错误。完成合并后，编译所得到的源代码， 并运行单元测试来测试主要中断。
其他资源 z
关于移除冲突的更多信息，请参见“如何：解决冲突”，地址为： http://msdn2.microsoft.com/en-us/library/ms181433(VS.80).aspx
如何避免冲突 为帮助避免冲突： z
确保有效的团队交流。当在某个源文件上工作时，让其他团队成员知道你正在工作的文件，以 及要更新哪个方面。虽然自动的冲突解决方法可以解决很多冲突，但我们应避免两个或更多的
z
开发人员在相同源文件的同一个工能区上工作，这很有可能发生多人对同一行代码进行修改的 情况。相同代码行上的冲突需要手动来解决冲突，这导致合并操作的复杂化。 确定谁拥有签出的文件。在更新文件之前，要检查是否另一位团队成员已经签出了该文件。如 果发生这种情况，需要询问那位同事的工作内容，然后决定是否可以等待他们完成更改，或者 继续对同一个文件执行并行工作是否安全，因为你们正在该文件中的独立的源代码区域中进行 独立的功能工作。
查看挂起的更改 1. 2.
在“源代码管理资源管理器”中，右击要查看挂起的更改的解决方案、项目、文件夹或文件。 选择“查看挂起的更改”。
此方法将显示选中范围内所有挂起的更改。也可以按以下方式使用命令行签出工具来了解挂起的更 改： tf status /format:detailed /user:* 此命令将显示关于所有用户所做的任何挂起的更改的详细状态信息。在得到的列表中，可以看到谁 签出了哪些文件，以及挂起的更改。要查看某个特定文件的挂起的更改，可以将文件名指定为 tf.exe 的第一个参数。
其他资源 z z z
关于在工作区中查看挂起的更改的更多信息，请参见“如何：查看和管理工作区中所有挂起的 更改”，地址为：http://msdn2.microsoft.com/en-us/library/ms181400(VS.80).aspx 关于查看其他工作区中的挂起的更改的更多信息，请参见“如何：查看其他工作区中的挂起的 更改”，地址为：http://msdn2.microsoft.com/en-us/library/ms181401(VS.80).aspx 关于 tf status 命令的更多信息，请参见“Status 命令”，地址为： http://msdn2.microsoft.com/en-us/library/9s5ae285(VS.80).aspx
如何创建自定义签入策略 要创建自定义签入策略，使用策略框架所提供的插件模型。 用户可以通过创建自定义签入策略来实现自己的策略逻辑，例如，可用于检查用户在签入时是否添 加了注释或是否正确使用了正则表达式。 在策略定义过程和策略评估期间都会用到插件。策略插件要么作为独立的实用程序安装，要么作为 独立应用程序的一部分安装，并向策略框架注册，以便可以按需要加载。 策略插件必须公开以下接口： z z
IPolicyDefinition – IPolicyDefinition 接口公开了在为团队项目定义策略需要时所使用的方法。 此接口包括用于调用特定于策略插件的用户界面的方法，以允许用户轻松地定义签入策略。 IPolicyEvaluation – IPolicyEvaluation 接口公开了在签入期间用于评估策略遵从性的方法。此
接口包括接收策略操作的内容的方法，并对内容进行分析以确定已定义的策略是否满足需求。 用户可以将多个策略插件打包到同一个程序集中。唯一的需求是将插件作为单独的类来实现。 注意：这些接口在 PolicyBase 类中公开。作为实现 IPolicyDefinition 和 IPolicyEvaluation 接口的 替代方法，用户可以从 PolicyBase 中派生类。
其他资源 z z z z z z z
关于创建和使用自定义签入策略的更多信息，请参见本指南中的“如何：在Visual Studio Team Foundation Server 中创建自定义签入策略”。 要了解如何自定义签入策略，请参见“演练：自定义签入策略和签入说明”，地址为： http://msdn2.microsoft.com/en-us/library/ms181281(VS.80).aspx 要查看拒绝签入选定模式的示例代码，请参见“拒绝某些模式的签入策略”，地址为： http://blogs.msdn.com/jmanning/archive/2006/02/02/523125.aspx 要查看对签入实施注释的示例代码，请参见“示例签入策略：确保注释非空”，地址为： http://blogs.msdn.com/jmanning/archive/2006/01/21/515858.aspx 要了解如何注册新签入策略，请参见“我创建了一条新的签入策略！如何添加？”，地址为： http://blogs.msdn.com/jmanning/archive/2006/02/07/526778.aspx 关于代码分析工具的更多信息，请参见“代码分析工具使用准则”，地址为： http://msdn2.microsoft.com/en-us/library/ms182023(VS.80).aspx 关于创建新策略的更多信息，请参见“策略插件”，地址为 http://msdn2.microsoft.com/en-us/library/bb130343(VS.80).aspx
签出、获取和锁定 z z
如何将计算机与 TFS 同步 如何为编辑准备文件
如何将计算机与 TFS 同步 要使计算机与版本控制服务器同步，可使用 tf get 命令。这是确保计算机与团队中其他部分保持同 步的快捷方法，从而确保用户拥有共享工作的最新副本。要下载所有文件（而不只是过时的文件）， 可从 Visual Studio 2005 命令提示窗口运行以下命令： tf get /all 使用此命令时，计算机上任何可写的本地文件都将被重写。如果用户希望重写可写的本地文件，以 便使计算机与服务器完全同步，可按以下所示使用 /force 开关： tf get /force 虽然此命令重写可写的本地文件，但它不重写正在挂起的编辑的可写文件。如果需要保持挂起的编 辑，则在重新与服务器同步之前签入或搁置编辑。
要从 Visual Studio 执行相同的操作： 1. 2. 3.
在团队资源管理器中，双击“源代理管理”文件夹，右击服务器或团队项目，然后单击“获取 指定版本”。 选择“改写未签出的可写文件”和“强制获取已在工作区中的文件版本” 在“类型”下拉列表中，确保选中“最新版本”，然后单击“获取”。
如果希望使计算机与版本控制服务器完全同步，不要使用 Visual Studio 中的“获取最新版本”选项。 由于此命令只下载那些未在用户工作区中的文件，并且不会重写本地目录中已签出的可写文件，因 此计算机不会与服务器保持同步。
其他资源 z
关于 get 命令的更多信息，请参见“Get 命令”，地址为： http://msdn2.microsoft.com/pt-br/library/fx7sdeyf(VS.80).aspx
如何为编辑准备文件 为了准备要编辑的文件，必须首先从 Team Foundation Server 源代码管理获取最新版本，然后签出 以进行编辑。 如何为编辑准备文件 1.
在“源代码管理”资源管理器中右击，然后单击“获取最新版本”。 这将将文件最新版本的副本下载到用户计算机的工作区中。
2. 3.
右击该文件，然后单击“签出以进行编辑”。 选择所需的锁定类型。选择“无”以允许在该文件上工作时其他用户可以签入和签出文件。 通常我们推荐这种类型的共享签出，因为大多数可能发生的冲突都可以自动解决。
注意：“获取最新版本”操作不会签出文件，并且“签出以进行编辑”操作也不会执行获取操作。 用户需要分别执行这两个步骤。这种行为与 Microsoft Visual SourceSafe 行为不同。 当选择锁定类型时，需要考虑以下几点： z z z
z
共享的签出（“无”）避免了在开发过程中引入潜在的瓶颈问题，因为它能够防止其他人在相 同的文件上工作。 如果用户担心冲突导致复杂的手动合并操作，则应该只在编辑文件时才锁定文件。 选择“签出”锁定类型以防止其他用户签出和签入该文件。此选项防止其他人员编辑该文件， 从而避免开发过程中出现潜在的瓶颈问题。此选项确保用户可以将更改应用回到源代码管理数 据库，而避免其他用户对该文件做出其他更改。 选择“签入”锁定类型以允许其他用户签出文件，但防止他们签入该文件。同样，此选项确保 用户能够签入编辑，以不会导致冲突。
其他资源 z
关于 checkout 命令的更多信息，请参见“Checkout 和 Edit 命令”，地址为： http://msdn2.microsoft.com/pt-br/library/1yft8zkw(VS.80).aspx
代码共享 z z
如何共享代码 如何管理共享的二进制文件
如何共享代码 如果用户的某些源代码供多个团队项目使用，则可以选择在团队项目中管理源代码，或者为共享的 源代码专门创建一个团队项目。 使用共享源代码的团队有以下两种选项： 1. 2.
引用共享位置中的代码。 分支共享代码。
1. 引用共享位置中的代码。 在这种情况下，使用共享代码的项目可以简单地将来自共享位置的源代码映射到他们的客户机的工 作区中。这还会创建一个配置，将来自共享位置的源代码和客户端项目统一。 这种方法的优点在于，每次最新的源代码被检索到工作区中时，都能拾取共享源代码的更改。例如， 考虑有两个团队项目的情况，项目名为“Client”和“Shared Code”，其中“Shared Code”是共享 源代码的位置。为了引用来自共享位置的代码，这些项目将按以下所示共享客户机硬盘上的一个公 共路径： z z
c:\TestProject\Client c:\TestProject\Shared Code
这两个项目都将具有映射到这些本地硬盘路径上的工作区。 源代码管理文件夹 本地文件夹 $/Client
c:\TestProject\Client
$/Shared Code
c:\TestProject\Shared Code
更多相关信息，请参见“在团队生成中处理多个团队项目”，地址为： http://blogs.msdn.com/manishagarwal/archive/2005/12/22/506635.aspx 2. 分支共享代码。 在这种情况下，使用共享代码的项目可以简单地将来自共享位置的代码分支到他们相应的团队项目 中。这还会创建一个配置，将来自共享位置源代码和服务器端的项目统一。
区别在于对共享源代码的更改将作为分支之间合并过程的一部分被拾取。这使得拾取共享源代码中 的更改的决策更显而易见。 例如，考虑有两个团队项目的情况，项目名为“Client”和“Shared Code”，其中“Shared Code” 是共享源代码的位置。使用以下步骤对来自共享位置的代码执行分支操作： a. b. c. d.
在 “源代码管理资源管理器”中，右击“共享代码”的根文件夹。 选择“ 分支 ” 选项。 在“分支”对话框中，将“目标”设置为客户端团队项目的根文件夹，然后单击“确定”。 分支操作完成后，不要忘记签入已分支的源代码。
其他资源 z z z
更多相关信息，请参见“在团队生成中处理多个团队项目”，地址为： http://blogs.msdn.com/manishagarwal/archive/2005/12/22/506635.aspx 关于分支与合并的简介，请参见“分支与合并入门”，地址为： http://msdn2.microsoft.com/en-us/library/aa730834(VS.80).aspx 关于项目引用的更多信息，请参见“项目引用”，地址为： http://msdn2.microsoft.com/en-us/library/ez524kew(VS.80).aspx
如何管理共享的二进制文件 管理共享的二进制文件类似于管理共享的源代码：用户必须决定在哪里存储二进制文件，以及希望 团队如何访问这些文件。 在存储二进制文件时，以下选项可用： z z
如果某个团队明确地拥有二进制文件，则将这些文件存储在他们的团队项目中。 如果共享二进制文件没有明确的所属权，可专门为这些共享二进制文件创建一个团队项目。
在另一个项目中使用二进制文件时，以下选项可用： z z
共享二进制文件通常仅周期性更新。如果是这种情况，则将来自共享位置的二进制文件分支到 使用的团队项目中。当二进制文件变更时，可以执行合并操作以获取最新版本。 如果需要与共享的二进制文件一直保持同步，则将来自共享位置的源代码映射到客户机的本地 工作区中。
将共享的二进制文件分支到项目中 1. 2. 3. 4.
在 “源代码管理资源管理器”中，右击“共享二进制文件”的根文件夹。 选择“ 分支 ” 选项。 在“分支”对话框中，将“目标”设置为客户端团队项目的根文件夹，然后单击“确定”。 分支操作完成后，不要忘记签入已分支的源代码。
无论使用工作区映射还是分支，都应该使用能够明确共享二进制文件在项目中的位置的命名约定， 例如： z
Main Source – 包含此项目的代码 Lib – 包含共享的二进制文件
其他资源 z z z
更多相关信息，请参见“在团队生成中处理多个团队项目”，地址为： http://blogs.msdn.com/manishagarwal/archive/2005/12/22/506635.aspx 关于分支与合并的简介，请参见“分支与合并入门”，地址为： http://msdn2.microsoft.com/en-us/library/aa730834(VS.80).aspx 关于项目引用的更多信息，请参见“项目引用”，地址为： http://msdn2.microsoft.com/en-us/library/ez524kew(VS.80).aspx
依赖项 z z
如何管理 Web 服务依赖项 如何管理数据库依赖项
如何管理 Web 服务依赖项 通常，产品中的 Web 服务统一资源定位器（URL）引用与开发和测试环境中的引用不同。为了促 进每个 Web 服务 URL 引用的管理，在用户配置文件中应指定 URL 值，且开发人员和测试人员 可以在不影响主 App.config 文件的情况下修改配置文件。要实现这一点，用户可以将 Web 服务的 URL 行为属性设置为 Dynamic。存储并从用户配置文件中引用 Web 服务 URL。 默认情况下，当用户添加 Web 引用时，Visual Studio 将此属性的值设置为“Dynamic”。 验证此值是否仍设置为 Dynamic 1. 2. 3.
在解决方案资源管理器中，展开 Web 引用的列表。 选择列表中的各 Web 引用。 对于每个 Web 引用，检查 URL 行为属性的值是否被设置为 Dynamic。
在用户配置文件中指定 Web 服务 URL 当第一次添加 Web 引用时，App.config 文件类似于以下所示： <configuration> <configSections> <sectionGroup name="applicationSettings" type="System.Configuration.ApplicationSettingsGroup, System, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" > <section name=" SomeService.Properties.Settings"
type="System.Configuration.ClientSettingsSection, System, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" requirePermission="false" /> </sectionGroup> </configSections> <applicationSettings> <YourProject.Properties.Settings> <setting name="SomeService_ localhost _Service" serializeAs="String"> <value>http://localhost/someservice/Service.asmx</value> </setting> </ YourProject.Properties.Settings> </applicationSettings> </configuration>
此文件有一个新的配置部分，包含 Visual Studio 在生成此代理时所找到的 Web 服务的地址。 创建 User.config 文件 1. 2. 3.
在“解决方案资源管理器”中，右击包含 Web 服务的项目，指向“添加”，然后单击“新建 项目”。 选择“应用程序配置文件”，更改 User.config 的名称，然后单击“添加”。
将应用程序配置文件（App.config）中的 <YourProject.Properties.Settings> 元素设置复制到 User.config 文件。该文件应仅包含运行时为之重定向的元素。删除 <?xml> 指令和 <configuration> 元素（如果存在），如以下示例所示： <YourProject.Properties.Settings> <setting name="SomeService_localhost_Service" serializeAs="String"> <value>http://localhost/someservice/Service.asmx</value> </setting> </ YourProject.Properties.Settings>
4.
在解决方案资源管理器中，右击 User.config 文件，单击“属性”，然后将“复制到输出目录” 属性设置为“更新时复制”。
开发人员应该将他们的 User.config 文件设置为引用适当的 Web 服务 URL 引用。 当访问 Web 服务 URL 时，更新用于引用 User.config 文件的 App.config 文件 1.
2.
为主应用程序配置文件的 <YourProject.Properties.Settings> 元素添加一个 configSource="user.config" 属性。访问此部分的信息时，这会静默地将运行时重定向到命名用 户配置文件。 删除 <YourProject.Properties.Settings> 元素的内容。 用户的 App.config 现在应类似于如下形式： <?xml version="1.0" encoding="utf-8" ?>
<configuration> <configSections> <sectionGroup name="applicationSettings" type="System.Configuration.ApplicationSettingsGroup, System, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" > <section name="SomeService.Properties.Settings" type="System.Configuration.ClientSettingsSection, System, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" requirePermission="false" /> </sectionGroup> </configSections> <applicationSettings> <YourProject.Properties.Settings configSource="user.config"> </ YourProject.Properties.Settings> </applicationSettings> </configuration>
在上述示例中，YourProject 是包含 Web 服务引用的项目的名称。确保在 App.config 文件中 <SomeService.Properties.Service> 元素为空。 重点： z 不要将 User.config 文件添加到源代码管理中。这样，每位开发人员（以及测试团队）都可以通 过使用其自己的 User.config 文件来显式地绑定到指定的 URL。为避免出现这种情况，首次签 入文件时，清除 User.config 文件复选框。然后，用户可以右击解决方案资源管理器中的文件并 选择“隐藏挂起的更改”选项以确保文件不在源代码管理中出现。 z 源代码管理可以包含其他 User.config 文件，例如，用于测试和生产的 User.config 文件。这些 文件应该由负责测试和生产环境的用户来管理。这些测试和生产 User.config 文件不应作为 Web 服务项目的一部分来存储，而应存储在源代码管理系统的不同区域中。 z 在源代码管理中存储全局 User.config 文件。可以只包含根元素（没有 <setting> 元素），或可 以指定 Web 服务的默认位置。要使配置系统正常工作，User.config 文件必须出现。 有一点很重要，即要使用这种机制，User.config 文件必须存在。当创建用于产品发布以及任何测试 环境的生成时，必须由某些团队成员负责确保环境的正确性。作为此生成步骤的一部分，必须从源 代码管理系统中检索出相应的 User.confg 文件，并将其复制到正确的位置，以便 MSBuild 能够找 到它。
其他资源 z z
更多相关信息，请参见“Visual Studio .NET 中的 Web 项目和源代码管理集成”，地址为： http://msdn2.microsoft.com/en-US/library/aa290068(VS.71).aspx 关于 ApplicationSettingsGroup 类的更多信息，请参见“ApplicationSettingsGroup 类”，地址 为：http://msdn2.microsoft.com/en-us/library/system.configuration.applicationsettingsgroup.aspx
如何管理数据库依赖项 以下过程解释了如何在用户配置文件中存储并引用数据库连接字符串。
使用用户配置文件来存储数据库连接字符串 1.
为主应用程序配置文件的 <connectionStrings> 元素添加一个 configSource="user.config" 属性，如下所示： <configuration> <connectionStrings configSource=”user.config”/> </configuration>
2.
要重写主应用程序配置文件，创建一个 User.config 文件（与应用程序配置文件位于相同的文件 夹内），然后向文件添加一条类似的 <connectionStrings> 项。 注意，以下连接字符串引用了一个本地数据库： <connectionStrings> <add name="DBConnStr" connectionString="server=localhost;Integrated Security=SSPI;database=Accounts"/> </connectionStrings> </configuration>
3.
在用户的项目中，使用以下代码可以从用户配置文件获取连接字符串。 这段代码使用了 System.Configuration.ConfigurationManager 类的静态 ConnectionStrings 属性。在 Win Form 应用程序中，必须显示添加一个到 System.Configuration.dll 的引用。 using System.Configuration; private string GetDBaseConnectionString() { return ConfigurationManager.ConnectionStrings ["DBConnStr"] .ConnectionString; }
4.
确保 User.config 文件随应用程序代码一起部署。要实现这一点，在解决方案资源管理器中，右 击 User.config 文件，单击“属性”，然后在属性面板中将“复制到输出目录”属性设置为“更 新时复制”。 不要将 User.config 文件添加到源代码管理中。这样，每位开发人员（以及测试团队）都可以通 过其自己的 User.config 文件来显式地指定连接字符串。源代码管理可以包含其他 User.config 文件，例如，用于测试和生产的 User.config 文件。这些文件应该由负责测试和生产环境的用户 来管理。这些测试和生产 User.config 文件不应作为数据库项目的一部分来存储，而应存储在源 代码管理系统的不同区域中。 源代码管理中应有一个 User.config 文件，用于所使用的各种环境，例如生产和测试。这些配置 文件应指定数据库连接字符串。要使配置系统正常工作，User.config 文件必须出现。
提示：默认情况下，添加解决方案时，用户配置文件会自动添加到源代码管理中。为避免出现这种 情况，首次签入文件时，清除 User.config 文件复选框。然后，用户可以右击解决方案资源管理器中
的文件并选择“隐藏挂起的更改”选项以确保文件永远不在源代码管理中出现。 有一点很重要，即要使用这种机制，User.config 文件必须存在。当创建用于产品发布以及任何测试 环境的生成时，必须由某些团队成员负责确保环境的正确性。作为此生成步骤的一部分，必须从源 代码管理系统中检索出相应的 User.confg 文件，并将其复制到正确的位置，以便 MSBuild 能够找 到它。
其他资源 z z
关于使用配置文件来定义数据源的更多信息，请参见“演练：使用配置文件定义数据库源”， 地址为：http://msdn2.microsoft.com/en-us/library/ms243192(VS.80).aspx 关于 configSource 属性的更多信息，请参见“SectionInformation.ConfigSource 属性”，地址为： http://msdn2.microsoft.com/en-us/library/system.configuration.sectioninformation.configsource.aspx
分布式/远程开发 z z
如何通过 Internet 访问 TFS 如何优化 TFS 版本控制代理性能
如何通过 Internet 访问 TFS 可以选择以下三种方法之一来提供通过 Internet 对 TFS 进行访问： z z z
使用 VPN 连接。可以通过虚拟专用网（VPN）提供对 TFS 的访问。 通过反向代理发布 TFS。通过反向代理（例如 Microsoft Internet Security and Acceleration (ISA) Server）来提供对 TFS 的访问。 将 TFS 定位于外部网中（“寄宿方案”）。可以将 TFS 服务器寄宿到外部网上。
如果通过 VPN 访问为远程用户提供支持，则使用 VPN 解决方案。这是最容易实现的解决方案， 它提供了很好理解的安全性，允许对所有 TFS 功能进行远程访问，并且允许使用 TFS 代理来提高 性能。在这个解决方案中，您的 TFS 位于内部网，外部用户通过 VPN 访问它。内部用户直接访 问 TFS 如果不是通过 VPN 访问为远程用户提供支持，或者不访问域，则使用反向代理方案。这种解决方 案的设置更加困难，但使远程用户能够访问位于内部的 TFS，而无需 VPN。在这个解决方案中， 您的 TFS 位于内部网，一个或多个反向代理机器（如 ISA Server）将 Internet 客户端请求传入您 的 TFS。 如果一组远程用户将使用专用的（例如社区开发站点）TFS 安装，则使用外部网方案。这种解决方 案提供了远程用户与内部网络资源之间最大的分离度。在这种解决方案中，只有外部客户访问 TFS， 且访问被定位到外部网防火墙的外部。 如果办公室内有多个客户连接到远程 Team Foundation Server，则应该在远程办公室中安装和配置 Team Foundation Server Proxy。这会提高性能，因为源代码管理文件会缓存在远程办公室的代理服务 器上。
如果只有单一客户连接到远程 TFS，则可将客户配置为直接连接到 TFS。
其他资源 z z z
要进一步了解 TFS 远程访问方案，请参见本指南的“第 17 章 – 为 Team Foundation Server 提 供 Internet 访问” 要进一步了解 Team Foundation Server Proxy，请参见“Team Foundation Server Proxy 和源代码 管理”，地址为：http://msdn2.microsoft.com/en-us/library/ms252490(VS.80).aspx 关于 TFS 代理性能的更多信息，请参见“如何：检查 Team Foundation Server Proxy 的缓存性 能，地址为：http://msdn2.microsoft.com/en-us/library/ms252455(VS.80).aspx
如何优化 TFS 版本控制代理性能 在远程位置，安装和配置 Team Foundation Server Proxy。这会提高性能，因为源代码管理文件会缓 存在远程办公室的代理服务器上。 配置和优化代理性能： 1. 确保启用了缓存，并监视缓存的性能。定期监视代理服务器上的性能计数器（默认安装）和事 件日志（用于错误/警告），以便查看代理的性能。 注意：TFS 代理将性能统计数据缓存到 XML 文件（名为 ProxyStatistics.xml）；用户可以更改 保存这些统计数据的时间间隔。ProxyStatistics.xml 文件惟一代理安装目录内的 App_Data 文件 夹中。 2. 运行预定任务，定期为代理服务器检索最新文件。这有助于确保文件的最新版本在代理缓存中 可用，并确保对这些文件的后续客户请求在缓存中能够命中记录。 3. 如果用户知道要通过低带宽（< 3 Mb/秒 [Mbps]）网络来下载大文件，则可在 Web.config 中将 executionTimeout 设置为相应的值。默认的值为 1 小时 <httpRuntime executionTimeout="3600"/>。
其他资源 z z z z
要进一步了解 TFS 远程访问方案，请参见本指南的“第 17 章 – 为 Team Foundation Server 提 供 Internet 访问” 要进一步了解 Team Foundation Server Proxy，请参见“Team Foundation Server Proxy 和源代码 管理”，地址为：http://msdn2.microsoft.com/en-us/library/ms252490(VS.80).aspx 关于检查 TFS 代理性能的更多信息，请参见： http://msdn2.microsoft.com/en-us/library/ms252455(VS.80).aspx 要进一步了解 TFS Proxy File Cache Server，请参见 MSDN 网络广播，地址为： http://msevents.microsoft.com/CUI/WebCastEventDetails.aspx?culture=en-US&EventID=103229112 0&CountryCode=US
迁移 z z
如何从 Visual SourceSafe 迁移源代码 如何从其他版本控制系统迁移源代码
如何从 Visual SourceSafe 迁移源代码 要从 VSS 迁移源代码，请执行以下步骤。 注意：只有 Team Foundation 管理员组的成员才能执行这些步骤。 1. 2.
准备 VSS。准备迁移前要先备份 VSS 数据库，以确保文件被签入，并运行 Visual SourceSafe Analyze 工具来识别和解决现有数据库中的数据完整性问题。 分析项目。使用转换器命令行工具（VSSConverter.exe），按以下方式来传递分析命令开关以及 XML 设置文件的名称：
VSSConverter analyze conversionsettings.xml 以下是一个 XML 设置文件的样例： <?xml version="1.0" encoding="utf-8" ?> <SourceControlConverter> <ConverterSpecificSetting> <Source name="VSS"> <VSSDatabase name="c:\VSSDatabase"></VSSDatabase> </Source> <ProjectMap> <Project Source="$/MyFirstProject"></Project> <Project Source="$/MySecondProject"></Project> </ProjectMap> </ConverterSpecificSetting> </SourceControlConverter> 设置文件包含 VSSDatabase 的名称。将 name 属性设置为指向包含源 safe .ini 文件的文件夹。 Project 元素定义了要在 VSS 数据库中转换的项目的路径。要迁移整个 VSS 数据库，使用 <Project Source="$/"></Project>。 VssConverter.exe analyze 命令还将生成一个 usermap.xml 文件。通过添加到此文件的映射，用户可 以更改与版本历史关联的名称，从 VSS 登录名更改为 TSF Windows 登录名。 3.
迁移项目。选择要迁移的文件夹，然后使用 VSSConverter.exe，并按以下方法设置 migrate 参 数：
VSSConverter migrate conversionsettings.xml 这里需要再次传递配置设置 XML 文件，但需要添加两个重要的元素： <?xml version="1.0" encoding="utf-8" ?> <SourceControlConverter> <ConverterSpecificSetting>
<Source name="VSS"> <VSSDatabase name="c:\VSSDatabase"></VSSDatabase> </Source> <ProjectMap> <Project Source="$/MyFirstProject" Destination="$/MyTeam_ProjectOne"></Project> <Project Source="$/MySecondProject" Destination="$/MyTeam_ProjectTwo"></Project> </ProjectMap> </ConverterSpecificSetting> <Settings> <TeamFoundationServer name="YourTFSServerName" port="PortNumber" protocol="http"></TeamFoundationServer> </Settings> </SourceControlConverter> 注意在 <Project> 元素上添加了 Destination 属性。此属性指向 TFS 中的团队项目（先前必须已创 建此项目）。还要注意，添加了 <Settings> 元素，它包含 TFS 应用程序层的连接细节。
其他资源 z z z
关于如何准备迁移的更多信息，请参见“演练：准备从 Visual SourceSafe 迁移到 Team Foundation”，地址为：http://msdn2.microsoft.com/en-us/library/ms181246(en-us,vs.80).aspx 关于如何执行迁移的更多信息，请参见“演练：从 Visual SourceSafe 迁移到 Team Foundation”， 地址为：http://msdn2.microsoft.com/en-us/library/ms181247(VS.80).aspx 关于 Visual SourceSafe 转换器的限制的更多信息，请参见“Visual SourceSafe 转换器限制”， 地址为：http://msdn2.microsoft.com/en-us/library/ms252491(VS.80).aspx
如何从其他版本控制系统迁移源代码 可以手动从要迁移出的原版本控制系统中导出文件，再将其导入 Team Foundation Server 版本控制 中。如果想要保留要从其迁移的版本控制系统的文件历史或其他属性，可使用 Team Foundation Server Version Control 对象模型来编写自己的迁移工具。 Microsoft 目前正在研发一种 ClearCase 转换器。当此转换器可用时，将在 TFS Migration 博客上发 布公告，地址为：http://blogs.msdn.com/tfs_migration ComponentSoftware 创建了一种与 GNU RCS、CS-RCS、GNU CVS、Subversion (SVN) 和 Visual SourceSafe (VSS) 兼容的转换器。
其他资源 z z z
要下载 Visual Studio Team Foundation Server SDK，请访问： http://go.microsoft.com/fwlink/?linkid=68586 要进一步了解 Team Foundation Version Control 可扩展性，请参见“演练：版本控制对象模型”， 地址为：http://msdn2.microsoft.com/en-us/library/bb187335(VS.80).aspx 关于 Component Software 转换器的更多信息，请参见 ComponentSoftware Web 站点，地址为：
http://www.componentsoftware.com/Products/Converter/
项目/工作区管理 z z z z
如何选择一个或多个团队项目 如何组织源代码树 如何定义工作区映射 如何使用工作区来隔离计算机上的代码更改
选择一个团队项目还是多个团队项目 为了规划项目结构，需要评估公共的项目组织策略，并选择最适合组织规模、服务器约束和过程工 作流的策略。项目应代表组织中最大的工作单元。用户应首选单一项目而不是创建多个项目。只在 理由充足的情况下使用多个项目，例如，团队变更或从一个版本到另一个版本有重大变更，并且用 户不想产生不需要的工作项（bug 等），或者流程模板发生更改等等。 创建单一项目的最大优点在于，它能够简化需要、功能、方案和 bug 在版本之间的移动。 最重要的决策点是： z z
是否不希望维护从一个版本到另一个版本的工作项和其他资产？如果是，则选择在同一个项目 中保持所有版本。 当迁移到新版本时，是否希望从头创建一个新的流程和工作项结构？如果是，则选择为每个版 本创建一个新的项目。
公共项目结构包括： z
z
每个应用程序均有一个项目。使用单一项目来包含应用程序的所有版本。在项目中为每个发布 创建一个分支。 使用此结构的原因：更容易带入将来的代码、工作项和其他资产。 不使用此结构的原因： 强制平行发布共享工作项架构、签入策略和过程指南。 报告更加困难，因为报告默认针对整个项目，必须在发布前添加筛选。 如果您有数以百计的应用程序，每个应用程序都处于自己的项目之中，那么就会遇到 TFS 可伸缩限制的问题。 您将积累下来自多次发布的“累赘”。清除这种累赘的最简单办法是创建一个新的项 目，并对要带入到项目中的代码执行分支操作。 每个发布均有一个项目。为应用程序的每个版本创建一个新的项目。 z 使用此结构的原因： 如果要在每次发布后都能够从一个“干净”的项目开始，则这种结构最适用。 原有的项目可用于维护并被传递给独立的维护工程师团队。 很容易将源代码从一个项目移动到另一个项目。 z 不使用此结构的原因： 很难将工作项和 TFS 资产从一个项目移动到另一个项目。在向另一个移动时，工作 项只能有一个副本。如果用户希望移动一组工作项，则必须手动操作或编写自己的实
用程序。 如果正在管理数百个项目，可能会遇到 TFS 可伸缩性限制问题。
选择战略时始终牢记以下考虑事项： z z
z
选择一种可长期使用的结构，因为重新设计已有团队项目的结构困难至极。 可在团队项目间轻松共享源代码，如下所示： 将源代码从一个项目分支到另一个项目。 将源代码从另一个项目映射到您的工作区中。 使用用于 Agile Software Development Process (MS Agile) 的 Microsoft 解决方案框架（MSF）， Team Foundation Server 大约可伸缩至 500 个项目，而使用 MSF CMMI 过程，可伸缩至 250 个项目。如果创建自己的过程或定制现有过程，则要记住工作项模式对服务器可伸缩性有极大 的影响。复杂的架构将得到支持更少项目的服务器。
其他资源 z
关于项目策略的更多信息，请参见 Eric Lee 的博客“何时使用团队项目”，地址为： http://blogs.msdn.com/ericlee/archive/2006/08/09/when-to-use-team-projects.aspx
如何组织源代码树 源代码树结构包含文件夹结构、文件结构和分支结构的组合。在主分支内，以下文件夹和文件结构 已证明适用于多种规模的团队： z Main – 为发布产品所需的一切资产的容器 z Source - 生成所需的全部内容的容器
z z z
Code – 源代码容器 Shared Code – 从其他项目共享的源代码容器 Unit Tests – 单元测试容器 Lib – 二进制依赖项的容器 Docs – 将随产品一起提供的文档的容器 Installer – 安装程序源代码和二进制文件的容器 Tests – 测试团队测试的容器
从主分支创建的任何分支都会将此文件夹和文件结构复制到新的分支中，例如： z
Development – 开发分支 Source – 生成所需的全部内容的容器 Code – 源代码容器 Shared Code – 从其他项目共享的源代码容器 Unit Tests – 单元测试容器 Lib – 二进制依赖项的容器 Main – 集成分支
z
Source – 生成所需的全部内容的容器 Code – 源代码容器
Shared Code – 从其他项目共享的源代码容器 Unit Tests – 单元测试容器 Lib – 二进制依赖项的容器 Docs – 将随产品一起提供的文档的容器 Installer – 安装程序源代码和二进制文件的容器 Tests – 测试团队测试的容器
其他资源 z
关于创建工作区的更多信息，请参见“如何：创建工作区”，地址为： http://msdn2.microsoft.com/en-us/library/ms181384(VS.80).aspx
如何定义工作区映射 定义工作区映射，以便将服务器上的源代码管理文件和文件夹映射到本地驱动器。 为尚未复制到硬盘上的项目创建工作区映射 1. 2. 3.
在“源代码管理资源管理器”中，选择源代码根文件夹。 右击并选择“获取最新版本”。 选择要将工作区映射到的本地文件夹。
为尚未复制到硬盘上的项目修改工作区映射 1. 2.
选择“文件->源代码管理->工作区”。 使用“管理工作区”对话框来添加、移除或编辑现有工作区。
查看现有工作区映射 1. 2.
在“源代码管理资源管理器”中，选择源文件夹。 右击并单击“属性”。 “本地名称”字段中将出现到本地驱动器的工作区映射。
在创建工作区映射时，请考虑以下最佳实践： z
z
z z
在团队项目的根级别创建映射。对于新的团队项目，将团队项目的根（$/MyTeamProject）映射 到本地驱动器上的同名文件夹，例如 C:\TeamProjects。由于映射是递归的，所以将自动创建整 个本地文件夹结构，且此结构与源代码管理中的结构完全相同。 使用共享计算机上的惟一本地文件夹路径。一台计算机的两名用户无法共享相同的工作区映射。 例如，您和您的同事无法将同一个团队项目 ($/MyTeamProject) 映射到本地计算机的同一文件 夹。相反，在“我的文档”下面创建映射（虽然这将导致位置路径过长），或在本地计算机上 建立一个以团队文件夹命名约定（例如 C:\TeamProjects\User1, C:\TeampProjects\User2 etc）。 可能不需要整个树。为提高性能并减少磁大小需求，只映射开发项目所需的文件。通常，我们 只需要使用与正工作的解决方案有关的文件和项目。 避免使用工作区映射来支持跨项目依赖项。通常，我们应该避免跨团队项目的依赖项，并尝试
将所有相关的/依赖的解决方案项目放置在同一个团队项目中。这将减少生成脚本定制的需求。 如果有一个依赖项，则使用项目引用来定义依赖项，或将其从共享的项目中分支到自己的项目 中。应避免使用文件引用，因为文件引用管理起来更困难。例外情况是当并行开发依赖项目且 需要实时更改的时候。在这种情况下，可以考虑使用工作区映射。我们仍可考虑通过分支操作 来创建一个隔离的缓冲区（如果依赖代码引起太多中断的更改）。
其他资源 z z
关于创建工作区的更多信息，请参见“如何：创建工作区”，地址为： http://msdn2.microsoft.com/en-us/library/ms181384(VS.80).aspx 关于编辑工作区的更多信息，请参见“如何：编辑工作区”，地址为： http://msdn2.microsoft.com/en-us/library/ms245466(VS.80).aspx
如何使用工作区来隔离计算机上的代码更改 开发人员可以创建两个工作区，一个包含对团队其他人员正工作的文件和文件夹的引用，另一个包 含想要隔离的文件和文件夹。用户可能希望隔离这些文件，以便随着正在某处发生的工作来并行演 进特定的文件。例如，这可用于处理有风险的挂起的更改，或进行代码评审。 创建一个次要工作区 1. 2. 3. 4.
5.
在“源代码管理资源管理器”中，单击“工作区”下拉列表，然后单击“工作区”。 在“管理工作区”对话框中，单击“添加”。 在“添加工作区”对话框中，输入新的工作区名称（例如 MyIsolatedWork），并提供一个注 释用于将来提醒此工作区的目的。 在“工作文件夹”下拉列表中，将工作区状态设置为“活动”，将源代理管理文件夹标识为包 含在工作区中（这可能是团队项目的根文件夹或任何子文件夹），然后在自己的计算机上指定 本地文件夹路径，以便包含来自工作区的文件。 单击“确定”，再单击“关闭”来创建一个隔离的工作区。
要为在独立工作区中开始工作而检索最新源代码集 1. 2.
在“源代码管理资源管理器”中，确保在“工作区”下拉列表中选中隔离的工作区名称。 选择团队项目根文件夹（或子文件夹，如果只需源树的一部分），右击然后再单击“获取最新 版本”。 这将从源代码管理服务器把文件夹结构以及最新的文件设置复制到已映射到新工作区的计算机 上的本地目录中。
其他资源 z z
关于创建工作区的更多信息，请参见“如何：创建工作区”，地址为： http://msdn2.microsoft.com/en-us/library/ms181384(VS.80).aspx 关于编辑工作区的更多信息，请参见“如何：编辑工作区”，地址为： http://msdn2.microsoft.com/en-us/library/ms245466(VS.80).aspx
安全性 z
如何保护开发人员工作区与 TFS 之间的通道
如何保护开发人员工作区与 TFS 之间的通道 为保护开发人员工作区与 TFS 之间的通道，可将 TFS 配置为使用 HTTPS 和安全套接字层（SSL） 加密。可以将 TFS 配置为只使用 HTTPS 和 SSL，同时禁用 HTTP 连接。为实现这一点，必须首 先将 TFS 配置为启用 HTTPS 和 SSL，然后执行其他的步骤来要求 HTTPS 和 SSL。 使用 HTTPS 和 SSL 对 TFS 与请求访问 Team Foundation Server 的 Web 资源（包括团队项目门 户、报告和工作项）的 Team Foundation 客户之间的网络流量进行加密。
其他资源 z z
z
更多相关信息，请参见“用 HTTPS 和安全套接字层（SSL）来保护 Team Foundation Server， 地址为： http://msdn2.microsoft.com/en-us/library/aa395265(VS.80).aspx 关于如何用安全套接字层（SSL）来设置 TFS 的更多信息，请参见“演练：用安全套接字层（SSL） 来设置 Team Foundation Server”，地址为： http://msdn2.microsoft.com/en-us/library/ms242875(VS.80).aspx 关于如何将 TFS 配置为只使用 HTTPS 和 SSL 的更多信息，请参见“如何：将 Team Foundation Server 配置为只使用 HTTPS 和 SSL”，地址为： http://msdn2.microsoft.com/en-us/library/aa395285(VS.80).aspx
搁置 z z
如何使用搁置来备份挂起的工作 如何使用搁置来与团队成员共享代码
如何使用搁置来备份挂起的工作 要将挂起的更改备份到服务器，需要搁置尚未签入的文件。这可以确保将源代码上载到服务器，而 不签入部分完成的工作，因为这可能导致生成不稳定。 搁置一组挂起的更改 1. 2. 3.
为查看挂起的更改，在“解决方案资源管理器”中右击解决方案，然后单击“查看挂起的更改”。 选择想要搁置的文件，然后单击“搁置”。 键入搁置集名，以及表示搁置集用途的注释，然后单击“搁置”。
在第二天恢复工作 1. 2.
在“文件”菜单上，指向“源代码管理”，然后单击“取消搁置”。 选择所需的搁置集，然后单击“取消搁置”。 Team Foundation Server 将每个搁置的修订作为挂起的更改恢复到目标工作区中（只要修订与工
作区中已挂起的更改不发生冲突）。
其他资源 z
关于搁置挂起的更改的更多信息，请参见“如何：搁置和取消搁置挂起的更改”，地址为： http://msdn2.microsoft.com/en-us/library/ms181404(VS.80).aspx
如何使用搁置与团队成员共享代码 要搁置源代码以便与团队成员共享，需执行“获取最新版本”操作，以便使工作区与最新的服务器 版本保持同步，然后生成自己的应用程序以确保其编译。使用“源代码管理资源管理器”搁置源代 码。然后，接收被传递的代码的团队成员需要搁置代码。 当用户的工作需要由另一位团队成员完成时，搁置功能很有用，在这种情况下，可以搁置更改以便 使传递更容易。通过同步最新的代码，可以将更改合并到已移到用户工作区之外的源文件中。 从源代码管理资源管理器搁置文件夹和文件 1. 2. 3.
在源代码管理资源管理器中，右击并选择“搁置挂起的更改”。 在“搁置 – 源文件”对话框中，在“搁置名称”框中输入装置名称，例如shelvetest。 在“注释”框中，输入“Testing my shelveset”然后单击“搁置”。 文件和文件夹被复制到源代码管理服务器中，这时其他团队成员可以取消搁置。 当其他团队成员取消搁置时，TFS 将每个搁置的修订作为挂起的更改恢复到目标工作区中（只 要修订与工作区中已挂起的更改不发生冲突）。
取消搁置一组挂起的更改 1. 2. 3. 4. 5. 6.
在 Visual Studio 2005 Team System 中，指向“源代码管理”，然后单击“取消搁置”。 在“所有者名称”框中，输入搁置集创建者的名称（例如 ADVENTUREWORKS\JuanGo 或简 写为 juango），然后单击“查找”。 在结果窗格中，选择要恢复到工作区中的搁置集，然后单击“细节”。 如果想要从 TFS 源代码管理服务器删除搁置集，则清除“在服务器上保留搁置集”选项。 （可选）如果不需要与要恢复的搁置集相关的工作项和签入说明，则清除“恢复工作项和签入 说明”选项。 当“详细信息”对话框出现时，选择想要恢复到工作区中的搁置集或搁置集项，然后单击“取 消搁置”。
其他资源 z
有关更多信息，请参见“如何：搁置和取消搁置挂起的更改”，地址为： http://msdn2.microsoft.com/en-us/library/ms181404(VS.80).aspx
源代码管理资源 z
关于 Team Foundation Server 源代码管理的更多信息，请参见“Team Foundation 源代码管理”， 地址为：http://msdn2.microsoft.com/en-us/library/ms181237(VS.80).aspx