开发者社区 | 系统要求和兼容性 | 许可条款 | TFS DevOps 博客 | SHA-1 哈希 | | 最新 Visual Studio 2019 发行说明|
注意
这不是 Team Foundation Server 的最新版。 要下载最新版本，请访问 Team Foundation Server 2018 Update 3 的最新发行说明。 可以更改此页面的语言，具体方法是单击页脚中的地球图标，然后选择所需语言。
本文将介绍 Team Foundation Server 2017 的相关信息。 单击此按钮下载。
要详细了解 Team Foundation Server 2017，请参阅 Team Foundation Server 要求和兼容性页面。
请参阅 TFS 安装页以获取详细信息。
发布日期：2018 年 2 月 28 日
此更新修复了潜在的跨站点脚本 (XSS) 和其他安全漏洞。 更多信息，请参见博客帖子。 由于是完全升级，因此可以直接升级到 TFS 2017.0.1。
发布日期：2016 年 11 月 16 日
Team Foundation Server 2017 新增功能摘要
已知问题
Team Foundation Server 2017 新增功能详细信息
代码搜索
代码搜索提供在所有代码中快速、灵活且准确的搜索。 随着代码库扩展，以及跨多个项目和存储库划分，查找所需内容变得越来越困难。 为了最大程度地实现跨团队协作和代码共享，代码搜索可以在所有项目中快速高效地找到相关信息。
从发现 API 实现的示例、浏览其定义，到搜索错误文本，代码搜索为所有代码研究和故障排除需求提供了一个一站式解决方案 （图 1）。
代码搜索提供：
- 在一个或多个项目中搜索
- 语义排名
- 丰富筛选
- 代码协作
有关详细信息，请参阅搜索全部代码。
包管理
包可让你在组织中共享代码：可以构造大型产品、基于常见共享框架开发多个产品或创建和共享可重用的组件和库。 包管理（图2）通过托管包、将其与所选人员共享并使 Team Build 和 Release Management 易于访问这些包，让代码共享变得容易。
使用包管理，不再需要通过直接在 Team Foundation Server 中托管 NuGet 包，来托管单独的 NuGet 服务器或文件共享。 它为 NuGet 3.x 提供了最佳支持，同时也为 NuGet 2.x 旧版客户端提供支持。 它可与现有 TFS 基础结构、团队和权限无缝结合，因此无需处理同步标识、在多个位置管理组等等。它还可轻松与 Team Build 集成，以便你可以在连续的集成工作流中创建和使用包。
有关详细信息，请参阅包管理概述。
敏捷改进
在 Team Foundation Server 2017 中，我们已向工作项和看板添加了新特性和功能。
新工作项表单
新工作项（图 3）窗体具有全新的界面外观。 它还添加了一些出色的新功能：
- 丰富的工作任务讨论体验。
- 支持附件的拖放功能。
- 改进的历史记录体验（历史记录和审核）。
- 改进的代码和构建集成。
- 州着色。
- 响应式设计。
注意
新工作项窗体仅在新集合中为默认设置。 如果要迁移现有集合，则需要通过管理员设置启用新工作项窗体。 有关详细信息，请参阅 管理新网页表单的推出。
跟踪工作项
现在只需通过单击窗体中的新“关注”按钮（图 4），就可以设置用于跟踪单个工作项的更改的警报。 在跟踪工作项时，将随时收到工作项更改的通知，包括字段更新、链接、附件和注释。
有关详细信息，请参阅跟踪工作项。
看板实时更新
你的看板现在已经上线！
你是否按了 F5 以在看板中查看一整天的内容？ 请尝试使用下面屏幕截图（图 5）中的图标。
当你团队中的任何人在板上创建、更新或删除工作项时，你将立即在板上收到实时更新。 此外，如果管理员进行看板或团队级别更新，如添加新列或启用积压工作上的 Bug，将通知你刷新看板以更新看板布局。 只需启用看板上的“塔”图标并开始与团队协作。
有关详细信息，请参阅看板基础知识。
清单改进
我们已经对清单的工作方式做出了几处改进。
清单标题现在显示为超链接（图 6）。 你可以点击标题以打开工作项表单。
清单现在还支持上下文菜单，可通过其打开、编辑或删除清单项（图 7）。
有关详细信息，请参阅添加任务清单。
史诗与功能看板下钻
现在，您可以向下钻取您的Epic和功能板（图 8）。 清单格式可让你轻松将工作标记为已完成，并提供已完成工作与未完成工作的便利鸟瞰视图。
有关详细信息，请参阅看板功能和长篇故事。
打开/关闭看板批注
我们为你提供了对显示在看板上卡片中的附加信息的更多控制。 现在可以选择想要在看板卡上查看的批注（图 9）。 只需取消选中批注，它即会从看板上的卡片中消失。 将在此处显示的前两个批注是子工作项（此示例中的任务）和测试批注。
有关详细信息，请参阅自定义卡片。
清除格式命令
我们已向工作项上的所有 RTF 控件添加了一个新的命令，它可用于清除所选文本中的所有格式。 如果你和大多数用户一样，那么你过去可能因为将带格式的文本复制粘贴到这个无法撤消或清除的字段中而感到困扰。 现在只需突出显示任何文本、选择“清除格式”工具栏按钮（或按 CTRL+空格键），文本即可返回到其默认格式。
在看板中进行筛选
通过对用户、迭代、工作项类型和标记设置筛选器，对看板进行个性化设置（图 10）。 这些筛选器可保留，以便查看个性化看板，即使从多台设备连接也是如此。
团队成员也可以筛选看板以查看归属于特定父工作项的进度。 例如，用户可以查看链接到某个功能的用户故事，或查看汇总到某个史诗的两个或多个功能的工作。 类似于任务清单，此项功能是我们提升不同积压工作级别可见性的又一项举措。
有关详细信息，请参阅筛选看板。
新工作项的默认迭代路径
当从“查询”选项卡或从“新工作项”仪表板小组件创建新工作项时，该工作项的迭代路径将始终设置为当前迭代。 并不是所有团队都希望这样，因为这样意味着问题可能会立即显示在任务板上。 利用此项改进，团队可以选择应用于新工作项的默认迭代路径（一个特定迭代或当前迭代）。 导航到你团队的管理区域以选择默认迭代。
有关详细信息，请参阅自定义区域和迭代路径页。
复选框控件
现在可以向工作项添加复选框控件（图 11）。 此新字段类型（布尔）具有普通字段的所有属性，并且可被添加到进程中的任何类型。 当显示在卡上或查询结果中时，值显示为 True/False。
有关详细信息，请参阅自定义字段。
标签的批量编辑
现可使用批量编辑对话框添加和删除多个工作项中的标记（图 12）。
有关详细信息，请参阅向工作项添加标记。
新扩展点
我们在看板和积压工作页上添加了新的贡献点，允许您将扩展编写为紧邻“看板/积压工作/容量”选项卡的枢纽选项卡。
我们已在待办事项上开放了一个新的扩展点。 扩展可以将右侧窗格作为目标，映射和工作详细信息就位于右侧窗格中（图 13）。
电子邮件改进
我们显著改进了 TFS 发送的工作项警报、关注和 @mention 电子邮件的格式和可用性（图 14）。 电子邮件现在包含一致的标头、明确的操作调用和改进的格式，以确保邮件中的信息易于使用和理解。 此外，所有这些电子邮件旨在确保它们在移动设备上良好呈现。
有关详细信息，请参阅工作项警报。
工作项模板
我们增加了直接在本机 Web 体验中创建丰富的工作项模板的功能（图 15）。 此功能之前在 Web 中非常有限，且仅通过 Visual Studio 增强工具以这一新形式提供。 团队现在可以创建和管理一组模板，用于快速修改常见字段。
有关详细信息，请参阅工作项模板。
不再支持 Project Server 集成
Team Foundation Server 2017 及更高版本将不再支持 Project Server 集成。 自 RC2 起，如果升级已配置了 Project Server 集成的 TFS 数据库，将收到以下警告：
我们已检测到你为此数据库配置了 Project Server 集成。 Team Foundation Server 2017 及更高版本将不再支持 Project Server 集成。
升级后，Project Server 集成将不再运行。
今后，我们将依赖于合作伙伴来提供集成解决方案。
有关此更改的详细信息，请阅读以下主题：将 TFS 与 Project Server 同步。
仪表盘和小组件改进
Team Foundation Server 2017 对多个小组件进行了改进，如查询图块和拉取请求小组件。
重新设计的组件目录
我们已重新设计了小组件目录，以便容纳不断增加的小组件集并提供更好的整体体验（图 16）。 新的设计改善了搜索体验，并重新设计样式以匹配我们的小部件配置面板的设计。
有关详细信息，请参阅小组件目录。
小组件更新
查询磁贴小组件现在支持最多 10 个条件规则，并且有可选择的颜色（图 17）。 当你想将这些磁贴用作关键绩效指标 (KPI) 以识别可能需要采取的健康和/或行动时，这非常有用。
Pull Request 小组件现在支持多种大小，允许用户调整小组件高度。 我们正在努力使我们发布的大多数小部件可以调整大小，请留意此处的更多更新。
新工作项小组件现在允许选择默认工作项类型，而不是强制选择要从下拉列表中反复创建的最常见类型。
我们已让 WIT 图表插件支持调整大小。 这使用户能够在仪表板上看到任何 WIT 图表的扩展视图（无论其原始大小如何）。
我们已更新团队成员小组件，以便更轻松地将人员添加到团队（图 18）。
现在，团队可以配置仪表板上查询结果控件的大小，使其能够显示更多结果。
“Sprint概述”小组件已重新设计，使团队能够更方便地确认他们是否步入正轨。
“已指派给我”小组件帮助用户在不离开仪表板上下文的情况下管理分配给他们的工作（图 19）。 通过提供专为此目的而设计的小组件，团队管理员只需不到 16 次单击，即可将此功能添加到其仪表板中，且无需上下文切换和键入。 用户现在可以在小组件上下文中对分配给自己的工作进行查看、排序、筛选和管理等操作。
仪表板接口 REST API
现在可以使用 REST API 以编程方式添加、删除和获取仪表板上的信息。 API 还允许你添加、删除、更新、替换和获取某个小组件上的信息或仪表板上的小组件列表。 文档在 Visual Studio 联机文档提供。
可允许的仪表板
非管理员用户现在可以创建并管理团队仪表板。 团队管理员可通过仪表板管理器限制非管理权限。
有关详细信息，请参阅仪表板。
Git 改进
在 Team Foundation Server 2017 的 Git 中进行了一些重大更改。 包括对分支页面的重新设计以及一个新的“压缩合并”选项。
重新设计的分支页
已彻底重新设计了分支页。 它具有“我的”视图，显示您已创建、推送或收藏的分支（图 20）。 每个分支显示其生成和拉取请求状态，以及删除之类的其他命令。 如果分支名称中存在斜线，如“features/jeremy/fix-bug”，它将显示为一个树，因此浏览大型分支列表很容易。 如果你知道你的分支的名称，则可以快速搜索找到所需分支。
有关分支的详细信息，请参阅管理分支。
新拉取请求体验
本版本中的拉取请求体验有一些重大更新，引入了一些真正强大的对比功能、新的评论功能体验和焕然一新的用户界面。
有关详细信息，请参阅使用拉取请求查看代码。
重新设计了 UI
打开拉取请求时，新的外观即呈现在眼前（图 21）。 我们已重新组织标头，将所有关键状态和操作汇总，以便从体验中的每个视图访问它们。
概述
概述现在会突出显示 PR 说明，提供反馈变得前所未有的轻松（图 22）。 事件和注释的显示方式是最新事项在上，便于审阅者查看最新的更改和注释。 提供了策略、工作项和审阅者的详细信息并对其进行了重新组织，以便更加简明扼要。
文件
本版本中最大的新功能是能够查看之前对拉取请求进行的更新（图 23）。 在之前的预览版中，我们发布了正确跟踪PR更新时评论变化的功能。 但，要查看两次更新之间的更改并不容易。 现在在“文件”视图中，你可以更精确地看到每次有新代码推送到你的拉取请求时，对哪些内容进行了更改。 如果你获得了有关一些代码的反馈，并且想在审阅时（独立于所有其他更改）查看其具体更改，这将非常有用。
更新
新的“更新”视图显示拉取请求随时间的变化情况（图 24）。 “文件”视图显示文件如何随时间变化，而“更新”视图则显示每次更新中增加的提交记录。 如果发生强制推送，“更新”视图将按历史中的发生顺序继续显示这些过去的更新。
现在支持使用Markdown和表情符号发表评论
在所有讨论中运用全部标记功能，包括格式设置、突出显示语法的代码、链接、图像和表情符号（图 25）。 注释控件也具有更加友好的用户编辑体验，允许一次编辑（然后保存）多个注释。
在拉取请求中添加和移除审阅者
现在可以更轻松地添加和删除拉取请求中的审阅者。 若要将审阅者或组添加到你的拉取请求，只需在审阅者部分中的搜索框中输入其（姓名）名称。 若要删除审阅者，在审阅者部分将鼠标悬停在其磁贴上，单击 X 即可删除（图 26）。
改进的生成和拉取请求可跟踪性
构建和拉取请求（PR）之间的可追溯性得到改进，使得从 PR 到构建再返回的导航更加轻松。 在由拉取请求触发的生成的生成详细信息视图中，源现在将显示指向排队生成的拉取请求的链接。 在构建定义视图中，任何由拉取请求触发的构建将在“触发者”列中提供到拉取请求的链接。 最后，“生成资源管理器”视图将在“源”列中列出拉取请求。
拉取请求的注释跟踪
改进了 VSTS 中的拉取请求功能，以在文件中正确的行上显示留下的注释，即使自注释添加后那些文件已被更改。 以前，即使文件内容已更改，注释始终显示在它们最初被添加时所在的文件的行上，换而言之，第 10 行上的注释将始终显示在第 10 行上。 有了这些最新的改进，代码后的注释会显示用户的意图，（如果在第 10 行添加了注释，且有两个新行随后添加到了文件开头，则注释将显示在第 12 行）。
这里是在第 13 行的注释处进行的示例更改 （图 27）：
甚至在代码已更改为将具有原始注释的行从第 13 行移位至第 14 行后，注释将会显示在预期位置（第 14 行）（图 28）。
自动完成的拉取请求在等待策略期间进行
使用分支策略来保护分支的团队将希望查看自动完成操作。 经常，拉取请求的作者已准备好合并他们的请求，但需要等待构建完成才能单击“完成”按钮。 其他时候，构建通过了，但有一个评审者尚未给予最终批准。 在这两种情况下，自动完成操作让作者将 PR 设置为在策略得到全部批准后立即自动完成（图 29）。
正如手动完成操作一样，作者有机会对合并提交消息进行自定义并选择适当的合并选项（图 30）。
设置了自动完成之后，PR 将会显示一个横幅，确认自动完成已设置好，并且正在等待策略完成（图 31）。
在满足所有策略后（例如生成已完成或已授予最终批准），将根据指定的选项和注释合并拉取请求（PR）。 如预期那样，如果存在生成失败或审阅者未批准的情况，拉取请求将保持活动状态，直到策略通过。
压缩合并拉取请求
完成拉取请求后，现在可以选择挤压合并（图 32）。 此新选项生成单个提交，此提交包含应用于目标分支的主题分支中的更改。 常规合并和压缩合并之间最明显的区别是，压缩合并提交只有一个父提交。 这意味着历史记录图表将更简单，因为对主题分支所做的任何中间提交在生成的提交图中将不可访问。
可在压缩合并拉取请求中查找更多详细信息。
提交可跟踪性
生成状态（成功或失败）现已清楚地显示在代码资源管理器和提交详细信息视图中（图 33）。 只需点击一下即可了解更多详细信息，因此您始终可以知道提交中的更改是否通过了构建。 还可以在生成定义的存储库选项中自定义哪些生成发布状态。 此外，提交详细信息视图的最新更改将提供有关所做更改的更深入的见解。 如果您使用拉取请求合并更改，您将会看到引入更改到主分支的拉取请求的链接（在合并提交的情况下，则是创建该合并提交的拉取请求）。 当您的更改到达主分支后，系统将显示一个分支链接，以确认这些更改已被包含。
在 Web 中查看 Git LFS 文件
如果已在 Git 中处理大文件（音频、视频、数据集等），就会了解 Git 大型文件存储 (LFS) 使用 Git 内的指针替换这些文件，同时将文件内容存储在远程服务器上。 此项更改使查看这些大文件的全部内容成为可能（只需单击存储库中的文件）。
有关详细信息，请参阅使用 Git 管理大文件。
创建和发送代码特定部分的链接
通过代码链接轻松地共享代码引用（图 34）。 只需在文件中选择文本，然后单击链接图标。 它将复制所选代码的链接。 当某个用户查看该链接时，你突出显示的代码将具有金色背景。 它甚至适用于部分行选择。
状态 API
现在可以在代码资源管理器和提交详情视图中清晰地看到构建过程的成功或失败 （图 35）。 点击即可了解更多详细信息，以便您始终知道提交中的更改是否通过了构建。 您还可以在构建定义的存储库选项中，自定义哪些构建发布其构建状态。
文件类型图标
在资源管理器、拉取请求、提交详情、搁置集、变更集或任何其他显示文件列表的视图中，您将看到与文件扩展名匹配的新文件图标（图 36）。
在创建存储库时添加ReadMe文件
新版 Git 存储库的创建过程得到了改进，让用户可以添加自述文件（图 37）。 向存储库添加 README 文件不仅可以帮助其他用户了解代码库的目的，还可以让你立即克隆该存储库。
生成改进
在此版本中，我们增加了日志的大小，添加了 Java 构建模板，并改进了 Xamarin 支持，这只是一些更改之一。
重新设计了生成队列选项卡
我们已为“构建队列”页面采用了新的设计，以便显示更长的队列和运行构建列表，体验更加直观（图 38）。
有关详细信息，请参阅管理生成系统。
启用生成结果扩展，以指定顺序和列
生成结果部分扩展现在可以指定显示的列以及显示它们的顺序（图 39）。 结果视图有两个列，且所有扩展默认位于第一列中。 注意：所有第三方扩展将出现在我们包含的生成结果部分之后。
生成行号
现在可以从生成错误跳转到导致该错误的代码行。 查看我们内部用作拉取请求策略的主要构建上的最新错误时，您会看到这个（图 40）：
构建日志视图支持更大规模的日志
以前的日志视图最多只支持 10,000 行。 新的查看器采用了 VS Code 所使用的 Monaco 编辑器，并支持最多 150,000 行日志。
Java 生成模板
通过对 Ant、Maven 和 Gradle 添加生成模板，使 Java 开发人员可以更轻松地开始生成（图 41）。
有关模板的详细信息，请参阅生成步骤。
Xamarin 生成任务
我们对 Xamarin 支持进行了一些重要改进：
- Xamarin.Android 步骤现在支持 Mac 和 Linux。
- Xamarin.iOS 步骤现在支持签名和打包。
- Xamarin 测试云结果可以显示在生成摘要页上。
- 新的 Xamarin 组件还原步骤。
- NuGet 安装程序步骤现在支持 Mac OS。
Xamarin 许可证步骤不再是必需的步骤，已从生成模板中将其删除。 作为这项努力的一部分，我们将逐步弃用该任务。 应将使用此任务的所有生成定义更新为删除此任务，以防止在最终删除此任务时发生任何中断。
最后，我们增强了 Xamarin 生成定义模板，以便使用这些新任务。 构建 Xamarin 应用。
适用于生成和发布管理的 Docker 集成
利用生成功能来生成 Docker 映像并将其上传到 Docker 中心，作为持续集成流的一部分（图 42）。 然后，将这些图像部署到大量 Docker 主机，作为 Release Management 的一部分。 市场扩展添加使用 Docker 所必需的所有服务终结点类型和任务。
拉取请求视图中的 SonarQube 结果
如果用于合并拉取请求的生成运行包含 SonarQube MSBuild 任务，那么您将看到新的代码分析问题作为讨论评论出现在拉取请求中（图 43）。 在 SonarQube 服务器上安装有插件的任何语言都适用这种体验。 有关详细信息，请参阅 SonarQube 代码分析问题集成到拉取请求博客文章。
为构建定义配置状态 API 报告
你现在可以选择哪些生成定义将其状态报告回 Git 状态 API。 如果你有许多生成给定存储库或分支的定义，但只有一个代表实际运行状况的定义时，这特别有用。
有关详细信息，请参阅生成 REST API 参考。
在团队会议室建立 vNext 支持
可以一直在团队聊天室中添加有关 XAML 构建的通知。 用户通过此冲刺还可以接收关于 vNext 构建完成的通知。
启用 Git CI 触发器的路径筛选器
托管的 Git 存储库的 CI 触发器可以包括或排除某些路径。 这使你可以将生成定义配置为仅在特定路径中的文件更改后运行（图 44）。
发布管理改进
自 Team Foundation Server 2015 中引入了基于集成式 Web 的 Release Management 以来，我们在此版本中进行了几处功能增强。
克隆、导出和导入发布定义
我们结合了发布中心内克隆、导出和导入发布定义的功能，无需安装扩展（图 45）。
有关详细信息，请参见克隆、导出和导入发布定义的文档。
“发布摘要”中显示的测试结果
在“发布摘要”页中，我们为外部服务启用了贡献点以显示特定于环境的信息。
在 Team Services 中，此功能用于显示测试作为发布环境的一部分运行时的测试结果摘要（图 46）。
有关详细信息，请参阅了解发布的摘要视图文档。
向脚本传递 OAuth 令牌
如果需要运行在 Team Services 上调用 REST API 的自定义 PowerShell 脚本以创建工作项或查询生成的信息，则需要在脚本中传递 OAuth 令牌。
配置环境时的新选项允许脚本在环境中作为任务运行以访问当前 OAuth 令牌（图 47）。
有关详细信息，请参阅环境的常规选项文档。
这是一个显示如何获取生成定义的简单示例（图 48）：
在部分成功部署时触发
生成和发布任务在“控制选项”参数中对每个任务均有“出错时继续”的选项。
在生成定义中，如果设置了此选项的任务失败，结果将为“生成已部分成功”。
同样的行为现在在发布定义中是可用的。 如果任务失败，则整个发布结果将显示为“发布已部分成功”（图 49）。
默认情况下，即使环境部署选项中指定了此行为，未完全成功的发布也不会自动触发对后续环境的发布。
但是，可以在每个发布环境中设置新选项（当上一发布已部分成功时，指示 Release Management 触发发布到后续环境）（图 50）。
有关详细信息，请参阅环境部署触发器文档。
使用直接存储在 GitHub 中的制品
有时你可能想要直接使用存储在版本控制系统中的项目，而无需通过生成过程传递它们，如本主题所述。
如果代码存储在 GitHub 存储库中，那么现在可以执行同一操作（图 51）。
有关详细信息，请参阅 TFVC、Git 和 GitHub 源文档。
使用 ARM 的 Web 应用部署
有新版本的 Azure Web 应用部署任务，称为 AzureRM Web 应用部署。
它使用 MSDeploy 和 Azure 资源管理器服务终结点连接。 除了基于 ASP.NET 4、Node 和 Python 的 Web 应用之外，使用此任务还可以部署 Azure Web 作业和 Azure API 应用。
此任务还支持常见发布选项，例如保留应用数据、使应用脱机和删除目标处的其他文件等功能。
更多功能（如配置转换）可能会在即将推出的版本中出现（图 52）。
任务组
通过“任务组”可将已在生成或发布定义中定义的一系列任务封装到可添加到生成或发布定义的单个可重用任务中，如同任何其他任务一样（图 53）。
可选择从封装任务提取参数作为配置变量，并提取任务信息的剩余部分。
新任务组将自动添加到任务目录，可以添加到其他发布和构建定义中。
有关详细信息，请参阅任务组文档。
发布的软删除
删除发布或根据保留策略被自动删除时，该发布会从概览和详情列表中移除。
但是，在它被永久删除之前将会在发布定义中保留一段时间（通常为 14 天）。
在此期间，它将显示在概述和详细信息列表的“已删除”选项卡上。
可以通过打开快捷菜单并选择撤消删除（图 54）来还原这些发布。
有关详细信息，请参阅还原删除的发布文档。
保留每个环境的发布和构建
版本定义的版本保留策略决定版本及相关联构建的保留持续时间。
默认情况下，发布会保留 60 天。 会自动删除在此期间没有部署或修改的发布。
但是，你可能想要保留更多已部署到特定环境的发布（如你的生产环境），或让其保留的时间长于刚部署到其他环境中的发布（如测试、暂存和 QA）。
如果需要重新部署该发布，还可将链接到发布的生成保留与发布同样的时间，以确保项目可用（图 55）。
有关详细信息，请参阅发布和生成保留文档。
链接的工件改进
两个新功能让处理构件和构件源变得更轻松：
- 您可以将多个制品来源链接到一个发布定义（图 56）。 每个构件都将下载到代理上名为“源别名”的文件夹中。 现在可以编辑链接项目的源别名。 例如，更改生成定义的名称时，可编辑源别名来反映生成定义的名称。
- 公开了许多 Build.* 格式（如 Build.BuildId 和 Build.BuildNumber）的变量以用于任务参数。 现在，当多个源与一个发布关联时，变量将使用您指定为主源的工件源中的值进行填充。 有关详细信息，请参阅项目变量文档。
部署 - 手动干预任务
现在，可以在部署到环境的过程中暂停执行。
在环境中包括手动干预任务让你能够暂时停止部署、执行手动步骤，然后继续进一步的自动步骤。
手动干预后，还可拒绝部署和阻止进一步执行步骤（图 57）。
有关详细信息，请参阅手动干预文档。
SQL 数据库部署任务脚本
增强了Azure SQL 数据库部署（图 58）任务，使其可以对 Azure SQL 数据库运行 SQL 脚本。 这些脚本可以作为文件提供，或者内嵌在任务中。
发布定义摘要 - 仪表板微件
将发布定义固定到仪表板上，这是一种简便的方法，可以让你所有的团队成员看到该定义的发布摘要。
有关详细信息，请参阅 将发布信息添加到仪表板 文档。
在特定时间将版本部署到指定环境
希望你所有的生产部署都在午夜进行吗？ 可以对从其他环境选择了成功部署（或最新部署）的环境配置一个条件，并可在特定时间对其部署（图 59）。
在多个环境中基于条件进行部署
直到上一版本，你可以进行并行部署（forkdeployments），但无法根据多个环境的状态启动到某个环境的部署（join deployments）。 你现在可以实现此操作。
有关详细信息，请参阅 并行分叉和联接部署文档。
适用于 Release Management 的 REST API
你可以使用 Release Management 的 REST API 服务来创建发布定义和发布，并管理部署发布的多个方面。
有关详细信息，请参阅 API 参考文档。
服务钩子集成
在创建新的发布、开始或完成部署时，或在审批处于挂起或完成状态时，发送发布通知。 与第三方工具（如 Slack）集成以接收此类通知。
部署到国内 Azure 云
在 Azure 经典服务终结点使用新的环境设置，将特定 Azure 云设为目标，包括预定义的国内云（如 Azure China 云、Azure US Government 云和 Azure German 云）。
有关详细信息，请参阅 Azure 经典服务终结点文档。
测试改进
在 Team Foundation Server 2017 中添加了关键测试改进。
更新后的测试结果存储架构
在此版本中，我们会将测试结果项目迁移到新的紧凑且高效的存储架构中。 考虑到测试结果是 TFS 数据库中占用存储空间最多的内容之一，我们希望此功能能转化为降低 TFS 数据库的存储占用。 对于从早期版本的 TFS 升级的客户，测试结果将会在 TFS 升级期间迁移到新架构。 此升级可能会导致升级时间较长，具体取决于你的数据库中存在多少测试结果数据。 建议配置测试保留策略，等待策略生效并降低测试结果使用的存储空间，以便加快 TFS 升级速度。 在安装 TFS 后，但在升级 TFS 实例前，你可以使用 TFSConfig.exe 工具来清理测试结果。 有关详细信息，请参阅 TFSConfig.exe 帮助。 如果无法灵活地配置测试保留或在升级前清理测试结果，请确保对升级窗口进行相应的计划。 有关配置测试保留策略的更多示例，请参阅 Team Foundation Server 2015 的测试结果数据保留。
测试中心改进
测试中心的测试配置管理
通过在测试中心内添加新的“配置”选项卡，将测试配置管理引入了 Web UI （图 61）。 现在，你可以从测试中心内创建和管理测试配置及测试配置变量。
有关详细信息，请参阅创建配置和配置变量。
将配置分配给测试计划、测试套件和测试用例
分配配置变得更容易。 可以直接从测试中心内将测试配置分配给测试计划、测试套件或测试用例（图 62）。 右键单击某个项目，选择“将配置分配到…”，即已完成并开始运行。 还可以在测试中心内按配置进行筛选（图 63）。
有关详细信息，请参阅将配置分配到测试计划和测试套件。
查看“测试结果”窗格中的测试计划/测试套件列
我们已向“测试结果”窗格添加了新列，显示在执行测试结果时所采用的测试计划和测试套件。 当深化了解测试结果时，这些列提供急需的上下文（图 64）。
测试中心内和卡片上的测试顺序
现可在测试中心内对手动测试进行排序（图 65），不考虑包含它们的套件类型：静态、基于要求的或基于查询的套件。 你可以简单地拖放一个或多个测试或使用上下文菜单来对测试进行重新排序。 完成排序后，可以按“顺序”字段对测试进行排序，然后从 Web 运行程序以该顺序运行它们。 也可以直接在看板上的“用户情景”卡上对测试进行排序（图 66）。
在测试中心内对测试套件进行排序
测试团队现可按需对测试套件进行排序。 在推出此功能以前，套件只能按字母顺序排序。 现在，通过使用测试中心的拖/放功能，套件可以在对等套件间重新排序或移动到层次结构中的另一套件（图 67）。
在分配测试人员过程中搜索用户
作为在不同中心推出的新标识选择控件的一部分，在测试中心，我们还启用了在将测试人员分配到一个或多个测试时搜索用户的选项（图 68）。 对于拥有较大的团队成员数量，但上下文菜单仅显示有限的条目集的方案来说，此功能非常有用*（图 69）。
选择一个进行测试的版本
现在可以选择您想要测试的“构建”，然后在测试中心使用“使用选项运行”来启动 Web 运行程序（图 70）。 运行过程中提交的任何 bug 都会自动与所选构建关联。 针对特定构建，还发布测试结果。
使用数据收集器从测试中心启动 Microsoft 测试运行程序客户端
现可选择数据收集器和数据生成来与测试运行相关联（图 71），并从测试中心以高性能方式启动 Microsoft 测试运行程序 2017（客户端），而无需在 Microsoft 测试管理器客户端中对其配置。 Microsoft 测试运行程序可在不打开整个 Microsoft 测试管理器 shell 的情况下启动，并将在测试执行完成后关闭。
有关详细信息，请参阅为桌面应用运行测试。
在测试中心选择数据收集器并启动探索性运行程序客户端。
现在，你可以从测试中心高效地选择你的数据收集器并启动探索运行程序 2017（客户端），而无需在 Microsoft 测试管理器客户端中对其配置。 在基于需求的套件中，调用上下文菜单中的‘使用选项运行’（图 72），然后选择需要的探索运行程序和数据收集器。 探索运行程序的启动方式与前面所述的 Microsoft 测试运行程序的启动方式类似。
为跨不同测试套件的测试配置测试结果
我们现在已增加了为在同一测试计划下的不同测试套件之间共享的测试配置测试结果行为的功能（图 73）。 如果选择了此选项，并且您从测试中心、Web 运行程序、Microsoft 测试运行程序或看板上的卡片中设置了某个测试的结果（标记为通过/失败/已阻止），那么该结果将传播到同一测试计划下具有相同配置的所有其他测试套件中的测试。 用户可以从测试中心的测试计划上下文菜单或通用设置配置对话框中的看板测试页面设置特定测试计划的“配置测试结果”选项。 此选项默认关闭，需要显式启用它，才能使之生效。
验证任务项中的 bug
现在可以通过重新运行识别到故障的测试来验证问题（图 74）。 可从 bug 工作项窗体上下文菜单调用“验证”选项在 Web 运行程序中启动相关测试用例。 使用 Web 运行程序执行验证，并直接在 Web 运行程序中更新 bug 工作项。
适用于测试计划/测试套件克隆的 REST API
我们已添加用于测试计划克隆和测试套件克隆的 REST API。 你可以在我们的 Team Services 集成网站上的测试管理部分下找到它们。
从看板卡中查看测试进度
现在，您可以直接从看板上的用户故事中添加、查看测试用例并与其进行交互。 使用新的“添加测试”菜单选项创建链接测试用例，然后在操作进行时直接从卡片监视状态（图 75）。
使用这项新功能，现在可以直接从看板上的卡片执行以下操作：
- 添加测试。
- 打开测试。
- 通过从一个用户情景拖/放到另一个来重新设置测试的父级。
- 使用 CTRL+ 拖/放将同一测试复制到另一个用户情景（适用于同一测试用例测试多个用户情景的方案）。
- 通过快速将其标记为通过/失败/等更新测试状态。
- 通过在 Web 测试运行程序中启动该测试，你可以使各个步骤通过或失败、记录 bug 等。
- 查看汇总状态摘要，其中显示该项目已通过的测试数量和剩余的测试数量。
如果需要高级测试管理功能（比如分配测试程序、分配配置、集中的参数、导出测试结果等），你可以切换到测试中心，开始使用已自动为你创建的默认测试计划/基于要求的套件。 有关详细信息，请参阅添加、运行和更新内联测试。
从卡片遍历至测试计划/测试套件
现在，你可以直接从看板上的卡片轻松导航到相关的测试计划或测试套件，在其中创建测试。 单击此链接（图 76）会转到测试中心，打开正确的测试计划，然后选择控制这些内联测试的特定套件。
看板的常用设置配置中测试页面
使用看板的常规设置配置对话框中的新测试页，控制创建内联测试的位置的测试计划（图 77）。 以前，卡片上创建的任何测试会被自动添加到新创建的测试计划（如果不存在与卡片的区域和迭代路径相匹配的测试计划）。 现在可以通过配置所选的现有测试计划来替代此行为，然后所有测试都将添加到所选的测试计划。 请注意，只有在测试批注已启用的情况下才能使用此功能。
Web运行器增强功能
在手动测试过程中添加测试步骤附件
我们已增强 Web 测试运行程序，可在手动测试过程中添加测试步骤附件（图 78）。 这些步骤结果的附件会自动显示在你在会话中报告的任何缺陷内，并随后显示在“测试结果”窗格中。
Web 运行程序中的屏幕截图、屏幕录制、图像操作日志和系统信息支持（使用 Chrome 浏览器）
在 Chrome 中使用 Web 运行程序时，现可截取屏幕截图并对其进行内联批注（图 79）。 还可以捕获不仅 Web 应用，还有桌面应用的按需屏幕录制。 会自动将这些屏幕截图和屏幕录制添加到当前测试步骤。 除了屏幕截图和屏幕录制以外，现在还可以从你的 Web 应用捕获按需图像操作日志。 需要在浏览器窗口上指定捕获操作的位置 - 该窗口（该窗口中打开的任何现有或新选项卡）上的所有操作或你启动的任何新的子浏览器窗口将自动被捕获，并与在 Web 运行程序中测试的测试步骤相关。 这些信息包括屏幕截图、屏幕录制和图像操作日志，随后将被添加到运行期间您提交的任何 bug，并附加在当前的测试结果上。 同样，系统信息数据会自动捕获，并作为您从 Web 运行程序提交的任何 bug 的一部分包含在内。 所有这些都利用了基于 Chrome 的测试和反馈扩展中的功能。
有关详细信息，请参阅在测试过程中收集诊断数据。
作为子任务归档的软件缺陷——Web Runner/测试和反馈扩展
当在 Web 测试运行器中运行测试时，无论是从看板上的卡片启动，还是从测试中心中的基于需求的套件启动，所有新提交的 Bug 现在都将被自动创建为该用户故事的子级。 同样，如果要从探索测试扩展浏览用户情景，任何存档的新 Bug 也将被创建为该用户情景的子级。 这一新行为使情景和 Bug 中的可跟踪性更简单。 只有当“通用设置配置”页中的“与 Bug 一起工作”设置为“Bug 不出现在 backlog 或板上”或“Bug 出现在带有任务的 backlog 和板上”时，此行为才适用。 对于“处理 bug”选项的所有其他设置，以及某些其他情况下（例如在一个已定义父级的现有 bug 上进行添加操作），则会创建一个相关链接。
从 Web 执行器更新现有 bug
除了通过 Web 运行程序创建新 bug，现在您还可以更新现有的 bug （图 80）。 所有收集的诊断数据、重现步骤以及当前会话中的可追踪链接都会自动添加到现有的缺陷中。
测试与反馈插件 - 改进
可从 Visual Studio Marketplace 安装基于浏览器的测试和反馈扩展。 它支持 Visual Studio Team Services 和 Team Foundation Server（2015 或更高版本）。
查看工作项
现在，可以对特定的工作项进行探索测试（图 81）。 可将选定的工作项与正在进行的测试会话相关联，并从扩展内部查看验收条件和说明。 还可在存档于所选工作项上的 bug 或任务之间实现端到端可跟踪性。 您可以直接从工作项或通过扩展进行探索。
• 直接从工作项（图 81）：使用上下文菜单中的“执行探索测试”选项，从产品内直接启动特定工作项的探索测试会话。 我们已在所有卡片、网格上和测试中心内添加了入口点。
• 在扩展中（图 82）：从 XT 会话内搜索工作项，然后将其与正在进行的会话相关联。
有关详细信息，请参阅使用测试和反馈扩展探索工作项。
使用测试和反馈捕获图像操作日志、屏幕录制和网页加载数据
图片操作日志：扩展程序提供了一个新选项，只需一键即可自动添加导致出现 bug 的步骤。 选择“包括图像操作日志”选项（图 83）来捕获鼠标、键盘和触控操作，并将相应的文本和图像直接添加到 bug 或任务中。
将屏幕录制为视频：您还可以使用扩展功能随需录制屏幕。 这些屏幕录制不仅可以从 Web 应用捕获，还可以从你的桌面应用捕获。 您可以使用扩展的“选项”页，将扩展配置为自动停止屏幕录制，并将其附加到提交的 bug 报告中。
网页加载数据：我们已向扩展添加新的背景捕获功能，即“网页加载”数据的捕获。 “图像操作日志”在背景中以图像形式捕获在探索 Web 应用时执行的操作，与此类似，“网页加载”功能自动捕获网页的详细信息以完成加载操作。 你可以不再依赖于网页加载的主观或感知的慢速，现在可以客观地量化 bug 中的慢速。 一旦提交 bug 后，除了平铺视图之外，还会附上一份详细的报告，帮助开发人员进行初步调查。
基于图像操作日志数据创建测试用例
在您进行探索性会话时创建测试用例，包含图像的测试步骤将为您自动填充（图 84）。 同步测试设计和测试执行是真正探索测试的基础，而这项新功能使之成为现实。 可以编辑捕获的文本、添加期望的结果、取消选中不相关的行，并将其保存用于即将进行的测试通过/运行。
有关详细信息，请参阅创建基于图像操作日志数据的测试用例。
探索性测试会话的见解
现在可以查看给定时间段内使用测试和反馈扩展创建的已完成探索测试会话（在团队或个人级别）。 在 Web 访问中，单击测试中心组内的运行中心中的“最近的探索会话”链接，即可访问此见解页面。 此新视图可帮助你获得有意义的见解，包括：
- 摘要视图显示已浏览工作项的详细信息、新创建的工作项、会话所有者，以及这些会话所消耗的总时间（图 85）。
- 可按照浏览的工作项、会话、会话所有者或者不按照任意项来透视分组依据视图。 对于任何关键点，您可以查看所有已创建工作项的列表，如 Bug、任务、测试用例，或将列表范围缩小到特定的工作项类型。
- 显示在分组视图中选定内容基础上信息的详细信息窗格。 对于选定的透视行（例如已探索的工作项），你可以在详细信息窗格中查看其摘要信息，如总会话数、花费在这些会话上的总时间、探索过它的会话所有者，以及针对它创建的 Bug、任务和测试用例，以及它们的状态和优先级。 对于选定的工作项行，可以直接查看其工作项表单，并根据需要进行更改。
有关更多信息，请参阅获取整个探索性测试会话的见解。
探索性测试会话：查看尚未探索的工作项
除了在“最近的探索会话”视图中查看所有探索的工作项的详细信息（按给定的数据范围的所有/我的会话筛选），我们现在还在同一视图中添加了查看所有未探索的工作项列表的功能（图 86）。 通过为你感兴趣的工作项指定共享查询开始，会话页显示来自查询的所有工作项的列表，并对摘要部分中的已探索和未探索项进行了细分。 此外，使用透视表按“未探索工作项”进行分组可以查看尚未探索的项目列表。 对于跟踪尚未探索或尚未进行 bug bash 的用户故事数量，此功能非常有用。
端到端利益干系人反馈流
请求反馈
具有基本访问级别的用户现在可以使用工作项菜单中的“请求反馈”选项，直接从相关方请求对于正在进行或已完成的功能/用户故事的反馈（图 87）。 这将打开请求反馈窗体，您可以在其中选择希望获取反馈的利益相关者，并可选择提供一组简单说明，提示希望获得意见的产品领域。 这会将个人邮件以及（如有）提供的说明一起发送给所选的利益相关者。
有关详细信息，请参阅使用测试和反馈扩展请求利益干系人反馈。
提供反馈
利益干系人可通过单击所接收邮件中的“提供反馈”链接来回应反馈请求，其将自动使用所选反馈请求（如果尚未安装，将提示安装扩展）配置测试和反馈扩展（以前称为探索测试扩展）。 然后，利益干系人可以使用该扩展的完整捕获功能来捕获其发现和以反馈响应/bug/任务工作项的形式来提交反馈意见。 此外，利益干系人可以导航到“反馈请求”页，以便在一个位置查看接收到的所有反馈请求。 从列表中，可选择想要对其提供反馈的反馈请求、通过将请求标记为完成或拒绝请求来管理“挂起反馈请求”（图 88），还可通过单击所需单选按钮在不同类型的反馈请求之间进行切换（图 89）。
有关详细信息，请参阅使用测试和反馈扩展提供反馈。
自发反馈
除了上述经请求的流之外，利益相关者还可使用扩展功能提供自愿反馈（图 90）。 他们可以打开扩展、在连接设置页中选择“已连接”模式并连接到帐户和希望向其提供反馈的项目/团队。 然后，他们可以使用该扩展来捕获其发现和以反馈响应/bug/任务工作项的形式来提交反馈意见。
有关详细信息，请参阅使用测试和反馈扩展提供自发反馈。
自动测试改进
在生成/发布摘要中的“测试”选项卡查看控制台日志和测试持续时间。
将提取在 .trx 文件中捕获的测试结果控制台日志，并将其作为测试结果附件发布（图 91）。 可选择在“测试”选项卡中进行预览，且不再需要下载 trx 文件来查看日志。
构建的测试趋势小组件
我们向小组件库中添加了新的“测试结果趋势”小组件（图 92）。 使用此小组件，在仪表板上为某个生成定义添加最多 30 次最近生成的测试结果趋势图表。 控件配置选项可帮助你自定义图表以包含关键点（如已通过测试数、未通过测试数、总测试数、通过率和测试持续时间）。
发布环境的测试状态摘要
建议使用发布环境来部署应用程序并对其运行测试。 在此版本中，我们在“发布”摘要页的“环境”部分集成了发布环境的测试通过率（图 93）。 如屏幕截图中所示，若某个环境失败，你可以通过查看测试列迅速推断该故障是否由失败的测试导致。 你可以单击通过率以导航到“测试”选项卡，并查看该环境中失败的测试。
分支和发布环境的自动测试历史记录
通常情况下，单个测试会在多个分支、环境和配置上运行。 当此类测试失败时，必须识别此次失败是否被包含到开发分支（如主分支）或此次失败是否也影响部署到生产环境的发布分支。 现在可以通过查看“结果摘要”页面中的“历史记录”选项卡来显示正在测试的各个分支的测试历史记录（图 94）。 同样，你可以通过环境轴进行分组，以可视化测试在不同发布环境中运行的历史记录。
持续测试的可跟踪性
用户现在可以直接在仪表板上跟踪其要求的质量（图 95）。 针对我们计划测试的用户，我们已有解决方案来提升需求质量，并且我们计划将这一解决方案提供给我们使用持续测试的用户。 用户可以将自动化测试直接链接到需求，然后使用仪表板小部件跟踪您感兴趣的需求的质量，并从生成或发布中提取质量数据。
远程测试 - 基于计算机数量分布测试
我们让程序集内的测试能够分布给使用运行功能测试任务的远程计算机（图 96）。 在 TFS 2015 中，你只能在程序集级别分配测试。 可以使用以下任务中的复选框来启用此功能。
对 SCVMM 和 VMWare 的自动测试
用户可以使用 Azure 在云中或使用 SCVMM 或 VMWare 在本地动态设置测试计算机，并使用这些计算机以分布式方式运行自己的测试。 用户可以使用其中一种计算机设置任务（Azure、SCVMM 或 VMWare）后接“运行功能测试”任务来运行测试。
Maven 和 Gradle 任务中的 SonarQube 分析
现在，您可以通过选择“运行 SonarQube 分析”选项，并提供终端、SonarQube 项目名称、项目密钥和版本来在 Maven 和 Gradle 构建任务中触发 SonarQube 分析（图 97）。
现在您还将在 SonarQube 项目页面上获取一个链接（图 98）。 可以请求完整的分析，以查看质量要求详细信息；如果不符合这些要求，则可以选择中断生成。
有关详细信息，请参阅 Gradle 生成任务现在支持 SonarQube 分析。
市场改进
现在，项目集合管理员可以从 Team Foundation Server 浏览到 Visual Studio Marketplace，并在团队项目集合中安装免费扩展。 扩展会自动从 Visual Studio Marketplace 下载，上传到 Team Foundation Server，并在所选的团队项目集合中安装（图 99）。
购买并安装付费扩展
现在，项目集合管理员可以从 Team Foundation Server 浏览到 Visual Studio Marketplace，购买付费扩展，并在选定的团队项目集合中安装扩展（图 100）。 管理员可以通过 Azure 订阅为扩展付费，并选择要分配给这些扩展的用户数。 这些扩展会自动从 Visual Studio Marketplace 下载，上载到 Team Foundation Server，并在所选的团队项目集合中安装。
有关详细信息，请参阅获取用于 Team Foundation Server 的扩展文档。
管理改进
Windows 身份验证
在之前的版本中，配置已加入域的 TFS 部署时，需要在 NTLM 或 Negotiate 安全支持提供程序之间为 Windows 身份验证做出选择。 在 2017 中，我们从配置体验中删除了此设置。 如果想在 2017 中继续使用 NTLM 身份验证，无需采取任何措施。 如果一直都在使用 Kerberos 身份验证，并想在 2017 中继续使用，无需采取任何措施。 TFS 2017 现在始终按此顺序配置 Negotiate 和 NTLM 安全支持提供程序。 采用此配置后，会尽可能使用 Kerberos 身份验证，以提高安全性。 无法使用 Kerberos 时，则使用 NTLM 身份验证。 我们进行了广泛测试，确保使用 NTLM 身份验证时不会因这种改变而对现有 TFS 部署产生任何影响。
新式导航体验
在此版本中，我们启用了新的和改进的顶部导航栏。 对新的导航栏有两个核心目标：
- 通过一次单击，快速允许你访问任何中心，从而提高了跨产品区域的导航效率。
- 为产品带来现代视觉审美和用户体验。
因为对用户来说，这是一项较大的更改，且该功能仍在迭代中，所以我们决定将新的导航 UX 在默认情况下设为关闭状态。 若想尝试新的导航，可以通过转到 Team Foundation Server 管理区域控制面板，并选择“打开新的导航”来启用它。 请注意，这将对服务器中的所有用户启用该功能。
团队项目重命名权限
控制哪些用户可以重命名团队项目的权限已更改。 以前，具有团队项目的编辑项目级信息权限的用户可以对其重命名。 现在通过新的重命名团队项目权限，可以授予或拒绝用户重命名团队项目的能力。
管理设置工作中心
我们已在管理设置页中引入新的“工作”中心，将常规设置（图 101）、迭代和区域合并在单个选项卡内。进行此更改后，用户将看到项目级别设置和团队设置之间的明显区别。 对于团队设置，用户将只看到与其团队相关的区域和迭代。 在项目级别中，设置页将使管理员能够管理整个项目的区域和迭代。 此外，对于项目区域路径，已增添了一个名为“团队”的新列，便于管理员轻松快速明确哪些团队选择了特定区域路径。
流程配置 REST API
此公共 API 使用户能够获得给定项目的进程配置。 进程配置包含以下设置：
- TypeFields：在敏捷工具中使用的可自定义字段的抽象概念。 例如，“情景点”字段的类型为“Effort”。
- 积压工作定义：定义位于每个积压工作上的工作项类型。 这是客户在开发扩展时经常请求的 API。 借助此数据，扩展可以知道如何利用特定于进程的字段在敏捷工具中启用常见方案（如更改工作项的活动或工作量、了解给定积压工作级别中包括的工作项或确定按区域路径还是自定义字段标识团队）。 有关详细信息，请参阅 工作概述
基于前缀的 AD 搜索的新管理员体验
Team Foundation Server 2017 引入了管理组和组成员资格的新体验。 你可以使用用户/组名称的基于前缀的搜索条件在 Active Directory 或本地计算机用户/组中搜索。 例如，“John D”和 samaccountname（例如“businessdomain\johbdnd”）要查看用户或群组的联系人卡片。
用户安全性设置
可以在新的“我的安全”体验中管理个人访问令牌和 SSH（图 102）。 使用“我的配置文件”管理 SSH 的用户，现在需要在用户安全性设置中管理 SSH 公钥（图 103）。
统一配置向导
早期版本中，可根据想要尝试的操作为 TFS 部署选取多个配置向导之一。 基本和完整向导可用于配置新部署；更新向导可用于生产和预生产升级；应用层专用向导可用于各种方案，包括扩展现有部署、将应用层替换为新硬件等。 TFS 2017 中，所有这些方案被统一为单个服务器配置向导，通过要求你作出简单的选择来指导你完成每个方案。 此外，高级配置（如预生产升级和克隆现有部署）现在可自动完成操作（过去通过 tfsconfig.exe 完成），包括更改服务器 ID、重新映射数据库连接字符串以及删除对外部依赖项的引用（过去通过 tfsconfig.exe PrepareClone 完成）。
新的访问级别
新 Visual Studio Enterprise 组添加到 Team Foundation Server 的“访问级别”管理门户后，可以快速确定拥有 Visual Studio Enterprise 订阅的用户。 确定后，对于从 Visual Studio Marketplace 安装的所有第一方 TFS 扩展，这些用户将获得完全访问权，无需支付额外费用。
个人访问令牌
除了 SSH 外，你现在可以使用个人访问令牌连接到任何 Team Foundation Server。 如果你在 Linux 或 Mac 上进行开发并希望在任何自动化工具和 GIT 中使用，此功能非常有用。 你可以在用户安全性设置页面管理你的个人访问令牌。
已知问题
这是此发布中已知问题的完整列表。
没有适用于 Team Foundation Server 2017 的 Power Tools
问题：
未发布适用于 TFS 2017 的 Power Tools。
解决方法：
非常高兴通知你，已将大多数之前的 Power Tools 集成到 TFS 2017。 但是未集成过程模板编辑器，不过可以在 Visual Studio Marketplace 中获取该编辑器。
更新自定义控件扩展
问题：
工作项窗体上字段的架构已更改。 自定义控件扩展的文档也发生了更改。
解决方法：
请参阅新文档：将自定义控件添加到工作项窗体。
导入工作项类型定义时出错
问题：
如果客户安装了工作项页面扩展，并导出后再导入工作项类型定义，他们将会收到以下错误信息：“未声明 'LayoutMode' 属性”。
解决方法：
每次导出工作项类型定义时，都会在 PageContribution 元素上出现额外的 LayoutMode 属性。 导入定义前，搜索 PageContribution 模式并删除 LayoutMode 属性。 例如，删除 LayoutMode="FirstColumnWide"。
客户应更新到 Git LFS 1.3.1 版或更高版本
问题：
未来版本中将不再支持早于 1.3.1 的 Git LFS 版本。
解决方法：
强烈建议使用 Git LFS 的客户更新到 Git LFS 1.3.1 版或更高版本。 LFS 客户端的早期版本与此版 TFS 中的身份验证更改不兼容。 为了给客户提供时间进行迁移，我们为 RTW 实施了短期解决方法。 将会在 Update 1 中删除该解决方法，届时低于 1.3.1 版的 Git LFS 客户端将不再起作用。
NuGet 还原未找到存在于 nuget.org 上的包
问题：
使用 NuGet 3.4.3 或更高版本时，NuGet 还原任务不会还原 NuGet.org 中的包，除非它是 NuGet.Config 中的显式源。
解决方法：
确保 NuGet.org 位于 NuGet.Config 中。
<packageSources><add key="nuget.org" value="https://api.nuget.org/v3/index.json" protocolVersion="3">
</packageSources>
NuGet 生成和发布任务不进行身份验证
问题：
使用 Team Foundation Server（简称TFS）/软件包管理时，如果代理以“网络服务”用户身份运行，则 NuGet 构建和发布任务不会对源进行身份验证，因为这是构建代理作为服务运行时的默认设置。 这是因为 3.5 以前的 NuGet 版本使用用户帐户的凭据（而不是生成任务提供的凭据）运行生成代理。
解决方法：
若要借助作为“网络服务”运行的代理，将 NuGet 生成/发布任务与 TFS 源结合使用，必须使用 NuGet 3.5 及更高版本。
NuGet 任务的生成和发布使用代理凭据
问题：
3.5 以前的 NuGet 版本使用用户帐户的凭据（而不是生成任务提供的凭据）运行生成代理。 这可能会导致意外访问或无法访问订阅源。
解决方法：
对 TFS 生成代理使用 NuGet 3.5 或更高版本。
外部扩展不会在升级 TFS 时自动升级
问题：
如果从 Visual Studio Marketplace 下载扩展并将其发布到 TFS 2015 安装，然后升级到了 TFS 2017，则在新版本的扩展发布到市场时，该扩展不会自动更新。
解决方法：
升级到 TFS 2017 后，卸载已在 TFS 2015 中安装的扩展。 然后重新安装最新的扩展。 在 TFS 2017 中，我们添加了一项功能，用于每天自动检查一次已更新的外部扩展并将其升级。
无法在发布定义中运行 Jenkins 队列作业任务
问题：
在发布定义中运行 Jenkins 队列作业任务时，客户会收到 500 服务器错误。
解决方法：
目前，Jenkins 队列作业任务可作为 TFS 生成定义的一部分运行，但对发布定义不适用。 将在未来版本中添加此功能。
需要针对 TFS 2017 DLL 重新生成自定义 TFS 服务器插件
问题：
自定义 TFS 服务器插件在升级到 TFS 2017 后无法工作。
解决方法：
针对 TFS 2017 程序集重新生成自定义服务器插件。
自 TFS 2015 RTM 开始，自定义 TFS 服务器插件的服务器对象模型已更改
问题：
自定义 TFS 服务器插件无法编译。
解决方法：
按照本篇博客文章中所述修复源代码。
使用管理员操作时，将引发异常
问题：
在“警报管理”页中，当团队管理员使用“查找特定用户的警报”搜索来查找团队的订阅时，可能会收到异常。
解决方法：
选项 1：单击“全部警报”节点，然后将“所有我的团队警报”筛选器设置为显示。 这将显示用户有权访问的所有组的全部警报。
选项 2：如果该组是一个团队，请勿按团队名进行搜索，而是导航到该团队的“警报管理”页来管理订阅。
在 Team Build / Release Management 中使用任务运行功能测试时出现问题
问题：
在 Team Build/ Release Management 中使用任务目录中的“Visual Studio 测试代理部署”和“运行功能测试”任务运行功能测试 - 该操作当前使用 Agents for Visual Studio 2015 Update 3，且只能用于运行使用 Visual Studio 2013 和 Visual Studio 2015 生成的测试。 这些任务不能用于运行使用 Visual Studio 2017 RC 生成的测试。 有关详细信息，请参阅此博客文章。
解决方法：
目前没有解决方法。 将在 TFS 2017 Update 1 时间范围内添加对以下内容的支持：使用 Test Agent 2017 以及运行通过 Visual Studio 2017 生成的测试。
扩展未自动更新
问题：
如果将以前版本的 TFS 升级到 TFS 2017，并在连接模式下运行 TFS 2017，那么扩展将不会按正常情况自动更新。
解决方法：
此时没有解决办法。 该问题已解决，自动更新功能将在 TFS 2017 Update 2 中推出。 如果由于某种原因等不到 Update 2，请通过支持渠道与我们联系，我们会提前共享该修复程序。
如果遇到阻止你在生产环境 (Go-Live) 中部署的问题，请联系 Microsoft 产品支持。 （仅英语）仅限美国营业时间（太平洋标准时间，周一至周五，每天早上 6 点至下午 6 点），1 个工作日内答复。
请参阅客户报告的有关 Team Foundation Server 2017 的问题。
反馈和建议
我们期待你的宝贵意见和建议！ 可以通过开发者社区建议功能、报告并跟踪问题，并能在 Stack Overflow 上了解相关建议。