Team Foundation Server 2017 Update 2 发行说明

项目
03/28/2024

注意

这不是 Team Foundation Server 的最新版。 要下载最新版本，请访问 Team Foundation Server 2018 Update 3 的最新发行说明。可以更改此页面的语言，具体方法是单击页脚中的地球图标，然后选择所需语言。

本文介绍 Team Foundation Server 2017 Update 2 的相关信息。单击此按钮下载。

有关 Team Foundation Server 2017 的详细信息，请参阅 Team Foundation Server 要求和兼容性页。

请参阅 TFS 安装页以获取详细信息。

发布日期：2017 年 7 月 24 日

Team Foundation Server 2017 Update 2 新增功能摘要

我们已在 Team Foundation Server 2017 Update 2 中增加了许多有价值的更新。其中一些要点包括：

工作项现在具有与每个工作项类型关联的图标。
我们引入了交付计划。
可以使用工作项搜索搜索工作项。
其中包括新的分支策略配置体验。
具有许多拉取请求改进。
现在有可视化 Git 历史记录的 Git 图。
现在可以添加并查看 Git 标记。
我们拥有新的包管理体验。
具有新的生成定义编辑器体验。
部署到 Azure Web 应用时可获取各种更新。
在部署容器时可获得许多改进。
我们引入了条件生成任务。
现在有现成可用通知。

通过按功能区域查看改进，可以查看所有新功能的详细信息：

工作项跟踪
版本控制
拉取请求
包管理
生成和发布
测试
仓库
管理
Microsoft Teams 集成

TFS 2017 Update 2 新增功能详细信息

工作项跟踪改进

工作项类型图标

我们做出了一个面向全球的承诺，确保客户可以完全访问我们的产品。作为该承诺的一部分，我们一直致力于查找和解决存在于从键盘模式到可视化设计和布局等任何位置的许多辅助功能问题。

在许多情况下，工作项跟踪仅依赖颜色来传达工作项类型。但是，这会对我们的色盲或弱视用户造成困扰，由于颜色的相似性，他们可能无法区分这些工作项。为了提高所有客户对工作项类型的可视性，我们在工作项类型的视觉对象语言中引入了图标。可以通过选择我们的图标库来自定义工作项类型。

表示有关积压工作 (backlog) 和查询网格类型的颜色条已经替换为彩色图标 （图 1） 。

看板上的卡片现在包含一个类型图标 （图 2） 。

交付计划

交付计划是一种组织工具，它可以通过在基于迭代的日历上跟踪工作状态来帮助推动跨团队的可见性和一致性。可以定制计划，将跨项目的任何团队或积压工作 (backlog) 级别包含在帐户中。此外，计划上的“字段条件”允许你进一步自定义视图，同时“标记”突出显示重要日期。

查看交付计划的市场页，了解详细信息并安装扩展。

如果用户的 TFS 实例与 Internet 断开连接，可直接通过 Web 访问中的“管理扩展”选项获取交付计划，而无需导航到 VSTS Marketplace。从“管理扩展”，单击“浏览本地扩展”，然后选择“交付计划”并单击“安装” 。有关详细信息，请参阅预安装扩展一文。

从工作项自动链接到生成

通过在生成定义中使用此新设置，可以跟踪已合并工作的生成，而无需手动搜索大量生成。与工作项关联的每个成功生成将自动在工作项窗体的开发部分中显示。

若要启用此功能，请在生成定义中切换 “选项” 下方的设置 （图 3） 。

弃用旧的工作项窗体

对新工作项窗体的总体反馈是积极的，并且现在已在我们的托管帐户上完全采用。我们希望本地客户能够利用使我们的 VSTS 用户感到满意的相同功能，因此我们已经决定弃用旧的工作项窗体和旧的扩展性模型。请参阅 Microsoft 应用程序生命周期管理页上有关我们计划的详细信息。

工作项搜索

工作项搜索可跨集合中所有项目提供对所有工作项的快速灵活搜索（图 4）。工作项搜索全文搜索引擎可用于在所有工作项字段中轻松搜索术语，并有效地查找相关工作项。在任何工作项字段上使用嵌入式搜索筛选器，以快速将范围缩小到工作项列表。

在 TFS 中配置搜索服务之后，可以进行搜索而无需安装任何其他程序。通过使用工作项搜索，可以执行以下操作：

在所有项目中搜索： 在你自己和合作伙伴团队的积压工作 (backlog) 中进行搜索。在所有工作项中使用跨项目搜索，以在组织的整个工作项中进行搜索。通过使用项目和区域路径筛选器来缩小搜索范围。
跨所有工作项字段进行搜索： 通过跨所有工作项字段（包括 ere 字段）进行搜索来快速轻松地查找相关工作项。在所有字段中使用全文搜索以有效地查找相关工作项。片段视图将指示找到匹配项的位置。
在特定字段中进行搜索： 在任何工作项字段上使用快速嵌入式搜索筛选器，在几秒钟内将搜索范围缩小至工作项列表。建议的下拉列表有助于更快地完成搜索。例如，执行 AssignedTo:Chris WorkItemType:Bug State:Active 搜索将查找分配给名为 Chris 的用户的所有活动 Bug。
利用与工作项跟踪的集成： 工作项搜索接口可与工作中心中的熟悉控件集成，以便用户进行查看、编辑、注释、共享等其他操作。

版本控制改进

新的分支策略配置体验

我们已经重新设计了分支策略配置体验并添加了一些出色的新功能（图 5）。其中最强大的功能之一是能够为分支文件夹配置策略。可以在“分支”视图中通过选择一个分支文件夹，然后从上下文菜单选择“分支策略”来执行此操作。

这将打开新的策略配置 UX，可在其中配置适用于分支文件夹中所有分支的策略 （图 6） 。

如果使用的是生成策略，则现在可以为一个分支配置多个生成。此外，还有新的选项可用来指定自动或手动触发器 （图 7） 。手动触发器对于类似自动测试运行这样可能需要很长时间才能运行的操作非常有用，而且只需要在完成拉取请求之前运行一次。生成策略还有一个显示名称，如果配置多个生成，该名称将非常有用。

配置手动触发策略后，可以在拉取请求的“策略”部分选择“队列生成”选项来运行它（图 8）。

对于必需的审阅者策略（图 9），我们为管理员添加了指定注解的功能，以便在应用策略时将该注解追加到拉取请求时间线（图 10）。

适用于非活动注释的新策略

确保使用新的注释策略来处理拉取请求中的所有注释。启用此策略后，活动注释将阻止 PR 的完成，以强制解决所有注释。给拉取请求作者留下注释但乐观地批准拉取请求的审阅者可以确信，渴望合并的作者不会错过任何注释。

文件中心改进

我们已经对文件中心进行了一些更新，以改善查看和编辑体验。

在查看方面，我们添加了透视，以便查看当前文件夹中的“README”（图 11）、预览 Markdown 文件、将文件与此前的版本进行比较（图 12）并查看指责。

对于编辑，用户现在可以预览更改，轻松地添加注释，提交到新分支，并链接工作项 （图 13） 。

可视化 Git 存储库

现在可以查看一个图，同时显示存储库或文件的提交历史记录。这使用户可以使用 Git 图为 Git 存储库创建所有分支和提交的心理模型（图 14）。此图以拓扑顺序显示所有提交。

Git 图的关键元素包括（图 15）：

Git 图为右对齐，因此与默认分支或所选分支关联的提交在右侧显示，而图的其他部分则在左侧显示。
合并提交由连接到它们的第一个父级和第二个父级的灰点表示。
正常提交由蓝点表示。
如果在接下来的 50 个提交的视图端口中看不到某个提交的父提交，那么我们将切断该提交连接。单击箭头之后，该提交就会连接到它的父提交。

在提交上查看 Git 标记

如果团队一直使用 Git 标记来标记存储库历史记录中的特定点，那么提交现在将显示已创建的标记。可以查看“提交列表”视图和“详细信息”页中特定提交的标记（图 16）。

将标记添加到提交

无需从命令行创建标记并将标记推送到存储库，现在只需转到提交然后添加一个标记（图 17）。通过标记创建对话框还可以标记存储库上的任何其他引用。

提交列表视图还支持上下文菜单 （图 18） 。无需转到 “提交详细信息” 页来创建标记，然后创建新分支 （图 19） 。

更新的变更集页和搁置集页

我们改进了 TFVC 中的变更集页和搁置集页。若使用辅助技术，则可以更方便地访问这两个页面。这些新页还具有包含变更集标题以及有关变更集的相关信息的新标头，例如作者的详细信息 （图 20） 。

变更集页和搁置集页还托管新的 Markdown 讨论控件（图 21），以便在 markdown、@mention 用户中键入注释，使用 # 关联工作项，并轻松地附加文件和图像。

改进的提交筛选

现在可以通过高级筛选选项来筛选提交历史记录结果（图 22）。可以通过以下方式筛选提交：

完整历史记录。
使用简化合并的完整历史记录。
第一个父级。
简单的历史记录（这是默认筛选器设置）。

将存储库从 TFVC 导入到 Git

可以将代码从 TFVC 存储库迁移到同一个帐户中的 Git 存储库。若要开始迁移，请选择存储库选择器下拉列表中的 “导入存储库”（图 23） 。

单独的文件夹或分支可以导入到 Git 存储库，或者可以导入整个 TFVC 存储库（减去分支） （图 24） 。还可以导入最多 180 天的历史记录。

Git LFS 文件锁定

我们已添加 Git LFS 文件锁定功能。这样，团队就可以使用无法区分的大型文件，以避免在两个或多个用户尝试同时编辑同一个文件时丢失工作。在任何人开始编辑文件之前，他们会使用锁定，该锁定会通知服务器。当其他人尝试采用锁定时，服务器将拒绝该请求，以便让第二位用户知道已经有人在使用该文件。使用此功能前，请升级到 Git LFS 2.1 或更高版本。

Git 提交注释使用新的讨论控件

我们已更新 Git 提交上的轻型注释，以便使用新的讨论控件。这在注释中为 Markdown 提供支持，并为 Git 和 TFVC 在 Web 中提供所有代码注释功能，以便使用最新体验。

新的树视图控件

拉取请求文件视图、Git 提交详细信息、Git 推送详细信息、TFVC 搁置集详细信息、TFVC 变更集详细信息、TFVC 变更集中心和 Git 历史记录中心已更新，并提供新的树视图控件（图 25）。稍微改进了树视图的可用性。首先，我们已更改视图以显示自动折叠空文件夹节点的简要树视图，以在视图中显示尽可能多的文件。

此外，树还可以更紧凑的方式显示注释。带有注释的文件显示每个注释线程的子项，其中的虚拟形象指示创建该线程的用户。新的注释线程和带有回复的线程由蓝色点表示，并且回复计数通过计数来汇总。

拉取请求改进

适用于 PR 作者和审阅者的改进的 CTA

对于使用分支策略的团队来说，在查看拉取请求时，有时很难确切地知道需要执行什么操作。如果对操作的主要调用是“完成”按钮，这是否意味着该请求已经准备好完成操作了？使用有关查看配置分支策略的页面和状态的用户信息，PR 视图现在将显示对该用户最有意义的操作的调用。

配置策略时（但尚未通过），“完成”按钮（图 26）现在会推荐使用“自动完成”功能。如果策略受阻，则不可能成功地完成拉取请求，因此我们提供了一个选项，当这些策略最终通过时，它将完成拉取请求。

对于审阅者来说，更可能是想要批准一个拉取请求而不是去完成它，因此，如果尚未批准，审阅者将会看到“批准”按钮（图 27）突出显示为主 CTA。

获得批准后，在审阅者同时还是完成 PR 的人员的情况下，审阅者将看到“完成”（或“自动完成”）按钮突出显示为 CTA。

可操作注释

在具有多个注释的 PR 中，很难跟踪所有对话。为了更好地管理注释，我们简化了解决项目的过程，这些项目已经通过若干增强功能加以解决：

在每个拉取请求的标头处，现在可看到已解决的注释计数（图 28）。

处理注释后，可以通过单击进行解决 （图 29） 。

在解决过程中，如果要添加注释，则可以一次性进行回复并解决（图 30）。

解决注释时，可看到计数上升，直到处理完所有注释（图 31）。

我们已改进概述中的筛选器，以便按照各种注释状态进行筛选，并显示每个筛选器选项的注释计数（图 32）。

更新视图显示变基和强制推送

在 “拉取请求详细信息” 视图中，已改进 “更新” 选项卡来显示何时发生了强制推送以及基提交是否发生了更改 （图 33） 。如果主题分支中的变基在完成拉取请求之前发生更改，那么这两个功能非常有用。现在，审阅者有足够的信息来了解出现的情况。

按人员筛选拉取请求

现在能更轻松的查找拉取请求！我们添加了新的筛选选项，以便可以找到由特定作者创建或分配给特定审阅者的拉取请求（图 34）。只需从作者或审阅者筛选器中选择一个用户，列表即可更新，显示仅与该筛选器匹配的拉取请求。

绕过拉取请求策略时所需的理由

绕过拉取请求策略时，需要指定原因。在 “完成拉取请求” 对话框中，如果他们选择绕过，则将看到新的 “原因” 字段 （图 35） 。

输入原因并完成拉取请求后，该消息在“概述”中显示（图 36）。

“共享拉取请求” 操作是通知审阅者的一种便捷途径 （图 37） 。在此版本中，我们添加了对团队和组的支持，因此只需一步即可通知拉取请求所涉及的每个参与者。

团队的拉取请求改进

如果你是多个团队的成员，则可看到分配给在“我的拉取请求”视图中列出的那些团队的所有拉取请求（图 38）。这使得必须访问“我的拉取请求”才能查看板上的所有 PR。

在未来版本中，我们会将团队添加到“代码”下的“拉取请求”中心，以便可以更轻松地查看单个项目的所有拉取请求。

拉取请求注释的默认通知

通过新的注释通知随时掌握 PR 中发生的对话（图 39）。对于已经创建的 PR，在用户添加新的注释线程或回复现有线程时，都会向创建者自动发送通知。当你对其他用户的 PR 添加注释后，你将收到关于你创建或回复的注释线程的任何未来回复的通知。

这些通知可作为现有订阅的一部分提供，并可在“通知”设置页上进行配置。

包管理改进

更新的包管理体验

我们更新了包管理用户体验，以便更快地解决用户报告的常见问题，并为即将推出的包生命周期功能留出空间（图 40）。请在更新体验页上了解有关更新的详细信息。

包管理将添加 npm README 和下载按钮

现在，可以在包中看到包含 README.md 的任何 npm 包的 README（图 41）。 README 可以帮助团队记录并共享有关包的知识。

也可以使用命令栏中的“下载”按钮来下载任何 npm 包。

NuGet 还原和 NuGet 命令生成任务

我们主要更新了 NuGet 安装程序（现在称为 NuGet 还原）任务，并添加了新的 NuGet 任务： NuGet 命令。最值得注意的是，“NuGet 命令”和“NuGet 还原”任务现在默认使用 nuget.exe 4.0.0 。

现在，NuGet 还原在 Visual Studio 生成步骤之前针对还原包最常见的方案进行了优化。它还对共享单个 NuGet 源的小项目提供更好的支持：现在可以选取一个Team Services 源，并将其添加到自动生成的 NuGet.Config 中。

对于更复杂的 NuGet 操作， NuGet 命令任务提供了指定任何命令和参数集的灵活性 （图 42） 。

生成和发布改进

新的生成定义编辑器

我们已重新设计生成定义编辑器，以提供更直观的体验，修复某些难题，并添加新的功能。我们希望用户可以更轻松地使用模板、添加任务和更改设置。此外，现在可以使用过程参数来轻松地指定最重要的数据位，而不必深入探索任务。

搜索模板

搜索想要的模板然后应用它，或者从一个空的过程开始 （图 43） 。

快速查找并在所需位置添加任务权限

搜索想要使用的任务，找到它之后，可以在左侧当前选择的任务之后添加它，或者将它拖放到所需位置（图 44）。

还可以拖放一个任务来移动它，或者在拖放的同时按住 Ctrl 键来复制任务。

使用过程参数将密钥自变量传递给任务

现在，可以使用过程参数 （图 45） 以便使用生成定义或模板的用户能够轻松地指定最重要的数据位，而无需深入探索任务。

如果从某些内置模板创建新的生成（例如 Visual Studio 和 Maven），则会看到说明工作原理的示例。新编辑器还包含几个其他增强功能，例如可以使用户更快地访问源设置。

有关使用新编辑器创建第一个生成定义的演练，请参阅适用于新手的 CI/CD。

请在 2017 用户体验页上了解详细信息。

扩展任务的多个版本

现在，扩展创建者可创建具有多个版本的给定任务的扩展，使他们能够为生产中的每个主版本交付修补程序。

请参阅 Reference for creating custom build tasks within extensions（在扩展中创建自定义生成任务的引用）。

条件生成任务

如果想要更好地控制生成任务（例如在出现问题的时候执行清理或发送消息的任务），我们现在提供了四个内置选项，以便用户在任务运行时进行控制（图 46）。

如果希望提高灵活性，例如在某些情况下针对具有某些触发器的特定分支运行的任务，则可以表明自己的自定义条件：

and(failed(), eq(variables['Build.Reason'], 'PullRequest'))

请参阅指定运行任务的条件页。

用于生成和部署基于容器的应用程序的内置任务

通过这个版本，我们默认已经将 Docker 扩展中的大部分任务都拉取到产品中，进行了改进，并引入了一组新的任务和模板，从而可以更轻松地生成一组容器方案。

Docker： 生成、推送或运行 Docker 映像或运行 Docker 命令。此任务可与 Docker 或 Azure 容器注册表一起使用。现在，可以结合使用内置的服务主体身份验证和 ACR，使之更易于使用。
Docker-Compose： 生成、推送或运行多容器 Docker 应用程序。此任务可与 Docker 或 Azure 容器注册表一起使用。
Kubernetes： 通过运行 kubectl 命令来部署、配置或更新 Azure 容器服务中的 Kubernetes 群集。
Service Fabric： 将容器部署到 Service Fabric 群集。目前，Service Fabric 是在云中运行 Windows 容器的最佳选择。

Azure Web 应用部署更新

我们已经对 Azure Web 应用程序做了很多改进：

Azure 应用服务部署任务支持部署 Java WAR 文件、Node.js、Python 和 PHP 应用程序。
Azure App Service 部署任务支持使用容器部署到适用于 Linux 的 Azure Web 应用。
Azure 门户持续交付已扩展为支持 Node 应用程序。
将 Azure App Service 管理任务添加到 Azure App Service 的启动、停止、重启或槽交换中。它还支持安装站点扩展，以启用所需的 PHP 或 Python 版本的安装或安装 IIS Manager 或 Application Insights。

我们还为最新版本的 Azure CLI 引入了 CI/CD 支持，以配置 CI/CD。下面是一个示例：

az appservice web source-control config --name mywebapp --resource-group mywebapp_rg --repo-url https://myaccount.visualstudio.com/myproject/_git/myrepo --cd-provider vsts --cd-app-type AspNetCore

.NET Core 任务支持项目文件

借助当前的更新，我们正在改进 .NET Core 任务，以支持除了 project.json 之外的 *.csproj 文件。现在可以使用生成代理上的 Visual Studio 2017 来生成使用 csproj 文件的 .NET Core 应用程序。

SSH 部署改进

“通过 SSH 复制文件”生成/发布任务现支持目标路径中的波形符 (\~)，简化了将文件复制到远程用户的主目录的过程。此外，新选项会在找不到要复制的文件时造成生成/发布失败。

SSH 生成/发布任务现支持在远程 Linux 或 macOS 计算机上使用 Windows 行尾运行脚本。

在生成或发布过程中安装 SSH 密钥

一个新的预览版任务，安装 SSH 密钥（预览），在生成或发布之前安装 SSH 密钥，并在生成或发布完成时将其从代理中删除。已安装的密钥可用于从 Git 存储库或子模块提取代码、运行部署脚本或需要 SSH 身份验证的其他活动。此功能将在以后得到改进，以支持密码和其他功能。

如果已指定 Visual Studio 2017 但在代理上不存在，则任务失败

借助 Visual Studio 生成和 MSBuild 任务，用户可以选择特定版本的 Visual Studio。到目前为止，如果 Visual Studio 2017 版本不可用，这些任务将自动选择下一个可用的版本。

我们会更改此行为。现在，如果你选择 Visual Studio 2017 但在代理上不存在，则生成将失败。

我们做了这一更改，原因如下：

较新的应用类型，如 .NET Core 不使用较旧的生成工具进行编译。它们明确要求使用 Visual Studio 2017 或更高版本。
在使用完全相同的 Visual Studio 版本时，将会获得更一致且可预测的结果。
每当生成任务回退时，可能会收到难以理解的编译错误。

提示

请确保使用一个与池相连的队列，该池具有使用 Visual Studio 2017 的代理，并且不具有仅使用 Visual Studio 早期版本的代理。

专用代理自动工作区清理

现在可以配置代理池以定期清理过时的工作目录和存储库（图 47）。例如，池将删除由已删除的生成和发布定义留下的工作区。

使用此选项应尽量避免专用生成和发布代理耗尽磁盘空间的可能性。维护是由每个代理（而不是每台计算机）完成的，因此，如果一台计算机上有多个代理，仍然会遇到磁盘空间的问题。

生成代理升级状态

升级代理后，它现在指示队列和池管理门户中的升级状态。

选择未使用计算机上的专用代理

在将生成或发布分配给专用代理时，系统现在使用计算机名作为一个因素。因此，当系统分配作业时，它会选择空闲计算机上的代理，而不是忙碌计算机上的代理。

管道队列

现在，我们已从基于代理的定价模型转移到了基于管道的定价模型。在此新模型中，用户可以并行运行数量与其帐户中配置的管道数量一样多的生成或发布。超过此限制的额外生成和发布将排入队列，并等待早期的生成和发布完成。 “管道队列”功能为用户提供对版本或发布位置的更多可见性。

启动“管道队列”时，可以看到以下信息：

1. 等待管道执行的生成和发布以及它们在等待队列中的位置。 2. 当前正在使用可用管道运行的生成和发布。

当生成/发布正在等待管道时，也可以直接从生成/发布日志页面内启动此视图，并在管道队列和其他详细信息中查找其当前位置。

“生成”摘要中的“发布”操作

我们现在支持“生成”摘要操作栏中提供的“发布”操作，使你能够轻松为生成创建发布。

变量组的安全性

现在，可以通过“创建者”和“管理员”等一组角色管理变量组的安全性。

默认情况下，将分配以下角色。

参与者的创建者角色
项目集合管理员、项目管理员、生成管理员和发布管理员的管理员角色
有效项目用户的读取者角色

可以替代所有变量组或特定变量组的默认设置。

iOS DevOps 增强功能

Apple App Store 扩展现支持双重验证（双因素身份验证），并支持将生成发布给外部测试人员 （图 48） 。

安装 Apple 证书（预览）是一项新的生成任务，它在代理上安装 P12 签名证书，以便后续的 Xcode 或 Xamarin.iOS 生成使用。

安装 Apple 配置文件（预览）是一项新的生成任务，它在代理上安装预配配置文件，以便后续的 Xcode 或 Xamarin.iOS 生成使用。

MSBuild、Xamarin.Android 和 Xamarin.iOS 生成任务现支持使用 Visual Studio for Mac 工具集执行生成。

Java 代码覆盖率增强功能

发布代码覆盖率结果生成任务报告 Cobertura 或 JaCoCo 代码覆盖率作为生成的一部分。它现在支持在“摘要文件”和“报表目录”字段中指定通配符和 minimatch 模式，允许在每个生成基础上对在生成之间进行更改的路径的文件和目录进行解析。

Maven 和 SonarQube 改进

Maven 生成任务现在允许在不同于 Maven pom.xml 文件中指定内容的情况下指定用于分析结果的 SonarQube 项目。

改进的 Jenkins 集成

Jenkins 队列作业生成/发布任务现在支持运行 Jenkins 多分支管道作业，同时在 Team Services 中显示 Jenkins 控制台输出（图 49）。管道结果会发布到 Team Services 生成摘要中。

Azure 虚拟机规模集部署

用于部署的一个常见模式是为应用程序的每个版本创建一个完整的计算机映像，然后部署该映像。为了方便起见，我们新建了一项生成不可变虚拟机映像任务。此任务在部署应用程序和所有需要的先决条件后使用打包程序来生成虚拟机映像。任务采用部署脚本或打包程序配置模板来创建虚拟机映像，并将其存储在 Azure 存储帐户中。然后，可以将此映像用于 Azure 虚拟机规模集部署，这种部署可以很好地处理此类型的不可变映像部署。

替代 Azure 资源组部署中的模板参数

当前在 Azure 资源组部署任务中，用户选择 template.json 和 parameters.json 并在文本框中按照特定的语法提供替代参数值。这种体验现已得到改进，以便在可以编辑和替代模板参数的网格中呈现这些参数（图 50）。可以通过单击替代参数字段旁边的 ... 来访问此功能，这会打开一个带有模板参数及其默认值和允许值的对话框（已在模板和参数 .json 文件中定义的前提下）。此功能需要在源中启用 CORS 规则。如果模板和参数 .json 文件位于 Azure 存储 blob 中，请参阅 Azure 存储服务文档来启用 CORS。

带有分支和标记筛选器的多个发布触发器

发布管理现支持在“生成”类型的多个项目源上设置 CD 触发器。添加后，当一个新的项目版本可用于任何指定的项目源时，就会自动创建一个新的发布。还可以指定源分支，新的生成应来源于该分支，以触发一个发布。此外，可以设置标记筛选器来进一步筛选应触发发布的生成。

在发布中设置项目源的默认值

在定义中链接项目源时，用户可以定义要在发布中部署的默认项目版本（图 51）。自动创建发布后，将部署所有项目源的默认版本。

部署请求者和审批者的职责分离

以前，环境所有者可以限制发布创建者批准到环境的发布部署。但是可以手动启动由其他用户创建的发布的部署，然后自行批准。

我们现在已经通过将部署创建者作为部署的独立用户角色来填补这一空白。可以限制发布创建者或部署创建者批准部署。

发布级别批准

现在可以选择自动批准在成功部署到另一个环境后自动触发的部署 （图 52） 。如果选择不批准每一个部署，那么可以一次批准具备相同审批者的部署链。

若有两种环境，即开发和测试环境，预部署审批者设置为“userA”和”userB”，两者都需要批准部署。如果测试上的策略设置如下所示，则在部署期间它足以让 userA 和 userB 仅批准开发。对测试的部署将获得自动批准。如果手动触发对测试的部署，则在部署之前需要批准，以确保正确批准。

部署到 Azure 政府云

在政府云中拥有 Azure 订阅的客户现在可以配置 Azure 资源管理器服务终结点来针对各国云端。

借助此功能，现在可以通过相同的部署任务使用 Release Management 将任何应用程序部署到在政府云中托管的 Azure 资源（图 53）。

设置最大并行部署数

使用此功能可以控制如何将多个挂起发布部署到给定环境中（图 54）。例如，如果发布管道在 QA 环境中执行生成验证，并且生成的生成速度比部署的完成速度更快，则可以配置多个代理和任意多个生成以进行并行验证。这意味着所生成的每个生成都得到了验证，并且等待时间取决于可用的代理数。利用此功能，可以通过在最近使用的生成中并行执行验证，并取消较旧的部署请求来优化验证。

手动干预任务的超时增强功能

现在，在挂起指定超时或 60 天之后（以首先达到的时间为准），可以自动拒绝或恢复手动干预任务。可以在任务的控制选项部分指定超时值。

Release Management 并行执行

Release Management 现在支持阶段的并行执行选项（图 55）。选择此选项可以通过使用多配置或多代理作为一个阶段乘数选项来扇出一个阶段。

多配置：选择此选项可以运行每个多配置值的阶段。例如，如果想要同时部署到两个不同的地区，则使用“变量”选项卡上定义的变量 ReleasePlatform，其值为并行运行该阶段的“east-US, west-US”，其中一个值为“east-US”，另一个为“west-US”。多代理：选择此选项以在并行的多个代理上运行具有一个或多个任务的阶段。

Azure 门户中的 Web 应用部署历史记录

现在，当通过使用应用服务部署任务完成部署后，发布管理可以更新 Azure 应用服务的部署日志。可以通过选择“应用服务”边栏选项卡中的“持续交付”选项来在 Azure 门户中查看部署历史记录。

测试改进

使用代理阶段运行测试

使用 Visual Studio 测试任务，现在可以使用代理阶段运行自动测试（图 56）。

现在我们具有跨生成、发布和测试的一个统一的自动化代理。它带来了如下优点：

可以针对测试需求来利用代理池。
在不同模式下使用相同的 Visual Studio 测试任务运行测试，根据需要基于单个代理的运行、基于多个代理的分布式测试运行或者多配置运行，来在不同浏览器上运行测试。

有关详细信息，请参阅此 Microsoft 应用程序生命周期管理文章。

自动测试的按需触发

“测试”中心现支持从测试计划和测试套件中触发自动测试用例（图 57）。从“测试”中心运行自动化测试需要进行一个设置，该设置类似于在发布环境中以计划方式运行测试。需要使用“从测试计划运行自动测试”模板在发布定义中设置一个环境，并关联测试计划以运行自动测试。有关如何设置环境和从“测试”中心运行自动测试的分步指南，请参阅文档。

仓库改进

Analysis Services 多维数据集处理的性能改进

我们已对“vDimWorkItemTreeOverlay”视图进行了性能改进，该视图用于基于链接创建“工作项树层次结构”维度。虽然它依赖于 System.LinkTypes.Hierarchy 链接，但我们观察到处理持续时间也会受到其他链接（例如 System.LinkTypes.Related）的影响。我们已优化视图，跳过了添加会限制读取数据量的链接类型的步骤。此更改可以明显减少某些仓库的处理时间。

不区分大小写的架构协调

仓库数据库的架构是在架构协调过程中，由合并字段基于所有附加的集合数据库创建的。以前，所有的比较都是区分大小写的，管理员必须确保字段引用名称精确匹配。这会导致在大小写方面存在细微差异的问题。在此版本中，我们提高了该过程对此类差异的容忍度。

管理改进

合并电子邮件收件人来接收通知

收到相同电子邮件通知的收件人现在一起包含在“收件人:”行上，并向他们发送一封电子邮件。以前，会向每个收件人单独发送电子邮件。这使得用户难以知道还有谁也收到了通知，并且难以通过电子邮件讨论相关事件。该功能适用于现成可用以及能够针对多个收件人的团队订阅。例如，当对拉取请求进行更改时，会向该拉取请求的所有审阅者发送一封电子邮件。

了解有关合并电子邮件收件人的详细信息。

现成可用的通知

当帐户中的活动与用户及团队直接相关时，他们会通过电子邮件自动收到通知，例如：

将工作项分配给用户时。
将某个用户或团队添加为拉取请求的审阅者时。
某个用户或团队成为更新的拉取请求的审阅者时。
另一个用户响应拉取请求注释时。
用户请求的生成完成时。
安装或请求扩展时（仅管理员）。

用户可以通过转到用户配置文件菜单下的“通知”设置，然后关闭相应的切换来取消订阅任何这些订阅。

帐户管理员可以通过导航到“设置”齿轮下的集合级别“通知”中心来禁用一个或多个自动订阅。任何这些订阅都可以通过单击“...””操作下的“禁用”来禁用。禁用订阅后，它将不再出现在用户的个人通知设置页中。

了解有关现成可用通知的详细信息。

扩展管理权限

管理员现可授予其他用户和组权限来管理集合扩展（图 58）。以前只有集合管理员（即项目集合管理员组的成员）可以查看扩展请求、安装、禁用或卸载扩展。

为了授予此权限，管理员可以通过打开“市场”菜单、选择“管理”扩展，然后单击“安全性”按钮来导航到“扩展管理”中心：

在扩展安装、请求注意等操作时获得通知

现在，管理员或能够管理扩展的人员可在扩展安装、卸载、启用、禁用或请求注意时自动收到通知。这在更大的部署中特别有用，在这种情况下，多个人员都有责任来管理扩展。管理员可以通过导航到“配置文件”菜单下的“通知”设置并关闭扩展切换来关闭这些通知。

管理员还可以为扩展相关的事件定义自定义订阅。例如，管理员可以在任意扩展更新时收到通知。

用户现在还可以关闭关于扩展请求的自动通知。

允许 TFS 管理员将订阅者添加到高级访问级别

在 Team Foundation Server 的未来版本中，将会删除高级访问级别。不过，在这种情况出现前，TFS 管理员可以将 MSDN Platform 和 Visual Studio Test Professional 订阅者添加到具有 Update 2 的高级访问级别。

应将 Visual Studio Enterprise 订阅者添加到 Visual Studio Enterprise 访问级别，而不是添加到高级访问级别。如果已经购买了测试管理器扩展，请继续在购买的团队项目中的“用户”中心管理它。

Microsoft Teams 集成

使用 Microsoft Teams 进行协作的组织现在可在其团队频道内看到其 TFS 项目中的活动。这样，团队在 Microsoft Teams 中工作时就可随时了解相关工作项更改、拉取请求、生成和版本等的最新信息。有关详细信息，请参阅文档。

已知问题

工作项窗体在 Web 中无法正确呈现

问题：

如果已安装了适用于 Visual Studio 客户端而非 Web 客户端的自定义控件（如多值控件），则 Web 中的工作项窗体将无法呈现。
解决方法：

需要更新到控件的最新版本。需要添加不包含缺失控件元素的 Web 布局。可以在 TFS 工作项跟踪的自定义控件页上找到 TFS 2017 Update 的最新多值控件。有关布局的详细信息，请参阅所有 FORM XML 元素引用 (TFS 2015)页。

TFS 版本是 RC2，而不是最终版本

问题：

下载 TFS 2017 Update 2 后但在 2017 年 8 月 1 日之前，安装的都是 RC2 版本。
解决方法：

这是由于安装链接中存在间歇性问题导致的，该问题已于 2017 年 8 月 1 日修复。请重新下载 TFS 2017 Update 2，然后安装此最终版本。

请参阅客户报告的有关 Team Foundation Server 2017 的问题。

反馈和建议

我们期待你的宝贵意见和建议！可以通过开发者社区门户报告并跟踪问题，并能在 Stack Overflow 上了解相关建议。

返回页首