微软 TeamFoundation 服务器秘籍（二）_web 体验中并不会公开所有集合级别管理。对于集合级别的所有管理操作,请使用 team

原文：annas-archive.org/md5/bd0c745fa9f073f50479ad01a83e6124

译者：飞龙

协议：CC BY-NC-SA 4.0

第五章：测试您的应用程序

“在水面上行走和从规范中开发软件很容易……如果两者都被冻结！” –Edward Berard

本章将涵盖以下内容：

• 在 CI 流水线中使用 TFBuild 运行 NUnit 测试

• 创建和设置机器组

• 通过 TFBuild 任务部署测试代理

• 在实验室机器组中分发测试执行

• 使用 TFBuild 在 Selenium 测试网格上触发 Selenium Web 测试

• 在 TFBuild 中集成云负载测试服务

• 从运行视图分析测试执行结果

• 从 TFS 导出和导入 Excel 中的测试用例

• 复制和克隆测试套件和测试用例

• 从测试中心导出测试工件和测试结果

• 在 Team Portal 的仪表板上绘制测试状态图表

介绍

软件团队时刻面临着交付更多、更快的压力。最终用户期望软件能正常工作。低质量的软件是不可接受的。但你可能会问，什么才是正确的质量标准呢？质量是一个非常主观的概念；因此，团队需要就其软件的质量标准达成一致。无法定义质量的团队通常会以覆盖率为测试目标，而非关注质量本身。

Team Foundation Server 中的工具包提供了手动和自动化测试的工具。Microsoft Test Manager（MTM），首次在 TFS 2010 中引入，使测试人员能够计划、跟踪和运行手动、探索性以及自动化测试。尽管 Test Manager 与 TFS 完全集成，但它并未与其他测试平台进行集成。Test Manager 的架构不支持扩展性。微软有支持每个开发者和每个应用的宏大目标；然而，无法在非 Windows 平台上运行的工具无法实现这一目标。测试工具正在逐步从 Test Manager 客户端迁移到基于 Web 的 Team Web Portal，以实现扩展性、跨平台可用性和与其他测试平台的集成。以下截图展示了测试中心中已经具备的测试功能、将逐步迁移的功能以及将保留在 MTM 中的功能。要查看所有功能的完整比较，请从课程材料中下载 Microsoft Test Manager Vs Test Hub Feature Comparison.png：

为了加快软件交付周期，软件测试需要融入到持续集成（CI）流水线中。为此，软件测试需要在开发过程中向左移动。测试驱动开发（TDD）使得开发人员能够编写可维护、灵活且易于扩展的代码。由单元测试支持的代码有助于识别变更的影响，并使开发人员能够自信地进行修改。除此之外，功能测试需要实现自动化。这使得软件测试人员能够专注于高价值的探索性测试，而不仅仅是覆盖测试矩阵。

DevOps 运动整体上支持将测试引入 CI 管道。TFS 中的工具已发展到支持这一点。2015 年之前的 TFS 版本配有独立的测试控制器和测试代理，而在 TFS 2015 中引入的新构建框架将测试运行器简化为构建定义中的一个任务。TFS 现在提供基于任务的开放和可扩展构建框架，不仅允许你选择自己喜欢的构建框架，还可以完全自主选择并组合你喜欢的测试框架。新的构建系统使代理成为一个通用的任务协调器，代理能够执行整个 CI 管道。这种新方法消除了管理多个单一用途代理的需求，减少了设置过程中的摩擦，并在无需繁琐配置的情况下提供了扩展选项。这还使得将其他测试框架和平台集成到同一管道中成为可能：

通过本章中的教程，你将学习如何利用构建定义中的任务按需配置测试代理，执行分布式测试，涵盖大量不同的自动化测试，如单元测试、功能性 UI 测试、Selenium 测试和远程机器组上的编码 UI 测试。我们还将探讨如何与 Visual Studio Team Systems 集成，运行云负载测试。最后，我们将查看来自测试执行的丰富测试报告和测试结果分析。

观察 TFS 中更大范围的 DevOps 能力所提供的丰富测试功能；如果你决定从现有的测试用例管理解决方案迁移到 Microsoft Test Manager，你可能会想知道迁移的可能性。我们将简要介绍几种今天可用的工具，帮助你完成迁移。最后，我们将探讨如何借助轻量级图表导出并可视化测试执行结果。

除了为手动和自动化测试人员提供世界级的工具外，TFS 还为利益相关者提供了丰富的集成测试工具。基于 Web 的测试扩展允许你直接从浏览器中对 Web 或移动应用程序进行探索性测试，支持任何平台（Windows、Mac 或 Linux）。你的利益相关者现在无需遵循预定义的测试用例或测试步骤。利益相关者可以捕捉并注释截图、记录 Bug 并共享笔记。测试会话记录并记录每一步，为开发人员提供丰富的操作日志，用于诊断应用程序和用户体验问题。阅读更多内容，请访问bit.ly/1I82pfK。

这些投资正在将测试工具从优秀提升到卓越。现在正是测试领域一个令人兴奋的时刻！

在 CI 管道中使用 TFBuild 运行 NUnit 测试

传统上，使用 NUnit 框架的开发人员需要在构建机器上安装 NUnit 测试适配器。如果构建服务器数量较少，这种方法是可行的，但当构建服务器数量较多时，就会变得非常繁琐。除了安装 NUnit 适配器，还可以通过在构建控制器属性中使用自定义程序集字段，将 NUnit 适配器的 DLL 注入到构建机器中。这种方法在基于 TFVC 的代码库中有效，但在使用 Git 仓库时会遇到一些挑战。这是使用非 Microsoft 测试框架时常见的配置地狱的例子。

新的构建框架使得运行非 Microsoft 单元测试框架变得完全无需配置。在这个食谱中，你将学习如何在构建定义中使用 Visual Studio 测试任务来运行 NUnit 测试，或者一般地运行任何非 Microsoft 单元测试框架。

准备工作

为了创建构建定义，你需要是项目构建管理员组的成员。

如何操作…

1. 启动 Team Explorer 并连接到 FarbikamTFVC 团队项目。从源代码管理资源管理器中，打开 FabrikamFiber.CallCenter.sln 文件：

2. 按照bit.ly/1XgG0UG的说明创建一个新的 NUnit 测试项目。将项目命名为 FabrikamFiber.Web.NUnit.Tests.csproj。

3. 右键点击 FabrikamFiber.Web.NUnit.Tests.csproj 项目，从上下文菜单中选择 管理 NuGet 包…：

4. 从 NuGet 包管理器中搜索并安装 NUnit 测试适配器。

5. 打开解决方案的文件夹位置，你会注意到 NUnitTestAdapter NuGet 包已经添加到包文件夹中：

6. 在 Team Explorer 的 待处理更改 视图中检查代码更改：

7. 在 FabrikamTFVC 团队 Web 门户中，导航到 BUILD 中心，点击 + 图标以添加一个新的构建定义。使用 Visual Studio 构建模板创建：

8. 在 Visual Studio 构建任务中，确保选中 恢复 NuGet 包 标志。你无需在构建或测试任务中做任何其他更改。确保代码仓库在仓库标签页中映射为 FabrikamTFVC。将构建定义保存为 FabrikamTFVC NUnit CI。你可以在 TFBuild 中创建持续集成构建定义 这一食谱中，详细了解如何设置构建定义，第四章，构建你的应用。

9. 排队构建。构建完成后，你将在构建摘要部分看到测试结果的摘要。构建成功执行了所有 NUnit 测试，且无需针对 NUnit 进行任何手动配置：

工作原理

现在我们来了解一下 TFBuild 如何识别 NUnit 测试的测试运行器。打开 FabrikamTFVC 的 NUnit CI 构建定义。在 Visual Studio 测试任务的 高级 部分，你会看到一个用于指定自定义适配器路径的字段：

在 Visual Studio 构建任务中选中恢复 NuGet 包标志后，解决方案依赖的所有 NuGet 包将被下载到代理的工作目录中。Visual Studio 测试任务会扫描代理的工作目录，查找所有的测试适配器包。在这个例子中，NUnit 测试适配器的 NuGet 包已提交到源代码管理中。在包恢复过程中，这个包会被恢复到代理的工作目录中；因此，Visual Studio 测试任务在扫描时加载了 NUnit 测试适配器。

注意

TFBuild 将测试和覆盖率结果发布到 TFS，无论使用的测试框架是什么。这一过程由 TFBuild 框架自动处理。

这种方法非常适合扩展，因为随着你增加更多机器进行测试，不需要担心手动将 NUnit 测试适配器添加到测试机器上。这也简化了测试适配器的升级。测试任务可以加载一个测试适配器的多个版本，并使用单元测试引用的适配器。

自定义测试适配器路径字段在这种情况下并未实际使用。然而，如果你的解决方案使用的单元测试框架没有关联的 NuGet 包，那么这个字段非常有用，用于指定测试适配器的路径。测试适配器的路径需要通过构建代理的源目录变量来构建。Build.SourceDirectory 变量指向构建代理中源代码已同步的目录。如果你的自定义测试适配器位于 $\\FabrikamTFVC\\myAdapters 文件夹中，你需要指定路径：$(Build.SourcesDirectory)\\src\\myAdapters\\TestAdapter.1.2。

创建和设置机器组

简单来说，机器组是机器的逻辑分组。机器组保存了组内机器的元数据、连接信息和登录详细信息。机器组可以直接在构建和发布定义中引用。在这个教程中，你将学习如何创建和设置机器组。

准备工作

场景：FabrikamTFVC 团队在 Fabrikam.lab 域中有一个实验环境。Fabrikam.lab 包括五台具有不同角色的服务器。FabrikamTFVC 团队希望能够直接从构建定义和发布定义中引用这些机器，以便在所有机器上部署测试代理并触发分布式测试运行。Fabrikam.Lab 由 Fabrikam 环境团队管理，后者不能与 FabrikamTFVC 团队共享环境凭据。在本食谱中，我们将演示 Fabrikam 环境团队为 FabrikamTFVC 团队设置和配置机器组 Fabrikam-QA 的过程：

机器组将被远程主机访问；远程主机很可能扮演构建代理或发布代理的角色。如以下图所示，远程主机与机器组处于同一网络，并与机器组建立了信任关系：

构建代理使用 Windows PowerShell 远程管理，这需要Windows 远程管理（WinRM）协议来连接到机器组中的机器。WinRM 必须在机器上启用，才能作为前提条件将其添加到机器组中。在这种情况下，Kerberos 将作为认证模式使用，因为代理和机器组在同一企业网络中。

目标机器状态 目标机器与自动化代理的信任关系 机器身份 认证账户 认证模式 认证账户在目标机器上的权限 连接类型 在企业网络中的域加入机器 受信任 DNS 名称 域账户 Kerberos 机器管理员 WinRMHTTP

在接下来的几个步骤中，我们将演示如何在一台机器上配置 WinRM，并且你将学习如何通过 WinRM 测试连接性：

1. PowerShell 2.0 和 Windows 管理框架 4.0 (bit.ly/1kNlxuW) 需要在代理和机器组中的所有机器上安装。

2. 登录到 QA-Web1.Farbikam.lab 机器，右键点击 Windows PowerShell 快捷方式并选择以管理员身份运行启动 Windows PowerShell。

3. 默认情况下，WinRM 服务配置为手动启动并已停止。执行 winrmquickconfig -q 命令会执行一系列操作：

   1. 启动 WinRM 服务。

   2. 将 WinRM 服务的启动类型设置为自动。

   3. 创建一个监听器，以便接受任何 IP 地址上的请求。

   4. 为 WS-Management 通信启用防火墙例外。

   5. 如果尚未注册，注册 Microsoft.PowerShell 和 Microsoft.PowerShell.Workflow 会话配置。

   6. 如果尚未注册，在 64 位计算机上注册 Microsoft.PowerShell32 会话配置。

   7. 启用所有会话配置。

   8. 更改所有会话配置的安全描述符，以允许远程访问。

   9. 重启 WinRM 服务使前述更改生效。

4. 接下来的几条命令将为 WinRM 准备 Kerberos 认证。

5. 增加每个会话的最大内存分配：

   winrm set winrm/config/winrs \'@{MaxMemoryPerShellMB=\"300\"}\'

6. 接下来，增加会话超时时间：

   winrm set winrm/config \'@{MaxTimeoutms=\"1800000\"}\'

7. 允许代理和机器组之间的流量不加密：

   winrm set winrm/config/service \'@{AllowUnencrypted=\"true\"}\'

8. 禁用基本认证：

   winrm set winrm/config/service/auth \'@{Basic=\"false\"}\'

9. 设置防火墙例外，允许端口5985的传入流量；这是 WinRM 在使用 HTTP 时的默认端口：

   netshadvfirewall firewall set rule name=\"Windows Remote Management (HTTP-In)\" profile=public protocol=tcplocalport=5985 remoteip=localsubnet new remoteip=any

10. 禁用客户端认证的摘要：

    winrm set winrm/config/client/auth \'@{Digest=\"false\"}\'

11. 设置服务认证使用 Kerberos：

    winrm set winrm/config/service/auth \'@{Kerberos=\"true\"}\'

12. 信任代理和机器组之间的所有连接：

    winrm set winrm/config/client \'@{TrustedHosts=\"*\"}\'Set-Item WSMan:\\localhost\\Client\\TrustedHosts *

13. 重启win-rm服务：

    Restart-Service winrm–Force

14. 为确保启用 Kerberos 认证，请运行以下命令：

    winrm get winrm/config/service/auth 

    

15. 现在，让我们验证是否在QA-Web1.Fabrikam.lab上正确设置了 WinRM。登录到实验室中的另一台虚拟机，这里以QA-Web2.Fabrikam.lab为例。右键点击 Windows PowerShell 快捷方式并选择以管理员身份运行来启动 PowerShell。执行以下命令：

    Test-Wsman –computerName QA-Web1.Fabrikam.lab

    

16. 执行以下命令以检查 WinRM 监听的端口：

    winrm e winrm/config/listener

    

    注意

    如果你想更改 WinRM 当前配置的监听端口，请执行以下命令：

    Set-Item WSMan:\\localhost\\listener\\*\\Port 8888

17. 最重要的是，验证你是否能够通过从QA-Web2.Fabrikam.lab手动运行以下命令来启动QA-Web1.Fabrikam.lab上的 Pssession。一旦你执行第一条语句，你将被提示输入凭据。输入具有管理员权限的域账户：

    $cred = get-credential

18. 执行下一条命令将使用你的域账户连接到目标服务器；DNS 将用于解析目标名称：

    Enter-Pssession -ComputerNameQA-Web1.Fabrikam.lab–Credential $cred

    

19. 按照步骤 1 到 5 在实验室中的其他机器上配置 WinRM。按照步骤 6 验证 WinRM 连接性后再继续。

如何操作…

1. 进入 FabrikamTFVC 团队 Web 门户的测试中心，在机器页面上，点击**+**图标创建一个新的机器组：

2. 按照以下截图中的内容输入详细信息：

3. 由于远程机器与Fabrikam.lab.Add建立了信任关系，因此Fabrikam.lab中的 WinRM 协议将使用 HTTP，并且所有机器的详细信息。现在，点击完成以完成设置：

它是如何工作的…

Fabrikam-QA 机器组的设置为所有机器使用统一的管理员凭据。也可以为机器组中每台独立的机器指定不同的凭据：

1. 要为每台机器输入凭据，请勾选为每台机器使用自定义凭据并结合全局凭据。

2. 密码字段在用户界面中被隐藏。此外，该字段的值也不会打印在任何日志文件中。

3. 标签为查询机器提供了一个很好的方式。在构建定义中使用测试代理部署任务时，你可以指定机器组，并使用标签来过滤包含标签的机器执行操作。

4. 目前，机器组仅支持有限的场景，主要包括本地域加入的机器和 Azure 中的独立机器。请参考 bit.ly/1NFqYma 获取完整的支持场景列表。

通过 TFBuild 任务部署测试代理

在 TFS 的早期版本中，测试控制器和代理通常作为单独的安装程序发布。虽然这些安装程序支持无人值守安装，但配置过程需要人工干预。这限制了按需扩展测试代理的能力。在 TFS 2015 中，测试控制器和代理不再作为单独的安装程序发布；相反，测试代理提供的功能已被简化为一个构建任务。在本教程中，你将学习如何在机器组中的多台机器上部署测试代理。

准备工作

场景：FabrikamTFVC 团队依赖于黄瓜框架（cucumber），由于黄瓜与构建代理上的现有框架存在冲突，无法在构建代理上安装。因此，FabrikamTFVC 团队希望将测试代理部署到 QA-App1.Fabrikam.lab 服务器上。该服务器已经是 Fabrikam-QA 机器组的一部分：

在本教程中，我们将使用 Fabrikam-QA 机器组。如果你尚未设置机器组，请按照教程 创建并设置机器组 中的指示操作。

如何操作…

1. 导航到 FabrikamTFVC 团队网站中的测试中心，在 机器 页面中，编辑 Fabrikam-QA 机器组。为机器 QA-App1.Fabrikam.lab 添加标签 Framework: Cucumber 并保存。

2. 导航到构建中心，使用空构建模板创建一个新的构建定义。确保在代码仓库标签中将仓库映射为 FabrikamTFVC。然后从测试部分添加 Visual Studio 测试代理部署 任务。该任务包括三个部分：配置 Fabrikam-QA 机器组、通过机器名称或标签选择机器，并使用标签 Framework:Cucumber 过滤机器：

3. 代理配置部分接受凭据，并且一旦安装，测试代理服务将以此身份运行。从变量选项卡创建测试代理的用户名和密码变量。将变量添加到代理配置部分。选中交互式进程选项以将代理作为交互式进程运行。如果没有请求将其作为交互式进程运行，则代理将作为 Windows 服务安装：

4. 高级部分允许你指定测试代理安装程序的位置。如果你想控制安装代理的版本，这非常有用。如果没有指定位置，将从 Internet 下载最新版本的测试代理。勾选启用数据收集选项：

5. 将构建定义保存为FabrikamTFVC Agent Deployment。从该构建定义排队一个新构建。构建完成后，导航到 QA-App1.Fabrikam.lab 服务器。测试代理已成功作为 Windows 服务安装。

它是如何工作的…

1. 构建代理从 Internet 下载测试代理安装程序到一个 temp 位置。然后将安装程序推送到远程 QA-App1.Fabrikam.lab 计算机进行安装：

2. 代理程序作为 Windows 服务安装在机器组中的计算机上：

在实验室机器组中分发测试执行

本章前面你学到了如何创建机器组并在机器组中的选定计算机上部署测试代理。TFBuild 框架提供了一个任务，用于将测试执行分发到多个测试代理。在这个配方中，你将学习如何触发跨多个测试运行器部署的测试农场进行分布式测试运行。

准备工作

场景：FabrikamTFVC 团队有超过 2,000 个自动化的代码 UI 测试，需要作为功能测试工作流的一部分执行。FabrikamTFVC 团队希望能够并行化测试执行。为此，团队希望将 Visual Studio 测试代理部署到 Fabrikam-QA 机器组中的所有计算机，然后通过在测试程序集级别分发测试执行来实现并行化：

在这个配方中，你将使用 Fabrikam-QA 机器组。如果你还没有设置机器组，按照 创建和设置机器组 配方中的说明操作。由于测试代理需要作为先决条件部署，才能分发测试，请按照 通过 TFBuild 任务部署测试代理 配方中的步骤操作，了解如何使用 TFBuild 在机器组中部署测试代理。

如何操作…

1. 在 FabrikamTFVC 团队 Web 门户中导航到构建中心，点击编辑以在编辑模式下打开 FabrikamTFVC Agent Deployment。

2. 点击**+添加一个构建步骤，然后在添加任务窗口中，选择构建**标签并添加 Visual Studio 构建任务。这个任务将用于编译测试项目：

3. 在部署标签下，添加Windows 机器文件复制任务。此任务将把测试程序集复制到需要执行测试的机器上：

4. 在测试标签下，添加使用测试代理的 Visual Studio 测试任务。这个任务将用于管理测试代理群组中的测试分发：

5. 点击关闭图标以关闭添加任务窗口。构建定义中的任务需要按照以下顺序排列：

6. 配置 Visual Studio 构建任务，以构建功能测试所涉及的解决方案：

7. 配置 Windows 机器文件复制任务，将测试程序集复制到机器组中机器上的目录中。建议使用配置变量将测试位置参数化。可以使用预配置的构建变量来构造需要复制的程序集路径，这些程序集位于构建代理的工作文件夹中。如果勾选了清理目标标志，构建引擎将在复制新文件之前删除目标文件夹中的内容。此任务的高级部分还包括一个启用并行复制文件的标志，可以使用此标志允许构建系统并行复制机器组中的机器上的二进制文件：

8. 不需要对 Visual Studio 测试代理部署任务进行更改。通过 TFBuild 任务部署测试代理配方中设置的配置将会在机器组中的所有机器上执行测试代理部署。使用测试代理的 Visual Studio 测试任务应紧随其后。选择 Fabrikam-QA 机器组作为目标机器组，在该机器组上执行测试。此外，还需要指定测试二进制文件的位置、测试程序集的模式、配置和测试执行的平台。在高级部分勾选代码覆盖率标志。你可以通过覆盖测试运行参数字段注入测试设置文件，选择性地覆盖测试设置文件中的配置：

9. 保存对构建定义的更改并排队新的构建。一旦构建完成，导航到构建摘要页面；使用测试代理的 Visual Studio 测试步骤的日志会显示测试分发的详细信息：

它是如何工作的…

让我们通过构建摘要中的测试代理任务查看 Visual Studio 测试的日志文件。如上图所示，测试 DLL 已经分发到组中的多个测试代理。分发是基于 DLL 而不是测试级别进行的。如果你的测试分布在多个项目中，这种 DLL 级别的分发可以显著减少执行时间，因为每个 DLL 都会分发到测试代理进行执行。

还值得注意的是，Windows 机器文件复制任务成功地将文件从代理工作目录移动到机器组中的C:\\Fabrikam\\FunctionalTests\\$(Build.BuildNumber)文件夹：

你将在第六章，发布你的应用中了解更多关于 Windows 机器文件复制任务的内容，因为它将在发布管理中广泛用于部署。

使用 TFBuild 在 Selenium 测试网格上触发 Selenium Web 测试

如果你的软件需要支持多个设备和浏览器，测试成本可能会显著增加。客户端脚本框架和响应式设计技术的兴起使得每个浏览器提供独特的沉浸式用户体验。随着设备和浏览器矩阵的迅速增加，几乎不可能通过手动测试覆盖所有矩阵。现在有许多商业和开源工具可以帮助开发测试自动化。Selenium 可能是最广泛使用的开源解决方案。TFS 与开源工具的结合效果更佳。在本教程中，你将学习如何通过 TFBuild 执行 Selenium 测试。

准备就绪

场景：FabrikamGit 团队使用 Selenium 自动化了功能测试。现在，团队希望通过在 Chrome、Firefox 和 Internet Explorer 中运行测试来验证功能。FabrikamGit 团队希望通过 TFBuild 触发这些测试在 Selenium 网格上执行。

请按照bit.ly/1PSjfWy中的博客文章中的说明，在 Windows 机器上设置 Selenium 网格。为了本教程的目的，我们将按照一个简单的设置，在同一台机器上同时运行 Selenium Hub 和 Node：

本书提供的课程材料包括一个 Selenium 测试项目。下载SeleniumHelloWorld.zip文件夹；或者，你也可以使用自己的 Selenium 测试项目。将Selenium.Web.Test.sln提交并发布到 FabrikamGit 仓库的主分支：

更多关于如何提交并发布更改到 Git 仓库的信息，请参阅第二章的介绍部分，设置与管理代码仓库。SeleniumHQ 网站（bit.ly/1YmqRDJ）提供了很棒的 C#教程，帮助编写 Selenium 测试。

如何操作…

1. 在 FabrikamGit 团队 Web 门户中，导航到构建中心。点击**+图标以添加新的构建定义。选择 Visual Studio 构建模板并点击创建**。在构建定义中导航到仓库选项卡，并将仓库映射到 FabrikamGit 仓库的主分支：

2. 在构建定义中，导航到构建选项卡，选择Visual Studio 构建任务。设置包含 Selenium 测试项目的解决方案名称。确保勾选了恢复 NuGet 包标志：

3. 选择 Visual Studio 测试任务，输入测试设置文件的路径，并通过覆盖 TestRun 参数字段注入 Selenium 网格的 URL：

4. 将构建定义保存为FabrikamGitSelenium。为此定义排队新的构建。构建执行完成后，您可以在构建摘要视图中查看测试结果：

它是如何工作的…

让我们从理解为什么 Selenium 网格 URL 通过覆盖 TestRun 参数字段被注入到 Visual Studio 测试任务开始。解决方案包含 Selenium 测试项目和Run设置文件。这是一个配置文件，保存了测试项目使用的测试设置。新的构建系统提供了通过覆盖 TestRun 参数字段直接传递值来覆盖Test设置文件中的值的能力，在这种特定情况下，是SeleniumTestGridURL的值。这个值被 Selenium 测试用来执行测试：

接下来，让我们查看此任务的构建执行日志文件；该文件提供了测试执行的清晰总结、持续时间和结果发布的更新：

最后但同样重要的是，TFBuild 系统会自动处理将测试结果发布回 TFS 的过程，无论使用的是哪种测试框架：

正如您在前面的截图中看到的，Selenium 测试项目的执行结果可以直接在构建摘要部分查看。

在 TFBuild 中集成云负载测试服务

“Amazon 的测试揭示：每增加 100 毫秒的加载时间，Amazon.com 的销售额就下降 1%（Kohavi 和 Longbotham 2007 年）。”

性能测试不能是事后考虑！成熟的软件团队会在开发生命周期的早期进行性能测试。进行性能测试的最大障碍是需要大量基础设施来为应用程序生成足够的负载，而这些基础设施的成本高且利用率低。如今，许多按需付费的云负载测试服务已经可用。微软还提供了与 Visual Studio 团队服务（VSTS）集成的负载测试服务。每个 VSTS 账户每月都会获得 20,000 个虚拟用户分钟的负载测试配额，免费提供。在本教程中，您将学习如何将 VSTS 云负载测试服务集成到 TFS 中的 CI 流水线。

准备就绪

Visual Studio 团队服务对于最多五人的团队是免费的。您可以在bit.ly/1lANwhA上创建一个免费账户。在本教程中，我们将使用账户tfs2015cookbook.visualstudio.com。

为了使 TFS 能够使用您的身份与 VSTS 账户进行身份验证，您需要在 VSTS 账户中生成一个个人访问令牌。请按照bit.ly/1I3kzVk上的说明生成个人访问令牌。

现在我们已经在 VSTS 中拥有了云负载测试服务和个人访问令牌，接下来需要将云负载测试服务作为端点添加到 TFS 中。添加 TFS 中的端点需要您拥有编辑项目级别信息的权限。您可以通过被添加到团队项目管理员组来获得此权限。请按照此处的说明，将云负载测试服务端点添加到 TFS。

导航到 FabrikamTFVC 团队管理控制台。在服务标签页中，点击**+图标添加一个新端点。选择通用**端点选项，并按照下图填写详细信息。将端点命名为CLD-VSTS。

如何操作…

1. 导航到 FabrikamTFVC 团队 Web 门户中的构建中心。编辑 FabrikamTFVC CI 构建定义。

2. 点击**+图标，启动添加新任务窗口。在测试标签页中，选择并添加基于云的 Web 性能测试**任务：

3. 云负载测试服务作为通用端点被添加到 Fabrikam 团队管理控制台。从注册连接下拉菜单中选择CLD-VSTS端点。输入您希望进行测试的端点。指定生成负载的位置：

4. 点击保存并触发队列一个新的构建。构建执行完成后，负载测试执行的结果将作为构建结果的一部分提供：

它是如何工作的…

你可以通过简单的配置开始对你的应用程序进行负载测试。入门非常容易，而且可以利用你 VSTS 账户中可用的免费云负载测试虚拟用户分钟。TFBuild 还包括一个基于云的负载测试任务，允许你运行多步骤的性能测试。

从运行视图分析测试执行结果

在 Team Foundation Server 2015 中，手动和自动化测试的执行结果都显示在运行页面中。该页面是 Team Web Portal 中的测试中心的新添加功能。运行页面为使用任何框架执行的测试提供了统一的分析体验。在本教程中，你将学习如何在 Team Web Portal 的运行视图中分析和处理测试执行结果。

如何操作…

1. 进入测试中心，点击运行以加载运行页面。运行页面显示了最近的测试运行。你可以一眼看到测试执行状态、测试配置、构建号、失败测试的数量和通过率：

2. 点击过滤器标签，进入过滤器视图。默认查询会显示过去 7 天的测试运行记录。修改并添加新的条件，以仅显示今天的自动化测试运行：

3. 查询将测试执行结果缩小为仅显示一次运行：

4. 双击测试运行 ID 以打开测试运行进行分析。此视图显示运行摘要，并通过图表可视化按属性、特征、配置、失败类型和解决方案来展示测试结果。与测试运行相关的任何附件也可以在此视图中查看：

5. 点击测试结果标签，查看此测试运行中执行的所有测试的列表。在 TFS 2015 之前，你需要下载 TRX 文件并在 Visual Studio 中打开它才能获取这些信息。这个视图提供了下一层的详细信息，包括测试执行时长和失败的错误消息：

6. 选择多个测试并点击创建 Bug来创建一个 Bug 类型的工作项。点击更新分析可以向测试结果添加评论。你还可以双击某个测试，进入该测试执行的更详细信息：

工作原理…

此功能为你提供了统一的测试分析体验，无论你选择使用何种框架执行测试。总的来说，你可以查询团队项目中所有可用的测试运行，深入查看特定测试运行，获取该运行的摘要视图，使用图表可视化测试运行，查询/筛选某次运行中的测试结果，深入查看特定测试结果，下载附件，最后但同样重要的是，分析测试失败并提交 Bug。

从 TFS 中导出和导入 Excel 格式的测试用例

虽然可以从 Microsoft Test Manager 和 Team Web Access 访问 TFS 中的测试用例，但你可能仍然会发现利益相关者希望从 Excel 中访问测试用例。作为偏好，部分利益相关者可能会觉得在 Excel 中记录测试用例更为方便。尽管 TFS 没有提供开箱即用的功能来导出和导入 Excel 格式的测试用例，但它提供了一个良好的软件开发工具包（SDK），可以用来创建工具以实现此类功能。在本教程中，你将学习如何使用“测试用例导出到 Excel”和“测试用例迁移 Plus（开源社区工具）”将测试用例导出到 Excel，并将测试用例从 Excel 导入到 TFS。

准备工作

下载并安装以下工具到你的机器上：

• 测试用例 导出工具：tfstestcaseexporttoexcel.codeplex.com

• 测试用例 导入工具：tcmimport.codeplex.com

注意

安装这些工具需要提升权限。安装这些工具的机器需要安装 Excel 版本。无需在 TFS 应用程序层安装这些工具。

如何操作…

从 TFS 导出测试用例

1. 启动测试用例导出工具时，你将被提示连接到 TFS。连接后，你将看到与该计划相关联的测试计划和测试套件列表。选择测试套件和导出文件位置，并填写导出的输出位置和文件名，如下图所示：

2. 导出过程为你提供以下选项：

3. 选择将每个测试套件导出到单独的工作表选项，以将每个测试套件导出到一个单独的工作表。在上面的示例中，回归包、支付和网站将被导出到工作簿中的三个单独的工作表。

4. 导出完成后，打开导出位置的电子表格以查看导出的结果。

从 TFS 导入测试用例

1. 启动测试用例迁移 Plus工具以启动测试用例导入向导。

2. 从源选项卡中选择数据源。输入格式可以是Excel 工作簿或MHT/Word。在本教程中，我们将使用输入源格式为Excel 工作簿。输入输出文件夹位置。一旦工作簿被解析，你将看到选定工作表中的列列表。点击下一步以配置目标设置：

3. 从目标标签页，输入目标详细信息，如团队项目和工作项类型，以便将测试用例导入。 从设置标签页，选择创建一个新的设置文件，并点击下一步按钮（设置文件将保存您的选择，以供未来的导入使用）。 从字段映射标签页，将电子表格中的列映射到工作项。例如，电子表格中的标题字段映射到工作项的标题字段。

4. 从链接映射标签页，您可以选择启用工作项之间的链接，使用其他标签页指定如何从源 Excel 文件读取数据。点击保存并迁移以根据通过向导配置的设置开始迁移过程。这将触发导入过程；更新进度将在用户界面上显示：

5. 一旦导入完成，通过点击关闭图标按钮退出向导。导入工具会处理工作表并在与源工作表相同的位置生成报告。导入设置文件也会在相同的位置生成。该导入设置文件存储在导入过程中指定的设置。该设置文件可以用于将来的导入：

6. 打开Report.xls文件，所有成功导入的测试用例将列在已通过表中。任何在导入过程中出现问题的测试用例将列在警告表中，而任何无法导入的测试用例将列在失败表中。

7. 要查看导入的测试结果，请导航到 Team Web Portal 中的 FabrikamTest 中心。您将看到新的计划出现在测试计划下拉菜单中。以下截图展示了 Team Web Portal 中的测试套件和一个链接的测试用例：

它是如何工作的…

这绝不是一个测试用例迁移解决方案，但值得指出的是，如果您使用支持将测试用例提取到 Excel 的其他测试用例管理工具，您可以使用这些工具将工件导入到 TFS 中。

还有更多内容

既然我们谈到测试套件，值得强调的是，TFS 2015 现在支持将多个人分配给一个测试套件。您可以通过右键点击测试中心中的测试套件，并从上下文菜单中选择分配人员来启用此功能。如以下截图所示，新表单允许将多个测试人员分配给测试套件：

这将遍历测试套件，并为每个人创建测试用例。一个包含测试用例链接的电子邮件将发送给个人。这是让多个个人使用相同测试套件进行测试的好方法，同时您还可以单独跟踪每个个人的测试活动。

复制和克隆测试套件及测试用例

TFS 提供了两种用于测试套件和测试用例的复制操作，即复制和克隆。复制使用一种叫做浅拷贝的机制，它只是创建对工件的引用。如果对工件进行了任何修改，这些修改将反映到所有引用中。克隆使用深拷贝机制；新工件没有指向原始工件的引用，并且不会受到对原始工件所做更新的影响。使用浅拷贝的常见场景是在多个迭代中使用相同脚本进行测试。另一方面，使用深拷贝的常见场景是通过复制多个现有的测试套件和测试用例来创建回归测试脚本。在这个教程中，你将学习如何使用复制和克隆功能。

准备工作

在这个教程中，我们将使用 Microsoft 测试管理器。Microsoft 测试管理器随 Visual Studio 企业版或 Visual Studio 测试专业版一起安装。启动 Microsoft 测试管理器并连接到 FabrikamTFVC 团队项目。

如何操作…

复制（浅拷贝）

1. 在 Microsoft 测试管理器中，从计划选项卡中，选择一个静态测试套件来存放新副本。

2. 从工具栏中，点击通过引用现有测试用例创建测试套件按钮。

3. 在对话框中，选择你想要复制的测试计划和测试套件，然后点击创建套件。

克隆（深拷贝）

1. 在 Microsoft 测试管理器中，从组织选项卡中，选择一个测试计划。

2. 从工具栏中，点击克隆按钮。

3. 在对话框中，选择一个或多个你想要克隆的测试套件。你也可以选择克隆与所选测试套件关联的需求。

4. 输入目标测试计划的名称，并设置相关的区域路径和迭代路径。

5. 接下来，点击克隆按钮触发克隆操作。克隆日志将显示克隆过程的更新信息。

   注意

   克隆测试用例在团队项目之间是支持的，但仅限于同一个团队项目集合内。

你还可以使用 tcm.exe 的 /clone 参数通过命令行克隆测试用例和测试套件。在以下示例中，你会注意到使用了 /clone 参数来克隆需求。目标中的区域路径和迭代路径字段的值将被指定的值覆盖：

tcm suites /clone /collection:http://tfs2015:8080/tfs/DefaultCollection /teamproject:FabrikamTFVC /destinationteamproject:FabrikamGit /clonerequirements /suiteid:234 /destinationsuiteid:567 /overridefield:\"Iteration Path\"=\" FabrikamGit\\sprint3\" /overridefield:\"Area Path\"=\" FabrikamGit\\catalog\"

它是如何工作的…

当你克隆一个测试套件时，以下对象会从源测试计划复制到目标测试计划：

测试计划对象 备注 测试用例 每个新测试用例保留其共享步骤。源测试用例和新测试用例之间会建立链接。新测试用例不包含测试运行、缺陷、测试结果和构建信息。 被克隆测试用例引用的共享步骤 所有源测试用例引用的共享步骤将在目标位置的克隆测试用例中保留。

| 测试套件 | 以下数据会被保留： |

• 测试套件的名称和层级结构

• 测试用例的顺序

• 分配的测试人员

• 配置

|

从克隆的测试用例中链接的操作记录 任何操作记录的链接会保留在克隆的测试用例中。 链接和附件 源中的任何链接和附件在克隆的测试用例中也可用。 测试配置 测试配置会在目标测试计划中重新应用。

从测试中心导出测试工件和测试结果

TFS 测试工件包括测试计划、测试套件、测试用例，当然还有测试结果。为了分享和报告，通常需要导出测试工件。在 TFS 2013 的时代，Test Scribe 作为 Visual Studio 扩展工具，是导出这些工件的唯一方式。现在，Test hub 提供了电子邮件或打印测试工件的功能，使你能够轻松与利益相关者分享测试工件。这个功能易于使用，可以在 Team Web Portal 的多个位置触发。在本教程中，你将学习如何从测试中心导出测试工件。

如何操作…

1. 浏览到 FabrikamTFVC 团队 Web 访问并进入 测试 中心。要在测试计划级别导出，选择测试计划，然后从工具栏中点击 电子邮件或打印测试工件 按钮：

2. 要在测试套件级别导出，选择测试套件，打开上下文菜单并选择 导出 选项：

3. 无论你选择从测试计划还是测试套件导出，在这两种情况下，你都会得到一个新表单来选择“导出内容的类型”和“导出方式”。在这个表单中，“内容的类型”指的是工件，而“导出方式”指的是电子邮件或打印。以下截图中的几个项目值得注意。最新测试结果选项是在更新 1 中新增的，选择此选项还会导出测试结果。选择 选定的套件及其子项 会递归导出所选套件的所有子项：

操作方式…

点击打印或电子邮件按钮将启动生成提取内容的过程；根据导出的工件的数量和大小，这一过程可能需要几秒钟才能完成。导出完成后，会弹出一个表单，显示导出的预览。你也可以在预览表单中编辑和格式化值。由于我们选择了电子邮件选项，该表单有一个字段，允许我们选择希望将导出内容发送给的电子邮件地址：

如下图所示，导出还包括测试步骤：

还有更多内容…

通过修改 TFS 在导出/打印过程中使用的底层模板，可以自定义导出的格式。在自定义模板之前，需注意以下几点：

您应当创建原始模板的备份，例如将其复制并重命名为TestSuite-Original.xsl。如果不这样做，在升级 TFS 时，您在TestSuite.xsl文件中所做的更改可能会被覆盖。导出不支持按项目进行自定义；样式更改将影响 TFS 实例中的所有项目。

按照此处列出的步骤将贵公司徽标添加到导出中：

1. 登录到 TFS 应用程序层，并导航到以下路径。将贵公司徽标（companylogo.png）添加到C:\\Program Files\\Microsoft Team Foundation Server 14.0\\Application Tier\\Web Services\\_static\\tfs\\12\\_content文件夹路径中。

2. 修改C:\\Program Files\\Microsoft Team Foundation Server 14.0\\Application Tier\\Web Services\\_tfs_resources\\TestManagement\\v1.0\\Transforms\\1033文件夹中的TestSuite.xsl文件。

3. 在记事本中打开TestSuite.xsl文件，并添加以下代码行以将贵公司徽标包含到导出模板中：

4. 可以通过在 Team Web Portal 的测试中心生成导出，来测试自定义的结果。

在 Team Portal 中将测试状态图表化到仪表板

Team Web Portal 中的图表工具提供了一种极好的方式来分析和可视化测试用例执行情况。通过图表工具创建的图表可以固定到自定义仪表板上。图表和仪表板是出色的信息展示工具，可以与团队成员和利益相关者共享测试执行结果。在本教程中，您将学习如何将测试执行结果固定到 Team Portal 中的自定义仪表板上。

入门

按照第一章 Team Project Setup中“配置团队项目仪表板”部分中的步骤，为测试创建自定义仪表板。

如何操作…

1. 导航到 FabrikamTFVC Team Web Portal 中的Test中心。Test Plan页面为您提供所选测试套件的测试套件列表和测试用例列表。Charts标签为您提供了可视化这些信息的极好方式。点击**+图标并选择New test result图表。选择条形图并按Outcome分组；这将在条形图中显示测试用例结果。点击OK**保存图表。右键点击新创建的图表，将图表固定到测试仪表板上：

2. 现在，点击**+图标并选择新建测试用例图表。测试用例图表类型支持趋势图，支持的趋势周期从 7 天到最多 12 个月。选择堆叠区域图类型，并选择按状态**进行堆叠。这将帮助你可视化测试用例随时间变化的状态。点击“确定”以保存图表，右键单击图表并将其固定到仪表板：

它是如何工作的…

这些图表是通过事务数据库中的工作项数据进行计算的。当工作项更新时，图表会立即反映这些更新。要了解更多关于团队门户网站中图表功能的内容，请参考bit.ly/1PGP8CU的操作指南。

第六章：发布您的应用程序

“持续部署可以被视为持续集成的延伸，旨在最小化交付时间” –敏捷联盟

在本章中，我们将涵盖以下内容：

• 在团队 Web 门户中创建发布定义

• 将工件映射到发布定义

• 配置发布定义以实现持续部署

• 在发布定义中添加和配置环境

• 配置发布定义的安全性

• 配置发布的全局和本地变量

• 使用发布管理部署 Azure 网站

• 使用发布管理部署 IIS Web 应用程序

• 在发布管理中跟踪发布

介绍

迄今为止，在本书中我们讨论了规划、开发、测试和构建软件。软件团队需要数周甚至数月来开发和测试软件；然而，只有当软件到达预定用户手中时，它的价值才能得以体现。发布管理为此提供了支持：

“发布管理是通过不同的阶段和环境管理、规划、调度和控制软件构建的过程，包括测试和部署软件发布。” –维基百科

2013 年 6 月 3 日，微软收购了 InCycle 软件公司的 InRelease 产品。InRelease 产品被重新命名为 Microsoft Release Management，并集成到 Team Foundation Server 2013 中。Microsoft Release Manager 让微软在日益增长的发布管理市场中占有一席之地。尽管 Release Manager 与 Team Foundation Server 一起发布，但它需要单独安装和配置。尽管进行了多次改进以增强两者之间的集成，但在某些地方它们依然显得割裂。基于 WPF 的桌面客户端笨重且功能受限。Release Manager 不支持非.NET 应用程序，也无法在非 Windows 平台上使用。显然，Release Manager 仅仅是一个过渡性的解决方案，最终需要被一个更合适的方案取代。

微软最近在 Visual Studio Team Services 中发布了基于 Web 的 Release Management 解决方案。尽管该新解决方案尚未在 Team Foundation Server 2015 Update 1 中发布，但预计将在 TFS 2015 的 Update 2 或 Update 3 中首次亮相。旧版 Release Management 解决方案将不会再进行进一步投资，并将不可避免地被新的基于 Web 的 Release Management 解决方案所取代。鉴于此，本章将完全聚焦于新的基于 Web 的 Release Management 解决方案。要尝试本章中的操作，您需要创建一个 Visual Studio Team Services 账户；请按照bit.ly/1N50I7j上的说明进行操作。

注意

本章中的配方基于新的基于 Web 的发布管理解决方案。预计新的基于 Web 的发布管理解决方案将在 Team Foundation Server 的更新 2 或更新 3 中可用。要尝试本章中的配方，请创建一个 Visual Studio Team Services 账户（bit.ly/1N50I7j）。

新的基于 Web 的发布管理解决方案与产品非常紧密集成。无需单独安装或配置即可开始使用新的发布管理解决方案。发布管理器的安全基础设施与以前的版本不同，因为它不再管理自己的组和权限。在 VSTS 中为发布管理引入了新的权限，例如创建发布定义、创建发布和管理审批人。这些权限的默认值为 Team 项目级别的特定组设置。然后，这些权限可以被覆盖，适用于特定发布定义或发布定义中的特定环境。

Team 构建和发布管理共享相同的代理池和队列基础设施。统一的代理基础设施减少了管理和设置的开销。用于协调操作的任务也在构建和发布之间共享。这大大减少了发布管理的学习曲线。新的解决方案是基于 Web 的、开放的、可扩展的，并且完全支持跨平台。Team 构建和发布管理之间的底层框架是相同的，因此你在发布管理中得到的实时控制台输出与 Team 构建中的相同。发布定义支持更改修订和类似于构建定义的不同功能。发布管理支持草稿发布，类似于 Team 构建中的草稿构建功能。构建和发布管理之间有如此多的相似之处，唯一的区别是构建还可以访问部署任务，你可能会问，构建和发布管理有何不同？

构建和发布管理之间的界限已经变得模糊，因为两者有很多相似之处。关键的区别在于部署只是发布管理中执行的活动之一。如下面的图所示，新的发布管理解决方案允许创建发布流水线。发布流水线可以包含一个或多个环境。每个环境可以有一个或多个物理或虚拟的部署目标。环境提供了发布前和发布后的审批工作流，以及用于测试和部署的任务：

通过发布管理器部署的软件可以从 Team 构建、Jenkins、Team City、FTP 等注入。通过在发布流水线中的所有环境共享工件，它真正让你做到“构建一次，随处部署”。

为了降低入门门槛，发布管理器提供了开箱即用的部署模板。部署模板添加了在环境中进行某种类型部署所需的任务集。你仍然需要配置这些任务，但预先添加任务可以让你在发布配置中更快起步。该框架还允许你克隆或将已配置的环境保存为模板。再次强调，目的是加速发布配置，并最大限度地在不同发布定义之间重用。发布管理预计将很快通过发布管理 REST API 补充 REST API 库。这将允许你将发布管理集成到组织中使用的其他发布工作流部分，或者在你发现需要的地方扩展发布管理功能。

本章开始时，你将学习新的基于网页的发布管理解决方案中的不同功能；在后续的章节中，我们将介绍适用于 Azure 和本地 Web 应用程序的部署场景。最后但同样重要的是，我们将了解发布管理中可用的发布跟踪和报告功能。

在 Team Web Portal 中创建发布定义

在本食谱中，你将学习如何使用空白的部署模板创建一个新的发布定义。你还将了解发布定义中的不同功能。

准备就绪

要创建一个新的发布定义，你需要是发布管理员组的成员。这些权限同样适用于项目管理员组。

如何操作…

1. 导航到 FabrikamTFVC 团队项目中的发布中心：

2. 点击**+图标以创建一个新的发布定义。这里有预配置的部署模板可以选择。在本食谱中，我们将从空白**模板开始。与其他模板不同，空白模板会创建一个没有任何预先添加任务的空白发布定义：

3. 将发布定义命名为FabrikamTFVC Web Release：

4. 导航到常规标签，并将发布编号格式从Release-$(rev:r)更改为Rel-$(System.TeamProject)-$(rev:r)。从此定义生成的发布将具有格式为Rel-FabrikamTFVC-1的发布名称：

5. 点击保存按钮以保存发布定义。在本食谱中，我们已经创建了一个空白的发布定义。接下来，我们将在*工作原理…*部分逐步介绍发布定义的不同功能。

工作原理…

在这个食谱中，我们从一个空的发布模板开始。部署模板窗口提供了一个选项，可以从一个预配置的发布模板开始。预配置的部署模板会为默认环境添加一个环境以及所有必要的发布任务，只需您配置任务即可。如以下截图所示，Azure 网站部署模板添加了一个默认环境和两个任务，分别是Azure Web 应用部署和Visual Studio 测试。从长远来看，您将开始看到更多预配置的部署模板可以直接使用：

现在让我们了解 FabrikamTFVC Web 发布定义中的环境选项卡的功能：

• 添加环境：这是您的应用需要部署到的服务器集合。点击添加环境图标也会打开部署模板窗口。该窗口使您能够添加环境并为该环境部署应用时相关的任务。

• 默认环境：这是一个逻辑容器，包含了在该环境中发布应用所需的任务。如以下截图所示，一个环境支持一定的配置级别。我们将在在发布定义中添加和配置环境食谱中详细讲解环境支持的功能：

• 添加任务：这是发布过程中前往环境的一个步骤。一组预创建的任务已经默认可用。画廊还提供了脚本任务，允许您执行一些预创建任务中可能没有的操作。该框架具有完全的可扩展性；请参考第四章中的使用 TFBuild 可扩展性框架创建新的构建任务，了解如何添加您自己的任务。构建和发布中心共享一个公共任务画廊。这使得您可以在发布过程中使用构建过程中使用的任务。随着我们在本章后续的食谱中开始配置任务，您将会学到更多关于任务的内容。

转到常规选项卡。此选项卡允许您指定发布名称格式。发布定义的发布名称默认为按顺序编号。第一个发布名为Release-1，下一个发布为Release-2，以此类推。您可以通过编辑发布名称格式模板来更改此命名方案。该字段支持使用预定义的（如以下表格所列）。您还可以使用自定义变量；我们将在为发布配置全局和本地变量食谱中详细介绍变量：

变量 描述 Rev:rr 一个自动递增的数字，至少包含指定数量的数字。 Date/Date:MMddyy 当前日期，默认格式为 MMddyy。支持的日期组合包括 M/MM/MMM/MMMM，d/dd/ddd/dddd，y/yy/yyyy/yyyy，h/hh/H/HH，m/mm，s/ss。 System.TeamProject 该构建所属的团队项目名称。 Release.ReleaseId 发布的 ID，在整个项目中是唯一的。 Release.DefinitionName 当前发布所属的发布定义名称。 Build.BuildNumber 发布中包含的构建编号。如果一个发布包含多个构建，则在持续部署的情况下，这是触发该发布的构建编号；在手动触发的情况下，这是第一个构建的编号。 Build.DefinitionName 发布中包含的构建的定义名称。如果一个发布包含多个构建，则在持续部署的情况下，这是触发该发布的构建的定义名称；在手动触发的情况下，这是第一个构建的定义名称。 Artifact.ArtifactType 与发布关联的工件源类型。例如，这可以是 Team build 或 Jenkins。 Build.SourceBranch 发布中构建排队时的分支。对于 Git，这是以refs/heads/master形式表示的分支名称。对于 Team Foundation Version Control，这是工作区的根服务器路径，形式为$/teamproject/branch。在 Jenkins 工件源的情况下，该变量未设置。 Custom variable 在发布定义中定义的全局配置属性的值。

历史选项卡显示了自发布定义创建以来对其所做的更改列表。你还可以区分两次发布定义修订之间的更改。工件选项卡允许你映射作为发布定义一部分需要部署的不同工件；你将在将工件映射到发布定义食谱中学习工件选项卡的功能。配置选项卡允许你为发布定义配置变量；你将在在发布定义中添加和配置环境食谱中学习配置选项卡的功能。触发器选项卡使你能够将发布配置为持续部署，通过将触发器设置为持续集成。此配置将在映射到发布定义的底层工件发生变化时触发发布过程。你将在为持续部署配置发布定义食谱中了解更多信息。 |

映射工件到发布定义

发布定义允许你将应用程序部署到多个环境中。部署应用程序所需的文件和安装程序称为工件。目前，发布管理支持来自 Team Build、Jenkins 和本地 TFS 的工件。一个发布定义可以包含一个或多个工件。这种灵活性对于构建模块化软件并将其组合形成发布的团队来说非常有用。在本配方中，你将学习如何将 Team Build 定义的输出映射到发布定义中。

准备工作

要编辑发布定义，你需要是发布管理员组的成员。这些权限也适用于项目管理员组。

场景：FabrikamTFVC 团队有两个构建定义，分别是FabrikamTFVC.Website和FabrikamTFVC.Services。网站和服务是同一应用程序的两个组件，这些组件需要在发布时一起推出。为了支持这一场景，FabrikamTFVC 团队需要将FabrikamTFVC.Website和FabrikamTFVC.Services的安装程序映射到发布定义 FabrikamTFVC Web 中：

你可以按照第四章中创建连续集成构建定义在 TFBuild 中的配方步骤进行操作，构建你的应用程序。按照在 Team Web Portal 中创建发布定义配方中的步骤，创建 FabrikamTFVC Web 发布定义。

如何操作…

1. 导航到 FabrikamTFVC 团队项目中的发布中心，编辑 FabrikamTFVC Web 发布定义。如下面的截图所示，发布定义提示你将构建定义链接到此发布：

2. 点击构建定义的超链接，设置工件类型为构建，然后选择FabrikamTFVC.Services构建定义。底部的文本告诉你此构建定义正在发布的工件。点击确定，完成将FabrikamTFVC.Services构建定义映射到 FabrikamTFVC Web 发布定义的操作：

3. 现在，导航到工件选项卡，你将看到FabrikamTFVC.Services构建定义作为此发布定义的工件源显示出来：

4. 点击链接工件源，将FabrikamTFVC.Website的构建定义映射到此发布定义。一旦完成，你会看到FabrikamTFVC.Services和FabrikamTFVC.Website都作为该发布定义的工件源显示出来。点击保存以提交更改到构建定义：

工作原理…

发布定义中的工件使你能够真正实现“一次构建，到处部署”。工件在发布定义级别进行映射，并可供发布定义中的所有环境使用。

当排队发布时，你可以选择用于发布的构建版本。如以下截图所示，你可以选择用于此发布的构建版本。这些工件在所有选定的环境中都可用。一旦发布从发布定义中被触发，工件的版本将无法更改：

如前所示，你可以直接从构建触发发布。从构建中选择发布后，打开队列发布选项，允许你选择其他工件的版本以及构建需要部署的环境。当你选择 Team build 作为发布定义的工件时，你将享受到这种真正集成的体验：

当触发发布时，所选版本的工件会被下载到代理的工作目录中。然后，在该环境中运行的任务可以部署这些工件。工件的下载行为可以自定义；你可以跳过将工件下载到某个特定环境的代理中。这可以通过在环境的常规设置中设置跳过工件下载标志来完成：

还有更多…

发布管理当前支持 Team build、Jenkins、本地 TFS 和其他源作为有效的工件源。源需要作为服务终结点从 Team 管理控制台中添加。如以下截图所示，你必须使用 Jenkins 终结点并指定连接详细信息，创建一个 Jenkins 服务终结点。成功添加 Jenkins 连接终结点后，你可以在发布定义中选择 Jenkins 作为工件类型：

发布管理还支持添加其他工件源。如果你想连接到像 Team City、NuGet 仓库或文件共享这样的源，这个选项会非常合适。

配置持续部署的发布定义

持续部署是一种软件工程方法，在这种方法中，团队会在将增量更改提交到代码库时，同时部署软件。这种方法旨在更快速、更频繁地构建、测试和发布软件。发布定义已经存储了生成需要部署的工件的系统详细信息。当新版本的工件可用时，发布定义可以配置为触发发布。在本教程中，你将学习如何配置发布定义，以便当新工件版本可用时触发新的发布。

准备就绪

要编辑发布定义，你需要是发布管理员组的成员。这个权限同样适用于项目管理员组。

场景：FabrikamTFVC 团队已将FabrikamTFVC.Website和FabrikamTFVC.Services映射到 FabrikamTFVC Web 的发布定义中。团队现在希望，FabrikamTFVC 发布定义在FabrikamTFVC.Services的新成功构建可用时，自动触发新发布。

如何操作…

1. 转到 FabrikamTFVC 团队项目中的发布中心，并编辑 FabrikamTFVC Web 的发布定义。点击触发器选项卡以配置此发布定义的触发器：

2. 勾选持续部署复选框，并选择FabrikamTFVC.Services作为工件源标签的触发器。同时，选择你希望发布自动部署到的环境。将所有更改持续部署到选定环境是常见场景；然而，发布管理允许你选择一个或多个环境进行持续部署。点击保存以提交更改：

3. 转到构建中心并排队一个新的FabrikamTFVC.Services构建。一旦FabrikamTFVC.Services成功完成，来自 FabrikamTFVC Web 发布定义的发布将被触发。如果FabrikamTFVC.Services选项失败，则不会触发新发布：

如何运作…

FabrikamTFVC 发布定义现在已配置为检测何时在FabrikamTFVC.Services构建定义中有新的工件可用。在背后，这个配置会在构建和发布定义之间设置一个队列。成功构建的FabrikamTFVC.Services会生成一个事件；一旦 FabrikamTFVC Web 发布定义中的接收器收到此事件，就会触发一个新发布。

发布将在所有选定的环境中按顺序触发。目前，你无法设置触发器来并行自动部署到多个环境。预计未来将会有 REST API 可供从其他系统远程触发发布。

还有更多…

虽然FabrikamTFVC.Services不需要是持续集成构建，但即使它是手动触发的，只要构建生成新的成功工件，发布就会被触发。你可以选择从构建中心将构建设置为持续集成，如下图所示：

在发布定义中添加和配置环境

发布定义由一组环境组成。环境是一个逻辑容器，包含了发布需要部署的位置和方式。环境可以是本地服务器、云服务器、多个云，或应用商店。每个环境中部署应用的步骤可以相同也可以不同。环境中的部署步骤通过任务来描述。在本教程中，你将学习如何添加和配置环境。

准备就绪

要编辑发布定义，你需要是发布管理员组的成员。这些权限也可供项目管理员组使用。

场景：FabrikamTFVC 团队拥有一组按开发、QA、预发布和生产环境分类的服务器。该团队希望能够在单个发布过程中将应用程序部署到所有环境中。每个环境有不同的所有者和批准人。团队希望发布定义能够配置，使开发人员可以批准将发布部署到开发环境；QA 批准所有发布到 QA 环境的版本。QA 和发布经理批准预发布环境（预生产）中的版本。发布经理批准生产环境中的发布：

如何操作…

1. 导航到 FabrikamTFVC 团队项目中的发布中心，编辑发布定义 FabrikamTFVC Web。将默认环境重命名为开发：

2. 通过点击省略号启动上下文菜单来配置开发环境。从上下文菜单中选择分配批准人…:

3. 这个窗口允许你配置预部署和后部署批准的批准人，并设置环境的总体所有者，还可以选择启用电子邮件通知。点击确定保存已配置的更改。此屏幕允许将个人用户账户以及组添加为批准人和所有者：

4. 现在你可以点击**+**图标，向开发环境添加部署任务。添加和配置任务将在未来的教程中介绍。

5. 在开发环境中，通过点击省略号启动上下文菜单。从上下文菜单中选择保存为模板…:

6. 给部署模板起个名字并填写描述，如下图所示：

7. 点击**+图标添加一个环境。这将启动部署模板窗口。如以下截图所示，你将看到一个新的自定义**标签。该标签将列出团队保存的所有自定义模板。选择并添加此模板，它将添加一个带有在步骤 3 中设置的批准配置的新环境：

8. 现在，添加新的环境用于 QA、暂存和生产，并按照准备就绪部分的图示设置批准者。如以下截图所示，每个环境都有符号来提供有用的信息：

   • 这显示了环境中任务的数量。目前，在这个 QA 环境中没有设置任务。

   • 这显示了环境中批准者的数量。目前，已为暂存环境设置了四个批准者。

   • 这显示了环境中变量的数量。目前，生产环境中没有设置变量。

9. 点击环境中的省略号以启动上下文菜单。在上下文菜单中选择克隆环境。这将把选定的环境克隆到一个新环境中。这对于你想要复制一个现有环境而不将其保存为模板时非常有用。

10. 安全性也可以在环境级别进行配置。选择一个环境并从上下文菜单中启动安全配置。此屏幕允许你配置特定于环境的权限，例如哪些组可以删除发布环境、编辑发布环境、管理发布批准者以及管理发布权限：

11. 用于部署环境的代理也可以在环境级别进行配置。从环境上下文菜单中选择代理选项…：

    代理选项窗口有各种配置选项，例如是否下载工件、使用哪个代理以及代理要求。变量标签允许你为此环境指定变量：

    

    如果你试图将应用程序部署到的环境位于仅可通过特定代理访问的安全网络中，那么按环境配置代理的能力非常有用。你可以使用配置队列选项来选择包含你需要使用的代理的队列进行此次部署。

12. 点击保存以提交更改。通过点击**+**图标排队一个新的发布版本：

它是如何工作的…

这将为发布定义 FabrikamTFVC Web 排队一个新的发布版本。如环境列所示，发布代表每个环境都有一条线。第一条灰色线前的图标显示该环境中的发布版本正在等待批准：

双击发布版本以导航到该发布版本的日志摘要标签。你可以看到，该发布版本正在等待批准以部署到开发环境：

开发环境在部署应用程序之前已配置好以供预审批。该环境还配置为发送电子邮件通知。根据配置，环境会发送电子邮件通知：

一旦发布预审批被授予，发布就会启动：

当指定多个批准者时，每个批准者将按顺序收到通知。所有列出的批准者必须批准部署才能继续。如果你指定一个组作为批准者，则当有待批准的部署时，整个组将收到通知。但该组中只需一个用户批准或拒绝部署即可。

摘要视图为你提供发布的整体摘要：

日志视图为你提供环境中执行的所有操作的完整细分：

这对于识别发布过程中的瓶颈非常有用。我们将在发布管理中的发布跟踪中更详细地讨论发布跟踪。

配置发布定义的安全性

与 TFS 中的其他模块一样，发布管理也使用基于角色的权限模型进行安全性管理。权限定义了可以授予或拒绝用户和组的授权。在本节中，你将学习如何在发布管理中应用不同级别的安全性。

正在准备中

要管理发布管理的权限，你需要将管理发布权限设置为允许。默认情况下，项目管理员和发布管理员组的成员会自动设置为允许：

操作方法…

1. 导航到 FabrikamTFVC 团队项目中的发布中心。在所有发布定义的上下文菜单中，选择**安全性…**以打开权限对话框。这将允许你管理团队项目中所有发布定义的权限：

   权限对话框显示了组、用户和权限。此对话框可用于更改组的权限，并添加新的用户和组到这些组中：

   

2. 在前一步中，我们学习了如何管理所有发布定义的安全性。要管理特定发布定义的安全性，请打开该发布定义的上下文菜单，并从菜单中选择安全性…：

   权限对话框允许你管理此特定发布定义的现有用户、新用户和组的权限。

3. 到目前为止，我们已经看到了如何为所有发布定义和特定发布定义应用安全性。发布管理还允许在发布定义中的环境上应用安全性。右键单击环境上下文菜单中的 FabrikamTFVC Web 发布定义并选择安全性…：

   权限对话框允许您为此特定环境管理现有用户、新用户和组的权限。

它是如何工作的…

发布管理包含一个基于角色的权限模型，以下表格总结了可以应用的权限及其层级：

权限 描述 范围 管理发布权限 可以更改其他任何权限 项目、发布定义和环境 删除发布定义 可以删除发布定义 项目和发布定义 删除发布环境 可以删除发布定义中的环境 项目、发布定义和环境 编辑发布定义 可以创建和编辑发布定义、配置变量、触发器和工件 项目和发布定义 编辑发布环境 可以编辑发布定义中的环境 项目、发布定义和环境 管理发布审批者 可以为发布定义中的环境添加或编辑审批者 项目、发布定义和环境 管理发布 可以编辑发布中的配置，并且可以启动、停止或重新启动发布部署 项目和发布定义 队列发布 可以创建新的发布 项目和发布定义 查看发布定义 可以查看发布定义 项目和发布定义 查看发布 可以查看属于发布定义的发布 项目和发布定义

这些权限的默认值已为所有团队项目集合和团队项目组设置。例如，项目集合管理员、项目管理员和发布管理员默认拥有所有上述权限。项目贡献者拥有除管理发布权限之外的所有权限。项目读取者默认被拒绝所有权限，除非是查看发布定义和查看发布。

配置发布的全局和局部变量

变量用于存储在发布过程中需要传递到任务中的值。与直接在任务中硬编码这些值相比，使用变量有很多优点：

• 变量支持以加密的方式存储值，使其无法被发布定义的用户查看或更改

• 将值存储在变量中有助于避免重复

• 变量可以在所有环境之间共享

• 变量可以在特定环境中的所有任务之间共享

在本教程中，你将学习如何为发布定义配置发布和环境变量。

准备工作

要编辑发布定义，你需要成为发布管理员组的成员。项目管理员组也具有这些权限。

场景：FabrikamTFVC 团队使用 Azure Blob 存储来存储 FabrikamTFVC Web 发布定义所需的文件。团队希望能够从整个发布定义中访问 Blob 存储连接详情。团队还需要存储某个任务在环境中所需的连接字符串详情。每个环境的连接字符串值不同。团队希望将这些值安全存储，以便连接字符串详情不会以明文形式显示：

如何操作…

1. 导航到 FabrikamTFVC 团队项目中的发布中心，并编辑 FabrikamTFVC Web 发布定义。点击配置选项卡。配置选项卡允许你添加可以跨发布定义共享的变量：

2. 点击**+**图标添加变量。根据以下截图，添加 Azure Blob 存储的连接详情。点击属性旁边的挂锁图标。此类属性的值将被安全存储，并且一旦保存后，用户无法查看。在部署过程中，发布管理服务会解密由任务引用的这些值，并通过安全的 HTTPS 通道将它们传递给代理：

3. 导航到环境选项卡，点击开发环境中的省略号，并从上下文菜单中选择配置变量…：

4. 点击**+**图标添加变量。添加连接字符串详情并点击挂锁图标以隐藏连接字符串。为存储数据库名称添加另一个变量。按照此步骤为所有其他环境配置这些变量：

5. 现在，导航到配置选项卡，并将右上角的变量类型更改为环境变量：

6. 这显示了所有环境的环境变量及其值的列表：

7. 你可以通过在视图列表旁边选择复选框来过滤掉不想查看环境变量的环境：

它是如何工作的…

在本配方中，我们在发布和环境级别配置了变量。在发布级别定义的变量可用于发布定义中所有环境的所有任务。在环境级别定义的变量仅对该环境中的任务可用；这些变量无法被其他环境访问。使用配置视图中的视图类型选项，您可以查看发布变量和环境变量。您可以点击属性旁边的挂锁图标来隐藏属性的值。此类属性的值会被安全存储，保存后无法被用户查看。在部署过程中，发布管理服务会解密任务引用的值，并通过安全的 HTTPS 通道将其传递给代理。您可以在任务中使用$(variablename)格式引用变量。除了使用自定义变量外，您还可以使用内置变量；内置变量的完整列表请参见bit.ly/1ON0Usg。

使用发布管理部署 Azure 网站

在本配方中，您将学习如何通过发布定义部署 Azure 网站。

准备就绪

要创建发布定义，您需要成为发布管理员组的成员。这些权限也适用于项目管理员组。

场景：FabrikamTFVC.Website构建定义生成一个作为工件的 Web 包。FabrikamTFVC 团队希望将 Web 包部署到 Azure 网站：

确保您拥有有效的 Azure 云订阅。从manage.windowsazure.com/publishsettings下载 Azure 发布设置文件。设置 Azure 网站。在本配方中，我们将使用https://fabrikamTFVC-dev.azurewebsites.net/。

导航到 FabrikamTFVC 团队管理控制台。点击服务选项卡并创建一个新端点。从服务端点的上下文菜单中选择Azure。将连接类型更改为基于证书。复制 Azure 发布设置文件中的详细信息并填写 Azure 端点连接详情。点击保存创建 Azure 端点：

导航到 FabrikamTFVC 团队项目中的构建中心。如果尚未拥有此构建定义，请参考第四章中的创建连续集成构建定义配方，学习如何创建构建定义。在 Visual Studio 构建任务中，配置以下MSBuild Arguments：

/p:DeployOnBuild=true /p:WebPublishMethod=Package /p:PackageAsSingleFile=true /p:SkipInvalidConfigurations=true

配置复制并发布构建工件任务以发布 Web 部署包的内容。可以通过设置以下配置来实现：

保存更改并排队构建。构建成功完成后，你可以从工件资源管理器中看到 Web 部署包：

现在，我们有一个有效的 Azure 订阅和一个 Azure 网站（fabrikamTFVC-dev.azurewebsites.net）。我们有一个 Azure 服务端点以及一个生成 Web 部署包的构建定义，作为工件。

如何操作…

1. 导航到 FabrikamTFVC 团队的发布中心。点击**+图标以创建一个新的发布定义。选择Azure 网站部署**模板：

2. Azure 网站部署模板添加了一个默认环境，其中包括Azure Web 应用部署和Visual Studio 测试任务：

3. 选择Azure Web 应用部署任务，并根据下图配置值。选择已配置为服务端点的 Azure 订阅。选择已创建 Web 应用FabrikamTFVC-dev的位置。指定工件库中 Web 部署包的路径：

4. 点击保存以将更改提交到此发布定义。创建一个新的发布。

如何运作…

发布代理使用 Azure 服务端点安全地将 Web 部署包发布到FabrikamTFVC-dev网站。发布中的日志标签显示处理的完整摘要：

服务端点有两个权限组，分别是端点管理员和端点读取者。需要管理此构建定义的人员应当属于端点管理员组，其他人可以属于端点读取者组：

使用发布管理部署 IIS Web 应用

在本教程中，你将学习如何使用发布管理部署 IIS Web 应用。

准备中

场景：FabrikamTFVC 团队在Fabrikam.lab域中有一组服务器，他们需要在这些服务器上执行 IIS Web 应用部署。

它需要安装在哪里？

如下图所示，服务器位于相同的域Fabrikam.lab中。IIS Web 应用部署需要在两台服务器上进行，即QA-Web1.Fabrikam.lab和QA-Web2.Fabrikam.lab：

代理使用 WinRM 协议连接到机器组中的机器。WinRM 需要在机器上启用，作为将其添加到机器组中的前提条件。请参考第五章中创建并设置机器组的食谱，来设置 Fabrikam-QA 机器组。网站将要部署到的机器组中的机器需要满足以下前提条件：

• Web Deploy 3.5 或更高版本

• 应该已经安装并配置了 IIS Web

• .NET 2 和.NET 4 应该通过aspnet_iisreg -i注册到 IIS

需要安装什么？

要在 IIS 上部署 Web 应用程序，需要确保 Web 部署包在目标机器上可用。你可以手动将 Web 部署包复制到目标机器，或者将其放置在目标机器可访问的 UNC 路径下。在本食谱中，我们将配置构建定义来生成 Web 部署包，并将其复制到所有目标机器上。

导航到 FabrikamTFVC 团队项目中的构建中心。编辑FabrikamTFVC.Website的构建定义。如果你还没有这个构建定义，可以参考第四章中创建 TFBuild 中的持续集成构建定义的食谱，了解如何创建构建定义。

如下图所示，在 Visual Studio 构建任务中，配置以下 MSBuild 参数：

/p:DeployOnBuild=true /p:WebPublishMethod=Package /p:PackageAsSingleFile=true /p:SkipInvalidConfigurations=true /p:PackageLocation=\"$(build.StagingDirectory)\"

现在我们将使用复制并发布构建工件任务，将$(build.stagingDirectory)的内容上传为工件。复制根目录设置为$(build.stagingDirectory)，因为 Visual Studio 构建任务已经设置了 MSBuild 参数，指定了 Web 部署包要复制到$(build.stagingDirectory)。**\\*搜索模式用于复制$(build.stagingDirectory)中的所有内容：

现在我们将使用 Windows 机器文件复制任务，将$(build.stagingDirectory)的内容复制到目标机器。机器文件中指定的机器名称需要已经配置为 WinRM。指定目标服务器上的本地文件夹或目标服务器可以访问的 UNC 路径。选中清理目标选项，将目标文件夹中的旧二进制文件覆盖为新二进制文件。同时，选中并行复制文件选项，加速在多台机器之间的复制操作。在变量选项卡中，添加两个变量，分别是machine.username和machine.password，用于存储目标机器的登录信息：

排队构建；构建成功完成后，导航到工件资源管理器。你应该能看到网站二进制文件，如下图所示：

现在，目标机器上的相同文件应该已经可以在C:\\Temp\\FabrikamTFVC.Website文件夹中找到。

在这个方案中，我们将创建一个新的发布定义，专门用于部署 IIS Web 应用程序和应用程序池。要创建发布定义，你需要是发布管理员组的成员。此权限也可供项目管理员组使用。

操作方法…

1. 在 FabrikamTFVC 团队项目中导航到发布中心。添加一个新的发布定义。选择一个空的部署模板，并将定义命名为 FabrikamTFVC Web 服务器发布定义。将默认环境重命名为 QA，并将 IIS Web 应用程序部署任务添加到该环境中：

2. 在QA环境中，点击省略号并从上下文菜单中选择配置变量…：

3. 为此环境添加两个变量，分别是machine.username和machine.password，它们包含需要部署 IIS 的机器的登录详情：

4. 现在配置 IIS Web 应用程序部署任务，首先指定机器和登录详情。我们将使用在前一步中定义的machine.username和machine.password变量。由于我们处于已配置为使用 HTTP 的 WinRM 闭域组中，选择HTTP：

5. 现在，指定 web 部署包的位置。由于 web 部署包是使用机器文件复制的，因此可以通过构建定义复制任务。你可以在此处直接指定本地目标机器的位置。可选地，你可以指定 web 部署参数文件并覆盖参数，以替换 web 配置中的网站属性，如应用程序名称、连接字符串、数据库详细信息等。或者，你也可以在部署后使用 PowerShell 脚本进行值替换：

6. 勾选创建或更新应用程序池选项，并指定应用程序池名称、.NET 版本、管道模式以及应用程序池的身份：

7. 点击保存并触发此发布定义的发布。等待发布完成，摘要视图将显示发布执行结果：

操作原理…

首先，让我们检查目标机器上的部署结果。如下面的截图所示，FabrikamAppPool已按照配置要求创建：

Web 部署包也已安装在默认网站下，并将网站二进制文件复制到C:\\inetpub文件夹：

该任务使用标准的 Web 部署包功能进行 IIS 部署。使用 WinRM 允许发布管理代理远程协调此工作流。您可以在bit.ly/1XT0yTq了解有关 Web 部署的更多参数和功能。

还有更多

IIS Web 应用程序部署任务也有创建或更新网站部分。这让您可以更精细地控制网站结构的指定。您可以使用此功能更改网站的物理路径、配置要使用的绑定，以及协议、端口和主机名：

在发布管理中跟踪发布

通常，我们希望按状态查看发布列表，检查当前发布的状态，跟踪发布的批准情况，调查日志中的失败，并查看处理发布的代理的详细信息。在本教程中，您将了解发布管理中所有可用的发布跟踪功能。

如何操作…

1. 导航到 FabrikamTFVC 团队的发布中心。登录页面会显示所有发布定义的列表。这是一种快速查看发布状态的方式。该视图展示了有关状态的信息，以及发布定义、环境、构建、分支、开始时间和创建者等内容。使用持续部署配置触发的发布会在第一列显示一个图标：

2. 这个视图可以通过发布状态进行筛选。在右上角，将状态下拉菜单更改为已拒绝；这将使列表仅显示已拒绝的发布：

3. 切换到概览标签。这将帮助您可视化所有发布定义的状态。如以下截图所示，Fabrikam 网站发布管道定义的最后一个发布在开发环境中成功，但在QA环境中失败，并且在暂存和生产环境中没有尝试部署。您可以点击发布定义名称旁边的省略号来排队一个新发布、编辑定义或管理发布定义的安全性：

   Fabrikam 网站发布管道显示 QA 环境中 Release-21 的状态；FabrikamTFVC Web 发布管道显示 Rel-FabrikamTFVC-3 在各环境中的状态

4. 定位到Release-11并双击查看该发布。默认情况下，打开的是发布摘要视图。摘要视图显示了发布的详细信息、环境、问题、工作项和测试结果。你也可以在此视图中重新启动或放弃发布：

5. 若要进一步挖掘问题，点击错误信息或导航到日志视图。日志视图让你按环境和任务浏览日志，从而更容易调查失败的原因：

6. 你可以隐藏日志，通过从右上角更改选项，仅查看审批或任务：

7. 发布中的提交和工作项视图展示了关于代码更改和与此发布处理的工件相关的工作项信息：

8. 现在，在团队门户中导航到团队项目集合管理页面。点击代理队列，查看按队列分组的构建和代理列表。下图展示了 Fabrikam CI01 代理队列处理的所有构建和发布。你可以通过点击超链接的定义或名称，直接浏览失败的构建和发布：

它是如何工作的…

发布管理让你能够跟踪发布，并通过深入分析各级层次来缩小失败的原因。尽管目前没有将发布状态固定到仪表板的图表功能，但此领域计划在接下来的几个发布中进行大量投资；希望这些投资会包括改进可视化发布流水线的功能。

第七章：管理 Team Foundation Server

“是硬件让机器变快……是软件让快机器变慢。” –Craig Bruce

本章将涵盖以下内容：

• 诊断 TFS 中的构建

• 分析 TFS 数据库并配置测试保留策略

• 使用活动和作业监视日志诊断 TFS 问题

• 更改更新频率并强制重新构建 TFS 仓库

• 配置 TFS 缓存设置

• 管理 TFS 中的 CodeLens

• 与 TFS 代理服务器的持续同步

• 创建 TFS 数据库备份计划

• 清理 TFS 中的死工作区和暂存集

介绍

我们正进入自动驾驶汽车的时代；你可能会问：“为什么产品不能自行维护？”产品团队交付高质量的软件，但功能的实际使用与预期使用可能有很大差异。产品所依赖的基础构建块以及依赖于产品的框架生态系统也在不断发展。TFS 的管理负担并不高。管理需求与使用程度成正比。较小的团队可能能够在团队成员的日常活动中管理 TFS，而较大的团队则可能需要一名专职的 TFS 管理员。

TFS 管理员需要执行的关键任务可以大致分为三类：更新、维护和优化：

让我们详细解释这些任务：

更新：保持环境的安全性非常重要，因此，MBSA 工具标识为“关键”的所有安全更新应在 48 小时内应用。产品更新大约每季度发布一次。每个产品更新包含 bug 修复、性能增强和新功能。季度更新很少有重大变化，这也减少了测试升级的工作量。产品更新也应尽快应用。还建议将底层操作系统和 SQL Server 更新到最新的可用服务包。

维护：需要有一个清晰的灾难恢复和备份恢复策略。应密切监控 TFS 数据库的使用情况，以发现任何意外的增长模式。建议使用 TFS Perfmon 计数器来基准测试服务器性能，并定期重新评估，特别是在升级时。有关 TFS Perfmon 计数器的更多信息，请访问 bit.ly/1SijysU。维护 TFS 还包括日常清理活动，如管理权限、构建投放位置、测试附件、工作区、暂存集等。

优化：通过使用活动日志监控 TFS 的使用情况，你可以识别扩展性的需求。负载均衡 TFS 应用层通常是提供弹性和扩展 TFS 设置的第一步。如果团队在低带宽环境中工作，安装 TFS 代理服务器可以显著改善体验。通过密切监控构建和发布代理的使用情况，你可以通过增加额外的代理来补充构建队列。这有助于减少构建和发布的排队时间。

如果你的组织已设置了系统中心，现在可以下载 Visual Studio Team Foundation Server 2015 的管理包，下载地址为bit.ly/1lgcEJN。如果你最近从 TFS 2013 或任何较早版本升级，建议阅读有关在现有团队项目中启用 TFS 2015 特性的信息(bit.ly/1P6IbLu)。MSDN 提供了大量文档(bit.ly/1R4Uh79)，涵盖了关键的管理概念，并附有示例和操作指南。此外，本文(bit.ly/1QGxVcQ)详细讨论了所有 TFS 管理员应关注的内容。TFS 管理和运维是一个相当庞大的话题。在本章中，我们将重点介绍每个 TFS 管理员应执行的一些关键管理活动。

在 TFS 中诊断构建问题

开发团队使用 TFBuild 来验证代码变更、检查代码质量和运行测试。构建是任何软件开发生命周期中至关重要的一部分。作为 TFS 管理员，你可能需要检查构建代理的问题或诊断特定的构建定义。在本篇教程中，我们将学习如何诊断构建代理和构建定义。

准备工作

从 TFS 管理控制台下载 TFBuild Agent。有关如何下载 TFBuild Agent 的更多信息，请参考第四章中的配置 TFBuild Agent、池和队列教程，构建您的应用。你需要拥有集合管理权限才能配置 TFBuild Agent。要创建或编辑构建定义，你需要是构建管理员组的成员。

如何操作…

1. 在诊断代理问题时，最好的起点是查看代理追踪日志。代理追踪日志存储在代理工作目录中的_diag文件夹内。

2. 如果在代理追踪日志中没有明显的异常，作为下一步，你应该对代理运行 HTTP 追踪。这可以通过使用 HTTP 代理工具来完成。如果你使用 Windows 系统，可以使用 Fiddler；其他平台可以使用 Charles Proxy。关于如何设置和捕获 HTTP 追踪，请参考bit.ly/1P6dqGt。

3. 在捕获 HTTP 跟踪时，代理需要以交互模式运行。浏览到已下载 TFBuild Agent 的位置。解压 TFBuild Agent。在管理员模式下打开命令提示符，并将工作目录设置为解压后的 TFBuild Agent 位置。如图所示，运行 ConfigureAgent 命令：

   ConfigureAgent 命令将提示配置代理的一些细节。当系统提示是否要将代理安装为 Windows 服务时，输入 N，这将使代理以交互过程运行，而不是将其安装为服务：

   

   所有代理活动将在命令提示符中以详细模式显示。这可能提供诊断代理问题的线索。

4. 在排查构建定义问题时，最好以详细模式运行构建定义。在详细模式下，代理会生成非常详细的日志；调查日志通常是识别导致意外行为问题的最佳方法。要以详细模式运行构建定义，请创建一个新的变量 System.Debug，并将该变量的值设置为 true：

它是如何工作的…

HTTP 跟踪可能包含凭据，因此请避免公开分享 HTTP 跟踪。目前，TFS 不支持个人访问令牌，因此作为替代方法，您可以创建一个临时帐户用于捕获跟踪；或者在与其他团队共享日志以供调查之前，先清理跟踪日志。

分析 TFS 数据库并配置测试保留策略

随着 TFS 使用量的增加，TFS 实例可能会积累大量的数据文件、构建、发布、工作项等。在大多数情况下，这是非常好的——毕竟，许多 应用生命周期管理 (ALM) 特性的重要价值之一就是维护与生产软件相关的各种工件的可靠历史记录。然而，随着时间的推移，维护旧数据会带来隐性和显性成本，比如性能影响、增加的升级时间以及更高的磁盘空间需求。在本食谱中，您将学习如何分析 TFS 数据库的大小并为团队项目设置测试保留策略。

准备中

不建议直接查询 TFS 事务性数据库的实时实例。请在 SQL 的另一个实例上还原 TFS 事务性数据库的备份，并在该实例上执行本食谱中的查询，而不是在实时实例上执行。
要管理团队项目的测试保留策略，您需要是团队项目管理员组的成员。

如何操作…

让我们首先分析 TFS 数据库，了解存储分布：

1. 打开 SQL Server Management Studio，连接到 TFS 事务数据库所在的 SQL 实例，打开一个新查询窗口并运行以下 T-SQL 代码来获取 TFS 数据库的数据库大小：

   use [master]select DB_NAME(database_id) AS DBName, (size/128) SizeInMBFROM sys.master_files with (nolock)where type=0 and substring(db_name(database_id),1,4)=\'Tfs_\' and DB_NAME(database_id)\'Tfs_Configuration\' order by size desc GO

   执行上述代码后，你将获得以下输出：

   

2. 在 SQL Server Management Studio 中，将连接的数据库范围限定为TFS_DefaultCollection列。执行以下 T-SQL 代码以识别此集合中存储的分布：

   SELECT Owner = CASE  WHEN OwnerId = 0 THEN \'Generic\'  WHEN OwnerId = 1 THEN \'VersionControl\'  WHEN OwnerId = 2 THEN \'WorkItemTracking\'  WHEN OwnerId = 3 THEN \'TeamBuild\'  WHEN OwnerId = 4 THEN \'TeamTest\'  WHEN OwnerId = 5 THEN \'Servicing\'  WHEN OwnerId = 7 THEN \'WebAccess\'  WHEN OwnerId = 8 THEN \'ProcessTemplate\'  WHEN OwnerId = 9 THEN \'StrongBox\'  WHEN OwnerId = 10 THEN \'FileContainer\'  WHEN OwnerId = 11 THEN \'CodeSense\'  WHEN OwnerId = 255 THEN \'PendingDeletion\'  END, SUM(CompressedLength) / 1024 as TotalSizeInKBFROM tbl_FileReference frJOIN tbl_FileMetadata fmon fr.PartitionId = fm.PartitionIdAND fr.ResourceId = fm.ResourceIdWHERE fr.PartitionId = 1GROUP BY OwnerIdORDER BY 2 DESC

   存储被分类为各个所有权区域。这应该有助于在高层次上识别热点区域。

3. 以下查询将展示关于各个所有权区域的更多详细信息：

   use Tfs_DefaultCollection select SUBSTRING(a.filename,len(a.filename)- CHARINDEX(\'.\',REVERSE(a.filename))+2,999)as Extension, sum(fm.compressedlength)/1024 as SizeInKB from tbl_Attachment as a inner join tbl_FileReference as fr on a.TfsFileId= fr.fileidjoin tbl_FileMetadata fm on fr.PartitionId = fm.PartitionId and fm.ResourceId = fr.ResourceIdgroup by SUBSTRING(a.filename,len(a.filename)- CHARINDEX(\'.\',REVERSE(a.filename))+2,999)order by sum(fm.compressedlength) desc

4. 从目前的分析来看，我们已经缩小了范围，TeamTest是数据库中占用最多资源的部分。细节显示，这主要是由于手动和自动测试产生的大量测试运行、结果和附件。要为 FabrikamTFVC 项目配置测试保留策略，请导航到 Team Web Portal 中的 FabrikamTFVC 管理控制台并切换到测试选项卡。如以下截图所示，设置手动和自动测试的保留策略：

工作原理…

测试保留策略是 TFS 2015 中的新功能。测试保留策略允许你分别管理自动化和手动测试的保留策略。默认配置是保留无限期。根据本示例，我们已将自动化测试执行、结果和附件的保留期限设置为 30 天，而手动测试执行、结果和附件的保留期限设置为 365 天。这些保留策略会通过 TFS 中的作业自动处理。

提示

警告

删除任何文件时应谨慎操作，并绝不直接从数据库中删除。和往常一样，在修改、更新或删除之前，务必对数据库进行完整备份。

没有办法在中心位置配置测试保留策略。因此，测试保留策略需要为每个团队项目单独配置。

测试保留策略只是控制 TFS 数据库大小的方式之一。TFS 还支持构建保留策略；这一点在第四章的使用构建保留策略自动删除构建一节中有详细讨论。此外，您还可以通过销毁已删除的版本控制分支、团队项目、文件和 XAML 构建来释放更多空间。请参考bit.ly/1PMhuvB了解如何实现这一点。

使用活动和作业监视日志来诊断 TFS 问题

TFS 将活动和作业执行数据同时记录在后端数据库中。TFS 具有内置作业代理，在应用程序层上运行并记录有关作业和进程的诊断信息。通过查看性能不佳和失败作业，以及诊断信息，可以更快地缩小潜在问题的范围。TFS 的诊断页面包括活动日志和作业监控日志。在本示例中，您将学习如何使用 TFS 的诊断页面。

准备就绪

要使用诊断页面，您需要成为 TFS 管理员组的成员。通过浏览 http://tfs2015:8080/tfs/_oi/ 来验证访问权限：

如何做到……

1. 要访问活动日志，请导航至 http://tfs2015:8080/tfs/_oi/_diagnostics/activityLog。如果您首次访问该页面，加载可能需要一些时间。

2. 该页面基本上展示了tbl_Command表中的数据。正如下图所示，页面包含命令、应用程序、状态、开始时间、执行时间、执行状态、身份、IP 地址、唯一标识符、用户代理、命令标识符、执行计数、认证和响应代码等列表项：

3. 双击列表中的项目以查看更多详细信息。如下图所示，对于协调工作空间命令的详细信息显示了操作的详细下一层级：

4. 活动日志页面还允许进行筛选和导出操作。由于tbl_command表中的数据仅保留 14 天，您可以将活动日志中的数据逐步导出到单独的存储库中，以保留这些有价值的信息用于历史趋势分析。

5. 单击作业监控选项卡以导航到作业监控视图。或者，您可以直接浏览 http://tfs2015:8080/tfs/_oi/_jobMonitoring。作业监控视图还包括三个子菜单：作业摘要、作业队列和作业历史：

6. 首先，让我们看看作业摘要视图。摘要视图显示了每个作业的总运行时间的图形表示。能够将作业执行时间与其他作业相对比有助于识别潜在问题。正如您在以下截图中所看到的，TFS 周期性身份同步和增量分析数据库同步作业处理时间较长，相比之下，优化数据库作业的处理时间较短：

7. 要获取有关增量分析数据库同步作业的更多信息，请点击作业名称旁边的蓝色条形图。这将导航到 作业历史标签。作业历史标签有两个图表，一个显示所有作业的执行时间，另一个显示增量分析数据库同步作业的详细信息。查看这两个图表可以帮助你比较它们之间的影响。下图展示了增量分析数据库同步作业的执行图。通过查看图表，你可以发现 07/25 号的作业明显超出了正常模式，花费的时间比平时要长得多。然而，图表中的队列时间指标显示，延迟是由于平均队列时间延长所导致的：

8. 返回到 作业摘要视图；该视图还有一个饼图，显示了 成功、阻塞 和 禁用 作业的分布。点击任何一项将导航到 作业历史视图，并提供每种类型作业的详细信息：

9. 最后但同样重要的是，作业摘要页面有一个作业运行次数的图表。该图表显示了某个特定作业的运行次数以及该作业的结果类型。点击图表中的任意条形图，查看该作业的详细信息。将鼠标悬停在图表上可以获取更多信息：

10. 接下来，导航到 作业队列标签。此标签中的图表描述了作业队列；它提供了每种队列类型的计数。点击条形图可以查看与每个队列类型相关的作业详情：

它是如何工作的……

建议不要直接查询 TFS 事务数据库。对数据库的任何更改都可能对 TFS 的功能产生重大影响。尽管某些更改可能不会立即显示影响，但这些更改可能会在升级时造成干扰。在诊断页面引入之前，唯一的办法就是直接查询数据库，获取并分析 command 和 actions 表中的数据。诊断页面使得访问这个宝贵的数据集变得更加容易。

所有内置的 TFS 作业都会在 command 表中跟踪其活动。日志记录由 TFS 框架内部处理。有一篇非常有趣的文章讲述了内置作业及其执行间隔；你可以在bit.ly/1kPSbfg上了解更多内容。

更改更新频率并强制重建 TFS 仓库

TFS 中的报告仓库是一个传统的数据仓库，由关系数据库和分析服务数据库组成。数据仓库聚合了所有操作数据，如版本控制、工作项跟踪、构建和测试。该仓库对应于Tfs_Warehouse关系数据库，数据立方体对应于 SQL Server 分析服务数据库Tfs_Analysis。TFS 仓库的默认重建频率为 2 小时。在本教程中，您将学习如何将 TFS 仓库的刷新频率从 2 小时手动更改为 1 小时。您还将学习如何强制重建 TFS 仓库的立方体。

注意

TFS 仓库的刷新频率默认是 2 小时；如果您将间隔缩短到低于默认的 2 小时，数据仓库的处理将频繁消耗服务器资源。如果您的 TFS 服务器有大量数据，减少刷新频率可能会对服务器性能产生不利影响。

准备就绪

若要完成此教程，您需要确保以下事项：

• 您正在使用的 TFS 部署配置了 TFS 仓库。您可以通过检查 TFS 管理控制台中的Reporting标签来验证：

• 您必须是 Team Foundation Administrators 安全组的成员，或必须将服务器级别的仓库管理权限设置为允许。

• 必须启动 Microsoft Team Foundation Server 应用池，以便使用仓库控制 Web 服务：

如何操作…

1. 登录 Team Foundation Server 应用层，并通过浏览http://localhost:8080/tfs/TeamFoundation/Administration/v3.0/WarehouseControlService.asmx验证仓库控制服务是否可用。如果未看到如以下截图所示的仓库控制 Web 服务，请重新访问准备就绪部分：

2. 在WarehouseControlWebService页面中，寻找changesetting网络方法。点击此方法以跳转到该函数的定义。这方法有两个输入参数，分别是settingId和newValue。在settingId文本框中输入RunIntervalSeconds。此属性表示仓库重建的频率。在newValue文本框中输入3600，其中3600代表 3600 秒（1 小时），即属性RunIntervalSeconds的新值：

3. 点击Invoke。这将把您重定向到响应页面。响应页面将列出该操作的结果。在这种情况下，消息确认运行间隔值已成功更新为 3600 秒：

4. 在这一步，我们将演示如何强制重建仓库。返回到仓库控制 Web 服务并选择 ProcessWarehouse Web 方法。该方法有两个输入参数，分别是 collectionName 和 jobName。在 collectionName 文本框中输入 defaultcollection，这是你想要强制重建的 TFS 集合。不要在 jobName 文本框中输入任何值：

   提示

   你可以选择将 collectionName 文本框留空。这将强制重建所有团队项目集合。

5. 点击 Invoke 会将你重定向到响应页面。响应页面将列出操作的结果。服务返回 True 时，表示它成功启动了仓库的处理，False 则表示处理失败。False 的值意味着仓库当前正在处理：

它是如何工作的…

强制重建 TFS 仓库并不是你需要定期做的事情。然而，如果你移动、恢复、重命名或故障转移 TFS 的数据层，则需要进行 TFS 仓库和数据立方体的重建。如果你移动、附加、分离或删除了团队项目集合，则需要重建仓库以查看更新后的报告。

还有更多

RebuildWarehouse 命令也可以通过命令行工具使用。有关如何使用 RebuildWarehouse 命令的更多细节，可以参考 bit.ly/1HjaQdp。

配置 TFS 缓存设置

TFS 应用程序层维护一个文件缓存，以通过从缓存中提供文件，而不是每次从数据库中重新获取文件，来加速文件下载过程。缓存随着时间的推移而增长，可能会开始占用应用程序层的存储空间。缓存使用了相当一部分可用空间；如果你的主驱动器没有足够的可用空间，你将无法有效利用缓存功能。将 TFS 缓存移动到单独的目录中，可以释放主驱动器的存储空间，并为新驱动器规划更轻松的备份或恢复过程。将缓存目录更改为独立目录后，你可能会看到一定的性能提升。在本食谱中，你将学习如何将 TFS 缓存目录更改为不同的目录。

准备工作

你需要有权限登录到 TFS 应用程序层。

如何操作…

1. 登录到 TFS 应用程序层。导航到 TFS 的安装文件夹，默认安装位置是 C:\\Program Files\\Microsoft Team Foundation Server 14.0。

2. TFS 的 web.config 文件位于 C:\\Program Files\\Microsoft Team Foundation Server 14.0\\Application Tier\\Web Services 文件夹中。在进行任何更改之前，请先备份 web.config 文件。打开 web.config 文件并搜索键 dataDirectory：

3. 将数据目录的值从默认值更改为新位置。在这个示例中，已为 TFS 缓存设置了一个新的驱动器W。重新指向缓存到W:\\TfsData\\ApplicationTier\\_fileCache并保存配置文件中的更改：

4. 除此之外，你还可以选择添加PercentageBasedPolicy键，该键决定可以由缓存消耗的剩余空间的百分比。该键仅接受整数值：

   或者，可以使用FixedSizeBasedPolicy键。该键的值是缓存允许的总空间。例如，将其设置为500意味着缓存仅有 500 MB 可用空间用于存储。如果同时指定了FixedSizeBasedPolicy和PercentageBasedPolicy键，则FixedSizeBasedPolicy的值优先。

工作原理…

保存web.config将重新启动应用程序池，并立即生效更改。在版本控制上进行get操作，TFS 将缓存文件的副本作为结果返回给客户端，保存在新位置。

在 TFS 中管理 CodeLens

CodeLens 是 Microsoft Visual Studio 的一个功能，直接在代码编辑器中显示有关代码的信息。在有了 CodeLens 之前，人们不得不在多个不同的窗口中查找诸如方法引用、与方法关联的测试、代码行的最后更改或类的代码变动等信息。由于所有这些信息都在 TFS 中，你只需期望它们能够在一个地方找到。CodeLens 通过将这些信息直接放在代码编辑器中使其可用，正是这么做的。CodeLens 支持 TFVC 和 Git 仓库。CodeLens 现在支持 C#、VB、C++、SQL 和 JavaScript 文件。你可以在 Visual Studio 中了解更多关于 CodeLens 和其他质量和诊断工具的信息：bit.ly/1NNbtJ6。

本书侧重于 TFS，你可能想知道为什么会讨论与 Visual Studio 特定功能相关的内容。TFS 负责准备由 CodeLens 在 Visual Studio 中提供的信息。TFS 具有专门的作业用于代码索引，并且生成的信息存储在 TFS 数据库中。在这个示例中，你将学习如何管理TfsConfig CodeIndex命令来检查 Team Project Collection 的索引状态，启用/禁用索引，查找大文件并忽略它们的索引，审查忽略列表并销毁代码索引。

准备工作

要使用CodeIndex命令，你需要是 Team Foundation Administrators 安全组的成员。此命令只能从 TFS 应用程序层调用；因此，你需要具有登录权限到 TFS 应用程序层。

如何操作…

1. 登录到 TFS 应用程序层并以提升的模式打开命令提示符。

2. 运行以下命令查看默认集合的索引状态：

   TFSConfig CodeIndex /indexingStatus /collectionName:\"default collection\"

3. 开始索引所有变更集：

   TFSConfig CodeIndex /setIndexing:on /collectionName:\"default collection\"

4. 停止索引之前创建的变更集，仅索引新的变更集：

   TFSConfig CodeIndex /setIndexing:keepupOnly /collectionName:\"default collection\"

5. 运行以下命令，列出默认集合中大小大于 10 KB 的前 50 个文件：

   TfsConfig CodeIndex /listLargeFiles /fileCount:50 /minSize:10 /collectionName:

6. 运行以下命令将特定文件排除在索引之外，并将其添加到忽略文件列表：

   TFSConfig CodeIndex /ignoreList:add \"$/Fabrikam Web Site/Catalog.cs\" /collectionName:\"default collection\"

7. 运行以下命令查看所有未被索引的文件：

   TFSConfig CodeIndex /ignoreList:view

8. 运行以下命令清除先前索引的数据并重新启动索引：

   TFSConfig CodeIndex /reindexAll /collectionName:\"default collection\"

9. 运行以下命令删除代码索引并进行确认：

   TFSConfig CodeIndex /destroyCodeIndex /collectionName:\"default collection\"

它是如何工作的…

TfsConfig 命令使您能够管理 CodeIndex 功能。有关各个命令的更多详情，请参考 bit.ly/1NNcwZi。

与 TFS 代理服务器的持续同步

如今，地理上分布的团队远程访问 TFS 已经很常见。远程用户可能会受到其所在位置与 TFS 托管位置之间连接延迟的影响。此时，团队基础代理服务器（Team Foundation Proxy Server）提供了解决方案。关于 TFS 代理缓存所有请求的说法是一个常见误解。事实上，代理服务器只缓存基于 TFVC 的版本控制中的Get操作。代理服务器并不会执行持续的同步或复制操作，而是仅在第一次请求时缓存该项内容。虽然来自远程位置的首次调用者仍然会面临get操作的延迟，但所有后续请求将像本地访问一样快速地获取数据。如今，鼓励开发人员频繁提交代码。这意味着在低网络带宽区域操作的地理分布式团队，在执行源代码控制的获取操作时会感到延迟。在本节中，您将学习如何预缓存数据到 TFS 代理，以提高代理的整体性能。

准备工作

本节需要您已设置 TFS 代理服务器。如果您还没有，可以按照 bit.ly/1lfGDS7 的步骤配置 TFS 代理服务器。为代理服务器添加额外的驱动器。在本节中，我们将使用 D:\\TFS\\Workspace 作为附加目录。

场景：在一个远程地点工作的部分分布式团队网络带宽较差，需要从 TFS 服务器下载代码的操作通常较慢。团队已在其远程地点安装了 TFS 代理服务器；然而，在下载源代码的增量更改时，仍然会遇到延迟。团队希望能采取主动的解决方案，将增量的代码更改下载到代理服务器中，这样当团队执行 Get 操作时，代理服务器可以直接从本地缓存中提供内容，而不必重新向 TFS 发起请求。

如何操作…

1. 登录到 TFS 代理服务器的计算机，浏览到 D:\\TFS\\Command 目录，并创建一个名为 PreGetTfsProxy.bat 的新文件。

2. 将以下代码复制到PreGetTfsProxy.bat文件中并保存更改：

   @echo off set local set TFSPROXY=http://localhost:8081 echo Forcing Pre-cache of files using TFS VC proxy at %TFSPROXY% cd D:\\TFS\\Workspace \"%PROGRAMFILES%\\Microsoft Visual Studio 14\\Common7\\IDE\\TF.exe\" get del /F /S /Q d:\\ tfs\\workspace\\*.* echo Pre-cache complete. end local 

3. 双击PreGetTfsProxy.bat来运行脚本测试脚本。如果脚本设置正确，D:\\TFS\\Workspace位置现在应该包含从 TFS 获取的源代码。

4. 设置一个 Windows 定期任务，每 10 分钟运行一次PreGetTfsProxy.bat文件。您可以调整此作业的执行频率，以最适合您组织的情况。

工作原理…

安装 Team Foundation Server Proxy Server 会安装 Team Foundation Server 命令行工具。TFS 代理服务器的核心功能是在本地缓存从 TFS 请求的任何文件，因此对于那些文件的任何后续调用可以直接由代理服务器提供。通过节省到 TFS 服务器的往返时间，代理服务器可以显著减少执行Get操作时注意到的延迟。TFS 代理服务器不执行工作区同步操作，而是仅缓存从 TFS 服务器请求的文件。在这个示例中，我们在代理服务器上创建了一个临时工作区，并通过 Windows 定期任务安排了Get操作的执行，以主动获取增量代码更改。这将导致代理服务器在代理服务器上主动缓存更改。虽然这种方法简单，但在同步源代码的同时非常有效。

TFS 代理服务器可以显著缩短执行Get操作所需的时间。Perfmon 是使用性能计数器测量系统性能的非常有用的工具。按照bit.ly/1SZEN2T中的步骤测量带有和不带代理服务器的Get操作的时间是一般推荐的，基准性能提升了代理服务器之后应该重新验证。

创建 TFS 数据库备份计划

“如果你没有计划，你就是在计划失败！” –本杰明·富兰克林

没有人愿意成为一个没有完整备份的服务器管理员。TFS 数据库是产品的核心；数据库是使用 Web Portal、Visual Studio 和 Microsoft Test Manager 交互的数据存储库。在这个示例中，您将了解到 TFS 提供的数据库备份功能。

准备工作

要配置备份计划，您需要是 TFS 管理员组的成员、SQL Server 管理员组的成员，以及（如果您的部署使用 SharePoint 产品）农场管理员组的成员。

TFS 服务帐户必须在每个托管您要备份的数据库的 SQL Server 实例上，设置允许 SQL Server 执行备份和创建维护计划的权限。您需要一个网络共享来存储数据库备份。服务帐户需要对存储备份的网络共享、文件夹或存储设备具有完全控制权限。

如何操作…

1. 登录到 Team Foundation Server 应用层并打开 Team Foundation Server 管理控制台。通过点击左侧导航面板中的计划备份进入计划备份屏幕：

2. 如图所示，指定网络备份路径并将持续时间设置为 30 天：

   高级部分允许您指定备份的文件扩展名以及事务备份文件：

   

   您还可以选择一个唯一的扩展名，并将其配置为排除在病毒扫描之外。业界普遍接受的备份扩展名是：bak用于完整备份，diff用于差异备份，trn用于事务备份。

3. 下一屏幕允许您指定报告数据库。勾选该选项将报告数据库包含在备份计划中。这样您就可以将报告数据库与 TFS 数据库一起备份。

4. 报告服务需要一个加密密钥以在数据库恢复后访问报告，请在报告密钥页面设置加密密钥密码并点击下一步。

5. 您可以选择性地勾选在备份计划中包含 SharePoint 数据库选项来备份 SharePoint 数据库。

6. 点击“下一步”进入警报屏幕。警报屏幕可用于指定备份计划的警报设置。您可以选择在备份任务成功或失败时提醒用户：

7. 调度备份页面允许您选择每日、手动和自定义调度。自定义调度让您可以更灵活地设置完整备份的调度、差异备份调度以及事务备份的间隔时间。

8. 在审核页面确认设置并点击下一步以触发验证检查。验证成功通过后，您可以点击配置按钮，根据设置配置备份：

9. 导航到\\\\tfs2015\\backup，您将找到BackupSets.xml、BackupSettings.xml和报告服务器的密钥。请复制并将其保存在安全的位置。

10. 您可以通过在 Team Foundation Server 管理控制台中点击立即进行完整备份链接来触发临时备份：

备份处理的更新会显示在弹出窗口中。备份完成后，您可以在网络共享中找到完整的备份集。

它是如何工作的…

了解数据的分类和关键性以及组织的恢复目标，对于制定组织的备份和恢复策略非常有帮助。某些组织可能有非常具体的备份需求，这些需求可能无法通过内置的“计划备份”进行配置。网站bit.ly/1IbxBLd详细讨论了这些使用案例。

Visual Studio ALM Rangers 提供了关于 TFS 灾难恢复规划的很好的指导。您可以在bit.ly/1Lwgx2y阅读更多内容。

清理 TFS 中未使用的工作区和 shelvesets - 进行中

对于 TFVC 用户来说，创建工作区以临时下载文件或简单地忘记删除未使用的 shelvesets 是很常见的。作为团队基础服务器管理员，减少这些杂乱无章的文件会对你有所帮助。tf.exe命令行工具提供了用于管理工作区和 shelvesets 的命令。在本实例中，您将学习如何使用tf.exe工具删除未使用的工作区和 shelvesets。

准备工作

要修改或删除现有的工作区或 shelveset，必须将全局管理工作区权限设置为允许。

如何操作…

1. 以提升模式启动开发者命令提示符。

2. 以下命令将删除属于 TFS 默认集合的Win2k12R2_John工作区。有关如何使用tf.exe命令切换工作区的更多示例，请参阅bit.ly/1P6mo6t：

   tf workspace /delete /collection:\"http://tfs2015:8080/tfs/defaultcollection\" workspacename:\"Win2k12R2_John\" 

3. 类似于工作区删除，shelveset 删除也遵循类似的命令模式。以下命令将从 TFS 的默认集合中删除Fabrikam_Delta工作区。有关更多示例，请参阅bit.ly/1lHChUk。

   tf shelve /delete shelvesetname:\"Fabrikam_Delta\" /collection:\"http://tfs2015:8080/tfs/defaultcollection\"

它是如何工作的…

TFS 命令行工具（tf.exe）随着 Visual Studio 的安装一起安装。TFS 命令行工具包含用于各种 TFS 操作的开关，使 TFS 管理员能够编写这些常规操作的脚本。您可以在bit.ly/1P6mo6t阅读更多有关这些操作的信息。

构建服务器是工作区的最大消耗者。长时间未使用的构建定义会保留工作区，并因此消耗大量存储。识别并手动删除这些死工作区是一项艰巨的任务。TFS 工作区清理工具是一个开源工具，托管在 CodePlex 上，可以通过删除若干天未使用的工作区来帮助您释放存储空间。您可以在bit.ly/1LxFDhv了解更多关于此工具的信息。

第八章：扩展和自定义 Team Foundation Server

“首先解决问题，然后再写代码。” –约翰·约翰逊

本章将涵盖以下主题：

• 从 NuGet Gallery 获取 TFS 对象模型

• 使用团队项目选择器程序化连接到 TFS

• 使用 TFS 对象模型确定 TFS 的版本

• 使用 TFS 对象模型程序化检索 TFS 权限

• 程序化获取团队项目的过程模板名称

• 使用 REST API 程序化获取构建详细信息

• 使用 REST API 程序化获取 Git 仓库列表

• 使用 REST API 程序化根据 ID 获取工作项

• 向现有的团队项目的产品待办项中添加团队字段

• 在工作项表单中添加多项选择控件

介绍

TFS 提供了集成的软件应用交付和生命周期管理工具。组织通常会使用不同的工具来管理生命周期的不同部分，例如，使用 Jira 进行敏捷项目管理，使用 TeamCity 进行构建，使用 Jenkins 进行发布管理，使用 ServiceNow 进行服务管理。客户期望能够在不同的系统之间集成和共享信息。Team Foundation Server 有一个相当大的工具和服务生态系统，以下截图显示了 TFS 生态系统中的一些合作伙伴，你可以在 vsipprogram.com/Directory 找到完整的列表：

基本上不可能提供与每个其他系统的开箱即用集成；为了弥补这一差距，TFS 提供了一个非常丰富的库，允许你在 TFS 中检索、编辑、更新、插入和删除数据。该 API 使这些操作变得安全且可审计。如今，TFS 有两种扩展技术，如下图所示：

让我们详细解释这两种扩展技术：

• TFS 对象模型：TFS 对象模型支持 .NET 和 Java 平台，并且自 TFS 2005 起就已包含在产品中。随着版本的发布，对象模型库增加了更多功能。使用对象模型构建的扩展可以集成到 Visual Studio 和 Team Explorer 中，也可以作为独立工具使用。对象模型有以下限制：

  • 它不支持团队网站门户的扩展性

  • 它不支持非 Windows 操作系统

  • 它不支持移动设备的客户端扩展

• RESTful 服务：RESTful 服务首次在 TFS 2013 中亮相。RESTful 服务是基于 JSON 的 REST 服务，主要集中在弥补 TFS 对象模型的局限性。这些服务使团队 Web 门户的扩展性、非 Windows 平台的扩展以及移动设备的客户端扩展成为可能。RESTful 服务也可以在 TFS 对象模型中调用。这非常强大，因为它使你能够为 TFS 对象模型中没有任何扩展点的功能构建扩展性。例如，Team Rooms 是一个仅限 Web 的功能，在 TFS 对象模型中没有扩展点。Team Rooms Visual Studio 扩展（bit.ly/1TeNIO7）是使用 Team Rooms REST API 和 TFS 对象模型构建的。

TFS 对象模型和 RESTful 服务为扩展性提供了无限的机会。尽管今天可以将 RESTful 服务与 TFS 对象模型一起使用，但 RESTful 服务尚未完全准备好用于扩展 TFS 中的团队 Web 门户。RESTful 服务使用 OAuth 进行身份验证和授权，而 TFS 并没有提供 OAuth 令牌生成能力。作为一种变通方法，可以使用备用凭据来验证 REST API。由于需要在托管 TFS 的 IIS 实例上启用基本身份验证，组织可能会不愿意启用备用凭据。本文中的配方通过使用备用凭据实现了 REST API。请按照此处的说明启用备用凭据：bit.ly/1IhEQH1。

由于 TFS 没有 OAuth 令牌生成能力，因此无法为 TFS 构建团队 Web 门户扩展。OAuth 令牌生成能力预计将在 TFS 2015 的未来更新中发布。TFS 和 VSTS 的 RESTful 扩展模型是相同的。由于 VSTS 拥有 OAuth 令牌生成系统，因此你可以在 VSTS 中使用 RESTful 服务开始为 VSTS 中的团队 Web 门户构建扩展。RESTful 服务是最近在 VSTS 中引入的市场能力的基础。预计这一能力将在未来的 TFS 更新中提供。你可以在这里了解更多关于 VSTS 市场的信息：bit.ly/1Q6afgw。

除了涵盖扩展性外，我们还将学习 TFS 中定制化的可能性。TFS 提供了一个定制框架，使得在团队项目级别上进行定制成为可能。对团队项目的定制是通过过程模板应用的。过程模板是一个包含 XML 文件的集合，这些文件保存了需要应用于团队项目的工件和过程的指令。举个例子，过程模板中包含了关于安全组、区域、迭代、工作项和积压项的指令。模板还应用了这些工件所展现的工作流和行为，例如，CMMI 模板中的 Bug 工作项有一个“准备测试”状态，而 Scrum 模板中的 Bug 工作项则没有。虽然 TFS 默认加载了 Scrum、Agile 和 CMMI 过程模板，但 TFS 支持定制现有过程模板以及创建新的过程模板，以最好地满足你团队的需求。一个过程模板由九个插件组成；每个插件在团队项目设置过程中执行一组任务。下图展示了可以定制的插件和对象文件：

当前的过程模板结构和工具存在多种限制：

• 工具：要编辑过程模板，你需要安装过程模板编辑器。该编辑器只能通过安装 TFS 强力工具 (bit.ly/1jJkEmt) 来安装。过程模板编辑器与 TFS 的版本密切相关。该编辑器只能通过 Visual Studio 启动。该编辑器不支持非 Windows 平台。

• 复杂性：要编辑过程模板，你需要对过程模板和团队项目有深入的了解。过程模板编辑器很基础；它没有提供任何验证功能，也没有测试所做更改的方式。

• 可维护性：如果团队项目的过程模板已被修改，TFS 不会自动将该产品升级到最新的功能。这样的项目需要手动启用新功能。

为了去除当前过程模板定制工具的限制，正在团队 Web 门户中开发一个新的过程定制体验。这个新体验将是基于 Web 的，因此可以在非 Windows 设备上使用。新的体验将通过提供丰富的引导体验来简化常见任务的过程修改。新工具将使得团队项目在升级后能够自动更新新功能。为了实现这一点，过程模板中的所有系统字段将被锁定，无法定制。新工具已经在 VSTS 中发布预览版。你可以在 bit.ly/1OxP31n 了解更多信息。预计新工具将在 TFS 2015 的未来更新中发布。本章中的示例基于使用过程模板编辑器定制过程模板。

总结一下，本章的扩展性方案基于 TFS 对象模型和带有备用凭据的 RESTful 服务。本章的自定义方案则基于过程模板编辑器。扩展性和自定义功能正在经历巨大的变化。虽然这两者的变更已经在 VSTS 中发布，但它们在 TFS 2015 Update 1 中不可用。预计这些变化将在未来的 TFS 2015 更新中提供。

从 NuGet Gallery 获取 TFS 对象模型

如果你之前使用过 TFS 对象模型，你会认识到获取 DLL 及其依赖项是一个繁琐的过程。TFS 的 DLL 需要从安装目录中提取。许可框架不允许分发这些 DLL。这意味着，任何与代码一起工作的人，要么需要安装所有依赖项，要么需要手动将 DLL 添加到项目引用中。在 TFS 2013 中，引入了一个独立安装程序，将所有 TFS 对象模型的二进制文件部署到机器上。虽然这简化了设置过程，但它确实增加了开发者的一步操作。这不仅复杂了开发过程，也使得构建和测试流程变得更加复杂。

NuGet 已经成为 Microsoft 开发平台（包括.NET）的标准包管理工具。NuGet 客户端工具提供了生成和使用软件包的能力。NuGet Gallery 是所有包作者和消费者使用的中央包仓库。通过 NuGet 提供对象模型似乎是自然而然的。随着 Team Foundation Server 2015 的发布，现在可以通过 NuGet 直接获取对象模型。此外，许可政策已被修改，以允许软件包的分发。在本方案中，你将学习如何通过 NuGet 获取 TFS 对象模型。

准备工作

本方案需要使用 Visual Studio 2015。如果你没有安装 Visual Studio，可以使用免费提供的 Visual Studio Community 版，下载地址为www.visualstudio.com/en-us/downloads/download-visual-studio-vs.aspx。

如何操作…

1. 打开 Visual Studio，创建一个新的 Windows 控制台应用程序项目，并将项目命名为asPlayPit。

2. 在解决方案资源管理器中，右键点击项目并选择管理 NuGet 包。这将打开 Visual Studio 中的 NuGet 包搜索窗口。

3. 搜索并添加Microsoft.TeamFoundationServer.Client和Microsoft.TeamFoundationServer.ExtendedClient软件包。

4. 安装这些软件包时，还会安装相关的依赖包。一旦软件包安装成功完成，在PlayPit项目的解决方案资源管理器中展开引用部分。你会看到所有的 TFS 和依赖的 DLL 已经成功添加为项目引用。

它是如何工作的…

在 Team Foundation Server 2015 中，Team Explorer 现在作为 VSIX 包安装。这有两个影响：

• 每次安装的 Team Explorer 安装位置可能会有所不同。

• TFS 程序集不再位于 全局程序集缓存 (GAC) 中。

如果您正在开发扩展，您的扩展将无法自行解析 TFS 引用，因为 TFS DLL 已不再位于 GAC 中。因此，建议您在项目中添加对 TFS NuGet 包的引用来解决这些依赖关系。将 TFS DLL 移出 GAC 的主要原因是为了减少管理多个版本及其依赖关系的复杂性。

通过 NuGet 添加包会在解决方案级别创建一个 package 文件夹。所有添加的包也存储在该文件夹中。如以下截图所示，作为此配方一部分安装的 TFS 及相关包已被下载到该文件夹中：

在提交代码时，这些包也会被提交到源代码管理中。这样做的好处是，任何处理该代码的人都不需要担心引用问题。可以在解决方案级别启用 自动恢复 NuGet 包 选项。这样，在编译时，其他开发者机器上的所有 NuGet 引用都会被恢复（这不需要将包提交到源代码管理中）。它还适用于构建和测试工作流，显著减少了开发环境设置的开销。许可条款已经更改，现在您可以将 TFS 2015 客户端 OM 与您的应用一起重新分发。有关包、其内容和用途的更多细节，请参阅 bit.ly/1jkoSQj。

使用团队项目选择器以编程方式连接到 TFS。

TFS 对象模型提供了几种连接到 Team Foundation Server 的选项。团队项目选择器 (TPP) 是其中之一；使用项目选择器的优点是用户可以看到他们熟悉的 TFS 连接对话框。用户可以通过该对话框指定 TFS 服务器的详细信息并进行身份验证。在此配方中，您将学习如何使用 TPP 以编程方式进行身份验证并连接到 TFS。

准备工作

请按照 从 NuGet Gallery 获取 TFS 对象模型 配方中的步骤，在 Visual Studio 中创建项目并将 TFS NuGet 包添加到该项目中。

如何操作…

1. 将以下代码复制到新创建项目中的 Program.cs 类中：

   // Global Variablesprivate static TfsTeamProjectCollection _tfs;private static ProjectInfo _selectedTeamProject;// Connect to TFS Using Team Project Pickerpublic static void ConnectToTfsUsingTeamProjectPicker(){// The user is allowed to select only one projectvar tfsPp = new TeamProjectPicker(TeamProjectPickerMode.SingleProject, false);tfsPp.ShowDialog(); // The TFS project collection _tfs = tfsPp.SelectedTeamProjectCollection;if (tfsPp.SelectedProjects.Any()) { // The selected Team Project _selectedTeamProject = tfsPp.SelectedProjects[0]; }}

2. 从 Main 调用 ConnectToTfsUsingTeamProjectPicker 方法。一旦触发 tfsPp.ShowDialog() 语句，TPP 窗口就会弹出。如下图所示，项目选择器允许您交互式地配置 TFS 服务器、集合和项目：

工作原理……

TeamProjectPicker 类接受 TeamProjectPickerMode 和 DisableCollectionChange 作为参数。在前面的代码片段中，我们强制 TeamProjectPicker 类以单项目模式启动，即只能选择一个团队项目。false 值用于覆盖，禁用选择器中可用的更改团队项目集合选项。其余代码仅是读取并将选定的团队项目名称存储在全局变量中。

你也可以传递 TeamProjectPicker.MultiProject 值，允许用户选择多个团队项目。你还可以通过传递 true 值给 DisableCollectionChange 参数来禁用更改项目集合的下拉菜单。

使用 TFS 对象模型确定 TFS 版本

如果你正在构建一个使用 TFS 对象模型的扩展，且目标是多个版本的 TFS，那么你很可能希望通过编程方式确定当前指向的 TFS 服务器版本。TFS 后期版本中引入的一些 API 服务在早期版本的 TFS 中不可用。不幸的是，API 并未暴露能够提供 TFS 精确版本的属性或函数。在这个配方中，你将学习如何通过编程方式确定 TFS 版本。

准备工作

按照 从 NuGet Gallery 获取 TFS 对象模型 配方中的步骤，在 Visual Studio 中创建一个项目。将项目命名为 DetermineTFSVersion，并向该项目添加 TFS NuGet 包。

如何实现…

1. 将以下代码复制到新创建项目中的 Program.cs 类中。

2. 在 Main 方法中，添加以下代码：

   var server = new TfsTeamProjectCollection(new Uri(\"http://tfs2015:8080/tfs\"));server.EnsureAuthenticated();var serverVersion = server.ServerDataProvider.ServerVersion;Console.WriteLine(\"Server Version: {0}\", serverVersion);Console.ReadKey();

3. 服务器版本将在控制台输出中打印出来，如以下输出所示：

它是如何工作的…

虽然此程序的输出不一定会给出 TFS 的完整程序集版本，但它有助于你了解产品的版本。在以下截图中，你可以看到 TFS 管理控制台中显示的 TFS 版本为 14.0.24706.0，而程序返回的是 Dev14.M89-Part7：

让我们逐步查看代码，理解具体做了什么：

• TfsTeamProjectCollection 类用于初始化与服务器的新连接。在此情况下，服务器的详细信息作为 URI 传递给该类。建立与 TFS 服务器连接的其他方式已在本章 使用团队项目选择器以编程方式连接到 TFS 配方中讨论。

• 如果连接尚未通过身份验证，EnsureAuthenticate 方法会被调用，启动身份验证连接过程。

• 一旦连接已通过身份验证，ServerVersion 属性（嵌套在 ServerDataProvider 类中）将保存 TFS 服务器版本的值。

• ServerVersion属性的值通过控制台的WriteLine方法打印到控制台。控制台的ReadKey方法用于暂停控制台，以便可以读取打印到控制台输出中的ServerVersion结果。

还有一种替代方法可以通过编程识别 TFS 的版本；TFS 位置服务返回 TFS 中可用服务的列表。此列表和服务的版本可以用来识别 TFS 的版本。关于这种方法的更多信息，请访问bit.ly/21l0YX8。

使用 TFS 对象模型通过编程检索 TFS 权限

TFS 管理员通常需要发布和审查用户权限。在本食谱中，您将学习如何使用 TFS 对象模型通过编程生成 TFS 中团队项目用户的安全组、成员、权限和安全设置。

准备就绪

按照从 NuGet Gallery 获取 TFS 对象模型食谱中的步骤，在 Visual Studio 中创建一个项目，并将 TFS NuGet 包添加到该项目中。

如何操作…

1. 通过编程连接到 TFS：第一步需要建立与 TFS 的连接。可以使用以下代码片段完成此操作：

   var tfs = TfsTeamProjectCollectionFactory .GetTeamProjectCollection(new Uri(\"http://tfs2015:8080/tfs\")); tfs.EnsureAuthenticated();

2. 获取版本控制服务器服务的实例：版本控制服务器服务公开了一个接口，其中包含一组方法，用于通过编程操作 TFS 版本控制组件：

   // Version control service exposes methods to work with TFS version controlvar vcs = tfs.GetService();// Since we\'ll be reporting groups for all team projects, imp to get all team projectsvar teamProjects = vcs.GetAllTeamProjects(false);// Narrow down to the FabrikamTFVC Team Projectvar teamProject = teamProjects.FirstOrDefault(p=>p.Name == \"FabrikamTFVC\");

3. 应用程序组：IGroupSecurityService接口用于检索团队项目的组成员列表：

   // Group Security service exposes methods to get groups, users and security detailsvar sec = tfs.GetService();Identity[] appGroups = sec.ListApplicationGroups(teamProject.ArtifactUri. AbsoluteUri);

   通过 Team Explorer，您可以进入设置页面并点击组成员资格超链接来检索此信息。点击组成员资格超链接将带您进入 Team Web Portal 中的安全页面。以下截图的左侧显示了 FabrikamTFVC 项目安全页面中的组，右侧显示了通过编程返回的结果：

   

4. 获取应用程序组中的成员：每个应用程序组包含用户或进一步的 AD 组。以下代码片段遍历应用程序组的成员并获取每个成员的身份：

   foreach (Identity group in appGroups){Identity[] groupMembers = sec.ReadIdentities(SearchFactor.Sid, new string[] { group.Sid }, QueryMembership.Expanded);foreach (Identity member in groupMembers) {Console.WriteLine(member.DisplayName); if (member.Members != null)  {foreach (string memberSid in member.Members) { Identity memberInfo = sec.ReadIdentity (SearchFactor.Sid, memberSid, QueryMembership.Expanded);var userName = memberInfo.Domain + \"\\\\\" + memberInfo.AccountName;Console.WriteLine(string.Format(\" {0}\", memberInfo.AccountName)); }  } }}

   现在，程序不仅返回组的名称，还返回每个嵌套组中的成员：

   

5. 获取用户会员设置：应用程序组中的用户要么继承权限，要么直接分配权限。以下代码片段使用版本控制服务中的GetPermissions方法来计算用户的会员设置：

   var actualPermission = vcs.GetPermissions(new string[] { TeamProject.ServerItem }, RecursionType.Full);foreach (var memberOf in memberInfo.MemberOf) { // Get information about the members}

   通过 Team Explorer，您可以进入设置页面并点击安全超链接来检索此信息。点击安全超链接将打开 Team Web Portal 中的安全页面：

   

6. 版本控制权限：可以使用版本控制服务中的GetEffectivePermissions方法检索版本控制上的单个用户权限：

   var permissions = vcs.GetEffectivePermissions(userName, teamProject.ServerItem);foreach (var permission in permissions){versionControlPerTmissions.Add(new VersionControlPermission(){Name = permission});}

   返回组中每个用户的版本控制权限。如下截图所示，用户Tarun是Project Valid Users组的成员，并具有Manage Branch权限：

   

以编程方式获取 Team Project 的流程模板名称

在此配方中，您将学习如何获取用于创建 Team Project 的流程模板名称。

准备工作

按照从 NuGet Gallery 获取 TFS 对象模型中的步骤，在 Visual Studio 中创建项目，并向此项目添加 TFS NuGet 包。

操作步骤…

1. 首先，以编程方式连接到 TFS。作为第一步，需要建立与 TFS 的连接。可以使用以下代码片段完成此操作：

   var tfs = TfsTeamProjectCollectionFactory .GetTeamProjectCollection(new Uri(\"http://tfs2015:8080/tfs\")); tfs.EnsureAuthenticated();

2. 要获取 Team Project 的流程模板详细信息，我们需要VersionControlServer服务的一个实例和Now实例来获取ICommonServerService。VersionControlServer服务用于获取项目详细信息，特别是我们需要的AbsoluteUri。AbsoluteUri用于由ICommonServerService标识项目属性，例如流程模板名称：

   // Get an instance of the VersionControlServervar vcs = server.GetService();// Get an instance of the ICommonStructureServicevar ics = server.GetService();ProjectProperty[] ProjectProperties = null;// Get the team project by namevar teamProject= vcs.GetTeamProject(\"FabrikamTFVC\");string ProjectName = string.Empty;string ProjectState = string.Empty;int templateId = 0;ProjectProperties = null;// Get the project properties using the ICommonStructureServerics.GetProjectProperties(teamProject.ArtifactUri.AbsoluteUri, out ProjectName, out ProjectState, out templateId, out ProjectProperties);// Output all the project propertiesforeach (var pp in ProjectProperties){Console.WriteLine(string.Format(\"{0} - {1}\", pp.Name, pp.Value));}

   执行此操作将返回属性及其值的列表。如下截图所示，Scrum模板已用于创建 FabrikamTFVC Team Project。SourceControlGitEnabled和SourceControlTfvcEnabled属性告诉您 Team Project 中的源控制功能：

   

工作原理…

使用流程模板管理器从 TFS 下载 Scrum 流程模板。从下载位置打开Classification文件夹下的Classification.xml文件。API 基本上渲染了Classification.xml的内容：

您可以在Classification.xml文件中添加更多属性和值，并使用此模板版本创建 Team Projects。ICommonStructureServer服务中的GetProjectProperties方法将返回新添加的属性。此外，您还可以使用ICommonStructureService中的UpdateProjectProperties方法更新这些属性的值。

使用 REST API 以编程方式获取构建详细信息

在此步骤中，您将学习如何使用BuildHttpClient REST API 获取 Team Project 中带有详细信息的构建列表。

准备工作

正如在章节介绍中提到的，Team Foundation Server 2015 尚未具备 OAuth 令牌提供能力；因此，使用 REST API 的唯一方法是使用备用凭据。备用凭据使用基本身份验证作为认证协议。在使用基本身份验证时，用户凭据以明文形式发送到服务器。在专业环境中，这种设置是不能接受的。请按照 bit.ly/1Nfe8e0 中的说明设置自签名证书，为 TFS 配置 SSL。通过 SSL，客户端和 TFS 之间的流量将被加密。

如果你只是想尝试一下 REST API 而不想涉及设置的复杂性，那么 API 沙盒是一个很好的起点：apisandbox.msdn.microsoft.com。API 沙盒已经连接到一个示例 Visual Studio Team Services 帐户，它提供了预配置的代码示例来尝试 API 提供的功能，你还可以额外连接到你自己的 Visual Studio Team Services 实例。虽然 API 沙盒不能连接本地 TFS 实例，但是通过在构造服务 URL 中指定 API 版本参数，你可以调用旧版本的 API。API 沙盒的替代方案是 Postman (bit.ly/1l044iU)。Postman 作为 Chrome 商店的免费扩展程序提供。它是一个非常好用的工具，可以更快地构建、测试和文档化 API。你可以直接在 Postman 中传递服务器 URL 和参数来触发所有的 REST 操作。这使得你也可以连接到本地的 TFS 实例；这对于尝试针对真实数据的 API 非常有用。

下载课程材料提供的 RESTDemo 解决方案。该解决方案包含三个项目，分别是 GetBuildDetails、GetGitRepos 和 GetWorkitemById。在 Visual Studio 中打开 RESTDemo 解决方案。在这个示例中，我们将通过 GetBuildDetails 项目来获取团队项目中具有详细信息的构建列表。

如何操作…

1. 在 RESTDemo 解决方案中，将 GetBuildDetails 设置为启动项目：

2. 运行 GetBuildDetails 项目，这将启动一个控制台，输入 TFS 服务器 URL，然后按 Enter：

3. 输入要连接到 TFS 的用户名和密码，然后按 Enter：

4. 输入您希望从中检索构建详细信息的项目名称：

5. 控制台将输出 FabrikamTFVC 中构建的列表以及构建的详细信息，如构建定义的名称、构建编号、结果、请求者、开始时间和完成时间：

工作原理…

我们将一起查看GetBuildDetails项目中的代码，以理解代码的工作原理。为了连接并从 TFS 获取数据，该项目需要 TFS API 二进制文件。该项目使用Microsoft.TeamFoundationServer.ClientNuGet包来获取正确的二进制文件引用：

从解决方案资源管理器中，打开GetBuildDetails项目中的Program.cs文件。该程序获取 TFS 服务器 URL、用户名和密码作为用户输入。密码在控制台中会显示为星号形式，将输入的字符替换为星号后再输出到控制台。创建一个VssBasicCredential实例，使用用户名和密码。然后，这些信息传递给BuildHttpClient。当创建BuildHttpClient类的实例时，构造函数将接收服务器 URL 和凭据。BuildHttpClient对象在实例化过程中会验证与 TFS 的连接：

var tfsServerUrl = Console.ReadLine(); var userName = Console.ReadLine(); var password = GetConsolePassword(); var projectName = Console.ReadLine(); var credentials = new VssBasicCredential(userName, password); BuildHttpClient buildClient = new BuildHttpClient(new Uri(tfsServerUrl), credentials); 

BuildHttpClient类包含GetBuildsAsync方法。团队项目名称作为参数传递给GetBuildsAsync方法：

var builds = buildClient.GetBuildsAsync(projectName).Result;

该功能返回一个构建列表。构建实体包含所有构建属性，如以下截图所示：

程序随后遍历构建列表，并将属性打印到控制台。您可以在www.visualstudio.com/integrate/api/build/overview获取更多关于构建 REST API 的详情。

使用 REST API 以编程方式获取 Git 仓库列表

在本食谱中，您将学习如何使用GitHttpClient REST API 以编程方式获取团队项目中的 Git 仓库列表。

准备工作

请参考准备工作部分中使用 REST API 以编程方式获取构建详情食谱中的说明，了解设置细节。下载课程材料中提供的RESTDemo解决方案。在本食谱中，我们将通过GetGitRepos项目获取来自团队项目的 Git 仓库列表及其详情。

如何实现…

1. 在RESTDemo解决方案中，将GetGitRepos设置为启动项目：

2. 运行GetGitRepos项目，这将启动一个控制台。输入 TFS 服务器 URL 并按Enter：

3. 输入您想要连接到 TFS 的用户名和密码，然后按Enter：

4. 输入您希望从中获取构建详情的项目名称：

5. 控制台输出包含 FabrikamGit 项目的 Git 仓库列表，并附带仓库的详细信息，如其 ID、名称和远程 URL：

工作原理…

我们将通过GetGitRepos项目的代码来了解代码的工作原理。为了连接并从 TFS 获取数据，项目需要 TFS API 二进制文件；项目使用Microsoft.TeamFoundationServer.ClientNuGet包来获取正确的二进制引用：

从解决方案资源管理器中打开GetGitRepos项目中的Program.cs文件。程序从用户那里获取 TFS 服务器的 URL、用户名和密码作为输入。密码在控制台中通过将输入的字符转换为星号的形式进行掩码处理，然后输出到控制台。创建一个VssBasicCredential实例，包含用户名和密码。该信息随后传递给GitHttpClient。创建GitHttpClient类的实例，构造函数接受服务器 URL 和凭据。GitHttpClient类在实例化过程中验证与 TFS 的连接：

var tfsServerUrl = Console.ReadLine();var userName = Console.ReadLine();var password = GetConsolePassword();var projectName = Console.ReadLine();var credentials = new VssBasicCredential(userName, password);GitHttpClient gitClient = new GitHttpClient(new Uri(tfsServerUrl), credentials);

GitHttpClient类包含GetRepositoriesAsync方法。团队项目名称作为参数传递给该方法：

var gitRepositories = gitClient.GetRepositoriesAsync(projectName, true).Result;

该函数返回一个GitRepository列表。GitRepository实体包含所有GitRepository的属性：

程序接着遍历GitRepositories列表，并将属性打印到控制台。你可以在www.visualstudio.com/integrate/api/git/overview获取更多关于 Git REST API 的详细信息。

使用 REST API 通过 ID 编程获取工作项

在这个示例中，你将学习如何通过WorkItemTrackingHttpClient REST API 编程获取工作项的详细信息。

准备工作

请参考通过 REST API 编程获取构建详细信息示例中的准备工作部分获取设置详情。下载课程材料中提供的RESTDemo解决方案。在这个示例中，我们将通过GetWorkItemById项目来获取工作项的详细信息。

如何操作…

1. 在RESTDemo解决方案中，将GetWorkItemById设置为启动项目：

2. 运行GetWorkItemById项目，这将启动一个控制台，输入 TFS 服务器的 URL，按Enter键：

3. 输入你想要连接到 TFS 的用户名和密码，按Enter键：

4. 输入你想查询 API 的工作项 ID：

5. 控制台输出工作项的详细信息，如所属的团队项目、类型、标题、状态和创建者：

工作原理……

我们将通过GetWorkItemById项目中的代码来了解代码的工作原理。为了连接并从 TFS 获取数据，该项目需要 TFS API 的二进制文件；该项目使用Microsoft.TeamFoundationServer.ClientNuGet包来获取正确的二进制引用：

从解决方案资源管理器中，打开Program.cs文件，位于GetWorkItemById项目中。该程序获取 TFS 服务器的 URL、用户名和密码信息作为用户输入。密码在控制台上以星号形式显示，即在打印到控制台之前将输入的字符替换为星号。使用用户名和密码创建VssBasicCredential实例。然后将这些信息传递给WorkItemTrackingHttpClient。创建WorkItemTrackingHttpClient类的实例，构造函数接受服务器 URL 和凭据。WorkItemTrackingHttpClient类会在实例化过程中验证与 TFS 的连接。正如你可能已经注意到的，在这个示例中我们并不需要询问团队项目的名称，因为工作项 ID 是在团队项目集合级别作用域内的。这意味着工作项 ID 在团队项目集合级别是唯一的，既然 TFS 服务器 URL 包含集合名称，那么不需要单独请求此信息：

var tfsServerUrl = Console.ReadLine();var userName = Console.ReadLine();var password = GetConsolePassword();var credentials = new VssBasicCredential(userName, password);WorkItemTrackingHttpClient witClient =new WorkItemTrackingHttpClient(new Uri(tfsServerUrl),new VssBasicCredential(userName, password));

WorkItemTrackingHttpClient类包含GetWorkItemAsync方法。工作项 ID 作为参数传递给此方法。

var workItem = witClient.GetWorkItemAsync(Convert.ToInt32(workitemId)).Result;

该函数返回一个WorkItem类型的对象。WorkItem类包含关于工作项字段的信息，以及关于关系和修订的信息：

然后程序将字段的值打印到控制台：

Console.WriteLine($\"Team Project: workItem.Fields[\"System.TeamProject\"]}\");Console.WriteLine($\"Type: {workItem.Fields[\"System.WorkItemType\"]}\");Console.WriteLine($\"Title: {workItem.Fields[\"System.Title\"]}\");Console.WriteLine($\"State: {workItem.Fields[\"System.State\"]}\");Console.WriteLine($\"Created By: {workItem.Fields[\"System.CreatedBy\"]}\");

你可以在www.visualstudio.com/integrate/api/wit/overview获取关于工作项 REST API 的更多详细信息。

向现有的团队项目中的产品待办事项添加团队字段

区域路径字段的最初目的是根据工作项所属的功能或技术领域对工作项进行逻辑分组，在这个字段被用作团队待办事项路径之前。如果你打算将区域路径用于工作项的功能或技术分组，你将需要一个新字段来将工作项分配到团队项目中的各个团队。在这个方案中，你将学习如何通过修改现有的流程模板向团队项目添加团队字段。

准备就绪

可以使用流程模板管理器下载流程模板。为此，请导航到团队资源管理器的设置页面。从团队项目集合视图中选择流程模板管理器超链接：

TFS 中的开箱即用流程模板已被锁定为不可编辑。这是通过向流程模板添加已知的 GUID 实现的。该 ID 帮助区分开箱即用的流程模板和其他模板。如果你打算自定义流程模板，建议将开箱即用的流程模板的 GUID 修改为不同的 GUID。如以下截图所示，可以通过下载流程模板并将 GUID 更改为不同的值来完成此操作：

修改现有的团队项目可能会导致数据损坏，因此建议在尝试本教程中突出显示的更改之前，使用更新后的流程模板创建一个测试项目。你需要是项目管理员组的成员才能对团队项目进行这些更改。

下载并安装 TFS Power Tools（bit.ly/1jJkEmt），这将安装流程编辑器扩展。

如何操作…

1. 创建一个 ProcessTemplateRecipe 目录，并创建一个新文件 TeamGlobalList.xml。将以下文本复制并保存到 TeamGlobalList 文件中：

2. 打开 Visual Studio，并从工具菜单启动流程编辑器。在上下文菜单中，选择导入全局列表：

3. 要上传 TeamGlobalList.xml 文件，请导航到该目录并选择 TeamGlobalList.xml。要验证上传，请从服务器中选择打开全局列表：

4. 从服务器打开 WIT，方法是从流程编辑器菜单中选择此选项。选择 FabrikamTFVC 团队项目和产品待办事项类型的工作项：

5. 流程编辑器以图形界面启动产品待办事项类型的工作项：

6. 新建按钮用于向工作项类型添加一个新字段。点击新建并输入如下截图所示的详细信息：

7. 在规则选项卡中，点击新建，选择允许的值。点击新建并选择先前创建的团队全局列表：

8. 导航到布局选项卡，并在状态组列下为团队创建一个新控件。根据如下截图配置团队控件：

9. 点击预览表单按钮以加载工作项表单中的更改预览。在工作项类型表单中点击保存以应用更改。

它是如何工作的…

要测试这些更改，请创建一个新的产品待办事项类型的工作项。表单现在包括团队字段。这些更改已应用于 Visual Studio 和团队 Web 门户中的工作项表单：

通过选择将字段添加为维度，现在支持使用 TFS 数据仓库进行报告。如果你打算将此字段用于报告，这是非常棒的。

过程模板支持在工作项表单级别进行自定义，也支持在其他级别进行自定义，如安全组、项目默认设置、版本控制和报告。MSDN 提供了全面的指导和操作步骤，介绍了如何应用这些自定义设置；你可以在bit.ly/1lmwLGr了解更多信息。

在工作项表单中添加多项选择控件

原生情况下，团队项目中的工作项表单不支持多值字段。虽然过程模板中没有原生支持多值字段，但有一个开源的多值字段控件，它可以帮助你实现这一点。在本操作中，你将学习如何在现有的团队项目中设置并使用多值字段控件。

准备工作

从 CodePlex 下载并安装自定义工作项控件：witcustomcontrols.codeplex.com。下载包包括 Web 扩展和 Visual Studio 扩展。Visual Studio 扩展需要安装在你打算在 Visual Studio 中使用多值控件的所有机器上。如果你只打算在 Web 门户中使用该控件，则不需要在机器上安装此控件。你需要是项目管理员组的成员，才能进行这些更改。

在这个操作中，我们将扩展本章前面介绍的团队全局列表字段，该字段在将团队字段添加到现有团队项目的产品待办事项中的操作中已经设置过。

如何操作…

1. 通过浏览http://tfs2015:8080/tfs/_admin/_extensions启动 Team Web Portal 扩展控制台：

2. 单击安装按钮，以将多值字段控件扩展上传到 Web 门户。从下载位置选择并添加扩展：

3. 上传后启用扩展。这将激活整个 TFS 实例中的扩展：

4. 打开 Visual Studio 并启动过程编辑器，从上下文菜单中选择从服务器打开 WIT。连接到 FabrikamTFVC 团队项目并打开产品待办事项工作项类型。在前一个操作中，添加了团队字段，并将其与类型为FieldType的控件关联。导航到布局标签，找到团队字段，将控件类型更改为MultiValueControl。点击保存以应用更改：

它是如何工作的…

要测试更改，请使用团队 Web 门户创建一个类型为产品待办事项（Product Backlog Item）的新的工作项。如下面的截图所示，团队字段在每个团队名称旁边显示一个复选框，允许你选择多个项目。选择多个值并保存工作项的更改。工作项中设置的值也可以从工作项查询窗口中查询：

当你在安装了多值选择控件的计算机上使用 Visual Studio 打开产品待办事项工作项表单时，你也将看到多值选择器选项。