微软-TeamFoundation-服务器秘籍-全-

微软 TeamFoundation 服务器秘籍（全）

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

译者：飞龙

协议：CC BY-NC-SA 4.0

前言

Visual Studio 是微软开发者工具和服务的套件，其中一些关键工具包括 Visual Studio IDE、Visual Studio Code、Visual Studio Team Services 和 Visual Studio Team Foundation Server（TFS）。早在 2004 年 11 月，微软就发布了集成的应用生命周期管理（ALM）工具的第一个版本，名为“Microsoft Visual Studio Team Systems”。在过去的 15 年里，该产品经历了几次演变，每次都丰富了开发者体验和工具的范围：

Visual Studio – 任何应用，任何开发者

Visual Studio 工具和服务家族现在支持跨多个平台的异构软件开发。产品中使用开源工具的体验已经得到了极大的提升。开源解决方案被赋予了首等公民的地位，更多的这些解决方案被预先打包进产品中。这清楚地表明微软希望成为每位开发者的首选平台，无论技术或平台如何。Visual Studio 工具家族中的工具和服务之间存在着巨大的重叠。本书完全聚焦于 Visual Studio Team Foundation Server 2015。

Microsoft Visual Studio Team Foundation Server 2015 是微软 ALM 解决方案的核心，提供了版本控制、工作项跟踪、报告和自动化构建等核心服务。TFS 帮助组织在设计、构建、测试和部署软件的整个过程中更有效地沟通与协作，最终提高生产力和团队产出、改善质量，并为应用程序生命周期提供更大的可视性。

在过去十年里，软件交付本身经历了一场革命。敏捷实践和精益框架的引入，如 Scrum、Kanban、XP 和 RUP 等，证明了迭代反馈驱动的开发有助于应对市场、业务和用户需求的变化。精益流程还帮助最大限度地减少浪费，并最大化向最终用户交付的价值。更好的 DevOps 实践，鼓励持续集成、持续部署、持续交付和持续反馈，并配合更好的工具，正在帮助组织打破团队之间的孤岛。关键任务应用程序仍可能选择使用瀑布模型交付，而某些业务线应用程序则可能选择精益方法论获得更大的成功。这并没有绝对的对与错；选择最适合您交付场景的过程和工具。Visual Studio TFS 默认支持大多数流程，并且为您提供了定制和定义最适合您组织的流程的灵活性。

Visual Studio Team Foundation Server 2015，本书中以下简称为 TFS，是微软提供的本地部署的 ALM 工具。微软还提供了一个名为 Visual Studio Team Services (VSTS) 的云托管服务。不要将 VSTS 与 Visual Studio IDE 在云端混淆；它实际上是一个开发者服务集合，类似于 TFS，运行在微软 Azure 上，扩展了云端的开发体验。微软对其托管服务非常重视，并已将其迁移到 3 周一次的发布节奏。所有功能首先在 VSTS 中发布，然后通过季度更新将大部分功能引入 TFS。已发布功能及未来计划发布的功能时间表可以在www.visualstudio.com/en-us/news/release-archive-vso.aspx查看。产品团队通过用户反馈征集新功能请求。如果你有一个迫切的功能想法，务必在visualstudio.uservoice.com/forums/121579-visual-studio-2015提交你的请求。VSTS 目前提供许多企业级功能，如保证的正常运行时间、使用 ADFS 和 AAD 的单一登录，以及通过在这些地区托管租户来遵守美国、欧洲和澳大利亚的数据主权法律。尽管 VSTS 自豪地拥有超过 300 万活跃用户，但需要对环境和数据拥有更多控制权的组织仍然更喜欢 TFS 而非 VSTS。

注意

本书中的所有示例都适用于 TFS；然而，由于 VSTS 与 TFS 之间有很多重叠，书中大部分内容也适用于 VSTS。

可以用来连接 TFS 的各种客户端大致可分为两类——主要客户端和特定任务客户端，如下图所示。有关这些客户端可以执行的功能的完整列表，请参见msdn.microsoft.com/en-us/library/ms181304.aspx。

如果你正在为个人使用或评估核心功能（如版本控制、构建和工作项跟踪）设置 TFS，建议使用 TFS Express。它是免费的，设置简单，且可以安装在客户端和服务器操作系统上。Express 不支持与 SharePoint 或 Reporting Services 的集成。如果你为组织设置 TFS，请使用 TFS 的标准版本。你可以在单台计算机、双服务器配置或多服务器配置中设置 TFS。使用以下便捷参考检查 TFS 2015 的兼容性矩阵：

msdn.microsoft.com/Library/vs/alm/TFS/administer/requirements

TFS 架构设置及网络和端口要求可以在msdn.microsoft.com/en-us/library/ms252473(v=vs.120).aspx找到。产品设置文档可以在msdn.microsoft.com/en-us/Library/vs/alm/TFS/setup/overview找到。ALM Rangers 提供的规划和灾难恢复指南(vsarplanningguide.codeplex.com/)对于规划企业级 TFS 设置非常有帮助。TFS 2015 特定的许可证更新将在第一章，团队项目设置中的分配许可证、添加用户并审计用户访问配方中讲解。要了解更多关于 TFS 许可证要求的信息，请阅读www.microsoft.com/en-gb/download/details.aspx?id=13350上的 Visual Studio 和 MSDN 授权白皮书。

本书中的配方要求使用标准的单机 TFS 设置。你可以使用前述安装说明设置一个独立的单服务器，或者选择使用预配置的 TFS 2015 虚拟机。下载并设置该虚拟机的说明可以在vsalmvm.azurewebsites.net/找到。

本书内容

第一章，团队项目设置，介绍了团队项目，这是一个逻辑容器，将与软件应用程序相关的所有工具和工件隔离并组合在一个命名空间中。欢迎页面、仪表板、团队房间等功能，能够更好地促进团队内的协作，而重命名团队项目和脚本化团队项目创建的功能，则使你能够更好地管理团队项目。在本章中，我们将学习团队项目的不同功能，并了解如何设置这些功能，以充分利用它们的潜力。

第二章，设置和管理代码库，介绍了 TFS，它是唯一提供集中式和分布式版本控制系统的产品。在本章中，我们将学习如何在一个项目中设置 TFVC 和 Git 代码库，以及如何通过在开发工作流中执行代码审查和代码分析来解决技术债务。

第三章，规划和跟踪工作，解释了那些已实现但从未使用的需求，或者那些使用过短暂时间后发现无法满足用户需求的需求，这会导致浪费、返工和不满。在这一章中，我们将学习如何设置和定制多个待办事项、看板和冲刺任务板。我们还将学习如何使用服务钩子与外部规划工具集成，并通过利用 TFS 中的反馈功能改进反馈循环。

第四章，构建你的应用程序，介绍了新的构建系统（TFBuild），它是一个跨平台、开放且可扩展的基于任务的执行系统，具有丰富的 Web 界面，允许构建的创建、排队和监控。在这一章中，我们将学习如何设置和使用 TFBuild 进行持续集成。我们还将学习如何将 TFBuild 与 SonarQube 和 GitHub 集成。我们还将回顾帮助为软件的持续交付奠定基础的功能。

第五章，测试你的应用程序，指出低质量的软件是不可接受的。但你可能会问：“什么是合适的质量水平？”在这一章中，我们将学习如何使用 TFS 中可用的测试工具进行规划、跟踪和自动化。我们还将学习如何利用新的构建系统将非微软测试框架（如 Selenium 和 NUnit）集成到自动化测试工作流中。

第六章，发布你的应用程序，解释了 TFS 中基于 Web 的新发布管理器，该管理器使用与 TFBuild 提供的相同代理和任务基础设施。在这一章中，我们将学习如何使用发布管道设置、安全性设置并部署到多个环境。我们还将学习如何跟踪和报告通过发布管道交付的发布版本。本章中的技巧使您能够为持续交付设置软件。

第七章，管理 Team Foundation Server，教你如何更新、维护和优化 TFS，从而实现地理分布团队的高可用性，并减少管理开销。

第八章，扩展和自定义 Team Foundation Server，解释了组织通常会有不同的工具来管理生命周期的不同部分，例如，使用 Jira 进行敏捷项目管理，使用 TeamCity 进行构建，使用 Jenkins 进行发布管理，使用 ServiceNow 进行服务管理。本章将介绍 TFS 对象模型和 TFS REST API，帮助你通过编程访问和集成系统。本章还将讲解如何通过利用过程模板定制来定制团队项目。

本书所需内容

本书中的食谱基于 Team Foundation Server 2015。所有食谱都已经在 TFS 2015 Update 1 环境中进行过测试。为了实践这些食谱，你需要一个安装了 Visual Studio 2015 的 Team Foundation Server 2015 工作环境。

本书的目标读者

本书适合所有软件专业人士，包括开发人员、测试人员、架构师、经理以及正在使用或计划使用 TFS 的配置分析师。

本书涵盖了 Team Foundation Server 2015 的功能，包括团队项目、源代码控制、工作项、构建、测试、发布、管理、扩展性和自定义，重点讨论 DevOps 和 ALM 相关的主题。

本书提供了针对 Scrum 团队的实用食谱，帮助他们利用 TFS 的新功能和现有功能，实现更快、更高质量的软件持续交付。本书不仅涵盖理论概念，每个食谱采用食谱格式，呈现问题、解决方案和解释，将你直接带入现实世界的实践场景。

本书假设你已具备 Team Foundation Server 2015 的工作环境，并对 TFS、软件开发生命周期和 Scrum 框架有基本了解。

章节

本书中，你将发现多个经常出现的标题（准备工作、操作方法、工作原理、更多内容、另见）。

为了清楚地指导你如何完成一个食谱，我们使用以下几种结构：

准备工作

本节将告诉你如何理解本食谱的内容，并描述为该食谱设置所需的软件或其他初步设置。

如何操作…

本节包含完成食谱所需的步骤。

它是如何工作的…

本节通常包括对上一节发生内容的详细解释。

还有更多…

本节提供关于食谱的额外信息，旨在让读者更深入了解该食谱。

另见

本节提供了有用的链接，指向与本食谱相关的其他有用信息。

约定

在本书中，你将看到多种文本样式，用于区分不同类型的信息。以下是这些样式的一些示例及其含义的解释。

文本中的代码词、数据库表名、文件夹名称、文件名、文件扩展名、路径名、虚拟网址、用户输入和 Twitter 用户名如下所示：“tfsdeleteproject命令分两阶段执行删除。”

代码块如下所示：

# User-specific files
*.suo
*.user
*.sln.docstates
# Specific files 
*.txt
# Build results
[Dd]ebug/
[Rr]elease/

所有命令行输入或输出将如下所示：

refs/heads/master, TF402455: Pushes to this branch are not permitted; you must use pull requests to commit changes.

新术语和重要词汇以粗体显示。您在屏幕上看到的词汇，例如在菜单或对话框中，出现在文本中如下所示：“从项目和我的团队子菜单中，点击新建团队项目...”。

注意

警告或重要提示会以类似这样的框显示。

提示

小贴士和技巧会像这样显示。

读者反馈

我们始终欢迎读者反馈。请告诉我们您对这本书的看法——您喜欢或不喜欢的地方。读者反馈对我们来说非常重要，因为它帮助我们开发出能真正满足您需求的书籍。

如需向我们发送一般反馈，请通过电子邮件发送至<feedback@packtpub.com>，并在邮件主题中注明书名。

如果您在某个领域拥有专业知识，并且有兴趣撰写或参与编写书籍，请查看我们的作者指南：www.packtpub.com/authors。

客户支持

现在，作为一本 Packt 书籍的自豪拥有者，我们提供一些帮助，帮助您充分利用您的购买。

下载示例代码

您可以从您的帐户中下载所有 Packt 出版的书籍的示例代码文件，网址是www.packtpub.com。如果您是从其他地方购买的本书，您可以访问www.packtpub.com/support，并注册以直接通过电子邮件获得文件。

勘误

尽管我们已尽力确保内容的准确性，但错误仍然会发生。如果您在我们的书籍中发现错误——可能是文本或代码中的错误——我们将非常感激您能报告给我们。这样，您可以帮助其他读者避免困扰，并帮助我们改进后续版本。如果您发现勘误，请访问www.packtpub.com/submit-errata提交，选择您的书籍，点击勘误提交表单链接，并输入勘误的详细信息。一旦您的勘误得到验证，我们将接受您的提交，并将勘误上传至我们的网站，或添加到该书名的勘误列表中。

要查看之前提交的勘误，请访问www.packtpub.com/books/content/support，并在搜索框中输入书名。所需的信息将显示在勘误部分。

盗版

互联网版权侵犯问题是所有媒体面临的持续性问题。在 Packt，我们非常重视版权和许可证的保护。如果您在互联网上发现我们作品的任何非法复制品，请立即提供其位置地址或网站名称，以便我们采取补救措施。

请通过<copyright@packtpub.com>联系我们，并提供涉嫌侵权内容的链接。

我们感谢您的帮助，保护我们的作者和我们为您带来有价值内容的能力。

问题

如果您在本书的任何方面遇到问题，可以通过<questions@packtpub.com>与我们联系，我们将尽力解决问题。

第一章：Team Project 设置

	"你应该关注的不是建筑的美丽，而是能够经得起时间考验的基础建设。"
	--David Allan Coe

本章将涵盖：

使用 Team Explorer 连接到 TFS
在 TFS 中设置用户配置文件
使用 Scrum 模板创建 Team Project
分配许可证、添加用户并审计用户访问
配置 Team Project 中的仪表板
为 Team Project 设置欢迎页面
创建并设置 Team Room
重命名 Team Project
通过命令行创建新的 Team Project
删除 Team Project

介绍

Microsoft Visual Studio Team Foundation Server 提供了一套集成工具，帮助团队有效管理其软件项目的生命周期。Team Foundation Server 中的 Team 被封装在 Team Project 的容器内。简而言之，Team Project 是一个逻辑容器，将与软件应用程序相关的所有工具和工件隔离在一个单一的命名空间中。

通过 Team Project 引入的概念边界消除了访问与应用程序开发无关的工件（如代码、工作项或发布信息）的问题。相关的 Team Projects 可以被分组到一个 Team Project Collection 中。它可以通过将这些相关的 Team Projects 托管在不同的数据库中，来实现物理上的分离。

Team Foundation Server 支持多个 Team Project Collections，每个集合可以内部托管多个 Team Projects。资源如构建池在 Team Project Collection 级别进行作用域设置。一个 Team Project 可以托管多个 Team；某些资源在 Team Project 级别设置，其他则在 Team 级别设置。如以下截图所示，源代码管理库（TFVC 或 Git）的选择是在 Team Project 级别进行的；然而，团队在选择待办事项清单和看板上的工作流程时具有自主权。所选的交付框架通过 Process Template 应用；它进一步应用特定交付框架的术语、工件和工作流程到 Team Project 以及其中的所有 Teams：

TFS 报告仓库是一个传统的数据仓库，由一个按近似星型架构组织的关系型数据库和构建在关系型数据库上的 SQL Server Analysis Services 数据立方体组成。所有的 Team Projects，不论它们属于哪个 Team Project Collection，都被汇总到一个单一的数据仓库中。

Team Foundation Server 提供了一个层次化的安全模型。权限可以通过 TFS 组或 AD 组成员身份在每个层级上进行设置，从服务器到对象层级。组可以嵌套，并设置为通过层次结构继承权限。权限继承可以设置为拒绝，以控制对选定资源的访问。有关预创建组的详细信息，包括访问权限和权限细节，可以在bit.ly/1PPaU6l找到。

权限可以用于限制对 Team 项目内部或项目之间资源的访问，Team 项目集合则提供了完全的隔离。Team 项目集合还提供了其他功能和技术上的优势，例如：

在多个部门之间使用单一的 TFS 实例，同时仍能提供一定程度的隔离。集合也可以用来反映组织结构。
备份和恢复的灵活性。这可以减少停机时间，因为恢复一个集合不会影响其他集合的用户。
通过将集合移动到单独的 SQL Server 实例上实现可扩展性和负载均衡。

在本章中，我们将讨论管理和过程模板的内容；这些主题将在后续章节中详细讨论。本章的重点是创建和设置 Team 项目的各个元素。

使用 Team Explorer 连接到 TFS

要构建、测试、跟踪或发布你的软件，你需要将你选择的客户端连接到 Team Foundation Server。作为软件开发人员，你将花费大量时间在 Visual Studio IDE 中。无论是将代码存储在 TFS Git 仓库中还是使用 TFVC 源代码管理，你都需要将 IDE 连接到 TFS 来与代码交互。在本节中，你将学习如何使用 Team Explorer 连接到 TFS。

准备工作

如果你已经安装了任何 Visual Studio 2015 版本，你已经拥有 Team Explorer。对于 TFS 2015，不再提供单独安装 Team Explorer 的选项；你至少需要安装 Visual Studio Community 来获得 Team Explorer。

注意

要通过任何 Office 产品连接到 TFS，你可以安装 TFS Office 集成安装程序：bit.ly/1k3wh7p。你可以在bit.ly/1Grh3DS了解更多关于 TFS Office 集成安装程序的好处。

当你第一次启动 Visual Studio 时，你将被要求使用 Microsoft 账户登录，如 Live、Hotmail 或 Outlook，并提供一些基本的注册信息。选择一个最能代表你的 Microsoft 账户。如果你已有 MSDN 账户，建议使用其关联的 Microsoft 账户登录。如果你没有 Microsoft 账户，可以免费创建一个。登录有多种好处，如在多台机器之间同步 Visual Studio 设置。虽然建议登录，但并非强制要求。

如何操作...

打开 Visual Studio 2015。
点击团队工具栏，选择管理连接...：
在 Team Explorer 中，点击管理连接超链接，选择连接到团队项目：
在连接到 Team Foundation Server窗口中，下拉菜单显示你以前连接过的所有 TFS 服务器。如果在下拉菜单中看不到你想连接的服务器，点击服务器...输入 Team Foundation Server 的详细信息。点击添加...并输入你的 TFS 服务器的详细信息。你可能需要输入登录凭据以便与服务器进行身份验证。
经身份验证的用户详情和服务器详情将在连接到 Team Foundation Server窗口中更新。点击连接按钮完成操作。
现在，你应该已成功通过 Team Explorer 连接到 TFS：

工作原理...

现在 Visual Studio 附带 GitHub 连接器。现在，Team Explorer 中的管理连接对话框不仅允许你连接到 TFS 和 VSO，还可以连接到 GitHub。这是 Microsoft 通过为非 Microsoft 产品提供无缝集成，展示其拥抱开源的一个很好的例子。

注意

如果你是 GitHub 免费账户用户，你将只能在 Visual Studio 中绑定一个账户，这是 GitHub 限制的。GitHub 企业用户可以从 Team Explorer 2015 中映射多个账户。

如果你在是否使用 Microsoft 账户登录 Visual Studio 上有些犹豫，权衡以下好处：

同步你的 Visual Studio 设置：当你在任何其他设备上登录 Visual Studio 时，Visual Studio 的设置（如快捷键绑定和颜色主题）会立即应用。
延长试用期：如果你没有 Visual Studio 许可证，通过登录，你可以将 Visual Studio Professional 或 Enterprise 的试用期从 30 天延长至 120 天。
解锁 Visual Studio：如果你的 Microsoft 账户与 MSDN 账户相关联，你的 Visual Studio 副本将自动解锁。

如果你不想同步设置，可以禁用此功能。在工具菜单中，选择选项。在环境下查找同步设置，然后取消选中以下截图所示的选项：

在 TFS 中设置你的用户资料

Team Foundation Server 允许你通过选择自己的设置来自定义体验。每个 TFS 用户都通过登录拥有一个个人资料。在本教程中，你将学习如何在 TFS 中自定义你的个人资料。

如何操作...

打开 Team Portal，导航至 http://tfs2015:8080/tfs/。
右上角包含登录用户的名称。点击该名称可以打开用户个人资料控制，如下图所示：
点击我的个人资料以查看和自定义您的个人资料。我们先浏览一下常规设置。
要更改个人资料图片，点击更改图片超链接，选择一个小于 4MB 的图片，然后点击保存更改。
要更改显示名称，点击编辑超链接，将名称从Tarun更改为Tarun Arora，然后按回车。
要更改首选电子邮件，点击编辑超链接，将电子邮件地址更改为tarun.arora@outlook.com，然后按回车。
UI 设置字段可以通过从下拉菜单中选择高对比度主题来从默认设置更改为高对比度：
点击地区设置标签，切换到地区设置页面。从这里可以更改语言和时区设置。

它是如何工作的…

用户个人资料设置仅适用于个人；这些设置不会影响其他用户。您的个人资料现在应包含图片、显示名称、首选电子邮件地址以及您选择的主题。您为工作项、构建和代码审查配置的任何提醒将发送到您的首选电子邮件地址。

TFS 中的时区设置将覆盖机器的时区设置。例如，如果您的机器在 UTC + 1 时区，但您的个人资料配置为 UTC + 5:30，创建一个新的工作项时，工作项中的创建时间将是 UTC + 5:30，而不是 UTC + 1。

注意

在团队基础服务器中，有些功能受托管团队基础服务器时区设置的影响。例如，如果您的团队基础服务器托管在美国华盛顿，而您的分布式团队部分位于印度德里，则当前冲刺将根据华盛顿时间的当天结束来结束。

当个人资料在团队项目范围内打开时，您将在个人资料菜单中看到我的提醒选项。提醒功能允许您在团队项目内发生某些事件时配置电子邮件通知。例如，构建完成、工作项分配等。

点击我的提醒将启动管理您的 TFS 提醒的窗口。在此窗口中，您可以管理基本提醒和自定义提醒。提醒可以通过条件进行自定义。该窗口还包含一个链接，指向高级提醒管理页面，可以用来管理团队提醒。

使用 Scrum 模板创建团队项目

在 TFS 中，团队项目是一个逻辑容器，用于存储工作项、代码、构建和发布等工件。不同的团队遵循不同的流程来组织、管理和跟踪工作。TFS 通过过程模板允许指定流程。系统默认提供了 Scrum、Agile 和 CMMI 模板。过程模板定义了可以用于规划和跟踪项目的工作项类型、查询和报告集合。在本教程中，您将学习如何使用 Scrum 模板创建新的团队项目。

准备工作

无法通过团队门户创建团队项目；在本教程中，我们将使用 Team Explorer 来创建一个新的团队项目。如果您还没有连接 Team Explorer 到 TFS，请参考 使用 Team Explorer 连接到 TFS 教程，了解如何进行连接。

要创建新的团队项目，您需要以下权限：

创建新项目权限：通过成为 项目集合管理员 组的成员，您继承此权限。Team Foundation 管理员全局组 也包括此权限。
创建新团队站点权限：此权限通过将用户添加到具有 SharePoint 站点集合完全控制权限的 SharePoint 组中来授予。如果您决定不在团队项目创建过程中创建 SharePoint 站点，则不需要此权限。

为了使用 SQL Server 报告服务，您必须是报告服务中 Team Foundation 内容管理角色的成员。

注意

要验证是否拥有正确的权限，您可以从 CodePlex 下载 Team Foundation Server 管理工具，网址为 tfsadmin.codeplex.com/。TFS Admin 是一个开源工具，采用 Microsoft 公共许可证（Ms-PL）发布。

如何操作...

打开 Visual Studio 2015，并将 Team Explorer 连接到 TFS：
在 项目和我的团队 子菜单中，点击 新建团队项目...。这将弹出新团队项目创建向导：
输入团队项目名称和描述，然后点击 下一步 按钮：
选择 Scrum 过程模板并点击 下一步。这是您在团队项目创建过程中可能做出的最重要的决定之一。了解有关不同过程模板的更多信息，访问 msdn.microsoft.com/library/vs/alm/work/guidance/choose-process。
选择 创建一个新的 SharePoint 站点 选项。点击 配置... 来指定新站点的位置。如果没有 SharePoint 集成，选择不配置 SharePoint 站点的选项。
这个源代码管理选择界面呈现了在团队项目创建过程中，你将被要求做出的第二个最重要的决策。TFS 支持集中式（TFVC）和分布式（Git）源代码控制系统。在第二章，设置与管理代码仓库中，我们将深入讨论这两种源代码控制类型。选择 Team Foundation Version Control 并点击 下一步：
在你查看设置后，点击完成以开始团队项目创建过程：
一旦团队项目创建完成，你将在表单上看到完成状态。点击 查看团队项目创建日志 超链接（我们将在 它是如何工作的… 部分讨论日志内容）。
Team Explorer 现在已更新为新创建的团队项目的详细信息：

它是如何工作的...

过程模板定义了一组将用于规划和跟踪项目的工作项类型和报告。过程模板还应用了工作项工作流和状态转换。让我们来看看现成模板之间的主要区别：

Scrum 模板旨在支持 Scrum 组织定义的 Scrum 框架。此过程模板在与产品待办事项项目相同的级别上跟踪缺陷，并使用努力字段来跟踪估算。
Agile 模板旨在支持不希望被 Scrum 限制的团队的敏捷开发。它通过使用故事点来估算用户故事。任务包含用于跟踪原始估算、剩余工作和已完成工作的字段。虽然最初 Agile 模板不允许在任何待办事项页面上进行缺陷跟踪，但现在可以通过团队门户中的团队设置进行配置。
CMMI 模板旨在支持正式的变更管理过程。此模板通过 Size 字段支持估算的需求。任务包含用于跟踪原始估算、剩余工作和已完成工作的字段。

现成的模板旨在满足大多数团队的需求。它们都支持使用敏捷规划工具创建产品待办事项，并在任务板上以冲刺的方式进行工作。如果你的团队有不同的需求，你可以自定义一个模板并创建团队项目，或者你可以从模板创建一个团队项目，然后对项目进行自定义。

你可以通过进入设置视图中的团队资源管理器的过程模板管理器来下载过程模板。有关如何下载过程模板的更多说明，请参阅msdn.microsoft.com/Library/vs/alm/Work/guidance/manage-process-templates。

打开 ProcessTemplate.xml 文件（位于之前下载的路径）；您会注意到它遵循一种 XML 结构，构建了一系列插件和设置插件的指令。主模板与由其他 XML 结构定义的子模块相关联。在以下表示中，您将看到这些 XML 模板与项目创建工作流生成的仪表之间的关联。有关流程模板自定义的详细信息，请参阅第八章，扩展和自定义 Team Foundation Server。

在团队项目创建过程中，以下项目会为您创建：

代码仓库：根据您的选择，已配置一个代码仓库。
团队：为团队项目创建一个与项目同名的默认团队。
区域路径：为团队创建一个与团队同名的默认区域路径。团队的待办事项列表配置为显示分配给此区域路径的工作项。
迭代路径：为团队预先创建了一组迭代。
团队门户：团队门户允许团队成员连接到 TFS 以管理源代码、工作项、构建和测试工作。
团队房间：为团队创建一个与团队同名的房间。团队房间用于协作。

如果您的 Team Foundation Server 配置为支持 SharePoint 项目门户和报告，您将在 Team Explorer 中看到 文档和报告 中心。文档视图提供与 SharePoint 项目门户的深度集成。这允许您创建文档库并与团队成员组织和共享文档。报告视图为您提供了一组预先创建的 SSRS 报告，您可以使用它们来跟踪和管理团队工作进展：

分配许可证、添加用户以及审计用户访问

Scrum 团队由产品负责人、开发团队和 Scrum Master 组成。虽然您的利益相关者不是 Scrum 团队的一部分，但他们需要看到产品待办事项列表。Scrum 团队是跨职能的，具备覆盖设计、开发、测试和增量部署的技能。从工具的角度来看，团队中的每个成员可能不需要相同的 TFS 访问权限。

TFS 提供三种访问级别：利益相关者、基本和高级。所需的 TFS 许可证在此列出：

访问级别	所需许可证
利益相关者	不需要许可证。
基本	TFS 客户端访问许可证（CAL）或带有 MSDN 订阅的 Visual Studio Professional。
高级	以下 MSDN 订阅之一：带 MSDN 的 Visual Studio Enterprise、MSDN Platforms，或带 MSDN 的 Visual Studio Test Professional。

在过去的一年里，产品授权已经显著简化。TFS 2015 和现在的 TFS 2015 更新 1 引入了一些关键的授权变更：

TFS CAL 许可证已被更改，以包含更多 TFS 功能的访问权限：
- 敏捷规划：TFS 2015 Web 访问中的所有待办事项管理和冲刺规划功能现在对任何拥有 TFS CAL 的用户开放。
- 图表创作：图表创作功能及将图表固定/分享至项目主页的功能现在可以通过 CAL 使用。
- 团队房间：团队房间现在在 TFS 2015 中通过 CAL 可用。
- 测试中心：在 TFS 2015 中，基于 Web 的测试体验（用于用户验收测试，如场景测试）现在在 TFS CAL 中可用。

购买 Visual Studio Team Services、Professional 或 Advanced 许可证时，您将获得一个免费的 TFS CAL 许可证，适用于该命名用户。这带来了几个优势：

现在，您可以“租赁” TFS CAL。您无需一次性支付 499 美元（列价）的许可证费用，而是可以按月支付较低的费用，按需使用。
使用供应商/承包商的公司现在有了一种简单的方式来管理需要临时访问其 TFS 的人员。
CAL 是“始终保持最新”。因为它是订阅制，而非一次性购买，所以当新的 TFS 版本发布时，您无需处理购买/续订 CAL 的问题。与 VS Online 许可证捆绑的 CAL 可与任何 TFS 版本兼容，而传统购买的 CAL 仅支持特定 TFS 版本及其早期版本。

访问级别和角色是 TFS 中两个独立的概念。访问级别决定了您有权使用哪些功能，而角色决定了权限。例如，基本许可证的访问级别包括源代码管理权限；但是，如果您是只读角色，您将无法编辑源代码。

团队基础服务器的访问级别与软件项目中的典型角色及其所执行的活动密切相关。以下表格总结了特性与访问级别的映射关系。因此，项目支持人员只需一个利益相关者许可证，项目经理或开发人员需要一个基本许可证，测试人员或项目组合经理则需要一个高级许可证。

特性	利益相关者	基本	高级
查看和编辑所有工作项	是	是	是
标准功能	是	是	是
敏捷看板	是	是	是
基本的待办事项和冲刺规划工具	是	是	是
图表查看	是	是	是
图表创作		是	是
代码		是	是
构建		是	是
请求和管理反馈			是
基于 Web 的测试执行		是	是
基于 Web 的测试用例管理			是
团队房间		是	是
管理账户		是	是
高级主页		是	是
高级待办事项和冲刺规划工具		是	是
高级投资组合管理		是	是
分析测试结果并管理机器组		是	是

拥有利益相关者访问权限的用户可以创建和修改所有工作项，并在我的查询文件夹下创建并保存所有工作项的查询。（与有限访问权限不同，有限访问权限下用户只能创建和修改自己创建的工作项，并查询和查看自己创建的工作项。）此外，利益相关者还可以使用团队基础客户端（如 Microsoft Excel、Microsoft Project 和 Microsoft Feedback Client）创建和修改工作项。

标准功能包括访问首页和工作中心。
可以查看待办事项页面和看板，并通过快速添加面板（显示在列表底部）添加工作项，但不能在页面上移动项或使用其他功能。
可以查看冲刺页面和任务板，并添加工作项，但不能使用其他冲刺计划工具功能。

要在 TFS 中设置新用户，用户首先需要分配一个许可证，然后添加到一个团队中。在本篇教程中，你将学习如何分配许可证并添加成员到团队，同时还将学习如何审核 TFS 中的用户访问权限。

准备工作

在本篇教程中，我们将分配许可证和权限给 FabrikamTFVC 团队项目中的以下用户。

姓名（用户名）	访问级别	评论
John Smith`TFS2015\JohnS`	利益相关者	John 通常通过反馈客户端提供反馈，并在产品待办事项中创建工作项。
Brian Miller`TFS2015\BrianM`	基础	Brian 是一名开发人员，他大部分时间都在进行编程和单元测试。
Aaron Cook`TFS2015\AaronC`	基础	Aaron 是一名开发人员，他大部分时间都在进行编程和单元测试。
Willy Peter`TFS2015\WillyP`	基础	Willy 是团队中的敏捷教练和开发人员，主要负责集成和 SQL Server 报告开发。
Annu Arora`TFS2015\AnnuA`	高级	Annu 是一名测试人员，她大部分时间都在进行功能测试和性能测试。
Tom Hacker`TFS2015\TomH`	高级	Tom 是一名业务分析师，他大部分时间都在进行编程和集成测试。
Chris Wang`TFS2015\ChrisW`	高级	Chris 是产品负责人，负责管理产品愿景和投资组合。

若要将新用户添加到访问级别，你需要是集合管理员。要将新用户添加到团队项目中，你需要是项目管理员；如果你还不是管理员，请安排加入这些组。

如何操作...

分配用户许可证：

登录到团队门户并通过访问 http://tfs2015:8080/tfs/_admin/_licenses 浏览到访问级别管理界面：
从左侧面板中，点击Stakeholder访问。在右侧面板中，点击添加按钮，并选择添加 Windows 用户或组。在添加新用户或组窗口中，输入用户详细信息为TFS2015\JohnS，然后点击确定按钮：

重复此步骤，将所有用户添加到获取准备部分中指定的访问级别的用户表中。此时，你应该已经有一个 Stakeholder、三个 Basic 和三个 Advanced 用户。

向项目中添加用户：

有两种方法可以将用户添加到团队项目。第一种方法是通过浏览http://tfs2015:8080/tfs/DefaultCollection/FabrikamTFVC/_admin/_security，导航到 FabrikamTFVC 项目的安全屏幕。在左侧面板中，点击贡献者组，在右侧面板中，点击成员标签，并点击添加...按钮以添加 Windows 用户或组。输入用户详细信息并点击确定：
另一种方式是通过浏览http://tfs2015:8080/tfs/DefaultCollection/FabrikamTFVC，导航到 FabrikamTFVC 项目主页。在成员小部件中，点击管理...，在管理 FABRIKAMTFVC 团队成员窗口中，输入用户详细信息并点击确定。重复这些步骤，以添加“入门”部分用户表中列出的其他用户。

注意

在 TFS 中管理用户要简单得多，如果你为他们创建 Windows 或 Active Directory 组。如果你决定在 TFS 中使用 Active Directory 组，建议创建专门用于 TFS 用户管理的组。

审核用户访问

在接下来的几步中，您将学习如何提取审核日志，跟踪用户和组的最后登录时间及其访问类型：

通过浏览http://tfs2015:8080/tfs/_admin/_licenses，进入团队 Web 访问中的访问级别屏幕。
从左侧导航中，点击导出审核日志。打开下载的 CSV 文件；我们将在如何工作...部分中深入探讨。

如何工作...

默认的访问级别分配给通过团队项目安全或成员屏幕直接添加的用户。建议将默认访问级别设置为基础。如果用户被分配到多个访问级别，最高级别始终优先。

接下来，让我们查看审核日志，将data.csv导入到 Excel 中。你应该能看到类似于以下截图的视图。最后访问时间（UTC）列告诉你用户是否访问过 TFS；对于没有访问过 TFS 的用户，你无需为其支付许可费用。

在团队项目中配置仪表板

团队门户主页传统上用于固定图表、工作项计数和构建状态小部件，以便团队成员和利益相关者可以一目了然地查看项目。由于主页具有硬编码的小部件，您被强制在页面上使用它们，因此这种方式效果不佳。此外，页面不支持小部件的分组或添加注释来补充小部件中的可视内容。在 TFS 2015 Update 1 中，主页被一个新功能仪表板取代。这个新功能提供了一个小部件库，可以用来为你的团队创建多个仪表板。在本教程中，您将学习如何使用小部件目录创建仪表板。

准备开始

要获得权限，你需要成为团队管理员才能创建仪表板。只有团队管理员才能创建、定制和移动仪表板上的小部件。查看仪表板不需要任何特殊权限。所有有权限访问团队门户的团队成员都可以查看和与仪表板进行交互。

团队门户主页已经被概览仪表板所取代。主页上的所有现有小部件都已迁移到概览仪表板中。要查看概览仪表板，请通过浏览http://tfs2015:8080/tfs/DefaultCollection/FabrikamTFVC/_dashboards进入 FabrikamTFVC 团队门户。

如何操作…

在 FabrikamTFVC 团队门户中，点击+图标以创建新的仪表板。为仪表板命名为团队更新：
从页面的右下角，点击大绿色圆圈以启动仪表板小部件库。从小部件库中，添加代码小部件：
小部件添加到仪表板后，点击该小部件进行配置。将名称设置为所有代码更改，并将代码路径设置为$/FabrikamTFVC。该小部件将显示过去 7 天内源路径$/FabrikamTFVC下的代码更改计数。点击保存以提交配置更改：
接下来，从小部件库中添加查询小部件。选择已阻止的任务查询，将查询结果映射到小部件中进行显示。如果计数大于或等于 1，请将背景颜色配置为红色：

根据工作项查询返回的工作项计数，格式化小部件的背景颜色
添加Markdown小部件。该小部件能够渲染 Markdown；小部件的大小可以调整为不同的尺寸。选择3 x 2大小，并添加如以下截图所示的注释：
画廊中有其他小组件，如工作项查询结果、新建工作项、团队聊天室、Sprint 容量、燃尽图等链接；这些也可以添加到仪表板中。目前没有用于图表的小组件。可以通过工作中心的图表视图添加图表，关于这一点将在第三章的 使用工作项查询创建图表 章节中详细讲解。

它是如何工作的…

仪表板提供了一种很好的方式来创建信息辐射器，向团队成员和外部利益相关者共享信息。小组件在仪表板中呈现为瓦片，这些瓦片使用 TFS REST API 从 TFS 中检索信息。信息通过小组件提供的模板加载到瓦片中。瓦片可以在仪表板上移动，并调整大小。瓦片支持交互性，例如点击查询瓦片将直接进入 工作项查询 窗口。目前，瓦片之间尚不支持跨瓦片交互。虽然可以创建多个仪表板，但目前无法为单个仪表板应用访问权限。预计在长期内，更多的小组件将被添加到小组件库中，API 将开放，以扩展和创建新的小组件。

设置团队项目的欢迎页面

仅通过团队项目的名称或描述很难总结出其目标。软件团队通常会创建介绍文档或 README 文件来总结项目的目的，并提供其他有用的参考材料。传统上，团队会将这些文件存储在 SharePoint 中。当这些信息与团队项目的上下文结合起来时，它会更加有用。一种名为 项目欢迎 页面的新特性为此提供了完美的解决方案。在这个示例中，你将学习如何使用 markdown 文件设置欢迎页面。

准备工作

项目欢迎页面是通过一种非常简单的基于约定的方法创建的。欢迎页面仅渲染已检查入项目源代码管理的 markdown 文件。

注意

对于基于 TFVC 的源代码管理，readme.md 文件需要位于团队项目文件夹的根目录下。对于基于 Git 的源代码管理，readme.md 文件需要位于默认分支的仓库根目录下。

团队项目欢迎页面要求底层文件以 markdown 格式编写。Markdown 旨在便于阅读和编写，主要强调可读性。TFS 在团队门户中提供了一个 markdown 编辑器，帮助你编写欢迎页面。你也可以选择使用桌面编辑器编写 markdown 文件。

如何操作…

打开团队网页访问并导航到 FabrikamTFVC 团队项目 http://tfs2015:8080/tfs/DefaultCollection/Recipes。
在首页中心，选择欢迎视图并点击编辑以开始编辑readme.md文件。

将 Markdown 片段复制到编辑器中：

# Welcome to the FabrikamTFVC
----------
The team project contains the resources for the Fabrikam Software & Services. 

## Contacts
---
* Project Owner - Tarun Arora [@arora_tarun](https://twitter.com/arora_tarun)

## Definition of Done
 All product backlog items need to abide to the definition of done before they can be marked done 
 1\. All source code is checked in
 2\. All code passes CI & no failing unit tests 
 3\. Business services code coverage of > 60%
 4\. All changes have been tested
 5\. Deployment script added & updated
 6\. Demo to Product Owner
 7\. All associated tasks must be completed 
## Definition of Bug
*Work in progress*

在最右侧的工具栏中，你会看到显示内容预览图标。点击预览图标，欢迎页面将会以 Markdown 形式呈现：
点击保存图标，将readme.md文件提交到版本控制系统。

工作原理…

TFS 支持常见的 Markdown 规范和 GitHub 风格的扩展。

提示

你可以在bit.ly/1jJjRlI了解更多关于 Markdown 语法的内容。

你可以在bit.ly/1jJl38D了解更多关于GitHub-Flavored-Markdown的信息。

为简化 Markdown 内容的创建和编辑，Team Foundation Server 允许你通过绝对路径和相对路径链接到其他 Markdown 文件。当 Markdown 渲染为 HTML 时，所有标题都会自动生成 ID，因此你可以使用以下约定通过标题 ID 链接到标题：显示文本。

TFS 还允许你引用一个尚不存在的 Markdown 页面；引擎足够智能，当你点击引用的链接时，会给你一个创建该页面的选项。你可以使用以下 Markdown 格式来实现：new page。

创建和设置 Team Room

协作是任何项目交付成功的关键。虽然有很多方式可以与团队成员协作，但要将这些对话追溯到工作内容的上下文中是非常困难的。TFS 提供了一个名为 Team Room 的协作中心，使得追踪工作、项目更新和团队协作变得容易。在本教程中，你将学习如何创建、设置和使用 Team Room。

准备就绪

所需权限：项目管理员组可以创建并管理他们所创建的 Team Rooms。团队管理员只能管理他们所管理的 Team 的 Team Rooms。

访问 Team Rooms 需要许可证：只有 Basic 和 Advanced 许可证的用户可以访问 Team Rooms。Stakeholders 无法访问 Team Rooms，需要升级为 Basic 许可证才能参与 Team Rooms。

注意

Team 和 Team Room 是在创建 Team 项目的过程中一起创建的。Team Room 的名称与 Team 的名称相同。

如何操作…

通过浏览http://tfs2015:8080/tfs/_home访问 Team Web Access 主页。
在顶部面板中，点击Rooms标签，这将带你进入 Team Room 的中心。在此页面中，你将看到所有可用的 Team Rooms 列表。Team Room 是随着 Team 项目的创建而创建的：
点击新建按钮以创建一个新的 Team Room。输入名称为FabrikamShipRoom，点击确定以进入FabrikamShipRoom：
单击管理事件...链接以选择在FabrikamShipRoom中可见的哪些 TFS 事件：
从代码更改选项卡中，添加一个团队项目。团队房间不是团队项目特定的，因此您可以选择多个团队项目。您还可以选择是否要所有更改或仅要特定于团队房间成员的更改。在这种情况下，请选择FabrikamTFVC，选择按房间成员，然后单击保存并关闭。
重复执行这些步骤以启用工作项、构建、代码审查和拉取请求的事件。

注意

通过取消选中FabrikamTFVC旁边的复选框，您可以停止在团队房间中接收此团队项目的警报。
单击管理用户...链接并选择添加 TFS 组以选择FabrikamTFVC。这将向FabrikamShipRoom添加所有 FabrikamTFVC 团队成员。要提交您的更改，请单击保存：
在发帖消息文本框中，复制以下文本：Welcome @Aaron Cook @Annu Arora @Brian Miller @Chris Wang @John Smith @Tom Hacker @Willy Peter to the #FabrikamShipRoom :)：

它是如何工作的...

通过讨论进行中的工作、提出问题、共享状态和澄清出现的问题来提高团队生产力。您的团队房间为团队成员在近距离和远距离之间进行沟通和记录提供了一个空间。团队房间不限于团队项目集，因此您可以在团队房间中跟踪多个项目。团队房间允许您按日期查看对话，要查看历史对话，请单击团队房间顶部栏中的左箭头。您还可以从日历中选择日期。

管理事件使您可以访问以下各种事件：

构建事件：当任何以下构建定义完成时，在房间中将出现一个事件，指示构建的状态。
代码更改：当代码被推送或检入以下任一团队项目时，在房间中将出现一个事件。您可以选择将此范围仅限于团队房间成员或任何人。
工作项更新：当在以下任一区域路径中创建工作项或更改现有工作项的状态或分配时，将出现一个事件在房间中。
代码审查：当在以下任一区域路径中创建代码审查时，在房间中将出现一个事件。
拉取请求：当在以下任一存储库中创建、批准、拒绝或完成拉取请求时，将在房间中显示一个事件。

正如您在前面的截图中看到的那样，由于FabrikamShipRoom订阅了工作项，当创建产品积压 ID 1 时，团队房间会发布警报。团队协作以找出根本原因并解决问题。

注意

通过在工作项 ID 前加上#，TFS 会将其完全限定。在团队房间中点击#3，你将直接进入工作项 ID 3 的工作项表单。

通过点击右侧面板上的音频图标，你可以选择静音或取消静音团队房间中新消息的声音。团队房间的数据保存在 Team Foundation Server 中。可以通过 TFS REST API 获取团队房间数据，我们将在第八章，扩展和自定义 Team Foundation Server中详细介绍。

重命名团队项目

随着软件的演变，你可能会发现最初选择的团队项目名称已经不再适合你的项目目的。直到 TFS 2015，团队项目一旦创建，几乎无法重命名。团队项目重命名是 Visual Studio User Voice 网站上投票最多的功能，获得了超过 6000 票。TFS 2015 现在允许你重命名团队项目。虽然产品已经使得重命名团队项目变得非常简单，但这仍然是一个非常具破坏性的过程。在本指南中，你将学习如何重命名团队项目，并了解如何进行重命名以及在重命名过程中需要注意的细节。

准备开始

团队项目重命名会更新所有版本控制路径、工作项、查询以及其他团队项目的工件，以反映新名称。团队项目可以多次重命名，旧名称也可以重新使用。建议在非工作时间进行此操作，以尽量减少影响。需要考虑的事项如下：

为了重命名团队项目，你需要是项目管理员组的成员。
在重命名过程中运行的构建可能会失败。
所有用户都需要重新启动 Visual Studio。
Git 远程仓库需要更新为新的项目名称。
版本控制工作区需要通过运行最新的获取版本命令进行修正。

注意

如果团队中的个人使用本地工作区，建议升级到 Visual Studio 2013 更新 5 或 Visual Studio 2015（发布候选版或更新版本），以便在下次获取时自动修正工作区。如果他们继续使用早期版本的 Visual Studio，则需要将任何待处理的更改保存、创建新工作区，并恢复已保存的更改。

如何操作...

通过团队 Web 访问有两个入口点可以使用项目重命名功能。

选项 1

通过浏览 http://tfs2015:8080/tfs/DefaultCollection/FabrikamTFVC/_admin/ 进入团队项目的管理页面。
在左侧列出项目名称和描述的地方，你可以点击项目名称文本框来修改名称：

选项 2

通过浏览 http://tfs2015:8080/tfs/DefaultCollection/_admin 进入集合管理页面。
从上下文菜单重命名团队项目：
将项目名称从 FabrikamTFVC 更改为 Fabrikam 并继续。你将收到一个项目重命名的警告信息。请仔细阅读警告信息，并确保团队项目的用户已知悉此重命名。

注意

当团队项目被重命名时，任何打开该团队项目的浏览器可能会遇到一些错误。这些错误是由于浏览器中缓存的旧团队项目名称所导致的。
勾选复选框以确认警告，并点击 重命名项目。对话框将显示状态。重命名完成后，点击关闭。

注意

任何在团队项目中创建的默认工件，如果它们与团队项目名称相同，将与项目一起重命名。这包括默认的团队、团队聊天室和 Git 仓库等工件。

它是如何工作的...

在本节中，我们将重点讨论在团队项目重命名完成后，团队需要执行的操作。

重启编辑器：你用来连接团队项目的编辑器需要重启。无论是 Team Explorer、Eclipse、Office、Microsoft Test Manager，还是任何其他使用 TFS 对象模型的客户端。
更新基于查询的测试套件：与工作项查询不同，基于查询的测试套件存储方式不同，并且在重命名后无法更新团队项目名称。如果你有任何基于查询的测试套件，请在浏览器中打开这些套件并更新查询以使用新的团队项目名称。
更新 SharePoint 团队站点和报告集成：SharePoint 和报告服务集成将继续工作，但一些报告在新的团队项目名称填充之前可能无法正常工作。在缓存更新为新名称之前，旧的项目名称仍然存在。报告和 SharePoint 服务器管理员可以手动运行这些作业，以立即填充新名称。

注意

如果仍然存在指向其的工作区映射，Team 项目名称将无法重复使用。这样做是为了避免工作区映射到两个项目时产生的歧义情况。您需要联系拥有这些映射的用户，删除它们或更新为使用新名称。

通过命令行创建新的 Team 项目

作为 Team Foundation Server 管理员，您会发现自己一遍又一遍地创建 Team 项目。多亏了 Team Foundation Server Power Tools，Team 项目创建过程可以进行脚本化。Team 项目是一个容器，可以托管多个团队，并简化各种工件（如流程、主任务列表、构建定义和代码工件）的共享。通常情况下，新的 Team 项目请求可能是由于请求者不完全理解多个团队如何在 Team 项目中容纳。始终有必要进行对话，以充分理解为何请求新的 Team 项目。在本教程中，您将学习如何使用命令行脚本创建新的 Team 项目。

准备就绪

Microsoft Visual Studio Team Foundation Server Power Tools 可通过 Visual Studio Gallery 获取。Power Tools 是一组工具、增强功能和命令行实用程序，可以提高 TFS 管理员的工作效率。通过浏览到bit.ly/1jJkEmt下载并安装 Power Tools：

从 Visual Studio 扩展库下载 Microsoft Visual Studio Team Foundation Server 2015 Power Tools

安装 TFS Power Tools 会安装命令行实用程序Tfpt.exe。Tfpt.exe 是tf.exe的配套工具，提供额外的版本控制命令、工作项跟踪和 Team 项目操作。打开新的命令行并输入tfpt.exe /?。如果没有看到以下截图中显示的可用命令列表，请验证安装是否正确。

如何操作...

在C:\ drive中创建一个新文件夹TFSCookbook\Chapter01。在 Notepad 中复制以下文本并将其保存到C:\TFSCookbook\Chapter01，命名为settings.xml：

<?xml version="1.0" encoding="utf-8"?> 
<Project >
   <TFSName>http://tfs2015:8080/tfs</TFSName>
<LogFolder>C:\TFSCookbook\Chapter01</LogFolder>
    <ProjectName>ScriptedTeamProject01</ProjectName> 
    <ProjectReportsEnabled>true</ProjectReportsEnabled>
    <ProjectSiteEnabled>true</ProjectSiteEnabled>
    <ProjectSiteTitle>ScriptedTeamProject01</ProjectSiteTitle>
    <SccCreateType>New</SccCreateType> 
    <ProcessTemplateName>Scrum</ProcessTemplateName> 
</Project>

在命令提示符中运行以下命令：

tfpt createteamproject /settingsfile:"C:\TFSCookbook\Chapter01\settings.xml" /validate /verbose

您应该收到一条消息，确认验证是否成功。如果没有，请根据设置文件中的信息检查错误消息：

要创建 Team 项目，请删除/validate开关并运行之前的命令。

tfpt createteamproject /settingsfile:"C:\TfsCookbook\Chapter01\settings.xml" /verbose

等待 Team 项目创建过程完成。

注意

请注意，tfpt createteamproject不支持使用 Git 作为源代码控制存储库脚本化新的 Team 项目。

工作原理...

Team 项目创建命令以settings.xml文件作为输入；让我们回顾一下在settings.xml中提供的信息：

TFSName：此标签用于指定你希望创建新团队项目的 TFS 服务器的连接详细信息。
LogFolder：此标签用于指定日志文件的文件夹目录。该路径应该存在于 TFS 应用程序层。
ProjectName：团队项目的名称。如果你指定一个已存在的团队项目名称，团队项目创建过程将在验证过程中失败。
ProjectReportsEnabled：某些默认的项目报告会在创建团队项目时生成。此标签接受布尔值；传入false可以跳过添加默认报告。
ProjectSiteEnabled：如果你的 Team Foundation Server 安装启用了 SharePoint 服务，你可以在此标签中传入true值，以便为新团队项目创建一个 SharePoint 团队站点。
ProjectSiteTitle：如果 ProjectSiteEnabled 的值为false，则此标签被忽略。此标签用于指定你选择在团队项目创建过程中作为 SharePoint 团队站点创建的名称。
SccCreateType：如果在此标签中传入true值，则会创建一个新的 TFVC 源代码管理；或者可以传入现有的 TFS 源代码路径，以便从指定的 TFS 路径的内容创建 TFVC 源代码管理。
ProcessTemplateName：此标签用于传递团队项目应基于的过程模板的名称。

注意

可以从过程模板管理器查看你团队基金会服务器上所有可用的过程模板。要访问过程模板管理器，打开 Visual Studio 并连接到 Team Foundation Server。在 Team Explorer 中选择设置。在设置视图中，点击 过程模板管理器。

现在，让我们回顾一下 createteamproject 命令：

tfpt createteamproject /settingsfile:"C:\TFSCookbook\Chapter01\settings.xml" /validate /verbose

/settingsfile 路径用于指定设置文件的位置。TFPT 解析设置文件并通过连接到 Team Foundation Server 来触发团队项目的创建过程，连接时使用设置文件中指定的详细信息。当使用 /validate 开关时，团队项目不会被创建；整个过程将作为验证运行，用于识别任何潜在问题。/verbose 标志用于记录此过程中执行的操作的详细信息。详细选项在排查问题时非常有用。

还有更多...

tfpt.exe 命令行工具还提供了许多其他有用的命令。值得一提的两个命令是 addprojectportal 和 addprojectreports。

addprojectportal：随着时间的推移，可能会意识到需要创建或移动项目门户。此命令支持在现有团队项目中执行这两种操作。

tfpt addprojectreports /collection:http://tfs2015:8080/tfs /teamproject:"Fabrikam" /processtemplate:"Scrum" /webapplication:"" /relativepath:"pathfromwebapp" /validate /verbose

addprojectreports：添加报告操作会在选择的团队项目中创建报告。如果报告已存在，则此命令会覆盖它们。
```
tfpt addprojectreports /collection:"http://tfs2015:8080/tfs" /
teamproject:"Fabrikam" /processtemplate:"Scrum" /validate /verbose
```

删除团队项目

删除团队项目会永久从数据库中删除与该项目相关的数据。这些数据无法恢复。因此，你应该保存可能需要以后访问的团队项目数据。在本教程中，你将学习如何使用 TFS 管理控制台和命令行删除团队项目。我们还将回顾这两种方法的区别。

准备工作

为了删除团队项目，你应该是以下组的成员：

团队基金会管理员组
SQL Server 管理员组
SharePoint 产品的农场管理员组（如果 TFS 已配置为与 SharePoint 集成，则需要此权限）

在本教程中，我们将回顾删除团队项目的两种可选方法。第一种方法是通过 TFS 管理控制台删除，另一种方法是通过命令行删除。当项目通过管理控制台删除时，任何关联的报告和 SharePoint 门户项目需要手动删除。TFSDeleteProject 命令行工具会删除所有工件。

如何操作...

选项 1

首先，让我们看看如何通过团队项目管理控制台删除团队项目：

登录到托管团队基金会应用程序层的服务器。
打开团队基金会管理控制台窗口，在左侧面板中点击团队项目集。点击团队项目标签页以查看默认集合中的项目：
选择Fabrikam团队项目并点击删除：
在删除团队项目窗口中，选择删除外部工件和删除工作区数据。点击删除按钮继续操作。
删除工作流被触发，切换到状态标签页以跟踪进度：
尽管所有指向项目门户的链接将从团队网页访问中删除，但作为门户的 SharePoint 网站需要从 SharePoint 中央管理手动删除。

选项 2

现在，让我们看看如何使用 tfsdeleteteamproject 命令行工具删除团队项目：

打开 Visual Studio 2015 命令提示符。或者，你可以打开命令提示符并将目录更改为%programfiles(x86)%\Microsoft Visual Studio 14.0\Common7\IDE。

运行以下命令：

tfsdeleteproject /q /force /collection:http://tfs2015:8080/tfs/ Fabrikam

命令行工具提供了一些额外的参数：

/q：这是一个可选参数；它启用静默模式，在删除过程中不会显示确认提示。
/force：这是一个可选参数；即使某些组件无法删除，也会强制继续删除过程。
/excludewss：这是一个可选参数。如果你不希望删除与团队项目关联的 SharePoint 网站，可以使用此参数。

它是如何工作的...

tfsdeleteproject 命令执行删除操作分为两个阶段。第一阶段删除项目数据，包括版本控制中的数据、构建和测试管理器、Team Explorer 中的团队项目组件、工作项以及仅属于该团队项目的工作项字段。第二阶段删除项目网站。这包括与该团队项目相关的任何报告以及 SharePoint 上的项目门户。

注意

如果你尝试访问一个已经被删除的团队项目，你可能会收到以下错误信息：TF200016: 以下项目不存在。请验证项目名称是否正确，并确保该项目在指定的 Team Foundation Server 上存在。

使用 tfsdeleteproject 时，以下数据可能会未被删除：

数据立方体中的团队项目信息：数据立方体中的团队项目信息只有在下一次重建时才会被移除。仓库的默认重建间隔为 2 小时。
构建产物文件和文件夹：构建二进制文件、构建日志文件以及包含测试结果的日志文件会在构建过程中发布。这些文件的位置不会被删除。这些文件需要从文件夹中手动删除。
共享工作项跟踪元数据：tfsdeleteproject 不会删除在多个团队项目之间共享的工作项跟踪的任何元数据。
包含共享代码的版本控制暂存集：如果暂存集中的代码来自多个团队项目，则该版本控制暂存集不会被删除。

第二章：设置和管理代码仓库

	“质量从来不是偶然的，它永远是智能努力的结果。”
	--约翰·罗斯金

在本章中，我们将介绍：

在现有的 TFVC 团队项目中创建一个 Git 仓库
启用代码分析检查策略
在 TFVC 中执行兄弟分支之间的无基础合并
在 TFVC 中重新调整分支的父分支
解锁其他人签出的文件
将在一个分支中创建的 shelve 集合还原到另一个分支
使用 .tfignore 和 .gitignore 忽略文件类型的提交
在 TFS 中进行代码审查
设置 Git 分支策略
在 TFS 中执行 Pull 请求
使用 TFS 分析服务立方体分析代码变化

介绍

代码仓库使开发人员能够更有信心地编写代码。现在，使用源代码控制的开发人员比以往任何时候都多。当多个开发人员共同协作开发时，代码仓库的最显著好处就能显现出来。更多的人参与意味着对版本的管理和理解有更大的需求。如果你需要为源代码控制辩护，那么需要提出以下问题：

你是否曾修改过代码，后来意识到这是一个错误并希望恢复？
你是否曾丢失代码或有一个过时的备份？
你是否曾需要维护多个版本的产品？
你是否曾想过查看你代码的两个（或更多）版本之间的区别？
你是否曾想过证明某个特定的修改是导致或修复了某段代码的问题？
你是否曾想过回顾某段代码的历史？
你是否曾想过向其他人的代码提交修改？
你是否曾想过分享你的代码或让其他人参与你的代码工作？
你是否曾想过查看到底是谁、何时、何地进行了哪些工作？
你是否曾想过在不干扰现有代码的情况下尝试一个新功能？

管理代码是应用生命周期管理的一个重要部分，这一过程广泛适用于各种编程语言和框架。源代码控制系统大致可以分为集中式和分布式两类：

集中版本控制系统（CVCS）在服务器仓库上保持一份源代码的单一“中央”副本。在使用集中版本控制系统时，开发人员将代码从仓库下载到本地工作空间。一旦在本地对代码进行了修改，就会提交到中央副本。对仓库的其他操作（如分支、合并、暂存等）也发生在服务器上，并且需要连接到服务器。

TFVC 是一个集中版本控制系统。在使用 Visual Studio 或 Eclipse 与 TFVC 一起工作时，IDE 与服务器保持频繁的通信。没有与服务器的活动连接，大多数常见操作是无法执行的。

分布式版本控制系统（DVCS）不一定依赖中央服务器来存储项目文件的所有版本。相反，开发者“克隆”一个代码库副本，并在自己的硬盘上拥有项目的完整历史记录。这个副本（克隆）包含了代码库中的所有数据——包括所有分支和提交历史。

Git 是一个分布式版本控制系统。除了推送和拉取操作外，大多数操作都可以在没有与服务器的活动连接时执行。

TFS 是唯一同时支持集中式（TFVC）和分布式（Git）源代码管理系统的平台。以下表格可以帮助你决定在何种情况下集中式版本控制比分布式更合适。关于两者差异的更多详细信息，可以参考 msdn.microsoft.com/en-us/Library/vs/alm/code/overview。

	集中式版本控制	分布式版本控制
检入/检出	编辑/提交
---	---
优势

支持非常大的代码库
精细级别的权限控制
允许使用监控

离线编辑支持
轻松编辑 Visual Studio 或 Eclipse 外的文件

完全离线体验
完整的代码库与可移植的历史记录
简化的分支模型

最适合

大型集成代码库
对源代码的控制和审计可达文件级别

中型集成代码库
在减少摩擦的同时实现精细控制的平衡

模块化代码库
与开源集成
高度分布式的团队

在 TFS 2015 之前，源代码控制类型的选择需要在团队项目创建时做出。在 Update 1 中，引入了一个新功能，允许团队在 TFVC 团队项目中创建 Git 仓库。这对那些在 TFVC 项目中已有大量投资，但又希望尝试 Git 的团队来说非常有用。这个功能及其优势在 在现有 TFVC 团队项目中创建 Git 仓库 章节中有详细讨论。对于任何来自 TFVC 背景并希望学习 Git 的用户，Git for TFVC 是一本非常有用的指南 (bit.ly/1RgboRk)。

如今，市场和业务需求比以往任何时候都在发生变化。开发团队面临着更大的压力，需要更快地交付更高质量的软件。除非基础代码库的质量良好且有单元测试支持，否则这是不可持续的。一个好的源代码控制库可以显著提高软件质量，但仅仅拥有一个好的源代码库控制库是不够的，推动质量的因素远不止如此。

说到质量，缺乏代码审查、糟糕的 DevOps 实践、缺少单元测试、过多的战术实现，以及没有解决根本问题，都是技术债务的主要原因。技术债务不会在一夜之间爆发，它是一个缓慢而渐进的过程。与财务债务不同，技术债务非常难以察觉。技术债务会减慢你交付价值的能力。你是否注意到这些迹象？

本章的目标是向你介绍 Web Portal 和 Team Explorer 中的各种源代码管理操作，了解帮助将质量构建到代码中的功能，最后但同样重要的是，理解 TFS 仓库中可用的代码度量标准。在本章中，我们将使用 CodePlex 上提供的 Fabrikam Fiber 代码库(fabrikam.codeplex.com)。按照以下步骤将代码设置到 FabrikamTFVC 和 FabrikamGit 团队项目中。

在 FabrikamTFVC 团队项目中设置 Fabrikam 解决方案

打开 Visual Studio，在 Team Explorer 中连接到 FabrikamTFVC 项目。点击超链接以配置你的工作区。接受默认的名称和位置，然后点击映射并获取。操作完成时会显示成功通知：
打开工作区位置，在本例中是C:\Users\Tarun\Source\Workspaces\FabrikamTFVC。创建一个新的文件夹Main；在Main文件夹中，创建一个Source文件夹并复制从 CodePlex 下载的 Fabrikam 代码库内容：
打开 Visual Studio 中的源代码管理资源管理器，在菜单栏中选择将项目添加到文件夹图标。在添加到源代码管理窗口中，单击Main文件夹，然后点击下一步。接着，点击排除的项目，选择所有项目，然后点击包括项目图标。现在应该没有排除的项目了。点击完成，然后点击FabrikamTFVC项目并从上下文菜单中选择提交待处理更改：
在源代码管理资源管理器中，右键单击Main文件夹，并在上下文菜单中的分支和合并子菜单下选择转换为分支...：
打开FabrikamFiber.CallCenter.sln文件，路径为$/FabrikamTFVC/Main/Source/FabrikamFiber.CallCenter。在解决方案资源管理器中右键单击解决方案，并从上下文菜单中选择添加解决方案到源代码管理...：
接受警告并在 Team Explorer 的待处理页面上提交更改。Fabrikam 解决方案现在已成功设置到 FabrikamTFVC 团队项目的主分支中。

在 FabrikamGit 团队项目中设置 Fabrikam 解决方案

打开 Visual Studio，在团队资源管理器中连接到 FabrikamTFVC 项目。点击超链接以克隆此仓库。接受默认名称和位置并开始克隆。操作完成后会显示成功通知：
打开本地工作目录，在此案例中为 C:\Users\Tarun\Source\Repos\FabrikamGit。创建一个新的文件夹 src，并将从 CodePlex 下载的 Fabrikam 代码库内容复制进去：
在团队资源管理器中，导航到更改页面。从未跟踪的文件部分，点击添加所有超链接，将所有最近复制到工作文件夹中的文件添加进来。点击提交按钮，将这些更改提交到仓库：
当提交操作成功完成后，会提示同步更改。点击同步，然后在外发提交（1）部分点击推送，将更改推送到远程服务器：
在团队资源管理器中，导航到分支页面。master 分支以及 remotes/origin 分支都会显示出来：

现在，Fabrikam 解决方案已成功设置在 FabrikamGit 团队项目的主分支中。

在现有的 TFVC 团队项目中创建 Git 仓库

传统上，只能使用 TFVC 作为源代码控制库。从 TFS 2013 开始，TFS 支持将 Git 作为源代码控制。Git 为分布式团队提供了许多好处，尤其是那些跨同一代码库协作的团队；你可以在这里阅读有关 Git 好处的更多信息：git-scm.com/about。那些渴望尝试 Git，但由于迁移现有投资所需的重做工作而无法尝试的 TFVC 团队，现在有了解决方案。TFS 现在支持混合团队项目。在这个教程中，你将学习如何在现有的基于 TFVC 的团队项目中设置 Git 仓库。

准备就绪

在 Team Foundation Server 2015 更新 1 中，你需要是项目管理员组的成员才能将现有的 TFVC 或 Git 项目转换为混合项目，这种项目同时托管 TFVC 仓库和多个 Git 仓库。用户需要使用 Visual Studio 2015 更新 1 来处理混合项目。使用旧版本的 Visual Studio，包括 2015 RTM，用户将看到项目仍然是最初创建时的类型。

如果您的 TFVC 项目是在 TFS 2015 Update 1 之前创建的，项目管理员需要在创建第一个存储库后应用一些项目级别的权限。进入版本控制管理页面并选择树形结构中的 Git 存储库 节点。要设置与任何默认过程模板（敏捷、Scrum 和 CMMI）相同的组权限，请添加以下 TFS 组并授予以下权限：

[项目名称]\读者
- - 允许：读取
- - 未设置：其他所有人
[项目名称]\贡献者
- - 允许：分支创建、贡献、注释管理、读取和标签创建
- - 未设置：其他所有人
[项目名称]\构建管理员
- - 允许：分支创建、贡献、注释管理、读取和标签创建
- - 未设置：其他所有人

同样地，当在 TFS 2015 Update 1 之前创建的 Git 团队项目中创建 TFVC 存储库时，需要修改以下文件夹级别的权限。

进入版本控制管理页面并选择树形结构中的 $/_ 项目名称 _ 节点。要设置与任何默认过程模板（敏捷、Scrum 和 CMMI）相同的组权限，请添加以下 TFS 组并授予以下权限：

[项目名称]\读者
- - 允许：读取
- - 未设置：其他所有人
[项目名称]\贡献者
- - 允许：签入、签出、标签、锁定、合并和读取
- - 未设置：其他所有人
[项目名称]\构建管理员
- - 允许：签入、签出、标签、锁定、合并和读取
- - 未设置：其他所有人

如果您的团队项目是在 TFS 2015 Update 1 后创建的，那么这些权限已经为您应用，无需其他操作，只需创建存储库。

如何操作...

通过浏览 http://TFS2015:8080/DefaultCollection/FabrikamTFVC/_versionControl，进入 FabrikamTFVC Web 门户的代码中心。
如下图所示，点击 FabrikamTFVC 以展开选项菜单。要创建新的 Git 存储库，请从选项菜单中点击 新建存储库...。命名存储库为 FabrikamFeature1 并点击创建：

注意

请注意，同一个团队项目内不支持创建多个 TFVC 存储库，但支持创建多个 Git 存储库。
创建操作将把您重定向到 Git 入门页面。该页面允许您生成存储库的克隆和命令行凭据，创建一个 README 文件以描述您的存储库，并提供设置 Git 存储库以便与 Xcode、Eclipse 和 Visual Studio 配合使用的命令。点击 在 Visual Studio 中克隆 以开始在 Visual Studio 中工作：
由于此操作，存储库已在 Visual Studio 中克隆：

它是如何工作的...

许多客户积极使用 TFVC 仓库，并且在他们的团队项目中有丰富的工作项历史记录和自定义。为了方便这些团队开始使用 Git，TFS 中的团队项目模型已被修改以支持多个源代码控制仓库。混合项目允许在 TFVC 项目中创建任意数量的 Git 仓库。该模型现在还支持在 Git 项目中创建 TFVC 仓库。

Team Explorer 在 TFS 更新 1 中进行了增强，以支持操作混合团队项目。正如以下图所示，Team Explorer 中的连接管理页面列出了团队项目中的所有源代码控制仓库。Team Explorer 中的工作流会根据你连接的仓库类型进行调整。

Web 门户还允许在代码中心之间切换 TFVC 和 Git 源代码控制。与源代码控制相关的工作流会根据选择进行显示。例如，选择 Git 后，你可以看到拉取请求（Pull requests）选项，而在 TFVC 的上下文中，你会看到 shelvesets 选项。

还有更多...

最近的关于 Team Foundation Server 和 Visual Studio Online 中 Git 体验的投资路线图提到了对 Team Explorer 中拉取请求（Pull requests）的支持，以及对 Git 大文件存储（Git Large File Storage）和 GitFlow 的支持；你可以在 bit.ly/1RXQRS1 了解更多信息。

启用代码分析检入策略

许多组织建议在将代码提交到源代码控制之前进行某些检查。修复坏代码的成本会随着时间的推移增加。在代码问题早期发现并修复的过程中有激励措施。我们在上一章讨论了完成的定义；可以将其视为检入的定义。在 TFS 中，检入策略是在检入操作期间执行的规则，用以确保所选的变更集可以提交。检入策略存储在服务器上，并在检入时在客户端机器上执行。检入策略仅在 TFVC 项目中受支持。虽然 TFS 有一些预配置的检入策略，但 TFS Power Tools 添加了几个其他的检入策略。在本章节中，你将学习如何配置代码分析检入策略。代码分析检入策略要求在检入之前运行代码分析。

准备工作

要完成本章节，你需要：

一个名为 FabrikamTFVC 的 TFVC 团队项目。有关如何创建 TFVC 团队项目的说明，请参考第一章中的 使用 Scrum 模板创建团队项目 章节，团队项目设置。
为了配置检入策略，你需要将编辑项目级别信息的权限设置为允许。添加自己。如果你是项目管理员或项目集管理员组的成员，你将已经拥有此权限。

注意

使用 Team Explorer everywhere 定义的提交策略仅在使用 Eclipse 的 Team Foundation Server 插件或 Team Foundation Server 的跨平台命令行客户端提交时适用。如果使用其他客户端，如 Team Portal 或 Visual Studio 中的 Team Explorer，这些策略将不适用。同样，使用 Team Portal 或 Visual Studio 中的 Team Explorer 定义的策略在使用 Eclipse 的 Team Foundation Server 插件或 Team Foundation Server 的跨平台命令行客户端提交时不会应用。

如何操作...

在 Visual Studio 中，打开 Team Explorer 并点击设置。导航到设置视图后，点击源代码管理超链接。在源代码管理设置窗口中，选择提交策略标签页。点击添加按钮，选择代码分析，然后点击确定。
在代码分析策略编辑器窗口中，从规则集下拉框中选择Microsoft 推荐的托管规则，然后点击确定：
选中强制提交仅包含当前解决方案中的文件。此选项允许你阻止提交任何不属于当前解决方案的文件。启用此选项是一个不错的选择，因为开发人员可能会不小心将文件提交到源代码管理中，而没有将该文件与解决方案关联。这可能会导致构建问题。

注意

代码分析规则集的定义存储在C:\Program Files (x86)\Microsoft Visual Studio 14.0\Team Tools\Static Analysis Tools\Rule Sets文件夹中。
从 FarbikamTFVC 项目中，打开FabrikamFiber.CallCenter.sln：
在FabrikamFiber.Web的Controllers中，打开HomeController.cs：
将以下代码复制到HomeController.cs中的Index()函数：
```
try
{}
catch(Exception ex)
{}
```
从 Team Explorer 中，导航到待处理更改窗口，并将代码更改提交到 TFS。由于没有运行静态代码分析，系统发出了策略警告：
双击警告信息查看详细信息：
在 Visual Studio 的分析菜单中选择在解决方案上运行代码分析来触发代码分析：
代码分析发现了新添加代码中的问题。如果没有运行代码分析，开发人员可能会错过这个问题。代码分析策略确保在代码提交之前运行代码分析：
由于现在已经运行了代码分析，提交代码时将不会发出提交策略违规的警告信息。

如何操作...

提交策略用于强制执行强制的软件开发实践。策略在提交过程中执行。由于 TFVC 提交在服务器上处理，提交请求会被拦截，以强制在客户端执行提交策略。如果用户试图进行违反策略的提交，提交将被阻止。

可以指定四种 Team Project 提交策略（要使用提交策略，必须连接到 Team Foundation Server）：

构建：这要求在新提交之前，必须修复在构建过程中出现的任何破坏性构建问题。
代码分析：这要求在提交代码之前，必须运行代码分析。
测试策略：这要求在提交代码之前，必须完成测试。
工作项：这要求在提交代码时，必须关联一个或多个工作项。

提交策略可以通过点击覆盖警告超链接来覆盖；在提供覆盖理由后，你可以继续提交代码：

注

你可以通过在 Team Explorer 中使用不覆盖策略的服务器端插件来关闭策略覆盖选项。更多细节请阅读以下博客文章 bit.ly/1jUhZ9y。

还有更多...

到目前为止，我们讨论了 TFVC 项目的提交策略。通过 TFS API，可以为 Git 项目创建自定义提交策略。服务器端插件会监听 Git 推送事件时触发的PushNotification。关于如何为 Git 仓库创建服务器端提交策略，以验证提交信息是否与推送关联，请参考 bit.ly/1OabagX。

在 TFVC 中执行无基础的兄弟分支合并

当多个团队共同向同一个仓库贡献代码时，管理源代码可能会变得具有挑战性。你是否已经熟悉 TFS 中可用的分支和合并工具？如果没有，我建议你阅读 ALM Rangers 版本控制指南 bit.ly/1He8pmL。该指南详细讲解了各种分支策略及其优缺点。

来自 ALM Rangers 版本控制指南的摘录，展示了不同的分支策略

随着时间推移，TFVC 中的分支管理可能会变得复杂；而 Git 中的分支则轻量且路径独立。在 Git 中，许多开发人员为他们正在编码的每个新特性创建一个分支，有时是按日创建。Git 允许你快速切换不同的分支，在代码库的不同变体之间进行切换。在使用 Git 时，你可以创建仅存在于你的开发机器上的分支，并在你准备好时与他人共享。考虑根据工作流评估你的源代码控制需求，访问 bit.ly/1P7UMvO；你可能会发现 Git 更适合你的需求。

在本示例中，你将学习如何在两个无关的 TFVC 分支之间执行合并操作，这些分支通常被称为兄弟分支。

准备工作

在你的 TFVC 基础团队项目中，创建如下图所示的分支结构。你可以使用 TFS Community Branch Tool 扩展来自动化创建分支，如下图所示 (bit.ly/1LZR2bx)：

在这个示例中，我们将处理以下场景。正在开发 Dev 分支的开发人员发现了一个关键问题，并通过代码提交解决了该问题。QA 分支已经被另一位开发人员用于进行一些无关的工作。为了将 Dev 分支的修复发布到生产环境，开发人员决定在 Dev 和 Prod 分支之间执行无基础的合并。

要执行合并操作，你的用户帐户需要具备合并权限。项目管理员组已授予此权限；但是，该权限也可以直接在单个用户和组上设置为允许：

如何操作…

在 Visual Studio 中，打开团队资源管理器并导航到源代码控制资源管理器。对 FabrikamTFVC 团队项目执行 获取最新版本 操作：
为了模拟在 Dev 分支上进行修复，打开 $\Dev\FabrikamFiber.CallCenter\FabrikamFiber.Web\Controllers\HomeController.cs 文件，并将以下注释放入 Index 方法中：

在团队资源管理器的待提交更改视图中提交对该文件的代码更改：
现在关键更改已经在 Dev 分支中，我们来看看将此更改从 Dev 分支无基础合并到 Prod 分支所需的步骤。在源代码控制资源管理器中，右键单击 Dev 分支，然后在 分支和合并 子菜单下选择 合并...：
合并向导中不会显示 Prod 分支在 目标分支 下拉菜单中。无关的分支只能通过 浏览... 按钮选择。点击 浏览... 并选择 Prod 分支，然后点击确定：
在目标分支旁边会出现一个警告标志，表示所选分支无关且会导致无基合并：
点击下一步进入下一屏幕：

注意

如果选择从所有更改更改为选择的更改集，则两个分支之间并未建立合并关系。尽管您仍然可以合并更改，但无法可视化该合并。
保持下拉框中的最新版本选项，并点击下一步：
合并操作完成后，您将被导航到解决冲突窗口。点击在合并工具中合并更改，然后检查并点击接受合并：
在合并完成后，解决冲突窗口将清除所有冲突。在 Team Explorer 中查看待处理更改，检查待处理更改并提交：
在源代码管理资源管理器中，右键点击Prod分支，选择查看历史记录。检查所有分支并点击可视化。从 Dev 到 Prod 的虚线表示无基合并。

它是如何工作的……

当进行无基合并时，将在两个兄弟分支之间建立关系。无基合并用虚线表示：

要查看更改的时间线，点击屏幕顶部的时间线跟踪视图：

在 TFVC 中重新设置分支的父节点

Team Foundation 版本控制提供了一个选项，可以将分支从给定层级中的某个位置修剪出来，并在同一层级的其他位置重新附加。如果您在设置分支结构时出现了问题，或者在扩展过程中原有结构停止工作，可以考虑使用这种方法。在本教程中，您将学习如何在 TFVC 中重新设置分支的父节点。

注意

重新设置父分支的移动是逻辑上的而非物理上的，可以在不停止开发人员工作的情况下完成。然而，建议让开发人员将更改暂存。您还应尽力使新父分支的内容与旧父分支尽可能接近，以避免合并冲突。

准备工作

要重新设置分支的父节点，您的用户帐户需要具有管理分支权限。项目管理员组和项目集合管理员组已授予此权限；不过，您也可以直接在单个用户和组上设置此权限：

管理分支权限允许您执行以下操作：

将文件夹转换为分支
执行以下操作
- 编辑分支属性
- 重新设置分支父节点
- 将分支转换为文件夹

在您的 TFVC 项目中，创建一个分支结构，如左图所示：

当前的分支结构

所需的分支结构

本教程中我们将处理的场景，如左侧图示所示，是开发团队从Main分支发布；Release 1.1是从Release 1分支出来的。如右侧图示所示，团队希望将Release 1.1直接移到Main分支下，这样更改就不需要通过Release 1进行合并到Release 1.1。

要将Release 1.1分支从Release 1重新设置为Main，需要在这两个分支之间建立关系。这只能通过对两个分支执行无基础合并来完成。请参阅在 TFVC 中对兄弟分支执行无基础合并教程，了解如何执行无基础合并。

本教程假设Main分支与Release 1.1分支之间已建立合并关系。在前面的图中，虚线表示这两个分支之间的关系。

如何操作…

导航到源代码控制资源管理器，右键点击Release 1.1分支，然后从分支和合并子菜单中选择重新设置父分支...：
在重新设置父分支窗口中，你将看到与Release 1.1有直接或间接关系的所有分支的列表。选择Main，然后点击重新设置父分支。选择无父分支将使Release 1.1成为一个独立的分支：
重新设置父分支操作发生在服务器上。你不会看到重新设置父分支操作带来的任何待处理更改。重新设置父分支操作后的分支层次结构如下：

它是如何工作的…

一旦重新设置父分支操作完成，你可以通过右键点击Release1.1分支，并选择属性，从高级子菜单中查看更新后的分支层次结构：

从左侧菜单点击关系选项卡，以查看分支关系。

解锁其他人签出的文件

在分布式团队中，开发人员经常有待处理的更改，这些更改会与共享的代码文件发生冲突。你是不是讨厌当某个开发人员请假时，文件仅被他们自己签出，或者某个开发人员离开组织时，文件仍然被签出？当文件被独占锁定时，必须移除锁定才能对文件进行提交。在本教程中，你将学习如何解锁其他用户签出的文件。

准备就绪

要撤销其他用户工作区中的待处理更改，你必须具有管理工作区权限，并将其设置为允许：

如何操作...

开发者 A 在 FabrikamTFVC 项目中以提交锁定类型检出了 $/FabrikamTFVC/Main/Source/FabrikamFiber.CallCenter/FabrikamFiber.Web/Web.config 文件。因此，尽管其他用户可以检出 Web.config 文件，但在开发者 A 解除此锁之前，任何人都无法提交该文件：

在下图中，Web.config 被选中并且具有提交锁。此状态在 待处理更改 列中显示为锁定：
现在，开发者 B 检出 Web.config 并向配置文件中添加一个新部分。为了提交更改到版本控制，开发者 B 尝试提交该文件。提交失败，显示以下消息。

注意

在提交过程中遇到了以下问题：

无法对 $/Fabrikam/Main/…/Web.config 执行操作。项目 $/Fabrikam/Main/ …/Web.config 在工作区 TFS2015;DeveloperA 中被锁定。
开发者 B 打开 "Visual Studio 2015 开发者命令提示符" 并运行以下命令以撤销开发者 A 的更改：
```
tf undo /workspace:TFS2015;"Developer A" /recursive $/FabrikamTFVC/Main/Source/FabrikamFiber.CallCenter/FabrikamFiber.Web/Web.config" /collection:"http://tfs2015:8080/tfs"
```
当提示是否确认撤销时，输入 Y。你也可以在上述命令中使用 /silent 开关来跳过提示：

开发者 B 现在可以通过 Visual Studio 的待处理更改窗口成功提交文件。

注意

虽然开发者 A 对 app.config 的锁已被移除，但开发者 A 在其机器上的配置文件中可能仍有待处理的更改。因此，开发者 A 可以执行 get 操作以获取开发者 B 的更改，并根据需要合并并继续操作，而不会丢失任何信息。

还有更多内容...

TFS Power Tools 提供了一个选项，可以在 Visual Studio 内直接撤销其他用户的待处理更改。如果你没有安装 TFS Power Tools，请参考第一章中的通过命令行创建新的团队项目一节，了解更多内容，团队项目设置。

右键单击你想要撤销的文件或文件夹。在上下文菜单中，选择 查找状态...，位于 源代码管理 子菜单下的查找中。你可以通过指定通配符和用户名来缩小搜索范围。搜索结果会显示在 源代码管理 窗口中的查找视图：

只需选择文件，并在上下文菜单中选择 撤销... 来撤销待处理的更改。

将一个分支中的 shelveset 还原到另一个分支

在使用 TFVC 时，你会发现 shelvesets 非常有用。Shelvesets 允许你将本地的更改备份到服务器上。开发者几乎总是在进行多任务操作；你可能会在一个分支上开始编码某个更改，然后意识到该更改实际上需要应用到另一个分支。在本配方中，你将学习如何在一个代码分支中暂存更改，然后将这些更改迁移到另一个分支，而无需将更改提交到源代码管理。

准备工作

FabrikamTFVC 项目有三个分支，Dev、Main 和 Prod，如下面的图所示。在本配方中，我们将从 Dev 分支中的待处理更改创建一个名为 shelvesetDev1 的 shelveset，并将待处理更改迁移到 Prod 分支，而无需将待处理更改提交：

本配方需要使用 tfpt 命令行工具。此工具随 TFS Power Tools 一同安装。如果你没有安装 TFS Power Tools，请参考第一章中关于通过命令行创建新的团队项目的配方，团队项目设置。

在 Dev 和 Prod 分支上执行 get latest 操作，确保它们是最新的。确保 Prod 分支中没有待处理的更改。如果分支不是最新的，在执行 unshelve 操作时可能会出现以下错误消息：无法确定工作区。

如何操作...

在 Team Explorer 中，打开源代码管理资源管理器并签出 $\Dev\FabrikamFiber.CallCenter\FabrikamFiber.Web\Controllers\HomeController.cs 文件，然后复制 Index 方法中的以下注释：

// 假设这是对该方法的关键修复：
在 Team Explorer 中，导航到 Pending Changes 视图并点击 Shelve 超链接。输入 shelveset 名称 shelvesetDev1，然后点击 Shelve 按钮：
打开 Visual Studio 开发者命令提示符，并将工作目录更改为目标分支的工作区目录。在此示例中，目标分支为 Prod：

运行以下命令将 shelveset 从 Dev 分支迁移到 Prod 分支：

tfpt unshelve /migrate /source:"$/FabrikamTFVC/Dev" /target:"$/FabrikamTFVC/Prod" "shelvesetDev1"

在 Shelveset Details 窗口中，点击 Unshelve 按钮以继续：
如果 TFS 认为它能够解决合并冲突，合并按钮将启用。如果 TFS 需要手动解决冲突，则 Resolve 按钮将启用。点击 Auto-merge All 按钮以继续：
一旦自动合并操作完成，命令提示符中将发布确认消息：
在源代码管理资源管理器中，导航到 Prod 分支。从 $\Prod\FabrikamFiber.CallCenter\FabrikamFiber.Web\Controllers 打开 HomeController.cs。在 Dev 版本中的 HomeController.cs 文件所做的更改将反映到 Prod 分支中的 HomeController.cs 文件：

使用 `.tfignore` 和 `.gitignore` 忽略提交文件类型

传统上，TFS 仅支持服务器工作区。局部工作区在 TFS 2012 中推出。局部工作区允许你在不连接服务器的情况下进行工作。所有核心版本控制操作都可以在没有服务器连接的情况下执行。局部工作区监听文件系统上的变化，从而推断正在执行的操作。例如，在文件系统中直接创建的新文件会显示为待提交更改。使用过 Subversion 源代码控制的用户会对局部工作区有所了解。你可以在 msdn.microsoft.com/en-us/library/bb892960.aspx 阅读有关局部工作区工作原理的更多信息。

许多与 Visual Studio 协同工作的工具和扩展会在本地工作区目录中生成临时文件。例如，ReSharper，一个用于 Visual Studio 的开发者生产力扩展，生成 _Resharper.[SolutionName] 文件，这些文件（默认情况下）会包含在待提交更改中。这些临时文件对版本控制没有任何帮助，应当被忽略；.tfignore 和 .gitignore 允许你做到这一点。可以在 .tfignore 和 .gitignore 中指定要忽略的文件类型；这些规则用于自动排除指定的文件类型不包含在待提交更改中。在本教程中，你将学习如何创建 .tfignore 和 .gitignore 文件，以自动排除某些文件类型。

准备就绪

为了按照本教程操作，你需要创建一个本地工作区。按照以下指示在 FabrikamTFVC 项目中创建本地工作区：

在本地磁盘中创建一个文件夹 Wks。本教程假设该文件夹为 C:\Wks。
打开 Visual Studio 中的 Team Explorer 并连接到 FabrikamTFVC 团队项目。
从 Visual Studio 菜单中，导航至文件 | 源代码控制 | 高级 | 工作区：
在 管理工作区 窗口中，点击添加。在 添加工作区 中，创建一个名为 TFS2015_99 的工作区，从 $/FabrikamTFVC/Main 映射到 C:\Wks。点击 高级>> 按钮，确认工作区位置是否设置为本地。然后，点击确定：
点击确定后，接受提示执行最新获取操作，将源代码下载到新的本地工作区。

如何操作...

执行以下步骤来设置基于 TFVC 的源代码控制的 .tfignore 文件：

打开 C:\Wks 并创建一个新文件 ThisIsAFakeClass.txt。
在 Team Explorer 中，导航至 FabrikamTFVC 项目的 待处理更改 视图。在 排除的更改 部分，检测到的数量显示为 1。
点击 检测到的项目 超链接。在 提升候选更改 窗口中，右键点击 ThisIsAFakeFile.txt 并选择 按扩展名忽略 (*.txt)：

.tfignore 文件会自动为你创建，并出现在 待处理更改 视图中。打开 .tfignore 文件；扩展名 *.txt 已被添加为需要忽略的项目。将以下内容复制到 .tfignore 文件中，以忽略所有 ReSharper 生成的文件：
```
######################################
*.txt
# Ignore Reshaprer files
*_ReSharper.*
*.DotSettings
```
将 .tfignore 文件提交到版本控制中；此规则集将在所有开发者工作站上评估，以忽略该 .tfignore 文件中指定的所有文件。

注意
- TFVC 支持多个 .tfignore 文件，其中项目范围内的 .tfignore 文件可以覆盖解决方案级别的 .tfignore 文件中的忽略规范。
- TFVC 接受排除规则，例如，要忽略所有 TXT 文件，除了 help.txt，可以使用 !help.txt。

执行以下步骤为基于 Git 的源代码管理设置 .gitignore 文件：

在 Team Explorer 中，打开 FabrikamGit 项目并导航至设置视图。点击 仓库设置 超链接。然后，点击添加来创建一个 .gitIgnore 文件：

点击编辑超链接以编辑 .gitignore 文件。将以下内容复制到 .gitIgnore 文件中：

# User-specific files
*.suo
*.user
*.sln.docstates
# Specific files 
*.txt
# Build results
[Dd]ebug/
[Rr]elease/

在 Team Explorer 中，导航至更改视图并提交 .gitIgnore 文件。点击同步超链接，将更新后的 .gitIgnore 推送到仓库。现在，所有开发者工作区将忽略该 .gitignore 文件中指定的文件扩展名。

注意

Git 支持多个 .gitIgnore 文件，其中项目范围内的 .gitIgnore 文件可以覆盖解决方案级别的忽略规范文件。

还有更多……

tfpt 命令行工具是与 TFS Power Tools 一起安装的，其中提供了两个非常有用的开关：scortch 和 treeclean。scortch 和 treeclean 允许你将工作区镜像到服务器状态，并移除工作区中的任何不需要的杂乱文件。了解更多关于 scortch 和 treeclean 的信息，请访问 adamprescott.net/2011/09/12/clean-tfs-workspaces-with-scorch-treeclean。

在 TFS 中进行代码审查

在本章的介绍中，我们简要讨论了技术债务以及它如何影响团队的生产力。使用良好的工程实践有助于解决可能导致技术债务的问题。业界普遍认同，代码审查是一种有效且实用的方法，可以在软件开发生命周期的早期发现代码不一致和潜在缺陷。

Forrester Consulting 进行的一项关于代码审查的价值和重要性的研究突出了以下被认为是代码审查好处的内容：

来源 - www.klocwork.com/getattachment/08c47c41-053c-4fe8-bbf7-91b95734747c/The-Value-and-Importance-of-Code-Review-Forrester?sitename=Klocwork

TFS 提供两种代码审查解决方案，一种通过 Team Explorer，另一种通过 Team Web Access。Team Explorer 中的代码审查解决方案首次在 TFS 2012 中引入，但因不支持迭代审查而受到批评。另一方面，Team Web Access 中的轻量级代码评论解决方案支持迭代审查，但不支持集成的 Visual Studio IDE 体验。你可以在www.visualstudio.com/en-us/get-started/code/get-code-reviewed-vs了解有关 Team Explorer 中可用代码审查解决方案的更多信息。在本教程中，你将学习如何在 Team Web Access 中使用轻量级代码评论进行代码审查。

准备就绪

在本教程中，我们将处理以下场景——Aaron 是 FabrikamTFVC 团队的开发人员。他正在FabrikamFiber.CallCenter.sln开发代码库中为服务票务仪表板显示 CreatedBy 列的一个新功能。Aaron 已经提交了他的更改（这创建了变更集 27），现在他希望 Tarun 对这些更改进行代码审查。Aaron 通过点击 Team Web Access 中的共享变更集图标将变更集发送给 Tarun：

通过点击变更集视图中的电子邮件图标发起代码审查

提示

下载示例代码

你可以从你的账户中下载示例代码文件，访问www.packtpub.com，下载你所购买的所有 Packt 出版书籍的代码文件。如果你在其他地方购买了本书，可以访问www.packtpub.com/support并注册，文件将直接通过电子邮件发送给你。

如何操作…

Tarun 收到一个反馈请求的电子邮件。点击超链接变更集 27会在审查模式下打开变更集，突出显示比较模式中的代码更改。也可以通过点击文件名超链接，在并排比较模式中查看更改：

通过点击变更集超链接，启动代码比较窗口，在此情况下为变更集 27
浏览Index.cshtml时，Tarun 发现了几个问题。他选择了有问题的代码并添加了内联评论：
Tarun 使用变更集顶部的添加评论按钮对变更集进行总体评论：
Tarun 通过点击Sharechangeset按钮提交反馈。电子邮件中包含所有评论的列表。
Aaron 逐一修复了 Tarun 指出的问题。Aaron 认为 Tarun 关于分页和过滤器的评论应该作为一个通用功能来构建。Aaron 从代码评论中创建了一个产品待办事项，并将其添加到团队的待办事项列表中：

如何运作…

轻量级代码评论是 Team Web Access 中的基于浏览器的代码评论解决方案。它为对整个文件或单个更改进行评论提供了良好的内联体验。代码评论使关于代码的互动或延时对话成为可能。代码评论是在浏览器中完成的，因此，除了其他功能外，它可以在任何地方工作——包括在您的手机上。

评论存储在 Team Foundation Server 中，与代码相关。如果代码或相关的代码文件被删除，关联的代码评论将自动删除。从评论中创建的工作项包括回到评论的引用；这有助于保持可追溯性：

还有更多…

尽管大家一致认为代码审查很重要，但业内对代码审查应该在提交前还是提交后进行意见分歧。请参考以下博客文章，讨论这两种方法的优缺点：

geekswithblogs.net/TarunArora/archive/2012/09/18/vs-2012-code-review-ndash-before-check-in-or-after.aspx

在 Git 中设置分支策略

在代码质量主题的基础上，如何帮助防止技术债务，分支策略是 TFS 中的一项新功能，它有助于提高进入 Git 仓库的代码质量。在本食谱中，您将学习如何在主分支上配置代码审查和门禁提交策略。

准备就绪

要在分支上配置分支策略，用户需要对该分支具有管理员权限。要为整个仓库应用分支策略，用户需要对仓库具有管理员权限。

为 FabrikamGit 团队创建一个持续集成构建；请参阅第四章中的《创建持续集成构建定义》食谱，构建您的应用程序。

场景：FabrikamGit 团队希望通过只允许通过 Fabrikam CI 构建并且已被团队中至少两个人进行代码审查的提交来保护主分支。如果正在更改的代码属于/src/FabrikamFiber.CallCenter/FabrikamFiber.Web区域，则必须由 Brian Miller 进行审查。

如何做…

打开 FabrikamGit 团队管理页面 http://tfs2015:8080/tfs/DefaultCollection/FabrikamGit/FabrikamGit%20Team/_admin/。进入版本控制标签并选择主分支。要访问分支策略，点击分支策略标签：
分支策略页面允许你配置限制性提交和代码审查的策略。
在自动构建拉取请求部分，勾选两个选项并从下拉菜单中选择FabrikamGit CI构建定义：
在代码审查要求部分，勾选要求代码审查，并将最小审阅者人数设置为2：
点击添加新路径超链接。添加路径 /src/FabrikamFiber.CallCenter/FabrikamFiber.Web/* 和审阅者 Brian Miller：
点击保存更改按钮以保存并应用限制性提交和代码审查策略。

工作原理...

分支策略会在提交时在服务器上进行评估。启用主分支的分支策略后，不能直接将代码提交到主分支。直接将代码提交到主分支时，会出现以下错误消息。

推送时报告了以下错误：

refs/heads/master, TF402455: Pushes to this branch are not permitted; you must use pull requests to commit changes.

还有更多...

有时可能会有绕过策略的正当理由。TFS 提供了这一功能。通过将免除策略执行权限设置为允许，用户或组可以绕过策略：

此权限可以作用于整个项目、一个仓库或一个单独的分支。如果你被授予免除策略执行的权限，你将不会收到警告，也不会被阻止直接推送或合并到分支。因此，正如人们常说的那样……拥有巨大权力的同时，也需要承担相应的责任。

在 TFS 中进行拉取请求

在本章前面，你已经学习了如何限制未经审查的代码进入主分支。拉取请求是将代码从主题分支（也称为功能分支）推送到主分支的方式。拉取请求使得在主题分支工作的开发人员能够在提交代码到主分支之前，获取其他开发人员对其更改的反馈。在本篇中，你将学习如何进行拉取请求，以接受来自主题分支的更改到主分支。

准备就绪

我们将在这个示例中演示的场景是：Brian 是 FabrikamGit 团队的开发人员。他正在开发一个功能，在服务仪表板上添加一个名为 problem type 的下拉菜单。Brian 创建了一个包含问题类型列表的枚举，并希望获得对此列表的反馈，并将他的更改合并到主分支。

打开 Visual Studio 并将其连接到 FabrikamGit 团队项目。从 Team Explorer 中心，点击分支。在分支视图中，右键点击master并在上下文菜单中选择从…新建本地分支。输入新分支的名称为Brian/Feature1，然后点击创建分支按钮：
从主题分支中，打开FabrikamFiber.CallCenter.sln。在FabrikamFiber.Web项目中，添加一个新文件夹并命名为Common。添加一个新类并命名为ProblemTypeEnum.cs。编辑该类并创建一个枚举，如截图所示：
从 Team Explorer 中，导航到更改视图。通过输入提交信息并点击提交按钮来提交待处理的更改。同步并发布分支：
通过访问http://tfs2015:8080/tfs/DefaultCollection/_git/FabrikamGit/branches，导航到 Team Web Access 中的分支视图页面。主题分支会在这里显示，突出显示它比 master 分支多了一次更改：
验证 master 分支是否已设置强制检查和代码审查策略。如果没有，请按照在 Git 中设置分支策略的步骤进行操作。

如何操作...

通过访问http://tfs2015:8080/tfs/DefaultCollection/_git/FabrikamGit/pullrequests，导航到 Web 门户中的拉取请求页面。您将看到一个提示，要求您从先前发布的分支创建拉取请求。或者，点击左侧面板中的新建拉取请求按钮：
创建拉取请求页面显示了更改的列表，并提供了文件级别的对比。目标分支被选择为 master，因为它已设置为默认分支。可选地，点击更多选项超链接以添加描述和额外的审核组：
评估 master 分支策略，FabrikamGit CI 构建会自动启动，并发出代码审查请求。引擎评估更改并确定合并操作不会发生冲突。由于代码更改位于/src/FabrikamFiber.CallCenter/FabrikamFiber.Web/，因此也会向 Tom Hacker 发出代码审查请求：
现在，Tom Hacker 登录 Web 门户，查找分配给他的拉取请求。他对该拉取请求进行了代码审查。Tom 建议对枚举进行一些更改，并将拉取请求标记为已批准并附有建议：
Brian 根据建议进行了更改，并将更改提交到主题分支。点击刷新以更新拉取请求中的更改：
分支策略会重新评估——触发的检查构建会运行，合并会被评估。一旦所需的审阅者批准了 Pull 请求，请求就准备好合并。点击 完成 Pull 请求 按钮将更改合并到主分支，并创建一个新的变更集：
现在，点击 删除源分支 按钮以删除 feature1 分支。这样做是一个良好的做法，因为保留不需要的分支会导致混乱。

Pull 请求已完成；更新的状态反映在 Team Portal 中。

工作原理...

从 Team Explorer 中心，点击同步页面，获取并拉取传入的更改。在分支视图中，点击 master 分支，并从上下文菜单中选择 查看历史记录。合并到主分支已作为 Pull 请求的一部分完成；这现在在分支历史中有所反映：

使用 TFS 分析服务立方体分析代码变动

TFS 分析服务立方体计算大型数据集，帮助用户回答关于软件项目的问题。TFS 数据仓库使用户能够连接各种数据集，并理解代码变动、代码覆盖率、构建、错误等趋势。在本教程中，您将学习如何将 Excel 连接到 TFS 分析服务立方体，并分析 FabrikamTFVC 项目中的代码变动。

准备就绪

为了通过 Excel 连接 TFS 分析服务作为数据源，您需要在 TFS 数据仓库中授予 Windows 帐户权限。或者，使用已经具有访问权限的 Windows 用户名和密码。

如何操作...

打开 Excel，在数据标签中点击 来自其他来源，然后选择 来自分析服务。在数据连接向导中，输入 TFS 分析服务器的连接详情，然后点击 下一步 按钮：

注意

如果您不确定仓库的连接详情，可以通过 TFS 管理控制台中的报告标签进行检查和验证。
在数据库下拉列表中选择 Tfs_Analysis，选择 代码变动，然后点击 下一步 按钮。修改列表示每个立方体和视角的最后处理数据时间。在下一个屏幕中，点击完成：
根据以下截图设置数据透视报告：

工作原理...

选择这些字段后，会生成如下输出。数据按年、月和周分组，显示代码库中的总行数，以及修改行数、删除行数、添加行数和总变动：

注意

如果你对构建质量指标报告感兴趣，TFS 已经提供了这个报告。该报告显示了指定构建定义的测试覆盖率、代码变化量和缺陷数量。你可以参考msdn.microsoft.com/en-us/library/dd380683(v=vs.120).aspx教程，了解更多关于这个报告的信息。

还有更多…

将数据透视表中的字段更改为下图所示。现在，让我们将版本控制层次结构和构建细节加入到方程式中，并像这里的截图一样更新数据透视表中的字段：

在值部分，添加“总行数”、“修改行数”、“新增行数”和“总变化量”。

这将导致按年份、周和日期以及版本控制层次结构进行透视。正如你在这里的截图中看到的，输出显示了分支的变化。你可以进一步钻取到特定的项目和类：

现在，将文件层次结构更改为过滤器，并将文件扩展名添加为行。在.asax、.config和.cshtml的文件扩展名过滤器中，输出将显示这些文件类型随时间的代码变化量。

可能性是无限的。一旦你掌握了分析报告的基础，你就可以开始探索数据仓库中其他维度，以将数据关联起来，发现更多关于你的软件项目的有趣趋势。

第三章：规划和跟踪工作

	“没有计划的目标只是一个愿望。”
	--安托万·德·圣埃克苏佩里

本章将涵盖以下内容：

选择在团队门户上显示的待办事项级别
映射、分配和跟踪多个团队共享的工作项
向看板添加额外的列
自定义看板上显示的卡片
为冲刺设置团队的能力和活动
按标签查询工作项
使用工作项查询创建图表
使用服务钩子与 Trello 看板集成
在 TFS 中永久删除工作项
使用 Microsoft Feedback 客户端提供反馈

介绍

传统上，企业将技术视为业务成本；如今，企业将技术视为做更多生意的机会。用于关键决策的软件系统的使用正在比以往任何时候都增加。领先的公司已经意识到进入数字生态系统的好处，并正在利用技术作为竞争优势。为了跟上市场变化的步伐，软件系统也需要改变。

实施了但从未使用的需求，或者那些仅用于识别的需求，无法满足用户的需求，导致浪费、返工和不满。无论你是采用 Scrum、瀑布式还是其他交付方法，良好的需求管理是软件项目成功的基石。

在 TFS 中，工作项用于记录和跟踪工作。流程（正式称为流程模板）用于协调交付框架术语和工作流。虽然 TFS 预装了 Scrum、敏捷和 CMMI 流程模板，但 TFS 支持自定义现有流程并创建新流程，以最佳方式满足团队的需求。TFS 中的计划和跟踪工具是基于 Web 的，这意味着你可以在任何平台和设备上访问它们。

我们先介绍一些关键概念，以更好地理解 TFS 中的计划和跟踪工具。本章中的所有实例都基于 Scrum 流程模板。

工作项：用于记录工作。TFS 为不同类型的工作提供不同类型的工作项。任务、产品待办事项、功能、缺陷、测试用例和反馈响应是 TFS 中可用的不同工作项类型之一。请参考 bit.ly/1WWDPuB 了解更多关于工作项的信息。
待办事项（Backlog）：这是按优先级排列的工作项列表。TFS 为不同的规划级别提供不同的待办事项。在本章中，您将学习到关于史诗（Epics）、功能（Features）和待办事项（Backlog Items）的内容。TFS 中的待办事项允许您添加新项、优先排序、可视化不同待办事项之间的关系，并查看现有待办事项的状态。现在，您可以配置是否让 BUG 显示在待办事项中。TFS 中的待办事项视图还包括团队速度和累计流量的图表。有关待办事项的更多信息，请参阅bit.ly/1RZT9Qw。
区域路径（Area Path）：这允许您为工作项添加分组维度。区域路径可以按团队、产品或功能区域对工作项进行分组。在团队项目中使用多个团队配置时，区域路径用于将工作项映射到一个团队。区域路径还支持按权限限制对工作项的访问。有关区域路径配置的更多信息，请参阅bit.ly/1j4baRr。
迭代路径（Iteration Path）：这允许您为工作项添加时间维度。迭代路径可以用于将工作项按冲刺、发布或其他事件特定的里程碑进行分组。有关迭代路径配置的更多信息，请参阅bit.ly/1NAbyQh。
看板（Kanban board）：这是一种通过交付工作流程可视化待办事项的方式。TFS 中的每个待办事项都带有一个看板。看板在规划和跟踪待办事项中的工作项时非常有用。
冲刺看板（Sprint board）：这是一种可视化分配给某个迭代的工作项的方式。冲刺看板可以按待办事项或人员进行可视化。现在可以配置冲刺看板来显示或隐藏 BUG。
过程（Process）：这定义了在团队项目中遵循的交付框架。工作项类型、状态、工作流、查询和报告都反映了该过程及其术语。有关 TFS 中可用的不同过程的更多信息，请参阅bit.ly/1Sy1v1D。

在本配方中，我们将使用 FabrikamTFVC 团队项目。如果您还没有 FabrikamTFVC 团队项目，请通过参考第一章中的使用 Scrum 模板创建团队项目配方来创建一个团队项目。

选择在团队门户上显示的待办事项级别

团队项目中的默认配置仅为每个团队提供两个待办事项级别。在 Scrum 模板中，这两个级别被称为功能（Features）和待办事项（Backlog Items）。

提示

史诗（Epics）是非常高层次的需求，代表着大量的工作。它们被拆解为功能（Features），并在多个冲刺中进行处理。根据bit.ly/1H5j1Kt，它们也是安全实现所需的。

在本示例中，您将学习如何从团队管理控制台激活史诗积压。

准备工作

要创建新的团队，您需要是项目管理员组的成员。要更改团队设置，您需要是团队管理员。如果您尚未拥有这些权限，请按照bit.ly/1MS1Xn9上的说明操作。

场景：FabrikamTFVC团队项目有两个团队，即 FabrikamFeature1 团队和默认的 FabrikamTFVC 团队。

FabrikamTFVC 团队：产品负责人、利益相关者和最终用户在史诗和特性积压上进行了大量协作。
FabrikamFeature1 团队：开发团队正在按照 FabrikamTFVC 团队优先级制定特性。

FabrikamTFVC 团队负责管理 Fabrikam 的史诗和特性工作项。FabrikamFeature1 团队负责处理由 FabrikamTFVC 团队分配给他们的特性工作项。FabrikamTFVC 团队只希望在其门户中看到两个层级的积压，即史诗和特性。FabrikamFeature1 团队希望在其门户中只看到一个层级的积压，即待办事项。

要创建 FabrikamFeature1 团队，请通过浏览到http://tfs2015:8080/tfs/DefaultCollection/FabrikamTFVC/_admin导航到 FabarikamTFVC 项目控制面板。点击新建团队按钮，输入团队名称为FabrikamFeature1 团队，然后点击创建团队按钮：

作为团队创建过程的一部分，创建了一个新的区域（FabrikamFeature1 团队），并映射到该团队。所有分配到区域路径 FabrikamFeature1 团队的工作项将显示在 FabrikamFeature1 团队的积压中。

操作步骤...

通过浏览http://tfs2015:8080/tfs/DefaultCollection/FabrikamTFVC/FabrikamTFVC%20Team/_admin导航到 FabrikamTFVC 团队控制面板。点击设置导航到团队设置页面：
在团队设置页面的积压部分，选中史诗并取消选择待办事项：
导航到 FabrikamFeature1 团队控制面板。在团队设置页面的积压部分，取消选择特性：
根据以下截图中显示的设置更新团队的积压视图。左侧的FabrikamTFVC团队只有史诗和特性的积压；FabrikamFeature1 团队只有待办事项的积压：

工作原理...

每个团队可以配置在团队门户中显示哪些积压。这使得团队可以专注于他们管理的积压，而不会被他们不使用的积压层级分散注意力。

还有更多内容...

团队设置页面还允许配置工作日。如果一个团队每周只工作 4 天，或者每周的星期一休息，而不是星期天休息，则可以通过更改工作日设置来进行配置。工作日用于计算团队的总容量，并在燃尽图中显示。这样做的目的是避免在燃尽图中显示团队的休息日，以免产生没有工作完成的错误印象。

Bug 工作项类型在积压项和看板上的行为也可以通过团队设置页面进行自定义：

Bug 在积压项和看板上的行为是可配置的，可以在积压项和看板上同时显示需求、在积压项和看板上同时显示任务，或者完全不出现在积压项和看板上。

这些设置都有强有力的论据；你可以在 bit.ly/1PL7SzD 找到一些优缺点。

映射、分配和跟踪多个团队共享的工作项

在一个团队项目中托管多个团队可以帮助你共享工作项、积压项以及其他工件，如代码、构建、测试和发布。在选择在团队门户上显示的积压级别这一食谱中，你学习了如何激活在团队门户上显示的积压级别。在这个食谱中，你将学习如何映射、分配和跟踪分配到多个团队的工作项。

准备工作

场景：FabrikamTFVC 团队项目有三个团队。FabrikamTFVC 团队专注于管理史诗和功能；另外两个团队负责管理他们所拥有的功能的产品积压项：

史诗 1 工作项被拆分为多个功能和产品积压项。FabrikamTFVC 团队希望在将这些工作项分配给不同的团队之前，先进行映射。FabrikamTFVC 团队希望跟踪各团队在史诗 1上的进展。

要设置这个场景，在 FabrikamTFVC 团队项目中创建一个新的团队 FabrikamFeature2 团队：

接下来，进入 FabrikamTFVC 团队门户并创建以下工作项：

工作项类型	标题	区域路径
史诗	史诗 1	FabrikamTFVC 团队
功能	功能 1	FabrikamTFVC 团队
功能	功能 2	FabrikamTFVC 团队
功能	功能 3	FabrikamTFVC 团队
产品积压项	产品积压项 1	FabrikamTFVC 团队
产品积压项	产品积压项 2	FabrikamTFVC 团队
产品积压项	产品积压项 3	FabrikamTFVC 团队

操作方法...

打开 FabrikamTFVC 团队的团队网页门户并导航到功能积压项。点击列选项图标，并将区域路径添加为选中的列：
切换父项开关为显示。所有孤立的功能（未关联到史诗类工作项的功能）将显示在名为未关联功能的标题下：
切换映射开关为开启：

将功能 1拖到史诗 1。这将把史诗 1映射为功能 1的父项。功能待办板会更新，以反映这一变化：

重新父化也可以通过拖放来完成。将功能 3拖到史诗 1下，以将其重新父化为史诗 1：

将功能 3 从未关联功能部分拖到史诗 1 史诗工作项下。

拖放也可以用于层次列表中，以重新排序项的优先级。在以下截图中，功能 1被拖动到最上方，表示它的优先级高于功能 2：

通过简单地拖放，功能 1可以被优先于功能 3。

现在，按准备工作部分所示，映射其他功能和产品待办事项。多选拖放也得到支持：

如准备工作部分所示，映射其他功能和产品待办事项。
将产品待办事项分配给FabrikamFeature1和FabrikamFeature2 Team，如准备工作部分所示。通过将区域路径更改为相应团队的区域路径，可以更改团队分配。
一旦待办事项的分配发生变化，未分配给 FabrikamTFVC 团队的工作项会在其前面显示一个空心矩形。这简化了跟踪团队拥有的和未拥有的项目：

它是如何工作的...

显示父项允许团队独立于工作项分配给哪个团队来跟踪工作项的完整层次结构。待办事项中的工作项，如果该团队没有拥有，前面会显示一个空心矩形。

总结来说，你学会了如何使用故事映射功能来映射工作项；这还有助于识别未关联的工作项。你还学会了如何在待办事项中拖放工作项，以重新排序待办事项中的工作项优先级。你学会了如何通过启用显示父项开关来查看工作项层级结构。最后但同样重要的是，你还学会了如何识别分配给不同团队的工作。

还有更多...

让我们来看看在待办事项视图中工具栏窗口中的一些有用选项：

新建：启动添加新工作项小部件。当你想将一个想法记录到待办事项中时，这非常有用。
展开全部：这将展开所有折叠的嵌套待办事项。
折叠全部：这将折叠所有展开的嵌套待办事项。
创建查询：通过复制用于生成此操作触发的待办事项视图的查询来创建新的工作项查询。
列选项：用于在待办事项视图中添加或移除列。此设置是针对每个用户的，您所做的更改不会影响其他用户的视图。
电子邮件：此选项会将您在待办事项中看到的视图通过电子邮件发送给您。如果您过滤了项，然后点击电子邮件，它只会显示过滤后的视图中的电子邮件。
筛选器：此文本框可在待办事项视图中进行文本搜索。这对于通过搜索关键字来缩小待办事项项的范围非常有用。

注意

TFS 2015 Update 1 提供了对多选拖放分配、重新排序、重新归类、多重编辑、移动到迭代和移动到位置的支持。

向看板添加额外的列

TFS 中的看板提供了待办事项的可视化表示。该看板可以根据贵组织中使用的交付工作流进行建模。在本教程中，您将学习如何向看板中添加额外的列并配置工作流。

提示

"Kanban"（看板）这个名称源自日语，粗略翻译为“告示牌”或“广告牌”。在软件开发的背景下，看板可以指一种可视化的过程管理系统，告诉你该生产什么、何时生产以及生产多少量（bit.ly/1j4bT57）。

准备工作

您需要是团队管理员或团队项目管理员组的成员，才能自定义看板。

场景：FabrikamFeature1 团队为每个待办事项使用开发、测试和发布工作流，然后标记为完成。团队为周期中的每个阶段设有退出标准。FabrikamFeature1 团队的测试能力有限。为了限制测试中的项，已为开发中的项设置了限制：

如何操作...

通过浏览到FabrikamFeature1 Team门户并点击待办事项项待办事项中的看板，导航到 FabrikamFeature1 团队的看板：
点击页面右上角的齿轮图标。此图标用于启动设置窗口。齿轮图标左侧的图标是搜索图标，可以用于在待办事项中执行文本搜索。齿轮图标右侧的图标用于将看板视图最大化为全屏模式：
在设置窗口中，从看板部分选择列。这将显示现有列的配置。可以为Bug和产品待办事项项（这些是需求类别中的默认工作项类型）配置设置：

通过使用设置窗口添加新列来配置看板
点击绿色加号图标添加新列。将列命名为精化，设置 WIP 限制为20并将列拆分为进行中和完成。将此列映射到工作项状态已批准。添加完成定义，如下图所示（完成文本框中写入的文本可以使用 Markdown 格式化）：
将已批准列重命名为开发，将状态映射更改为已承诺，将 WIP 限制设置为3，勾选将列拆分为进行中和完成复选框，并添加完成定义，如下图所示：
将已批准列重命名为测试，设置 WIP 限制为2，保持工作项状态为已承诺，勾选拆分列为进行中/已完成，并添加完成定义。
点击绿色加号图标添加新列。将列命名为发布，设置 WIP 限制为5，不将列拆分为进行中和完成。将此列映射到工作项状态已承诺。添加完成定义。点击保存并关闭返回到待办事项看板。
看板板现在已经配置为 FabrikamFeature1 团队用于交付其产品待办事项的交付工作流：

它是如何工作的...

看板板可以在团队级别进行配置，这使团队能够定义并遵循最适合他们的流程。每个待办事项列表可以配置一个看板板。因此，如果团队有史诗、功能和待办事项，则团队将有三个看板板，可以自定义并用于管理工作。

传统上，流程需要自定义以在工作项中添加额外的状态。2013 年，产品中引入了一种新的扩展性模型——WIT 扩展。WIT 扩展允许创建新的工作项字段，并将其关联到工作项状态，而无需对工作项进行任何自定义。有关 WIT 扩展如何在运行时动态更新工作项定义的更多信息，请访问bit.ly/1N7FAAt。

在我们在此配方中所涉及的场景中，Dev、Test和Release字段都与已承诺状态相关联。当工作项从Approved转换为Committed时，它会出现在Dev / Doing列中。负责该工作项的人员可以在更改完成且符合完成定义后，将工作项提升到Dev / Done列。工作项的状态将继续显示为Committed。当负责测试的人员准备好测试更改时，工作项可以拉入Test / Doing列。工作项的状态将继续显示为Committed。当更改经过测试并符合完成定义时，可以将工作项提升到Test / Done列。工作项的状态将继续显示为Committed。一旦团队准备好安排发布，工作项可以拉入Release列。工作项的状态将继续显示为Committed。

一旦更改成功发布，工作项可以移至Done列。这将更新工作项的状态，从Committed变为Done：

工作项状态转换历史

工作项字段转换历史，显示从 Dev\Done 列到 Test\Doing 列的转换

将列拆分为Doing和Done可以更好地展示工作的进展。看板上的工作项字段用于生成累积流图。该图提供了每列花费时间的可视化表示。这对于识别价值流动和交付过程中的潜在瓶颈非常有用：

累积流图

注意

累积流图上的日全食可以用来定制图表的开始日期。

看板还让你监控在制品（WIP）的数量。例如，如果Test列中的在制品数量超过 3 个限制，WIP 会变成红色，表示违反限制。

点击列名旁的信息图标可以显示完成定义，如下图所示：

点击信息图标显示完成定义

看板还支持折叠New和Done列。看板也可以最大化为全屏视图。

还有更多...

任务可以直接从看板中添加到产品待办事项中。看板还会显示工作项卡上的已完成任务数与总任务数的对比：

可以直接从产品待办事项卡片中添加任务到看板。

看板还支持横向泳道。最常见的用法是创建“加急泳道”，用于紧急工作，可以跳过队列并抢先处理其他工作。泳道可以从设置窗口配置；可以通过点击看板上的齿轮图标来启动设置窗口：

配置窗口允许配置泳道的顺序。在此情况下，加急泳道会显示在默认泳道上方。泳道可以折叠。工作项可以在泳道之间移动，泳道的移动也会在工作项历史记录中进行跟踪。

在 TFS 2015 Update 1 中，新增了三个字段：Board Column、Board Column Done 和 Board Lane，用于在看板上查询工作项。以下截图演示了如何查询 FabrikamFeature 1 团队看板上默认泳道中的所有工作项，且这些工作项被分配到测试 / 进行中列：

看板列现在可以进行查询、图表分析和提醒。有关使用案例和设置操作指南，请参考bit.ly/1MS3QA8。

自定义显示在看板上的卡片

看板有助于可视化、跟踪和共享待办项的进展。另一方面，冲刺看板帮助可视化、跟踪和共享团队在冲刺中的进展。Web 门户中的这两个看板都是有用的信息发布器，有助于工作计划和跟踪。工作项以卡片形式显示在看板上。在 TFS 2015 及 Update 1 版本中，看板新增了多个功能，使得卡片更加可操作。在本指南中，您将学习如何自定义卡片，显示附加的工作项字段，并根据规则对卡片进行样式化。

准备工作

您需要是团队管理员或团队项目管理员组的成员，才能自定义团队设置。

本指南中的场景：FabrikamFeature1 团队希望在所有待办项卡片上显示工作项 ID、标签、创建者、工作量、优先级和价值领域字段。该团队仅希望在 Bug 卡片上显示创建者、分配给和标识于字段。该团队希望所有优先级为 1 的项目卡片使用粗体标题和灰色背景。

如何操作...

在 FabrikamFeature1 团队门户中，通过浏览https://tfs2015:8080/tfs/FabrikamTFVC/FabrikamFeature1%20Team/_backlogs/board/Backlog%20items进入待办事项视图。
导航到看板视图并点击齿轮图标以启动设置窗口。在设置窗口中，从卡片部分选择字段。
在产品待办项标签页中，勾选所有核心字段：
从附加字段中添加价值领域、创建者和优先级字段：
默认情况下，如果工作项卡片中的字段没有值，则该字段会被隐藏。你可以选择通过勾选显示空字段复选框来更改此行为：
切换到Bug标签页，并选择所有核心字段。在附加字段中，添加识别于字段。
在设置窗口中，从卡片部分下选择样式。添加一个新的样式规则，并将规则命名为Priority 1。将卡片颜色更改为灰色，并将卡片标题设置为粗体。在规则标准中，设置规则标准为priority = 1。一个规则标准中可以添加多个字段：

注意

请注意，每个看板和冲刺板的样式规则可以单独配置。
点击保存并关闭。看板中的工作项将刷新，并根据规则显示额外的工作项字段和样式。样式规则使得包含重要信息的卡片更为突出。当一个工作项符合多个规则时，将使用第一个规则。

卡片上的所有工作项字段可以直接在卡片内更新，这使得卡片更加具有操作性。

设置团队的容量和活动以进行一个冲刺

在本章前面的配方中，你了解了产品待办事项。如果产品待办事项是工作的需求，那么冲刺待办事项则是完成这些工作的计划。为了规划冲刺的工作，团队需要了解总的可用容量。直到 TFS 2015，团队容量功能仅限于每个成员每个冲刺一个活动。在本配方中，你将学习如何为每个团队成员在冲刺中输入多个活动和容量。

准备工作

场景：FabrikamFeature1 团队将在明天开始为期两周的下一次冲刺。团队由八名成员组成，其中几位成员在此期间有计划的假期。团队希望了解本次冲刺的总可用容量。

要添加一个新的冲刺并配置冲刺的开始和结束日期，请通过浏览http://tfs2015:8080/DefaultCollection/FabrikamTFVC/FabrikamFeature1%20Team/_admin导航到 FabrikamFeature1 团队的控制面板，并切换到迭代标签页。点击新建子项按钮，在 FabrikamTFVC 下添加一个新的迭代；双击该迭代以设置日期：

如何操作...

通过浏览http://tfs2015:8080/DefaultCollection/FabrikamTFVC/FabrikamFeature1%20Team/_backlogs，导航到 FabrikamFeature1 团队工作中心。新添加的冲刺将在此页面的左侧显示。点击Sprint 1并转到容量标签页：
点击添加缺失的团队成员图标（如图中所示），以添加所有缺失的团队成员：
设置活动和每天的小时数，如以下截图所示。使用行末的省略号为个人添加多个活动：
John 在本次冲刺中无法参与团队工作。通过点击行末的省略号并在上下文菜单中选择删除该用户，将 John 从列表中删除：
点击团队休假日旁边的日期超链接，以更新团队的休假日，如以下截图所示：

个人的休假天数可以通过点击休假日列中的日期超链接来更新，这有助于使团队容量更加准确。
点击保存图标保存团队的容量。团队的总容量、按活动划分的团队容量和每个团队成员的容量会在工作详情面板中更新。

如何操作...

在选择在团队门户上显示的待办事项层级的教程中，你了解到团队的工作日是通过团队设置窗口进行配置的。团队的工作日用于推算冲刺的总工作小时数。任何团队或个人的休假天数都会从总工作小时数中扣除；这有助于我们得出团队在冲刺中的可用容量。在工作详情部分，活动和个人会影响团队容量。

团队容量在规划冲刺活动时非常有用；在跟踪进度和在团队成员之间平衡工作时同样有用。要查看工作详情面板的操作，拖动产品待办事项 1到冲刺 1。使用产品待办事项旁边的+符号创建一些任务，如以下截图所示：

现在，切换到冲刺板，并通过更改卡片上的分配给字段将这些任务分配给团队成员。你可以选择性地将冲刺板上的按人分组字段从待办事项改为人员，这有助于你按个人查看任务分配。现在，切换回待办事项视图；工作详情部分会更新，反映出按活动和个人的工作分配情况：

任务可以直接分配给工作分配面板中的个人。如以下截图所示，PBI 1 – 任务 2被通过拖动任务到 Chris 的工作分配面板中，分配给了 Chris：

当团队、活动或个人分配的工作超过可用容量时，工作分配面板中的容量条会变红。

还有更多...

Sprint 燃尽图帮助你识别冲刺中的工作完成趋势，并展示冲刺中剩余的工作量。Web Portal 中的 Sprint 燃尽图还显示了可用的工作容量和理想燃尽量。关于 Sprint 燃尽图的更多信息可以参考bit.ly/1MiMTlm。

速度代表团队在一次冲刺中完成的总工作量。一旦团队完成了几个冲刺，你就可以开始看到已完成工作的趋势。这些数据对于预测未来冲刺的工作量非常有用。关于速度计算的更多信息可以参考bit.ly/1H5nkoU。

通过标签查询工作项

工作项标签是将关键词与工作项关联的好方法。这些关键词作为元数据帮助你对工作项进行分组、搜索和过滤。在本教程中，你将学习如何通过标签查询工作项。

Getting ready

所有项目有效用户组成员都有权限创建标签。利益相关者的访问级别不允许创建标签。利益相关者只能使用已有标签标记工作项。

场景：FabrikamTFVC 团队有一个功能待办事项列表，他们希望通过发布预计将要发布的功能来进行标记。尚未审核的功能需要标记为Pending Review。产品负责人希望创建一个工作项查询，查询标签为发布版本 1（排除任何标记为阻塞的工作项）的工作项，并将查询结果与利益相关者共享。

可以通过打开工作项表单并点击添加图标来为工作项添加标签。从列表中选择现有标签或添加新标签：

在 FabrikamTFVC 功能待办事项中，将需要在版本 1 中发布的功能标记为R1，版本 2 中发布的功能标记为R2，尚未审核的功能标记为Pending Review：

将需要在版本 1 中发布的功能标记为 R1，版本 2 中发布的功能标记为 R2，尚未审核的功能标记为 Pending Review。

How to do it...

若要查看预计将在R1中发布的工作项，请导航到 FabrikamTFVC 团队门户中的功能待办事项。点击漏斗按钮加载标签工具栏；标签工具栏按计数显示标签列表：
点击R1，筛选出标记为 R1 的功能待办事项。其中一个标记为R1的项目也被标记为Blocked。点击All以移除标签筛选条件：
从工作中心导航到查询页面。点击New图标，从下拉菜单中选择新查询。在查询编辑窗口中，添加一个标签的过滤条件，如下图所示：
如果你希望在不保存查询的情况下复制此查询的 URL，可以点击复制查询 URL按钮：
从弹出窗口按Ctrl + C复制。将此 URL 通过电子邮件发送给利益相关者。该 URL 将直接显示工作项结果。该临时 URL 将在 90 天后自动过期：

还有更多...

看板板块支持通过标签进行样式设置。此自定义可以在待办视图中的团队设置窗口中进行。若为一个标签指定了多个样式规则，则第一个匹配规则优先。在下面的截图中，标签R1已设置为黄色：

使用工作项查询创建图表

工作项查询（WIQ）提供了根据具体需求筛选工作项的方法。WIQ 使用一种名为工作项查询语言（WIQL）的自定义语言；该语言的复杂性被隐藏在工作项查询编辑器之后。WIQ 返回工作项列表，有时你可能需要可视化工具来分析结果。数据可视化工具有助于发现那些可能被忽略的趋势。团队门户中的轻量级图表功能允许你使用 WIQ 创建图表。在这个教程中，你将学习如何使用 WIQ 创建并共享图表。

准备开始

利益相关者访问级别不允许创建图表。需要基础或高级访问级别才能创建图表。

场景：FabrikamFeature1 团队希望追踪过去 12 周应用程序中未解决的 BUG 趋势。

以下截图展示了如何使用筛选条件创建新的 WIQ。点击列选项图标，将状态列包含在查询结果中：

将查询保存为FabrikamFeature1 Bugs - Open并存入我的查询文件夹：

如何操作...

在查询页面，打开FabrikamFeature1 Bugs - Open查询并点击图表标签：
点击+图标以启动新图表窗口，从趋势部分选择区域，并将图表命名为Feature1 Bugs 12 Weeks - Trend。将范围更改为 12 周：
你可以通过点击图表并从颜色选择器中选择颜色来编辑图表的颜色。点击图表并选择红色。点击确定关闭：
新图表已加载到图表标签中：
如果你点击图表右上角的日蚀图标，你将看到编辑或删除图表的选项。为了与团队分享图表，首先需要共享基础的工作项查询。将工作项查询从我的查询拖动到共享查询文件夹中：

将工作项查询从“我的查询”拖动到“共享查询”
现在图表中的“日食”图标让你可以将图表分享至某个仪表板。选择技术债务仪表板（仪表板可以自定义；请参考第一章中的配置团队项目仪表板配方，团队项目设置）：
图表被添加到技术债务仪表板：

它是如何工作的……

在 Web 门户中可以创建两种类型的图表：快照图表和趋势图表。快照图表只是将工作项查询的结果表示在图表上。趋势图表使用 TFS 中的数据，计算所选时间段内的查询结果。趋势图表可以显示最多过去一年的趋势。

图表是使用事务数据库中的工作项数据计算得出的。当工作项更新时，图表会立即反映更新。只有平面工作项查询可以用于创建图表。如果你尝试使用其他查询类型创建图表，将显示以下警告消息：

使用服务钩子集成 Trello 看板

传统上，依赖于 TFS 数据的应用程序会不断轮询 TFS 以检查更新。服务钩子是 TFS 2015 中引入的新功能，提供了将 TFS 中的事件级联到另一个应用程序的方式。当一个应用程序在 TFS 中注册事件通知时，会在 TFS 与该应用程序之间创建一个安全队列。当该应用程序注册的事件在 TFS 中发生时，它会立即发布到应用程序。这消除了应用程序需要轮询 TFS 以检查更新的需求。

如果你不熟悉 Trello，它是一个非常棒的基于 Web 的工具，帮助你设置几乎所有任务的看板。许多组织使用 Trello 看板进行产品规划。你可以在 trello.com 了解更多关于 Trello 的信息。

在本配方中，你将学习如何创建一个服务钩子，将来自 TFS 团队门户的新功能工作项安全发布到 Trello 的看板上。

准备工作

权限：要配置服务钩子，你需要是团队项目管理员组的成员。

在接下来的几步中，我们将配置一个 Trello 看板，用于后续发布数据：

通过浏览 trello.com/signup 进入 Trello 注册页面。输入你的详细信息并点击创建新账户按钮。
使用你的帐户登录 Trello，并创建一个新团队。将团队命名为 Fabrikam：
创建一个新的看板并命名为 Feature Tracker：

点击“看板”以创建 Fabrikam 团队的新看板，并将看板命名为 Feature Tracker
导航至Feature Tracker看板，添加待办事项、进行中和已完成列表：

如何操作…

通过浏览http://tfs2015:8080/tfs/DefaultCollection/FabrikamTFVC/_admin/_servicehooks导航到 FabrikamTFVC 服务钩子，进入团队管理控制台：

为项目创建第一个订阅
点击为该项目创建第一个订阅超链接，并从新订阅窗口中选择Trello。点击下一步以进入触发器窗口。
在触发器窗口中，将选择更改为工作项创建事件，设置区域路径为FabrikamTFVC，工作项类型为功能。点击下一步：
在设置窗口中，选择立即获取超链接以获取授权令牌。该令牌由 Trello 发放，允许 TFS 访问你的 Trello 看板：
点击登录并使用 Trello 登录信息进行身份验证：
复制 Trello 发放的授权令牌：
在服务钩子触发器配置窗口中，输入如下截图所示的详细信息：
点击测试以使用配置触发测试：
点击完成以完成配置。
要尝试 TFS 和 Trello 之间的集成，浏览http://tfs2015:8080/tfs/DefaultCollection/FabrikamTFVC/_backlogs#level=Features导航到 TFVC 功能待办事项。向待办事项中添加一个新功能，如下截图所示：
现在，导航到 Trello 看板。此功能也已在 Trello 中的Feature Tracker看板中创建：

如何运作…

当 TFS 中发生事件时，项目中所有启用的订阅都会被评估。对于所有匹配的订阅，都会执行消费者动作。在这种情况下，Trello 的订阅被执行，结果是在 Feature Tracker 看板的待办事项列表中生成一张新卡片。

团队管理控制台中的服务钩子配置屏幕显示了 14 天内每个订阅的流量情况：

服务钩子配置窗口允许你配置卡片标题和描述的格式。向导支持占位符表达式。在以下截图中，卡片标题被配置为工作项类型 #工作项编号: 工作项标题格式：

使用服务钩子将数据从 TFS 发布到其他系统时，有一点非常重要，那就是 TFS 权限不会级联到其他系统。例如，FabrikamTFVC 团队有四个成员；但是，如果 Trello 看板是公开的，那么工作项卡片将对任何人可见。

还有更多…

TFS 还提供了其他的服务钩子。可以在bit.ly/1l0OZgi找到支持的服务钩子完整列表。

永久删除 TFS 中的工作项

工作项用于在 TFS 中捕获、规划和跟踪工作。工作项中的历史标签提供了对该工作项所做更改的完整审计跟踪。创建一个后续决定不再需要的工作项是常见的做法。可以通过将工作项状态更改为 已移除，从待办事项中排除该工作项；但是，工作项并未被删除。目前，用户界面中没有永久删除工作项的功能。在本食谱中，您将学习如何使用 witadmin 命令行工具永久删除工作项及其所有历史记录。

提示

使用witadmin命令删除工作项会将工作项永久从 TFS 数据库中移除，无法恢复或重新激活。

准备工作

要使用 witadmin 命令删除工作项，您需要是该集合中项目管理员组或团队基础管理员组的成员。

如何操作…

以提升权限打开 Visual Studio 开发人员命令提示符并运行以下命令。导航至 Common7\IDE 文件夹：

运行以下命令以永久删除工作项 ID：15、16 和 17：

witadmin destroywi /collection:http://tfs2015:8080/tfs/DefaultCollection /id:15,16,17

当提示时，按 Y 以确认此操作不可恢复：

工作原理…

witadmin命令行工具集包含一系列命令和开关，允许您在团队项目中导入、导出和管理工作项。在本食谱中，我们使用了detroywi命令，它会永久删除命令中指定的工作项。

由于工作项 ID 在整个集合中是唯一的，因此无需提供团队项目名称；/collection开关用于指定工作项所属的团队基础集合。/id开关用于指定一个或多个工作项 ID。/noprompt开关可以选择性地用于禁用确认提示。

使用 Microsoft Feedback Client 提供反馈

与利益相关者保持持续的反馈循环有助于软件开发团队生产更好的软件。有时，来自利益相关者的反馈会丢失，因为它是口头的，或者根本没有被跟踪。开发团队与利益相关者之间的反馈循环可以通过使用简化反馈捕捉和跟踪的工具来改进。在本食谱中，您将学习如何使用 Microsoft Feedback Client 提供反馈。

准备工作

本食谱要求您安装 Microsoft Feedback Client。可以从bit.ly/1H5osc8下载独立安装程序。

提示

提交反馈不需要许可证。由于 TFS 中没有匿名用户的概念，反馈只能从 TFS 中已设置的用户请求。所有拥有相关权限的利益相关者可以通过响应反馈请求或选择性地通过 Microsoft Feedback Client 提交反馈。不过，请求反馈和查看已提交的反馈需要高级许可证。

在接下来的几个步骤中，您将学习如何从团队 Web 门户中提出反馈请求：

转到 FabrikamFeature1 团队的 Web 门户。在“其他链接”部分，点击请求反馈：

注意

如果您看不到请求反馈超链接，说明您的访问类型设置不正确。请将自己添加到高级访问类型中。
这将启动反馈请求窗口。反馈请求表单包括一个部分，用于提供有关如何启动应用程序的信息，一个部分，用于指定反馈应关注的内容，最后但同样重要的，是一个部分，用于指定您希望征求反馈的用户列表。按照以下截图所示填写反馈请求表单。
输入您希望请求反馈的人员的姓名：

注意

您不能请求没有 TFS 访问权限的用户提供反馈。
指定用户如何访问应用程序。可用的选择有Web 应用程序、远程机器和客户端应用程序。这将生成一个可操作的链接，用户可以点击该链接直接从反馈请求启动应用程序：
通过指定您希望收到反馈的区域来提供方向。可以通过点击添加反馈项超链接添加多个反馈项：
点击预览图标以预览反馈请求：
点击发送后，反馈请求将发送给 John 和 Tom。

如何做...

利益相关者收到反馈请求电子邮件。可以通过点击电子邮件中的开始反馈会话超链接来启动反馈会话。当会话开始时，您会注意到反馈请求表单中填写的说明会加载到反馈会话中：
Microsoft 反馈客户端允许屏幕和语音录制，并且在反馈捕获过程中可以包含截图和附件，以及评论：
也可以在反馈响应中添加总体评分：
一旦反馈响应完成，团队门户中的反馈响应瓷砖将反映这一变化：

反馈响应

它是如何工作的...

反馈响应记录在工作项中。如下面的截图所示，工作项包含了通过 Microsoft Feedback Client 捕获的所有详细信息。作为工作项的反馈响应，能为你提供工作项的所有优势。我们已经在本章中介绍了其中的一些功能，例如跟踪、标记、固定、仪表板和报告：

反馈响应记录在工作项中。工作项的状态部分显示了反馈项的创建者、分配对象、状态和总体评分。

第四章：构建你的应用程序

	"用代码行数来衡量编程进度，就像用飞机的重量来衡量建造进度一样。"
	--比尔·盖茨

TFS 在 TFS 2015 中推出了一种新的构建系统，叫做 TFBuild。在本章中，你将学习以下内容：

配置 TFBuild 代理、池和队列
使用无人值守安装设置 TFBuild 代理
在 TFBuild 中创建持续集成构建定义
将构建徽章固定到团队门户的欢迎页面
使用基于角色的访问管理构建资源
使用构建保留策略自动删除构建
使用用户能力识别池中的构建代理
在构建输出中使用构建号版本化 DLL
使用 TFBuild 扩展框架创建新构建任务
将 SonarQube 与 TFBuild 集成以管理技术债务
使用 TFBuild 构建 GitHub 代码库

介绍

作为开发人员，编译代码并运行单元测试可以确保你的代码更改不会影响现有的代码库。将代码更改集成到源代码控制库中，能够让其他用户验证他们的更改是否与你的更改兼容。作为最佳实践，团队通常每天将更改多次集成到共享库中，以减少引入破坏性更改或更糟糕的情况——互相覆盖的风险。

提示

持续集成（CI）是一种开发实践，要求开发人员每天多次将代码集成到共享的代码库中。每次提交都会通过自动构建进行验证，从而帮助团队及早发现问题。

作为 CI 过程的一部分运行的自动化构建通常被称为 CI 构建。关于 CI 构建应该做什么并没有明确的定义，但最基本的要求是编译代码并运行单元测试。在非开发者的远程工作区上运行 CI 构建，有助于发现那些可能被忽视的依赖关系，避免它们进入发布流程。我们可以无休止地讨论 CI 的好处；关键是它使你能够随时拥有潜在的可部署软件。

提示

可部署的软件是客户最为看重的实际资产。

从概念到应用，在本章中，你将学习如何利用 TFS 中的构建工具来设置一个以质量为中心的持续集成（CI）过程。但首先，让我们简单了解一下 TFS 中的构建系统。下图展示了 TFS 中构建系统的三代演变：

TFS 经历了三代构建系统。最初的是使用 XML 配置的 MSBuild；接下来是使用 Windows Workflow Foundation 配置的 XAML；现在是使用 JSON 配置的 TFBuild。基于 XAML 的构建系统将在 TFS 2015 中继续得到支持。XAML 构建系统无法自动迁移到 TFBuild，这通常是因为这两种构建系统架构的差异。

TFS 中的新构建系统称为 Team Foundation Build（TFBuild）。它是一个可扩展的基于任务的执行系统，具有丰富的 web 界面，允许创建、排队和监视构建。TFBuild 完全支持跨平台，底层构建代理能够在 Windows 和非 Windows 平台上原生运行。TFBuild 提供开箱即用的集成，支持集中版本控制（如 TFVC）以及分布式版本控制（如 Git 和 GitHub）。TFBuild 支持构建 .NET、Java、Android 和 iOS 应用程序。本章中的所有示例都基于 TFBuild。

TFBuild 是一个任务协调器，允许你运行任何构建引擎，如 Ant、CMake、Gradle、Gulp、Grunt、Maven、MSBuild、Visual Studio、Xamarin、XCode 等。TFBuild 支持工作项集成、发布构建产物和将测试执行结果发布到 TFS，与所选择的构建引擎无关。构建代理是可直接复制的，无需任何安装。代理会自动更新，因此无需更新基础设施中的每个代理：

TFBuild 提供了丰富的基于 web 的界面。它不需要 Visual Studio 来创建或修改构建定义。从简单到复杂，所有构建定义都可以轻松地在 web 门户中创建。该 web 界面可以在任何设备和任何平台上访问：

可以直接从 web 门户编写构建定义

构建定义是任务的集合。一个任务就是一个构建步骤。构建定义可以通过拖放任务来组成。每个任务都支持启用、遇到错误继续执行 和 始终运行 标志，使得随着任务列表的增长，构建定义的管理变得更加容易：

构建系统支持调用 PowerShell、批处理、命令行和 shell 脚本。所有开箱即用的任务都是开源的。如果某个任务不满足你的需求，你可以从 GitHub 下载该任务：github.com/Microsoft/vso-agent-tasks 并进行自定义。如果你找不到某个任务，你也可以轻松创建一个。在本章中，你将了解更多关于自定义任务的内容。

构建定义的更改可以保存为草稿。构建定义在历史标签中保持所有更改的历史记录。还可以进行更改的并排对比。更改构建定义时输入的评论会显示在更改历史记录中：

构建定义可以保存为模板。这有助于在新的构建定义中标准化某些任务的使用：

现有的构建定义可以保存为模板

同一个构建可以设置多个触发器，包括 CI 触发器和多个定时触发器：

基于规则的保留策略支持设置多个规则。保留可以按“天”或“构建数量”来指定：

构建输出日志会在 Web 门户中实时显示。即使构建完成后，构建日志也可以从控制台访问：

构建报告经过改版，提供了更多关于构建执行的可见性，除此之外，测试结果现在可以直接从 Web 界面访问。.trx文件不需要下载到 Visual Studio 中查看测试结果。我们将在第五章，测试你的应用程序中详细介绍这一点：

旧的构建系统对每个构建控制器的团队项目集和每台构建机器的控制器有限制。TFBuild 取消了这一限制，支持在多个团队项目集之间重用队列。以下图示展示了新构建系统的架构：

在前面的图中，我们观察到以下内容：

可以在一台机器上配置多个代理
来自不同机器的代理可以被分组到一个池中
每个池只能有一个队列
同一个队列可以在多个团队项目集之间共享

为了演示 TFBuild 的功能，我们将使用 FabrikamTFVC 和 FabrikamGit 团队项目。如果你还没有这些团队项目，可以按照第一章，创建一个使用 Scrum 模板的团队项目的食谱操作。

配置 TFBuild 代理、池和队列

在本食谱中，你将学习如何配置代理并创建池和队列。你还将学习如何在多个团队项目集之间使用队列。

准备工作

场景：在 Fabrikam，FabrikamTFVC 和 FabrikamGit 团队项目需要各自的构建队列。FabrikamTFVC 团队的构建过程可以在 Windows 服务器上执行，而 FabrikamGit 团队的构建过程需要同时支持 Windows 和 OS X。团队希望在 Windows 服务器上设置三个构建代理，在 OS X 机器上设置一个构建代理。团队还希望将两个 Windows 代理分组到一个 Windows 池中，供 FabrikamTFVC 团队使用，并将一个 Windows 代理和一个 Mac 代理分组到另一个池中，供 FabrikamGit 团队使用：

权限：要配置构建代理，您应该属于构建管理员组。

在 Windows 系统上设置构建代理的前提条件如下：

构建代理应安装支持的 Windows 版本。支持的版本列表可以在 msdn.microsoft.com/en-us/Library/vs/alm/TFS/administer/requirements#Operatingsystems 中找到。
构建代理应安装 Visual Studio 2013 或 2015。
构建代理应安装 PowerShell 3 或更高版本。

如果您选择保留 Configure the build service to start automatically 选项，构建代理将在 TFS 服务器安装过程中为您配置：

在本例中，我们将从头开始配置代理。通过导航到 TFS 管理控制台中的 Agent pools 选项 http://tfs2015:8080/tfs/_admin/_AgentPool 来删除默认池或您创建的任何其他池：

如何操作

登录到您希望设置代理的 Windows 机器。通过浏览器访问http://tfs2015:8080/tfs/_admin/_AgentPool，在 TFS 管理控制台中导航到 Agent pools。点击 New Pool，将池名称设置为 Pool 1，并取消勾选 Auto-Provision Queue in Project Collections：
点击 Download agent 图标。将下载的文件夹复制到 E:\ 并解压到 E:\Win-A1。您可以使用任何驱动器，但建议使用非操作系统驱动器：
以管理员身份运行 PowerShell 控制台，并将当前路径更改为代理所在的位置，这里是 E:\Win-A1。在 PowerShell 控制台中调用 ConfigureAgent.ps1 脚本并按 Enter 键。这将启动构建代理配置工具：
按照以下截图所示输入配置详细信息：

提示

建议将构建代理安装为服务；但您也可以选择将代理作为交互式进程运行。如果您想调试构建或临时将机器用作构建代理，这个选项非常有用。

配置过程会创建一个 JSON 设置文件，并创建工作和诊断文件夹：
在 TFS 管理控制台中刷新代理池页面，新的配置代理将在池 1下显示：
重复步骤 2 到 5 以在池 1中配置Win-A2。重复步骤 1 到 5 以在池 2中配置Win-A3。值得注意的是，每个代理都从各自的文件夹中运行：
现在，登录到 Mac 机器并启动终端：
通过运行这里显示的命令来全局安装代理安装程序。你将需要输入机器密码以授权安装：

这将在用户配置文件中下载代理，如下所示：

下载代理时执行的操作摘要
运行以下命令以在用户配置文件中全局安装代理安装程序：
运行以下命令将为代理创建一个名为osx-A1的新目录；在该目录中创建代理：
代理安装程序已从用户配置文件复制到代理目录，如下所示：
传递以下显示的参数以配置代理：
这完成了在 Mac 上配置 xPlatform 代理的过程。在 TFS 管理控制台中刷新代理池页面，查看代理是否出现在池 2中：
构建代理已在团队基础服务器级别进行配置。为了将构建代理用于团队项目集合，必须在构建代理和团队项目集合之间建立映射。这是通过创建队列来完成的。要配置队列，请通过访问http://tfs2015:8080/tfs/DefaultCollection/_admin/_BuildQueue，导航到集合管理控制台。在构建选项卡中，点击新建队列；此对话框允许你将池作为队列引用：
将池 1映射为队列 1，将池 2映射为队列 2，如下所示：
现在，TFBuild 代理、池和队列已经准备好使用。管理控制台中代理名称和队列前面的绿色条表示代理和队列处于在线状态。

它是如何工作的...

要测试该设置，请通过访问http://tfs2015:8080/tfs/DefaultCollection/FabrikamTFVC/_build，导航到 FabrikamTFVC 团队项目构建中心，创建一个新的构建定义。点击添加新建构建定义图标。在常规选项卡中，你会看到队列出现在队列下拉菜单中。这确认队列已正确配置，并可以在构建定义中进行选择：

池可以跨多个团队项目集合使用。如以下截图所示，在团队项目集合 2 中，点击 新队列... 会显示现有的池已经在默认集合中映射：

使用无人值守安装设置 TFBuild 代理

新的构建框架允许通过脚本注入一组参数值来无人值守地设置构建代理。此技术可用于启动新的代理，并将其附加到现有的代理池中。在本配方中，您将学习如何通过脚本配置和卸载构建代理。

准备工作

场景：FabrikamTFVC 团队希望能够通过脚本直接安装、配置和卸载构建代理，而无需通过团队门户进行此操作。

权限：要配置构建代理，您需要属于构建管理员组（Build Administrators Group）。

按照之前的配方 配置 TFBuild 代理、池和队列 下载构建代理。将该文件夹复制到E:\Agent。脚本会引用这个Agent文件夹。

如何操作...

以提升权限模式启动 PowerShell，并执行以下命令：

.\Agent\VsoAgent.exe /Configure /RunningAsService /ServerUrl:"http://tfs2015:8080/tfs" /WindowsServiceLogonAccount:svc_build /WindowsServiceLogonPassword:xxxxx /Name:WinA-10 /PoolName:"Pool 1" /WorkFolder:"E:\Agent\_work" /StartMode:Automatic

提示

请相应地替换用户名和密码的值。

执行脚本将产生以下输出：

该脚本通过名称为WinA-10的代理作为 Windows 服务运行，服务帐户为svc_build。该代理被添加到Pool 1：
要卸载WinA-10，请在提升权限的 PowerShell 提示符下运行以下命令：
```
.\Agent\VsoAgent.exe /Unconfigure "vsoagent.tfs2015.WinA-10"
```
提示

要卸载，脚本需要从Agent文件夹的范围之外执行。从Agent文件夹范围内运行脚本将导致错误信息。

工作原理...

新的构建代理本身支持通过脚本进行配置。未来的 TFS 2015 更新将发布一种新的功能，称为个人访问令牌（PAT）。PAT 允许您为特定范围生成个人 OAuth 令牌；它取代了将密码输入配置文件的需求。

在 TFBuild 中创建一个持续集成构建定义

在本配方中，您将学习如何编写一个持续集成构建定义。

准备工作

场景：FabrikamTFVC 团队希望设置一个在每次代码提交时执行的构建定义。团队希望使用Pool 1来运行此构建定义，该池已安装所需的框架来编译代码并执行单元测试。

要创建新的构建定义，您需要拥有构建定义作者或构建者的权限。可以通过将自己添加到构建管理员安全组中来授予此权限。

如何操作...

通过浏览到http://tfs2015:8080/tfs/DefaultCollection/FabrikamTFVC/_build，导航到 FabrikamTFVC 团队门户中的构建中心。点击+图标以创建新的构建定义。在定义模板窗口中选择Visual Studio：

这将加载一个名为New Visual Studio definition 1的空构建定义：
导航到常规标签，按照以下截图中的示例设置各字段：

构建作业超时允许你输入构建作业需要执行的最短时间，在此时间之前服务器会取消该构建。此字段中的空值或0值表示无限超时。

构建作业授权范围的默认值是项目集合。只有当构建定义需要访问团队项目范围外的资源时，才应使用项目集合。

构建号格式的默认值为$(date:yyyyMMdd)$(rev:.r)。作为开发最佳实践，建议始终在构建输出的 DLL 文件中打印构建号。此方法不适用于默认的构建号格式。将构建号格式更改为程序集版本格式，例如1.0.$(date:yyyyMMdd)$(rev:.r)。有关构建号宏的完整列表，请访问msdn.microsoft.com/en-us/library/hh190719.aspx。
导航到代码库标签。它允许你为构建指定源代码控制设置。按照以下截图中的示例设置各字段。清理字段会强制每次构建都重新创建服务器工作区。通常，在构建之前清理工作区会使构建时间更长。如果只想将增量变更拉入构建工作区，请将该值设置为false。标签源会标记构建定义构建的代码版本。此处指定的标签格式字段将创建标签名称，格式为BuildDefinitionName_BuildNumber：
导航到触发器标签并勾选 CI。按照此处截图中的示例配置过滤器。批量更改设置允许将为同一构建排队的多个提交合并成一个单一的 CI 构建：

配置 CI 时需要应用至少一个过滤器。在设置为包含的路径下所做的任何检入都会触发构建定义。排除过滤器用于排除指定路径下的检入，避免触发构建定义。在这种情况下，任何在$/FabrikamTFVC/Main/Source/lib文件夹下的检入都不会触发此构建定义。导航到选项选项卡并按下图所示设置字段。多配置允许你在同一次构建过程中构建多个配置。如果构建的代码具有平台依赖性，建议将多个配置作为同一构建定义的一部分进行构建。选中并行后，多个配置的构建可以并行执行：
现在，导航到构建选项卡。新的构建引擎以协调者的形式出现。需要在构建选项卡中指定协调的步骤。正如你在构建选项卡中看到的那样，四个构建步骤——Visual Studio Build、Visual Studio Test、索引源并发布符号以及发布构建工件——会通过所选模板预先添加给你。点击Visual Studio Build并更新下图所示的字段：

构建选项卡包括 Visual Studio Build、Visual Studio Test、索引源并发布符号，以及发布构建工件任务。这些任务在使用 Visual Studio Build 模板创建新构建定义时会自动添加。
选择你希望编译的解决方案的路径。将其保持为默认值**/*.sln将会构建Repositories选项卡中指定路径下的所有解决方案。
MSBuild 参数文本框允许你传递额外的 MSBuild 参数。MSBuild 参数的完整列表可以在msdn.microsoft.com/en-us/library/ms164311.aspx找到。
你会注意到平台和配置已预先配置了一个变量。变量使你能够集中管理值，而不是将它们硬编码到构建定义中。变量还允许你在运行时覆盖这些值。这些变量的值在变量选项卡中指定；你可以选择导航到变量选项卡以覆盖模板注入的默认值。
选中恢复 NuGet 包复选框允许构建系统在构建执行期间下载任何依赖的 NuGet 包。

提示

自动恢复 NuGet 包是一个非常有用的功能；它可以避免你将依赖包检查到 TFS 中。
高级设置允许你指定特定版本的 MSBuild 或 Visual Studio 来编译代码。默认是 x86。
控制选项文本框允许您禁用特定的构建定义；此选项还允许您指定构建错误时的行为。您可以选择在遇到第一个构建错误时停止构建过程。
接下来，点击Visual Studio 测试步骤；您将看到左侧面板上的可配置变量列表。与构建步骤类似，此步骤还允许您选择用于执行测试的 VS Test Runner 版本。高级部分还允许您指定自定义测试适配器的路径。如果您计划使用非 VS Test Runner 执行测试，这将非常有用。勾选启用代码覆盖率复选框，其他字段保留默认值：

勾选代码覆盖率启用复选框，其他字段保留默认值
- 测试程序集：测试程序集字段应指定您希望 VS Test Runner 执行的测试项目的路径。此字段接受通配符；根据默认设置，所有输出为 *test*.dll 的项目将被测试运行器选择执行。
- 测试筛选条件：此字段允许您使用特定筛选器运行选择性的测试。可以在运行设置文件字段中传递一个运行设置文件。如果开发团队希望在开发者机器和构建服务器上使用相同的测试设置执行测试，这将非常有用。可以通过覆盖测试运行参数字段覆盖测试设置文件中指定的测试运行参数。
接下来，点击索引源并发布符号。在源代码编译过程中，构建引擎生成了符号文件。符号文件是与特定程序集匹配的 .PDB 文件，并包含调试工具使用的信息。对于 .NET 程序集，符号文件包含源文件名、行号和局部变量名。构建定义能够将符号发布到符号服务器。开发人员可以在 Visual Studio 中指向该符号服务器；这将在调试时自动下载正确的符号。如果您尚未拥有符号服务器，可以按照此处的说明设置基于文件共享的符号服务器：msdn.microsoft.com/en-us/library/windows/hardware/mt146873(v=vs.85).aspx。

将构件名称设置为 Symbols_$(BuildConfiguration)

最后，导航到发布构建工件任务。此任务允许您指定构建工件发布的位置。选择用于存储构件的服务器，此选项在大多数情况下是最佳和最简单的：

在发布构件中，将构件类型设置为服务器
点击保存并为构建定义命名；添加一个注释，如以下截图所示：
点击队列构建以手动触发该构建定义的新构建。构建输出控制台开始实时显示构建代理的活动：

它是如何工作的...

正如你所注意到的，选择 Visual Studio 模板后，默认体验会为你预配置大部分设置，使你能够几乎立刻设置好 CI 流程。

还有更多...

在新的构建框架中，构建输出也进行了重构。如以下截图所示，构建输出包含了测试结果和代码覆盖率结果。输出还包括一个单独的视图，便于查看时间线和工件：

将构建徽章固定到团队门户中的欢迎页面

构建徽章是一个动态生成的图像，显示某个构建定义的最新构建状态。在本指南中，你将学习如何将构建徽章固定到团队门户中的仪表板。

准备工作

要修改构建定义，你需要拥有构建定义作者或构建者的权限。通过将自己添加到构建管理员安全组，可以授予此权限。

如何操作...

导航到构建中心，进入 FabrikamTFVC 团队项目；浏览http://tfs2015:8080/tfs/DefaultCollection/FabrikamTFVC/_build。
在左侧面板的构建定义菜单下找到构建定义FabrikamTFVC CI，然后选择编辑该构建定义。
导航到构建定义的常规标签页，并勾选启用徽章选项：
点击保存以更新更改，从而启用徽章构建定义。保存更改后，徽章启用字段旁会出现一个新的超链接显示 URL...。点击显示 URL...超链接并复制该超链接：
浏览http://tfs2015:8080/tfs/DefaultCollection/FabrikamTFVC/_welcome，进入团队门户中的 FabrikamTFVC 团队的欢迎页面。
编辑README.md并粘贴构建徽章的 URL。保存更改。在以下截图中，当前 FabrikamTFVC 构建的状态以红色显示为失败。通过的构建以绿色显示，部分成功的构建则以橙色显示：

它是如何工作的...

Team Foundation Server 构建 API 暴露了一个公共端点，用于显示最后一次构建的状态。通过传递构建定义 ID，URL 会调用该端点，要求将构建定义状态呈现为徽章_apis/public/build/definitions/94fb1544-b441-45f5-a54d-466fc5d66817/4/badge。

还有更多

现在，构建定义支持将更改保存为草稿。这可以通过选择保存为草稿选项来完成，如截图所示：

构建定义，也可以保存为草稿，支持队列构建功能。由草稿构建定义生成的构建，其构建名称中包含DRAFT关键字：

这为你提供了一种在广泛共享之前验证构建定义更改的好方法。

使用基于角色的访问管理构建资源

旧的构建资源权限模型是扁平化的，这意味着你只能授予某人管理所有或不管理任何构建资源的权限。在新的构建系统中，安全性是一个合理的层次结构，因此你可以按队列或池的基础来控制权限。该构建系统提供了“基于角色的访问控制”，而不是直接暴露底层权限。在这个教程中，你将学习如何在池和队列级别上为构建资源设置权限。

准备就绪

场景：要管理所有池的成员资格，你需要是团队基础管理员组的成员。要管理单个池的权限，需要是团队项目集合管理员组的成员。为了管理队列的权限，你需要是项目集合构建管理员组的成员。构建定义管理需要是构建管理员组的成员。

如何操作...

通过浏览到http://tfs2015:8080/tfs/_admin/_AgentPool，在帐户管理控制台中导航到代理选项卡。点击所有池并将你打算在 TFS 中全局使用的构建代理服务帐户添加到代理池服务帐户角色：

要将服务帐户的作用域限制为Pool 1，点击Pool 1，选择代理池服务帐户选项，然后点击添加...以添加帐户：
通过浏览到http://tfs2015:8080/tfs/DefaultCollection/_admin/_AgentQueue，在默认项目集合作用域中，导航到代理队列选项卡。点击所有队列。从这里可以设置所有队列管理员、创建者和用户的角色成员资格：

在 Pool 1 级别，管理员、创建者和用户角色仅作用于 Pool 1 级别。这些权限可以通过点击Pool 1并将用户和组添加到相关角色来设置。

如何运作...

如下图所示，新的构建系统包含了一个基于角色的层次化访问控制模型。在接下来的部分中，我们将逐一介绍每个角色及其提供的访问权限：

所有队列：
- 代理队列管理员：该角色中的用户能够管理项目集合中的所有队列。
- 代理队列创建者：该角色的用户可以创建新队列。如果没有与队列同名的池，则会在队列创建时创建一个池，并将调用者添加为该队列和相应池的管理员。如果已经存在同名池，则调用者必须拥有池的管理权限（必须是池管理员），才能创建使用该池的新队列。
- 代理队列用户：该角色的用户可以使用整个集合中的所有队列。使用意味着他们可以将队列分配给构建空间中的定义。
单个队列：
- 代理队列管理员：与之前的角色相同，但权限仅限于特定队列。
- 代理队列用户：与之前的角色相同，但权限仅限于特定队列。
所有池：
- 代理池管理员：该角色的用户可以管理整个帐户中的所有池。
- 代理池服务账户：该角色的用户可以连接到池并接收有关构建作业的消息，包括控制消息，如“更新自己”和“取消此作业”。
单个池：
- 代理池管理员：与之前的角色相同，但权限仅限于特定池。
- 代理池服务账户：与之前的角色相同，但权限仅限于特定池。

使用构建保留策略来自动化构建删除

构建保留策略允许您使用一组规则删除旧的构建及其输出和相关工件。旧构建系统中的构建保留策略有两个缺点：

保留策略只能应用于每个构建定义
保留仅基于构建的数量

新的构建系统允许全局保留策略；这使得管理构建保留更加容易。新系统支持按构建的年龄进行保留，简化了创建有意义的保留规则。在本教程中，您将学习如何在团队项目集合级别和构建定义级别分别应用构建保留策略。

准备就绪

要管理集合的构建资源，您需要是项目集合构建管理员组的成员。

场景：Fabrikam 团队希望在默认团队项目集合中强制执行所有构建定义的默认保留策略，保留期为 20 天。FabrikamTFVC 团队只希望将 FabrikamTFVC CI 构建定义的构建保留 5 天。在 Fabrikam，所有超过 45 天且未标记为永远保留的构建都应被删除。

保留策略适用于所有团队项目集合中的构建。如果有些构建需要比全局策略规定的最大保留期更长时间保留，可以通过将构建标记为永久保留来实现。浏览到您希望从保留策略中排除的特定构建。然后，右键点击该构建，并设置该构建的 永久保留 标志：

如何操作……

浏览到默认项目集合的构建标签页，路径为 http://tfs2015:8080/tfs/DefaultCollection/_admin/_buildQueue。

在 最大保留策略 部分，将 保留天数 文本框更新为 45。这将强制所有构建的最大保留期为 45 天，排除那些标记为永久保留的构建。点击 保存更改 以应用更改：

在 默认保留策略 部分，将 保留天数 文本框更新为 20 天。此设置将级联到所有新创建的构建定义。点击 保存更改 以应用更改：

导航到 FabrikamTFVC CI 构建定义，然后进入保留标签页。将 保留天数 的值更新为 5 天。可以通过点击删除图标删除保留规则；也可以通过点击 添加新规则... 图标添加新的保留规则：

它是如何工作的……

TFS 有一组计划任务，用于管理 TFS 中的各种操作。构建保留策略由 TFS Agent 协调；只有那些标记为永久保留的构建才会被排除在删除过程之外。目前，无法更改删除构建记录和测试记录的全局设置，也无法应用分支筛选器。

在构建定义级别，可以更改作为保留策略一部分被删除的内容。删除测试结果 设置仅删除测试运行、结果和附件，手动测试结果不会被删除：

还有更多内容……

新的构建系统还提供了在单个构建中关联标签并使用标签筛选构建的功能。让我们从标记一个构建开始。打开一个构建并在标签部分添加一些标签，如下图所示：

在构建列表页面，输入您希望用来筛选构建列表的标签。如以下截图所示，构建列表通过 Bug#1291 和 Investigate 标签进行筛选：

使用用户权限识别池中的构建代理

为特定构建设置专门的构建代理并不罕见。例如，一个应用程序可能依赖于 SharePoint SDK。可以设置一个构建代理来处理具有这种依赖关系的构建。新的构建系统引入了能力的概念。能力，最基本的形式，是一组键值对，用于识别构建服务器的能力。需要特定能力来执行的构建，可以通过引用这些键值对，将其路由到相关的构建代理。构建代理支持系统能力和用户能力。系统能力是构建代理上已经可用的软件框架列表，由构建代理生成。用户能力可以手动添加到构建代理；这是为构建代理标记键值对的一种有用方式。在本教程中，您将学习如何向构建代理添加用户能力，以便在构建代理池中识别它。

准备就绪

场景：FabrikamTFVC 团队有一个解决方案，依赖于 SharePoint 2016 SDK。它已向 Pool 1 添加了一个附加的代理，该代理已安装 SharePoint 2016 SDK。虽然其他构建定义可以同时使用Win-A1和Win-A2，但所有来自 FabrikamTFVC CI 构建的构建请求需要仅路由到Win-A2：

例如，要修改构建代理的能力，您需要是构建管理员组的成员。

如何操作…

通过浏览http://tfs2015:8080/tfs/_admin/_AgentPool，导航到管理控制台中的Agent pools标签。
点击Pool 1并选择Win-A2。在USER CAPABILITIES部分，点击Add capability超链接。将SharePoint.SDK添加为键，2016添加为值：
导航到 FabrikamTFVC CI 构建，编辑构建定义，并浏览到General标签。在Demands部分，点击Add demand超链接。添加SharePoint.SDK并将比较符设置为equals，将Value字段设置为2016。点击Save以将更改应用到构建定义：
点击Queue build图标。在弹出的窗口中，点击Demands标签。你会看到新添加的SharePoint.SDK需求出现在此视图中。需求可以直接在此窗口中添加、删除或编辑。点击OK触发该构建定义的构建：

它是如何工作的…

构建框架扫描Pool 1以查找与构建定义中指定的需求列表匹配的代理。如果没有代理满足构建定义提出的需求，排队构建时会生成警告消息，指示没有可用的构建代理来处理构建请求。

以下截图显示，构建已通过匹配构建需求和代理能力成功路由到 Win-A2：

先前版本的 TFS 通过构建代理和构建定义标签允许构建路由。新的构建系统通过提供自动生成的系统能力列表以及使用比较符来创作构建定义中的需求，丰富了这一体验。

在构建输出中为 DLL 版本打上构建号

可追溯性在软件开发生命周期中非常重要。团队努力实现需求与测试用例、代码提交与构建、代码更改与测试运行之间的可追溯性。说到可追溯性，将构建输出中的二进制文件映射回构建是非常有用的。在此教程中，你将学习如何为构建输出中的 DLL 文件打上它们生成时的构建号戳。

准备就绪

场景：FabrikamTFVC 团队希望标记构建中使用的源代码，并使用构建号标记标签和构建输出：

下载课程材料中提供的 StampBuildNumber.ps1 脚本。将 StampBuildNumber.ps1 脚本检查入 script 文件夹，如下图所示：

权限：你需要编辑构建定义权限以执行此操作；你可以通过被添加到构建管理员组来获得这些权限。

如何操作…

通过浏览 http://tfs2015:8080/tfs/DefaultCollection/FabrikamTFVC/_build 导航到 FabrikamTFVC 团队项目中的构建中心，选择要编辑的 FabrikamTFVC CI 构建。
导航到常规选项卡，修改 构建号格式 字段为 1.0.$(Year:yy)$(DayOfYear).$(BuildID)。
在构建定义中的仓库选项卡中，选择成功构建后 源代码标记 选项，并将 标记格式 字段修改为 $(build.buildNumber)。
导航到构建选项卡，点击 添加构建步骤...，然后选择 PowerShell 任务：
更新 PowerShell 任务中的脚本文件路径，将其指向 StampBuildNumber.ps1 脚本的位置，在此案例中为 $/FabrikamTFVC/Main/Source/script/StampBuildNumber.ps1。该脚本期望构建号和代理工作区作为输入参数。这些值可以通过预定义变量 $(Build.BuildNumber) $(Agent.BuildDirectory)\$(Build.Repository.Name) 注入。可以在 msdn.microsoft.com/Library/vs/alm/Build/scripts/variables 找到预定义变量的完整列表。
点击保存并输入评论，以应用对 FabrikamTFVC CI 构建定义所做的更改。排队一个构建来验证 DLL 中的构建号戳印：

构建 1.0.15289.68 成功执行了 StampBuildNumber.ps1 脚本；构建号匹配的构建源标签将在成功构建后生成。构建输出可以从 Artifacts 视图中下载。文件版本 和 产品版本 字段的值与构建号相同。这提供了构建号在不同构件中的端到端映射。

它是如何工作的……

为了成功地在 DLL 上戳上构建号，构建号需要使用程序集版本格式。关于语义化版本控制（Semantic Versioning），有一些有趣的建议，您可以在semver.org/上阅读更多内容。

每个 C# 项目都包含一个 AssemblyInfo.cs 文件；如下图所示。此类包含 AssemblyVersion 和 AssemblyFileVersion 的属性。StampBuildNumber.ps1 脚本会将 AssemblyVersion 和 AssemblyFileVersion 字段覆盖为注入的构建号：

执行 StampBuildNumber 脚本的 PowerShell 任务需要在 Visual Studio Build 任务之前运行，以确保在编译过程中使用更新后的 AssemblyVersion 和 AssemblyFileVersion 属性值。

StampBuildNumber 脚本接受两个参数，如此处所示。这些参数通过构建定义中的预定义变量进行注入：

Set-AssemblyVersion 函数验证构建号值是否符合程序集版本格式。然后，在构建工作区中执行扫描以定位 AssemblyInfo.cs 类。接着，将 AssemblyInfo.cs 文件中的 AssemblyVersion 和 AssemblyFileVersion 属性替换为构建号的值：

以下截图展示了来自代理工作目录的处理过的 AssemblyInfo.cs 文件：

使用 TFBuild 可扩展性框架创建新的构建任务

新的构建系统提供了一系列预打包的构建任务。开箱即用的任务与流行的脚本引擎相辅相成。这有助于解决一些未被开箱任务直接覆盖的场景。新的构建系统从头开始架构，特别注重可扩展性。在本配方中，您将学习如何使用新构建系统中提供的可扩展性框架创建一个新的构建任务。

准备就绪

TFS 扩展命令行工具（tfx-cli）需要用于构建任务管理。该工具基于 Node.js。作为使用 tfx-cli 的先决条件，需要从 nodejs.org/en/download 下载并安装 Node.js。扩展性命令行工具可以通过启动命令提示符并运行以下命令直接安装：

npm install -g tfx-cli

要与 TFS 进行身份验证，tfx-cli 工具仅接受 个人访问令牌（PAT）或备用凭据。由于 TFS 尚未发布对 PAT 的支持，因此需要使用备用凭据进行身份验证。有关如何设置备用凭据的指导，请参见 github.com/Microsoft/tfs-cli/blob/master/docs/configureBasicAuth.md。

以下截图演示了如何通过传递团队项目集的连接详情以及备用凭据来使用 tfx-cli 进行身份验证：

为了验证你是否正确完成了设置，可以通过运行命令 tfx build tasks list 来尝试获取构建任务列表：

如何操作...

要创建新任务，运行命令 tfx build tasks create，如下所示：

一个模板任务已下载到工作文件夹，准备好供你开始编辑：
要将此任务上传到库中，请运行 tfx build tasks upload.\MyTask：
导航到 FabrikamTFVC CI 构建定义，点击编辑来编辑构建定义。在任务列表中选择新添加的 MyTask，它会显示在 Utility 部分下。点击添加将此任务包含在定义中：
更新消息文本框中的消息并保存更改。排队一个新构建：

构建成功运行 MyTask，并在控制台输出中打印消息 Hurray! My First Build Task...：

它是如何工作的...

执行 create new task 命令时，一组模板文件会被下载。task.json 文件包含有关任务的元数据。如以下截图所示，该文件包含任务元数据、代理依赖关系、任务特定属性和输出行为。例如，如果默认类别是 utility，则可以通过更改类别的值来修改构建任务上传到的类别：

其他文件也有其重要意义：

sample.ps1 文件包含在 Windows 代理上运行时执行的 PowerShell 构建任务逻辑。
sample.js 文件包含在跨平台代理（如 OS X 或 Linux）上运行时执行的 JavaScript 构建任务逻辑。
icon.png 文件是默认图标，应替换为具有透明背景的自定义 32×32 PNG 文件。

如果你在寻找灵感，所有现有的现成任务都是开源的，可以直接通过 GitHub 上的贡献进行增强，链接在此：github.com/Microsoft/vso-agent-tasks。

将 SonarQube 与 TFBuild 集成以管理技术债务

技术债务可以被定义为当前状态与代码库最佳状态之间的差距。技术债务通过使代码难以理解、易于破坏、难以验证，进而产生计划外的工作，最终阻碍进展，从而消耗生产力。技术债务是不可避免的！它起初微小，并随着仓促的更改以及缺乏上下文和纪律而逐渐增长。组织通常发现，他们的超过 50% 的能力都被技术债务所消耗。如第二章《设置和管理代码库》中所讨论的，最大的问题是识别和管理技术债务。SonarQube 是一个开源平台，是理解和管理技术债务的事实标准解决方案。在本教程中，你将学习如何通过 TFBuild 集成 SonarQube 来分析基于 .NET 的应用程序。

准备工作

SonarQube 是一个用于管理代码质量的开放平台。因此，它涵盖了代码质量的七个维度，如下图所示。SonarQube 最初在 Java 社区中非常有名，现在已经支持超过 20 种编程语言。微软和 SonarSource 的联合投资使得 SonarQube 更容易与 TFBuild 集成，并且在分析基于 .NET 的应用程序方面表现更好。你可以在 www.sonarqube.org/resources/ 阅读更多关于 SonarQube 提供的功能。

在本教程中，我们将使用 SonarQube 分析 FabrikamTFVC 代码库中的技术债务。如果你还没有 SonarQube 实例，可以通过访问 github.com/SonarSource/sonar-.net-documentation/blob/master/doc/installation-and-configuration.md 按照说明进行设置。

要完成本教程，你需要 Sonar 数据库连接字符串和用户帐户详细信息，以便从 TFBuild 连接到 SonarQube。本教程使用了前面提到的安装和配置链接中描述的单服务器设置：

Database Connection String - jdbc:jtds:sqlserver://TFS2015:1433/Sonar;instance=SQLEXPRESS;SelectMethod=Cursor
UserName - SonarUser
Password - SonarUser

如何执行…

通过浏览到 FabrikamTFVC 团队门户中的 Build 核心，导航到 FabrikamTFVC CI 构建定义。点击 Edit 超链接开始编辑 FabrikamTFVC CI 构建定义。
通过点击添加构建步骤来添加新任务。在构建类别中，选择SonarQube for MSBuild - 开始分析和SonarQube for MSBuild - 结束分析：
在 Visual Studio 构建任务之前组织开始分析任务，并在所有代码构建和测试任务执行完毕后组织结束分析任务：
在SonarQube 开始分析任务中，指定 SonarQube 实例的连接详细信息。SonarQube 端点需要通过端点管理器进行映射和添加，如下所示：
端点提供了类似于构建权限模型的基于角色的访问控制模型。用户和组可以通过此访问控制模型直接设置端点的管理和使用：
选择 SonarQube 服务端点并更新数据库设置：
更新项目设置，如下所示：
保存构建定义的更改并排队一个新构建。使用SonarQube 开始分析任务中的信息，构建代理将连接到 SonarQube 实例。它将使用 Sonar MSBuild 运行器处理代码，执行 .NET 和 JavaScript 代码分析、代码克隆分析、代码覆盖分析，并计算 .NET 和 JavaScript 的度量标准。这些结果将由SonarQube 结束分析任务发布：

它是如何工作的…

SonarQubeMSBuild 运行器用于从 TFBuild 调用 SonarQube 分析。让我们查看运行器执行的代码分析结果。通过浏览http://localhost:9000/进入 SonarQube 仪表盘。主页显示Fabrikam CallCenter (Main) 项目，如下所示：

通过钻取Fabrikam CallCenter (Main) 项目的仪表盘，你可以看到各种分析的高级度量：

仪表盘为你提供代码、复杂性、重复、单元测试覆盖率和债务分析的高级总结

问题部分显示了使用 .NET 代码分析规则集在代码库中发现的所有问题的完整列表。可以在此视图中直接跟踪、抑制、分配问题并为发布计划做准备：

问题部分显示了在分析过程中识别出的代码库问题列表

还有更多…

新的构建框架提供了创建自定义变量的功能。变量提供了一种方式，可以在构建定义中的多个字段之间共享公共值。与值不同，变量可以在运行时动态更新。该框架还允许将变量标记为安全，这样它的值就不会显示在构建定义中，也不会在构建执行时记录。在本教程中，SonarQube 连接字符串和账户详情是直接传递给构建任务的。这些值也可以通过构建变量传递，如下图所示：

使用 TFBuild 构建 GitHub 代码仓库

新的构建系统提供与 GitHub 的无缝集成。在本教程中，您将学习如何使用 TFBuild 来构建 GitHub 中的仓库。

准备工作

如果您还没有 GitHub 仓库，可以从help.github.com/articles/create-a-repo创建一个。

在本教程中，我们将使用位于github.com/visualstudiogeeks/的VisualStudioGeeks仓库。

如何操作…

从个人资料菜单登录到 GitHub 仓库，导航到设置，然后选择个人访问令牌。点击生成新令牌按钮以创建新的个人访问令牌：
指定令牌名称并选择访问范围。为了触发构建，需要选择admin:repo_hook访问级别：
点击生成令牌按钮。复制访问令牌并将其保存在安全的位置。请注意，您将无法再次查看此令牌；如果丢失，必须重新生成一个新令牌：
导航到 FabrikamTFVC 团队项目并浏览到构建中心。点击+图标以创建新的构建定义。选择 Visual Studio 模板，然后点击确定。将构建定义保存为VisualStudioGeeks CI。
导航到仓库选项卡，并选择仓库类型为外部 Git。输入仓库名称、仓库 URL、用户名以及访问该仓库的个人访问令牌：
在触发器选项卡中，选择计划选项，并指定从此构建定义触发构建的计划。保存对此构建定义的更改并触发一个新构建：

如前图所示，Build 20151020.5成功地从仓库VisualStudioGeeks同步了代码。

工作原理...

为 Visual Studio Geeks 仓库生成的个人令牌，具有 admin:repo_hook 范围，提供了对仓库钩子的完全控制权限。此访问权限允许监听器订阅代码更改提交到仓库时生成的提交事件。尽管 TFBuild 在 TFS 2015 中提供了构建 GitHub 仓库的功能，但目前尚不支持持续集成流程。如 TFS 功能时间表所示，持续集成构建工作流预计将在 TFS 2015 的未来更新中引入：www.visualstudio.com/en-us/news/release-archive-vso.aspx。

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

	“在水面上行走和从规范中开发软件很容易……如果两者都被冻结！”
	--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 单元测试框架。

准备工作

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

如何操作...

启动 Team Explorer 并连接到 FarbikamTFVC 团队项目。从源代码管理资源管理器中，打开 FabrikamFiber.CallCenter.sln 文件：
按照bit.ly/1XgG0UG的说明创建一个新的 NUnit 测试项目。将项目命名为 FabrikamFiber.Web.NUnit.Tests.csproj。
右键点击 FabrikamFiber.Web.NUnit.Tests.csproj 项目，从上下文菜单中选择 管理 NuGet 包...：
从 NuGet 包管理器中搜索并安装 NUnit 测试适配器。
打开解决方案的文件夹位置，你会注意到 NUnitTestAdapter NuGet 包已经添加到包文件夹中：
在 Team Explorer 的 待处理更改 视图中检查代码更改：
在 FabrikamTFVC 团队 Web 门户中，导航到 BUILD 中心，点击 + 图标以添加一个新的构建定义。使用 Visual Studio 构建模板创建：
在 Visual Studio 构建任务中，确保选中 恢复 NuGet 包 标志。你无需在构建或测试任务中做任何其他更改。确保代码仓库在仓库标签页中映射为 FabrikamTFVC。将构建定义保存为 FabrikamTFVC NUnit CI。你可以在 TFBuild 中创建持续集成构建定义 这一食谱中，详细了解如何设置构建定义，第四章，构建你的应用。
排队构建。构建完成后，你将在构建摘要部分看到测试结果的摘要。构建成功执行了所有 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 测试连接性：

PowerShell 2.0 和 Windows 管理框架 4.0 (bit.ly/1kNlxuW) 需要在代理和机器组中的所有机器上安装。
登录到 QA-Web1.Farbikam.lab 机器，右键点击 Windows PowerShell 快捷方式并选择以管理员身份运行启动 Windows PowerShell。
默认情况下，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 服务使前述更改生效。
接下来的几条命令将为 WinRM 准备 Kerberos 认证。

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

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

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

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

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

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

禁用基本认证：

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

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

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

禁用客户端认证的摘要：

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

设置服务认证使用 Kerberos：

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

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

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

重启win-rm服务：
```
Restart-Service winrm–Force
```
为确保启用 Kerberos 认证，请运行以下命令：
```
winrm get winrm/config/service/auth 
```
现在，让我们验证是否在QA-Web1.Fabrikam.lab上正确设置了 WinRM。登录到实验室中的另一台虚拟机，这里以QA-Web2.Fabrikam.lab为例。右键点击 Windows PowerShell 快捷方式并选择以管理员身份运行来启动 PowerShell。执行以下命令：
```
Test-Wsman –computerName QA-Web1.Fabrikam.lab
```
执行以下命令以检查 WinRM 监听的端口：
```
winrm e winrm/config/listener
```
注意

如果你想更改 WinRM 当前配置的监听端口，请执行以下命令：
```
Set-Item WSMan:\localhost\listener\*\Port 8888
```
最重要的是，验证你是否能够通过从QA-Web2.Fabrikam.lab手动运行以下命令来启动QA-Web1.Fabrikam.lab上的 Pssession。一旦你执行第一条语句，你将被提示输入凭据。输入具有管理员权限的域账户：
```
$cred = get-credential
```
执行下一条命令将使用你的域账户连接到目标服务器；DNS 将用于解析目标名称：
```
Enter-Pssession -ComputerNameQA-Web1.Fabrikam.lab–Credential $cred
```
按照步骤 1 到 5 在实验室中的其他机器上配置 WinRM。按照步骤 6 验证 WinRM 连接性后再继续。

如何操作...

进入 FabrikamTFVC 团队 Web 门户的测试中心，在机器页面上，点击+图标创建一个新的机器组：
按照以下截图中的内容输入详细信息：
由于远程机器与Fabrikam.lab.Add建立了信任关系，因此Fabrikam.lab中的 WinRM 协议将使用 HTTP，并且所有机器的详细信息。现在，点击完成以完成设置：

它是如何工作的...

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

要为每台机器输入凭据，请勾选为每台机器使用自定义凭据并结合全局凭据。
密码字段在用户界面中被隐藏。此外，该字段的值也不会打印在任何日志文件中。
标签为查询机器提供了一个很好的方式。在构建定义中使用测试代理部署任务时，你可以指定机器组，并使用标签来过滤包含标签的机器执行操作。
目前，机器组仅支持有限的场景，主要包括本地域加入的机器和 Azure 中的独立机器。请参考 bit.ly/1NFqYma 获取完整的支持场景列表。

通过 TFBuild 任务部署测试代理

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

准备工作

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

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

如何操作...

导航到 FabrikamTFVC 团队网站中的测试中心，在机器页面中，编辑 Fabrikam-QA 机器组。为机器 QA-App1.Fabrikam.lab 添加标签 Framework: Cucumber 并保存。
导航到构建中心，使用空构建模板创建一个新的构建定义。确保在代码仓库标签中将仓库映射为 FabrikamTFVC。然后从测试部分添加 Visual Studio 测试代理部署 任务。该任务包括三个部分：配置 Fabrikam-QA 机器组、通过机器名称或标签选择机器，并使用标签 Framework:Cucumber 过滤机器：
代理配置部分接受凭据，并且一旦安装，测试代理服务将以此身份运行。从变量选项卡创建测试代理的用户名和密码变量。将变量添加到代理配置部分。选中交互式进程选项以将代理作为交互式进程运行。如果没有请求将其作为交互式进程运行，则代理将作为 Windows 服务安装：
高级部分允许你指定测试代理安装程序的位置。如果你想控制安装代理的版本，这非常有用。如果没有指定位置，将从 Internet 下载最新版本的测试代理。勾选启用数据收集选项：
将构建定义保存为FabrikamTFVC Agent Deployment。从该构建定义排队一个新构建。构建完成后，导航到 QA-App1.Fabrikam.lab 服务器。测试代理已成功作为 Windows 服务安装。

它是如何工作的...

构建代理从 Internet 下载测试代理安装程序到一个 temp 位置。然后将安装程序推送到远程 QA-App1.Fabrikam.lab 计算机进行安装：
代理程序作为 Windows 服务安装在机器组中的计算机上：

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

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

准备工作

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

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

如何操作…

在 FabrikamTFVC 团队 Web 门户中导航到构建中心，点击编辑以在编辑模式下打开 FabrikamTFVC Agent Deployment。
点击+添加一个构建步骤，然后在添加任务窗口中，选择构建标签并添加 Visual Studio 构建任务。这个任务将用于编译测试项目：
在部署标签下，添加Windows 机器文件复制任务。此任务将把测试程序集复制到需要执行测试的机器上：
在测试标签下，添加使用测试代理的 Visual Studio 测试任务。这个任务将用于管理测试代理群组中的测试分发：
点击关闭图标以关闭添加任务窗口。构建定义中的任务需要按照以下顺序排列：
配置 Visual Studio 构建任务，以构建功能测试所涉及的解决方案：
配置 Windows 机器文件复制任务，将测试程序集复制到机器组中机器上的目录中。建议使用配置变量将测试位置参数化。可以使用预配置的构建变量来构造需要复制的程序集路径，这些程序集位于构建代理的工作文件夹中。如果勾选了清理目标标志，构建引擎将在复制新文件之前删除目标文件夹中的内容。此任务的高级部分还包括一个启用并行复制文件的标志，可以使用此标志允许构建系统并行复制机器组中的机器上的二进制文件：
不需要对 Visual Studio 测试代理部署任务进行更改。通过 TFBuild 任务部署测试代理配方中设置的配置将会在机器组中的所有机器上执行测试代理部署。使用测试代理的 Visual Studio 测试任务应紧随其后。选择 Fabrikam-QA 机器组作为目标机器组，在该机器组上执行测试。此外，还需要指定测试二进制文件的位置、测试程序集的模式、配置和测试执行的平台。在高级部分勾选代码覆盖率标志。你可以通过覆盖测试运行参数字段注入测试设置文件，选择性地覆盖测试设置文件中的配置：
保存对构建定义的更改并排队新的构建。一旦构建完成，导航到构建摘要页面；使用测试代理的 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 测试。

如何操作…

在 FabrikamGit 团队 Web 门户中，导航到构建中心。点击+图标以添加新的构建定义。选择 Visual Studio 构建模板并点击创建。在构建定义中导航到仓库选项卡，并将仓库映射到 FabrikamGit 仓库的主分支：
在构建定义中，导航到构建选项卡，选择Visual Studio 构建任务。设置包含 Selenium 测试项目的解决方案名称。确保勾选了恢复 NuGet 包标志：
选择 Visual Studio 测试任务，输入测试设置文件的路径，并通过覆盖 TestRun 参数字段注入 Selenium 网格的 URL：
将构建定义保存为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。

如何操作…

导航到 FabrikamTFVC 团队 Web 门户中的构建中心。编辑 FabrikamTFVC CI 构建定义。
点击+图标，启动添加新任务窗口。在测试标签页中，选择并添加基于云的 Web 性能测试任务：
云负载测试服务作为通用端点被添加到 Fabrikam 团队管理控制台。从注册连接下拉菜单中选择CLD-VSTS端点。输入您希望进行测试的端点。指定生成负载的位置：
点击保存并触发队列一个新的构建。构建执行完成后，负载测试执行的结果将作为构建结果的一部分提供：

它是如何工作的…

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

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

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

如何操作...

进入测试中心，点击运行以加载运行页面。运行页面显示了最近的测试运行。你可以一眼看到测试执行状态、测试配置、构建号、失败测试的数量和通过率：
点击过滤器标签，进入过滤器视图。默认查询会显示过去 7 天的测试运行记录。修改并添加新的条件，以仅显示今天的自动化测试运行：
查询将测试执行结果缩小为仅显示一次运行：
双击测试运行 ID 以打开测试运行进行分析。此视图显示运行摘要，并通过图表可视化按属性、特征、配置、失败类型和解决方案来展示测试结果。与测试运行相关的任何附件也可以在此视图中查看：
点击测试结果标签，查看此测试运行中执行的所有测试的列表。在 TFS 2015 之前，你需要下载 TRX 文件并在 Visual Studio 中打开它才能获取这些信息。这个视图提供了下一层的详细信息，包括测试执行时长和失败的错误消息：
选择多个测试并点击创建 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 导出测试用例

启动测试用例导出工具时，你将被提示连接到 TFS。连接后，你将看到与该计划相关联的测试计划和测试套件列表。选择测试套件和导出文件位置，并填写导出的输出位置和文件名，如下图所示：
导出过程为你提供以下选项：
选择将每个测试套件导出到单独的工作表选项，以将每个测试套件导出到一个单独的工作表。在上面的示例中，回归包、支付和网站将被导出到工作簿中的三个单独的工作表。
导出完成后，打开导出位置的电子表格以查看导出的结果。

从 TFS 导入测试用例

启动测试用例迁移 Plus工具以启动测试用例导入向导。
从源选项卡中选择数据源。输入格式可以是Excel 工作簿或MHT/Word。在本教程中，我们将使用输入源格式为Excel 工作簿。输入输出文件夹位置。一旦工作簿被解析，你将看到选定工作表中的列列表。点击下一步以配置目标设置：
从目标标签页，输入目标详细信息，如团队项目和工作项类型，以便将测试用例导入。从设置标签页，选择创建一个新的设置文件，并点击下一步按钮（设置文件将保存您的选择，以供未来的导入使用）。从字段映射标签页，将电子表格中的列映射到工作项。例如，电子表格中的标题字段映射到工作项的标题字段。
从链接映射标签页，您可以选择启用工作项之间的链接，使用其他标签页指定如何从源 Excel 文件读取数据。点击保存并迁移以根据通过向导配置的设置开始迁移过程。这将触发导入过程；更新进度将在用户界面上显示：
一旦导入完成，通过点击关闭图标按钮退出向导。导入工具会处理工作表并在与源工作表相同的位置生成报告。导入设置文件也会在相同的位置生成。该导入设置文件存储在导入过程中指定的设置。该设置文件可以用于将来的导入：
打开Report.xls文件，所有成功导入的测试用例将列在已通过表中。任何在导入过程中出现问题的测试用例将列在警告表中，而任何无法导入的测试用例将列在失败表中。
要查看导入的测试结果，请导航到 Team Web Portal 中的 FabrikamTest 中心。您将看到新的计划出现在测试计划下拉菜单中。以下截图展示了 Team Web Portal 中的测试套件和一个链接的测试用例：

它是如何工作的…

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

还有更多内容

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

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

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

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

准备工作

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

如何操作…

复制（浅拷贝）

在 Microsoft 测试管理器中，从计划选项卡中，选择一个静态测试套件来存放新副本。
从工具栏中，点击通过引用现有测试用例创建测试套件按钮。
在对话框中，选择你想要复制的测试计划和测试套件，然后点击创建套件。

克隆（深拷贝）

在 Microsoft 测试管理器中，从组织选项卡中，选择一个测试计划。
从工具栏中，点击克隆按钮。
在对话框中，选择一个或多个你想要克隆的测试套件。你也可以选择克隆与所选测试套件关联的需求。
输入目标测试计划的名称，并设置相关的区域路径和迭代路径。
接下来，点击克隆按钮触发克隆操作。克隆日志将显示克隆过程的更新信息。

注意

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

你还可以使用 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 的多个位置触发。在本教程中，你将学习如何从测试中心导出测试工件。

如何操作...

浏览到 FabrikamTFVC 团队 Web 访问并进入测试中心。要在测试计划级别导出，选择测试计划，然后从工具栏中点击 电子邮件或打印测试工件 按钮：
要在测试套件级别导出，选择测试套件，打开上下文菜单并选择导出选项：
无论你选择从测试计划还是测试套件导出，在这两种情况下，你都会得到一个新表单来选择“导出内容的类型”和“导出方式”。在这个表单中，“内容的类型”指的是工件，而“导出方式”指的是电子邮件或打印。以下截图中的几个项目值得注意。最新测试结果选项是在更新 1 中新增的，选择此选项还会导出测试结果。选择 选定的套件及其子项 会递归导出所选套件的所有子项：

操作方式...

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

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

还有更多内容...

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

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

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

登录到 TFS 应用程序层，并导航到以下路径。将贵公司徽标（companylogo.png）添加到C:\Program Files\Microsoft Team Foundation Server 14.0\Application Tier\Web Services\_static\tfs\12\_content文件夹路径中。
修改C:\Program Files\Microsoft Team Foundation Server 14.0\Application Tier\Web Services\_tfs_resources\TestManagement\v1.0\Transforms\1033文件夹中的TestSuite.xsl文件。
在记事本中打开TestSuite.xsl文件，并添加以下代码行以将贵公司徽标包含到导出模板中：
```
<div style="align:center;">
<img src="img/companylogo.png" />
</div>
```
可以通过在 Team Web Portal 的测试中心生成导出，来测试自定义的结果。

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

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

入门

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

如何操作...

导航到 FabrikamTFVC Team Web Portal 中的Test中心。Test Plan页面为您提供所选测试套件的测试套件列表和测试用例列表。Charts标签为您提供了可视化这些信息的极好方式。点击+图标并选择New test result图表。选择条形图并按Outcome分组；这将在条形图中显示测试用例结果。点击OK保存图表。右键点击新创建的图表，将图表固定到测试仪表板上：
现在，点击+图标并选择新建测试用例图表。测试用例图表类型支持趋势图，支持的趋势周期从 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 中创建发布定义

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

准备就绪

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

如何操作...

导航到 FabrikamTFVC 团队项目中的发布中心：
点击+图标以创建一个新的发布定义。这里有预配置的部署模板可以选择。在本食谱中，我们将从空白模板开始。与其他模板不同，空白模板会创建一个没有任何预先添加任务的空白发布定义：
将发布定义命名为FabrikamTFVC Web Release：
导航到常规标签，并将发布编号格式从Release-$(rev:r)更改为Rel-$(System.TeamProject)-$(rev:r)。从此定义生成的发布将具有格式为Rel-FabrikamTFVC-1的发布名称：
点击保存按钮以保存发布定义。在本食谱中，我们已经创建了一个空白的发布定义。接下来，我们将在工作原理...部分逐步介绍发布定义的不同功能。

工作原理…

在这个食谱中，我们从一个空的发布模板开始。部署模板窗口提供了一个选项，可以从一个预配置的发布模板开始。预配置的部署模板会为默认环境添加一个环境以及所有必要的发布任务，只需您配置任务即可。如以下截图所示，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 发布定义。

如何操作...

导航到 FabrikamTFVC 团队项目中的发布中心，编辑 FabrikamTFVC Web 发布定义。如下面的截图所示，发布定义提示你将构建定义链接到此发布：
点击构建定义的超链接，设置工件类型为构建，然后选择FabrikamTFVC.Services构建定义。底部的文本告诉你此构建定义正在发布的工件。点击确定，完成将FabrikamTFVC.Services构建定义映射到 FabrikamTFVC Web 发布定义的操作：
现在，导航到工件选项卡，你将看到FabrikamTFVC.Services构建定义作为此发布定义的工件源显示出来：
点击链接工件源，将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的新成功构建可用时，自动触发新发布。

如何操作…

转到 FabrikamTFVC 团队项目中的发布中心，并编辑 FabrikamTFVC Web 的发布定义。点击触发器选项卡以配置此发布定义的触发器：
勾选持续部署复选框，并选择FabrikamTFVC.Services作为工件源标签的触发器。同时，选择你希望发布自动部署到的环境。将所有更改持续部署到选定环境是常见场景；然而，发布管理允许你选择一个或多个环境进行持续部署。点击保存以提交更改：
转到构建中心并排队一个新的FabrikamTFVC.Services构建。一旦FabrikamTFVC.Services成功完成，来自 FabrikamTFVC Web 发布定义的发布将被触发。如果FabrikamTFVC.Services选项失败，则不会触发新发布：

如何运作…

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

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

还有更多…

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

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

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

准备就绪

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

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

如何操作...

导航到 FabrikamTFVC 团队项目中的发布中心，编辑发布定义 FabrikamTFVC Web。将默认环境重命名为开发：
通过点击省略号启动上下文菜单来配置开发环境。从上下文菜单中选择分配批准人...:
这个窗口允许你配置预部署和后部署批准的批准人，并设置环境的总体所有者，还可以选择启用电子邮件通知。点击确定保存已配置的更改。此屏幕允许将个人用户账户以及组添加为批准人和所有者：
现在你可以点击+图标，向开发环境添加部署任务。添加和配置任务将在未来的教程中介绍。
在开发环境中，通过点击省略号启动上下文菜单。从上下文菜单中选择保存为模板...:
给部署模板起个名字并填写描述，如下图所示：
点击+图标添加一个环境。这将启动部署模板窗口。如以下截图所示，你将看到一个新的自定义标签。该标签将列出团队保存的所有自定义模板。选择并添加此模板，它将添加一个带有在步骤 3 中设置的批准配置的新环境：
现在，添加新的环境用于 QA、暂存和生产，并按照准备就绪部分的图示设置批准者。如以下截图所示，每个环境都有符号来提供有用的信息：
- 这显示了环境中任务的数量。目前，在这个 QA 环境中没有设置任务。
- 这显示了环境中批准者的数量。目前，已为暂存环境设置了四个批准者。
- 这显示了环境中变量的数量。目前，生产环境中没有设置变量。
点击环境中的省略号以启动上下文菜单。在上下文菜单中选择克隆环境。这将把选定的环境克隆到一个新环境中。这对于你想要复制一个现有环境而不将其保存为模板时非常有用。
安全性也可以在环境级别进行配置。选择一个环境并从上下文菜单中启动安全配置。此屏幕允许你配置特定于环境的权限，例如哪些组可以删除发布环境、编辑发布环境、管理发布批准者以及管理发布权限：
用于部署环境的代理也可以在环境级别进行配置。从环境上下文菜单中选择代理选项...：

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

如果你试图将应用程序部署到的环境位于仅可通过特定代理访问的安全网络中，那么按环境配置代理的能力非常有用。你可以使用配置队列选项来选择包含你需要使用的代理的队列进行此次部署。
点击保存以提交更改。通过点击+图标排队一个新的发布版本：

它是如何工作的...

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

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

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

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

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

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

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

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

配置发布定义的安全性

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

正在准备中

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

操作方法…

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

权限对话框显示了组、用户和权限。此对话框可用于更改组的权限，并添加新的用户和组到这些组中：
在前一步中，我们学习了如何管理所有发布定义的安全性。要管理特定发布定义的安全性，请打开该发布定义的上下文菜单，并从菜单中选择安全性...：

权限对话框允许你管理此特定发布定义的现有用户、新用户和组的权限。
到目前为止，我们已经看到了如何为所有发布定义和特定发布定义应用安全性。发布管理还允许在发布定义中的环境上应用安全性。右键单击环境上下文菜单中的 FabrikamTFVC Web 发布定义并选择安全性...：

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

它是如何工作的…

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

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

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

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

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

变量支持以加密的方式存储值，使其无法被发布定义的用户查看或更改
将值存储在变量中有助于避免重复
变量可以在所有环境之间共享
变量可以在特定环境中的所有任务之间共享

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

准备工作

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

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

如何操作…

导航到 FabrikamTFVC 团队项目中的发布中心，并编辑 FabrikamTFVC Web 发布定义。点击配置选项卡。配置选项卡允许你添加可以跨发布定义共享的变量：
点击+图标添加变量。根据以下截图，添加 Azure Blob 存储的连接详情。点击属性旁边的挂锁图标。此类属性的值将被安全存储，并且一旦保存后，用户无法查看。在部署过程中，发布管理服务会解密由任务引用的这些值，并通过安全的 HTTPS 通道将它们传递给代理：
导航到环境选项卡，点击开发环境中的省略号，并从上下文菜单中选择配置变量...：
点击+图标添加变量。添加连接字符串详情并点击挂锁图标以隐藏连接字符串。为存储数据库名称添加另一个变量。按照此步骤为所有其他环境配置这些变量：
现在，导航到配置选项卡，并将右上角的变量类型更改为环境变量：
这显示了所有环境的环境变量及其值的列表：
你可以通过在视图列表旁边选择复选框来过滤掉不想查看环境变量的环境：

它是如何工作的…

在本配方中，我们在发布和环境级别配置了变量。在发布级别定义的变量可用于发布定义中所有环境的所有任务。在环境级别定义的变量仅对该环境中的任务可用；这些变量无法被其他环境访问。使用配置视图中的视图类型选项，您可以查看发布变量和环境变量。您可以点击属性旁边的挂锁图标来隐藏属性的值。此类属性的值会被安全存储，保存后无法被用户查看。在部署过程中，发布管理服务会解密任务引用的值，并通过安全的 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 部署包的构建定义，作为工件。

如何操作…

导航到 FabrikamTFVC 团队的发布中心。点击+图标以创建一个新的发布定义。选择Azure 网站部署模板：
Azure 网站部署模板添加了一个默认环境，其中包括Azure Web 应用部署和Visual Studio 测试任务：
选择Azure Web 应用部署任务，并根据下图配置值。选择已配置为服务端点的 Azure 订阅。选择已创建 Web 应用FabrikamTFVC-dev的位置。指定工件库中 Web 部署包的路径：
点击保存以将更改提交到此发布定义。创建一个新的发布。

如何运作…

发布代理使用 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 应用程序和应用程序池。要创建发布定义，你需要是发布管理员组的成员。此权限也可供项目管理员组使用。

操作方法…

在 FabrikamTFVC 团队项目中导航到发布中心。添加一个新的发布定义。选择一个空的部署模板，并将定义命名为 FabrikamTFVC Web 服务器发布定义。将默认环境重命名为 QA，并将 IIS Web 应用程序部署任务添加到该环境中：
在QA环境中，点击省略号并从上下文菜单中选择配置变量...：
为此环境添加两个变量，分别是machine.username和machine.password，它们包含需要部署 IIS 的机器的登录详情：
现在配置 IIS Web 应用程序部署任务，首先指定机器和登录详情。我们将使用在前一步中定义的machine.username和machine.password变量。由于我们处于已配置为使用 HTTP 的 WinRM 闭域组中，选择HTTP：
现在，指定 web 部署包的位置。由于 web 部署包是使用机器文件复制的，因此可以通过构建定义复制任务。你可以在此处直接指定本地目标机器的位置。可选地，你可以指定 web 部署参数文件并覆盖参数，以替换 web 配置中的网站属性，如应用程序名称、连接字符串、数据库详细信息等。或者，你也可以在部署后使用 PowerShell 脚本进行值替换：
勾选创建或更新应用程序池选项，并指定应用程序池名称、.NET 版本、管道模式以及应用程序池的身份：
点击保存并触发此发布定义的发布。等待发布完成，摘要视图将显示发布执行结果：

操作原理…

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

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

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

还有更多

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

在发布管理中跟踪发布

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

如何操作…

导航到 FabrikamTFVC 团队的发布中心。登录页面会显示所有发布定义的列表。这是一种快速查看发布状态的方式。该视图展示了有关状态的信息，以及发布定义、环境、构建、分支、开始时间和创建者等内容。使用持续部署配置触发的发布会在第一列显示一个图标：
这个视图可以通过发布状态进行筛选。在右上角，将状态下拉菜单更改为已拒绝；这将使列表仅显示已拒绝的发布：
切换到概览标签。这将帮助您可视化所有发布定义的状态。如以下截图所示，Fabrikam 网站发布管道定义的最后一个发布在开发环境中成功，但在QA环境中失败，并且在暂存和生产环境中没有尝试部署。您可以点击发布定义名称旁边的省略号来排队一个新发布、编辑定义或管理发布定义的安全性：

Fabrikam 网站发布管道显示 QA 环境中 Release-21 的状态；FabrikamTFVC Web 发布管道显示 Rel-FabrikamTFVC-3 在各环境中的状态
定位到Release-11并双击查看该发布。默认情况下，打开的是发布摘要视图。摘要视图显示了发布的详细信息、环境、问题、工作项和测试结果。你也可以在此视图中重新启动或放弃发布：
若要进一步挖掘问题，点击错误信息或导航到日志视图。日志视图让你按环境和任务浏览日志，从而更容易调查失败的原因：
你可以隐藏日志，通过从右上角更改选项，仅查看审批或任务：
发布中的提交和工作项视图展示了关于代码更改和与此发布处理的工件相关的工作项信息：
现在，在团队门户中导航到团队项目集合管理页面。点击代理队列，查看按队列分组的构建和代理列表。下图展示了 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。要创建或编辑构建定义，你需要是构建管理员组的成员。

如何操作…

在诊断代理问题时，最好的起点是查看代理追踪日志。代理追踪日志存储在代理工作目录中的_diag文件夹内。
如果在代理追踪日志中没有明显的异常，作为下一步，你应该对代理运行 HTTP 追踪。这可以通过使用 HTTP 代理工具来完成。如果你使用 Windows 系统，可以使用 Fiddler；其他平台可以使用 Charles Proxy。关于如何设置和捕获 HTTP 追踪，请参考bit.ly/1P6dqGt。
在捕获 HTTP 跟踪时，代理需要以交互模式运行。浏览到已下载 TFBuild Agent 的位置。解压 TFBuild Agent。在管理员模式下打开命令提示符，并将工作目录设置为解压后的 TFBuild Agent 位置。如图所示，运行 ConfigureAgent 命令：

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

所有代理活动将在命令提示符中以详细模式显示。这可能提供诊断代理问题的线索。
在排查构建定义问题时，最好以详细模式运行构建定义。在详细模式下，代理会生成非常详细的日志；调查日志通常是识别导致意外行为问题的最佳方法。要以详细模式运行构建定义，请创建一个新的变量 System.Debug，并将该变量的值设置为 true：

它是如何工作的…

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

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

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

准备中

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

如何操作...

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

打开 SQL Server Management Studio，连接到 TFS 事务数据库所在的 SQL 实例，打开一个新查询窗口并运行以下 T-SQL 代码来获取 TFS 数据库的数据库大小：
```
use [master]
select DB_NAME(database_id) AS DBName, (size/128) SizeInMB
FROM 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
```
执行上述代码后，你将获得以下输出：

在 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 TotalSizeInKB
FROM tbl_FileReference fr
JOIN tbl_FileMetadata fm
on fr.PartitionId = fm.PartitionId
AND fr.ResourceId = fm.ResourceId
WHERE fr.PartitionId = 1
GROUP BY OwnerId
ORDER BY 2 DESC

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

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

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.fileid
join tbl_FileMetadata fm on fr.PartitionId = fm.PartitionId and fm.ResourceId = fr.ResourceId
group by SUBSTRING(a.filename,len(a.filename)- CHARINDEX('.',REVERSE(a.filename))+2,999)
order by sum(fm.compressedlength) desc

从目前的分析来看，我们已经缩小了范围，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/ 来验证访问权限：

如何做到……

要访问活动日志，请导航至 http://tfs2015:8080/tfs/_oi/_diagnostics/activityLog。如果您首次访问该页面，加载可能需要一些时间。
该页面基本上展示了tbl_Command表中的数据。正如下图所示，页面包含命令、应用程序、状态、开始时间、执行时间、执行状态、身份、IP 地址、唯一标识符、用户代理、命令标识符、执行计数、认证和响应代码等列表项：
双击列表中的项目以查看更多详细信息。如下图所示，对于协调工作空间命令的详细信息显示了操作的详细下一层级：
活动日志页面还允许进行筛选和导出操作。由于tbl_command表中的数据仅保留 14 天，您可以将活动日志中的数据逐步导出到单独的存储库中，以保留这些有价值的信息用于历史趋势分析。
单击作业监控选项卡以导航到作业监控视图。或者，您可以直接浏览 http://tfs2015:8080/tfs/_oi/_jobMonitoring。作业监控视图还包括三个子菜单：作业摘要、作业队列和作业历史：
首先，让我们看看作业摘要视图。摘要视图显示了每个作业的总运行时间的图形表示。能够将作业执行时间与其他作业相对比有助于识别潜在问题。正如您在以下截图中所看到的，TFS 周期性身份同步和增量分析数据库同步作业处理时间较长，相比之下，优化数据库作业的处理时间较短：
要获取有关增量分析数据库同步作业的更多信息，请点击作业名称旁边的蓝色条形图。这将导航到 作业历史标签。作业历史标签有两个图表，一个显示所有作业的执行时间，另一个显示增量分析数据库同步作业的详细信息。查看这两个图表可以帮助你比较它们之间的影响。下图展示了增量分析数据库同步作业的执行图。通过查看图表，你可以发现 07/25 号的作业明显超出了正常模式，花费的时间比平时要长得多。然而，图表中的队列时间指标显示，延迟是由于平均队列时间延长所导致的：
返回到 作业摘要视图；该视图还有一个饼图，显示了成功、阻塞和禁用作业的分布。点击任何一项将导航到 作业历史视图，并提供每种类型作业的详细信息：
最后但同样重要的是，作业摘要页面有一个作业运行次数的图表。该图表显示了某个特定作业的运行次数以及该作业的结果类型。点击图表中的任意条形图，查看该作业的详细信息。将鼠标悬停在图表上可以获取更多信息：
接下来，导航到 作业队列标签。此标签中的图表描述了作业队列；它提供了每种队列类型的计数。点击条形图可以查看与每个队列类型相关的作业详情：

它是如何工作的……

建议不要直接查询 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 服务：

如何操作…

登录 Team Foundation Server 应用层，并通过浏览http://localhost:8080/tfs/TeamFoundation/Administration/v3.0/WarehouseControlService.asmx验证仓库控制服务是否可用。如果未看到如以下截图所示的仓库控制 Web 服务，请重新访问准备就绪部分：
在WarehouseControlWebService页面中，寻找changesetting网络方法。点击此方法以跳转到该函数的定义。这方法有两个输入参数，分别是settingId和newValue。在settingId文本框中输入RunIntervalSeconds。此属性表示仓库重建的频率。在newValue文本框中输入3600，其中3600代表 3600 秒（1 小时），即属性RunIntervalSeconds的新值：
点击Invoke。这将把您重定向到响应页面。响应页面将列出该操作的结果。在这种情况下，消息确认运行间隔值已成功更新为 3600 秒：
在这一步，我们将演示如何强制重建仓库。返回到仓库控制 Web 服务并选择 ProcessWarehouse Web 方法。该方法有两个输入参数，分别是 collectionName 和 jobName。在 collectionName 文本框中输入 defaultcollection，这是你想要强制重建的 TFS 集合。不要在 jobName 文本框中输入任何值：

提示

你可以选择将 collectionName 文本框留空。这将强制重建所有团队项目集合。
点击 Invoke 会将你重定向到响应页面。响应页面将列出操作的结果。服务返回 True 时，表示它成功启动了仓库的处理，False 则表示处理失败。False 的值意味着仓库当前正在处理：

它是如何工作的…

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

还有更多

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

配置 TFS 缓存设置

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

准备工作

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

如何操作...

登录到 TFS 应用程序层。导航到 TFS 的安装文件夹，默认安装位置是 C:\Program Files\Microsoft Team Foundation Server 14.0。
TFS 的 web.config 文件位于 C:\Program Files\Microsoft Team Foundation Server 14.0\Application Tier\Web Services 文件夹中。在进行任何更改之前，请先备份 web.config 文件。打开 web.config 文件并搜索键 dataDirectory：
将数据目录的值从默认值更改为新位置。在这个示例中，已为 TFS 缓存设置了一个新的驱动器W。重新指向缓存到W:\TfsData\ApplicationTier\_fileCache并保存配置文件中的更改：
除此之外，你还可以选择添加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 应用程序层。

如何操作...

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

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

TFSConfig CodeIndex /indexingStatus /collectionName:"default collection"

开始索引所有变更集：

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

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

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

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

TfsConfig CodeIndex /listLargeFiles /fileCount:50 /minSize:10 /collectionName:<CollectionName>

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

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

运行以下命令查看所有未被索引的文件：
```
TFSConfig CodeIndex /ignoreList:view
```

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

TFSConfig CodeIndex /reindexAll /collectionName:"default collection"

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

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 发起请求。

如何操作...

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

将以下代码复制到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

双击PreGetTfsProxy.bat来运行脚本测试脚本。如果脚本设置正确，D:\TFS\Workspace位置现在应该包含从 TFS 获取的源代码。
设置一个 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 执行备份和创建维护计划的权限。您需要一个网络共享来存储数据库备份。服务帐户需要对存储备份的网络共享、文件夹或存储设备具有完全控制权限。

如何操作...

登录到 Team Foundation Server 应用层并打开 Team Foundation Server 管理控制台。通过点击左侧导航面板中的计划备份进入计划备份屏幕：
如图所示，指定网络备份路径并将持续时间设置为 30 天：

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

您还可以选择一个唯一的扩展名，并将其配置为排除在病毒扫描之外。业界普遍接受的备份扩展名是：bak用于完整备份，diff用于差异备份，trn用于事务备份。
下一屏幕允许您指定报告数据库。勾选该选项将报告数据库包含在备份计划中。这样您就可以将报告数据库与 TFS 数据库一起备份。
报告服务需要一个加密密钥以在数据库恢复后访问报告，请在报告密钥页面设置加密密钥密码并点击下一步。
您可以选择性地勾选在备份计划中包含 SharePoint 数据库选项来备份 SharePoint 数据库。
点击“下一步”进入警报屏幕。警报屏幕可用于指定备份计划的警报设置。您可以选择在备份任务成功或失败时提醒用户：
调度备份页面允许您选择每日、手动和自定义调度。自定义调度让您可以更灵活地设置完整备份的调度、差异备份调度以及事务备份的间隔时间。
在审核页面确认设置并点击下一步以触发验证检查。验证成功通过后，您可以点击配置按钮，根据设置配置备份：
导航到\\tfs2015\backup，您将找到BackupSets.xml、BackupSettings.xml和报告服务器的密钥。请复制并将其保存在安全的位置。
您可以通过在 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，必须将全局管理工作区权限设置为允许。

如何操作…

以提升模式启动开发者命令提示符。
以下命令将删除属于 TFS 默认集合的Win2k12R2_John工作区。有关如何使用tf.exe命令切换工作区的更多示例，请参阅bit.ly/1P6mo6t：
```
tf workspace /delete /collection:"http://tfs2015:8080/tfs/defaultcollection" workspacename:"Win2k12R2_John" 
```
类似于工作区删除，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。

如何操作...

打开 Visual Studio，创建一个新的 Windows 控制台应用程序项目，并将项目命名为asPlayPit。
在解决方案资源管理器中，右键点击项目并选择管理 NuGet 包。这将打开 Visual Studio 中的 NuGet 包搜索窗口。
搜索并添加Microsoft.TeamFoundationServer.Client和Microsoft.TeamFoundationServer.ExtendedClient软件包。
安装这些软件包时，还会安装相关的依赖包。一旦软件包安装成功完成，在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 包添加到该项目中。

如何操作…

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

// Global Variables
private static TfsTeamProjectCollection _tfs;
private static ProjectInfo _selectedTeamProject;

// Connect to TFS Using Team Project Picker
public static void ConnectToTfsUsingTeamProjectPicker()
{
// The user is allowed to select only one project
var 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];
       }
}

从 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 包。

如何实现...

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

在 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();

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

它是如何工作的...

虽然此程序的输出不一定会给出 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 包添加到该项目中。

如何操作...

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

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

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

// Version control service exposes methods to work with TFS version control
var vcs = tfs.GetService<VersionControlServer>();

// Since we'll be reporting groups for all team projects, imp to get all team projects
var teamProjects = vcs.GetAllTeamProjects(false);
// Narrow down to the FabrikamTFVC Team Project
var teamProject = teamProjects.FirstOrDefault(p=>p.Name == "FabrikamTFVC");

应用程序组：IGroupSecurityService接口用于检索团队项目的组成员列表：
```
// Group Security service exposes methods to get groups, users and security details
var sec = tfs.GetService<IGroupSecurityService>();

Identity[] appGroups = sec.ListApplicationGroups(teamProject.ArtifactUri. AbsoluteUri);
```
通过 Team Explorer，您可以进入设置页面并点击组成员资格超链接来检索此信息。点击组成员资格超链接将带您进入 Team Web Portal 中的安全页面。以下截图的左侧显示了 FabrikamTFVC 项目安全页面中的组，右侧显示了通过编程返回的结果：

获取应用程序组中的成员：每个应用程序组包含用户或进一步的 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));
                        }
                    }
                }
}

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

获取用户会员设置：应用程序组中的用户要么继承权限，要么直接分配权限。以下代码片段使用版本控制服务中的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 中的安全页面：
版本控制权限：可以使用版本控制服务中的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 包。

操作步骤...

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

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

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

// Get an instance of the VersionControlServer
var vcs = server.GetService<VersionControlServer>();
// Get an instance of the ICommonStructureService
var ics = server.GetService<ICommonStructureService>();
ProjectProperty[] ProjectProperties = null;

// Get the team project by name
var teamProject= vcs.GetTeamProject("FabrikamTFVC");

string ProjectName = string.Empty;
string ProjectState = string.Empty;
int templateId = 0;
ProjectProperties = null;

// Get the project properties using the ICommonStructureServer
ics.GetProjectProperties(teamProject.ArtifactUri.AbsoluteUri, 
out ProjectName, out ProjectState, 
out templateId, out ProjectProperties);

// Output all the project properties
foreach (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 项目来获取团队项目中具有详细信息的构建列表。

如何操作…

在 RESTDemo 解决方案中，将 GetBuildDetails 设置为启动项目：
运行 GetBuildDetails 项目，这将启动一个控制台，输入 TFS 服务器 URL，然后按 Enter：
输入要连接到 TFS 的用户名和密码，然后按 Enter：
输入您希望从中检索构建详细信息的项目名称：
控制台将输出 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 仓库列表及其详情。

如何实现…

在RESTDemo解决方案中，将GetGitRepos设置为启动项目：
运行GetGitRepos项目，这将启动一个控制台。输入 TFS 服务器 URL 并按Enter：
输入您想要连接到 TFS 的用户名和密码，然后按Enter：
输入您希望从中获取构建详情的项目名称：
控制台输出包含 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项目来获取工作项的详细信息。

如何操作…

在RESTDemo解决方案中，将GetWorkItemById设置为启动项目：
运行GetWorkItemById项目，这将启动一个控制台，输入 TFS 服务器的 URL，按Enter键：
输入你想要连接到 TFS 的用户名和密码，按Enter键：
输入你想查询 API 的工作项 ID：
控制台输出工作项的详细信息，如所属的团队项目、类型、标题、状态和创建者：

工作原理……

我们将通过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），这将安装流程编辑器扩展。

如何操作…

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

<?xml version="1.0" encoding="utf-8"?>
<gl:GLOBALLISTS >
    <GLOBALLIST name="Teams">
        <LISTITEM value="Unassigned"/>
        <LISTITEM value="Fabrikam Feature 1"/>
        <LISTITEM value="Fabrikam Feature 2"/>
        <LISTITEM value="Fabrikam Feature 3"/>
        <LISTITEM value="Fabrikam Feature 4"/>
    </GLOBALLIST>
</gl:GLOBALLISTS>

打开 Visual Studio，并从工具菜单启动流程编辑器。在上下文菜单中，选择导入全局列表：
要上传 TeamGlobalList.xml 文件，请导航到该目录并选择 TeamGlobalList.xml。要验证上传，请从服务器中选择打开全局列表：
从服务器打开 WIT，方法是从流程编辑器菜单中选择此选项。选择 FabrikamTFVC 团队项目和产品待办事项类型的工作项：
流程编辑器以图形界面启动产品待办事项类型的工作项：
新建按钮用于向工作项类型添加一个新字段。点击新建并输入如下截图所示的详细信息：
在规则选项卡中，点击新建，选择允许的值。点击新建并选择先前创建的团队全局列表：
导航到布局选项卡，并在状态组列下为团队创建一个新控件。根据如下截图配置团队控件：
点击预览表单按钮以加载工作项表单中的更改预览。在工作项类型表单中点击保存以应用更改。

它是如何工作的…

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

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

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

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

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

准备工作

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

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

如何操作…

通过浏览http://tfs2015:8080/tfs/_admin/_extensions启动 Team Web Portal 扩展控制台：
单击安装按钮，以将多值字段控件扩展上传到 Web 门户。从下载位置选择并添加扩展：
上传后启用扩展。这将激活整个 TFS 实例中的扩展：
打开 Visual Studio 并启动过程编辑器，从上下文菜单中选择从服务器打开 WIT。连接到 FabrikamTFVC 团队项目并打开产品待办事项工作项类型。在前一个操作中，添加了团队字段，并将其与类型为FieldType的控件关联。导航到布局标签，找到团队字段，将控件类型更改为MultiValueControl。点击保存以应用更改：

它是如何工作的…

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

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

posted @ 2025-06-29 10:40 绝不原创的飞龙阅读(35) 评论(0) 收藏举报

刷新页面返回顶部

龙哥盟

掠夺·扩张·投机·博弈

微软-TeamFoundation-服务器秘籍-全-

微软 TeamFoundation 服务器秘籍（全）

前言

注意

本书内容

本书所需内容

本书的目标读者

章节

准备工作

如何操作…

它是如何工作的…

还有更多…

另见

约定

注意

提示

读者反馈

客户支持

下载示例代码

勘误

盗版

问题

第一章：Team Project 设置

介绍

使用 Team Explorer 连接到 TFS

准备工作

注意

如何操作...

工作原理...

注意

在 TFS 中设置你的用户资料

如何操作...

它是如何工作的…

注意

使用 Scrum 模板创建团队项目

准备工作

注意

如何操作...

它是如何工作的...

分配许可证、添加用户以及审计用户访问

准备工作

如何操作...

分配用户许可证：

向项目中添加用户：

注意

审核用户访问

如何工作...

在团队项目中配置仪表板

准备开始

如何操作…

它是如何工作的…

设置团队项目的欢迎页面

准备工作

注意

如何操作…

工作原理…

提示

创建和设置 Team Room

准备就绪

注意

如何操作…

注意

它是如何工作的...

注意

更多内容...

注意

提示

重命名团队项目

准备开始

注意

如何操作...

选项 1

选项 2

注意

注意

它是如何工作的...

注意

通过命令行创建新的 Team 项目

使用 `.tfignore` 和 `.gitignore` 忽略提交文件类型