Team Foundation Server 2017 发行说明
开发者社区 | 系统要求和兼容性 | 许可条款 | 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） 窗体具有全新的界面外观。 它还添加了一些出色的新功能：
- 丰富的工作项讨论体验。
- 支持拖放附件。
- 改进的历史记录体验（History & auditing（历史记录和审核））。
- 改进的代码和生成集成。
- 状态着色。
- 响应式设计。
注意
仅当用于新集合时，才默认为新工作项窗体。 如果要迁移现有集合，则需要通过管理员设置启用新工作项窗体。 有关详细信息，请参阅 Manage roll out of the new web form（管理新 Web 窗体的推出）。
跟踪工作项
现在只需通过单击窗体中的新“关注”按钮 （图 4） ，就可以设置用于跟踪单个工作项的更改的警报。 在跟踪工作项时，将随时收到工作项更改的通知，包括字段更新、链接、附件和注释。
有关详细信息，请参阅 关注工作项。
看板实时更新
你的看板现在是实时的！
你是否按了 F5 以在看板中查看一整天的内容？ 请尝试使用下面屏幕截图 （图 5） 中的图标。
当你团队中的任何人在板上创建、更新或删除工作项时，你将立即在板上收到实时更新。 此外，如果管理员进行看板或团队级别更新，如添加新列或启用积压工作上的 Bug，将通知你刷新看板以更新看板布局。 只需启用看板上的“塔”图标并开始与团队协作。
有关详细信息，请参阅看板基础知识。
清单改进
我们已经对清单的工作方式做出了几处改进。
清单标题现在显示为超链接 （图 6） 。 你可以单击标题以打开工作项窗体。
清单现在还支持上下文菜单，可通过其打开、编辑或删除清单项 （图 7） 。
有关详细信息，请参阅添加任务清单。
长篇故事和功能板向下钻取
现在可以向下钻取长篇故事和功能板 （图 8） 。 清单格式可让你轻松将工作标记为已完成，并提供已完成工作与未完成工作的便利鸟瞰视图。
有关详细信息，请参阅看板功能和长篇故事。
打开/关闭看板批注
我们为你提供了对显示在看板上卡片中的附加信息的更多控制。 现在可以选择想要在看板卡上查看的批注 （图 9） 。 只需取消选中批注，它即会从看板上的卡片中消失。 将在此处显示的前两个批注是子工作项（此示例中的任务）和测试批注。
有关详细信息，请参阅自定义卡片。
清除格式命令
我们已向工作项上的所有 RTF 控件添加了一个新的命令，它可用于清除所选文本中的所有格式。 如果你和大多数用户一样，那么你过去可能也因为将带格式的文本复制粘贴到这一不能撤消（或清除）的字段中而抓狂。 现在只需突出显示任何文本、选择“清除格式”工具栏按钮（或按 CTRL+空格键），文本即可返回到其默认格式。
在看板中进行筛选
通过对用户、迭代、工作项类型和标记设置筛选器，对看板进行个性化设置 （图 10） 。 这些筛选器可保留，以便查看个性化看板，即使从多台设备连接也是如此。
团队成员也可以筛选其看板以查看计入到特定父工作项的进度。 例如，用户可以查看链接到功能的用户情景，或查看汇总到长篇故事的两个或多个功能的工作。 类似于清单，此项功能是我们为把可见性带入不同积压工作 (backlog) 级别所做的进一步努力。
有关详细信息，请参阅筛选看板。
新工作项的默认迭代路径
当从“查询”选项卡或从“新工作项”仪表板小组件创建新工作项时，该工作项的迭代路径将始终设置为当前迭代。 这并不是所有团队都想要的，因为这意味着 bug 可能会立即显示在任务板上。 利用此项改进，团队可以选择应用于新工作项的默认迭代路径（一个特定迭代或当前迭代）。 导航到你团队的管理区域以选择默认迭代。
有关详细信息，请参阅自定义区域和迭代路径页。
复选框控件
现在可以向工作项添加复选框控件（图 11）。 此新字段类型（布尔）具有普通字段的所有属性，并且可被添加到进程中的任何类型。 当显示在卡上或查询结果中时，值显示为 True/False。
有关详细信息，请参阅自定义字段。
标记的批量编辑
现可使用批量编辑对话框添加和删除多个工作项中的标记 （图 12） 。
有关详细信息，请参阅向工作项添加标记。
新扩展点
我们在板和积压工作 (backlog) 页上添加了新的贡献点，支持将扩展编写为“看板/积压工作 (Backlog)/容量”选项卡旁的透视选项卡。
我们已公开了积压工作上的新的扩展点。 扩展可以将右侧窗格作为目标，映射和工作详细信息就位于右侧窗格中 （图 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) 来确定运行状况和/或可能需要的操作时，这极为方便。
拉取请求小组件现在支持多个大小，允许用户控制小组件的高度。 我们正致力于使我们提供的大多数小组件可调整大小，可在此处查看详细信息。
新工作项小组件现在允许选择默认工作项类型，而不是强制选择要从下拉列表中反复创建的最常见类型。
我们已让 WIT 图表小组件可调整大小。 这使用户能够在仪表板上看到任何 WIT 图表的扩展视图（无论其原始大小如何）。
我们已更新团队成员小组件，以便更轻松地将人员添加到团队 （图 18） 。
现在，团队可以配置仪表板的查询结果小组件的大小，从而使其显示更多结果。
已重新设计了“冲刺(sprint)概述”小组件，使团队能够更轻松地查看是否步入正轨。
“已指派给我”小组件帮助用户管理分配给他们的工作，而无需离开仪表板上下文 （图 19） 。 通过提供专为此目的而设计的小组件，团队管理员只需不到 16 次单击，即可将此功能添加到其仪表板中，且无需上下文切换和键入。 用户现在可以在小组件上下文中对分配给自己的工作进行查看、排序、筛选和管理等操作。
仪表板 REST API
现在可以使用 REST API 以编程方式添加、删除和获取仪表板上的信息。 API 还允许你添加、删除、更新、替换和获取某个小组件上的信息或仪表板上的小组件列表。 文档在 Visual Studio 联机文档提供。
可允许的仪表板
非管理员用户现在可以创建并管理团队仪表板。 团队管理员可通过仪表板管理器限制非管理权限。
有关详细信息，请参阅仪表板。
Git 改进
在 Team Foundation Server 2017 的 Git 中进行了一些重大更改。 包含分支页的重新设计和新的“Squash 合并”选项。
经过重新设计的分支页
已彻底重新设计了分支页。 它具有“mine”透视，显示已创建、推送到或收藏的分支（图 20）。 每个分支显示其生成和拉取请求状态，以及删除之类的其他命令。 如果分支名称中存在斜线，如“features/jeremy/fix-bug”，它将显示为一个树，因此浏览大型分支列表很容易。 如果你知道你的分支的名称，则可以快速搜索找到所需分支。
有关分支的详细信息，请参阅管理分支。
新拉取请求体验
本版本中的拉取请求体验有一些重大更新，引入了一些真正强大的差异功能、新的注释体验和全新的 UI。
有关详细信息，请参阅使用拉取请求查看代码。
重新设计的 UI
打开拉取请求时，新的外观即呈现在眼前 （图 21） 。 我们已重新组织标头，将所有关键状态和操作汇总，以便从体验中的每个视图访问它们。
概述
概述现在会突出显示 PR 说明，提供反馈变得前所未有的轻松（图 22）。 事件和注释的显示方式为最新项在上，从而帮助审阅者查看位于显眼位置的最新更改和注释。 提供了策略、工作项和审阅者的详细信息并对其进行了重新组织，以便更加简明扼要。
文件
本版本中最大的新功能是能够查看之前对拉取请求进行的更新（图 23）。 在之前的预览版中，我们发布了正确跟踪注释的功能（因为更新拉取请求时对其进行了更改）。 但，要查看两次更新之间的更改并不容易。 现在可在“文件”视图中确切地看到每次将新代码推送到拉取请求中时，对哪些内容进行了更改。 如果你获得了有关一些代码的反馈，并且想在审阅时（独立于所有其他更改）查看其具体更改，这将非常有用。
更新
新的“更新”视图显示拉取请求随时间的变化情况（图 24）。 “文件”视图显示文件怎样随时间改变，而“更新”视图显示每次更新所增加的提交。 如果曾发生强制推送，由于曾经进行过更新，“更新”视图将继续显示这些过去的更新。
现可使用标记和表情符号进行注释
在所有讨论中运用全部标记功能，包括格式设置、突出显示语法的代码、链接、图像和表情符号（图 25）。 注释控件也具有更加友好的用户编辑体验，允许一次编辑（然后保存）多个注释。
添加和删除拉取请求中的审阅者
现在可以更轻松地添加和删除拉取请求中的审阅者。 若要将审阅者或组添加到你的拉取请求，只需在审阅者部分中的搜索框中输入其（姓名）名称。 若要删除审阅者，在审阅者部分将鼠标悬停在其磁贴上，单击 X 即可删除 （图 26） 。
改进的生成和拉取请求可跟踪性
生成和拉取请求之间的可跟踪性得到改进，使在 PR 和生成之间来回导航变得轻松。 在由拉取请求触发的生成的生成详细信息视图中，源现在将显示指向排队生成的拉取请求的链接。 在生成定义视图中，任何由拉取请求触发的生成将在“触发者”列中提供到拉取请求的链接。 最后，生成资源管理器视图将在源列中列出拉取请求。
拉取请求的注释跟踪
改进了 VSTS 中的拉取请求，以显示正确行上的文件中剩余的注释，即使这些文件从注释被添加后已被更改。 以前，即使文件内容已更改，注释始终显示在它们最初被添加时所在的文件的行上，换而言之，第 10 行上的注释将始终显示在第 10 行上。 有了这些最新的改进，代码后的注释会显示用户的意图，（如果在第 10 行添加了注释，且有两个新行随后添加到了文件开头，则注释将显示在第 12 行）。
下面的示例更改了第 13 行上的注释（图 27）：
甚至在代码已更改为将具有原始注释的行从第 13 行移位至第 14 行后，注释将会显示在预期位置（第 14 行） （图 28） 。
自动完成拉取请求等待策略
使用分支策略来保护分支的团队将需要签出自动完成操作。 许多时候，拉取请求的作者准备合并其拉取请求，但需要等待生成完成才可单击“完成”。 其他时候，虽然生成已通过，但有一个审阅者尚未给予最终批准。 在这两种情况下，自动完成操作让作者将 PR 设置为在策略得到全部批准后立即自动完成 （图 29） 。
正如手动完成操作一样，作者有机会对合并提交消息进行自定义并选择适当的合并选项 （图 30） 。
设置自动完成后，PR 将显示一个横幅，确认自动完成已设置且正在等待策略完成 （图 31） 。
满足所有策略后（例如，生成已完成或已授予最终批准），则使用指定选项和注释合并拉取请求。 如预期那样，如果存在生成失败或审阅者未批准的情况，拉取请求将保持活动状态，直到策略通过。
挤压合并拉取请求
完成拉取请求后，现在可以选择挤压合并 （图 32） 。 此新选项生成单个提交，此提交包含应用于目标分支的主题分支中的更改。 常规合并和挤压合并之间最明显的区别是，挤压合并提交只有一个父提交。 这意味着历史记录图表将更简单，因为对主题分支所做的任何中间提交在生成的提交图中将不可访问。
可在挤压合并拉取请求中查找更多详细信息。
提交可跟踪性
生成状态（成功或失败）现已清楚地显示在代码资源管理器和提交详细信息视图中 （图 33） 。 只需一次单击即可了解更多详细信息，因此始终都可知悉提交中的更改是否通过了生成。 还可以在生成定义的存储库选项中自定义哪些生成发布状态。 此外，提交详细信息视图的最新更改将提供有关所做更改的更深入的见解。 若使用拉取请求合并更改，则会看到将更改引入主分支的拉取请求（若是合并提交，则为创建它的拉取请求）的链接。 当更改到达主分支后，将显示分支链接以确认已包含所做更改。
在 Web 中查看 Git LFS 文件
如果已在 Git 中处理大文件（音频、视频、数据集等），就会了解 Git 大型文件存储 (LFS) 使用 Git 内的指针替换这些文件，同时将文件内容存储在远程服务器上。 此项更改使查看这些大文件的全部内容成为可能（只需单击存储库中的文件）。
有关详细信息，请参阅使用 Git 管理大文件。
创建和发送到代码的特定部分的链接
通过代码链接轻松地共享代码引用（图 34）。 只需在文件中选择文本，然后单击链接图标。 它将复制到所选代码的链接。 当某个用户查看该链接时，你突出显示的代码将具有金色背景。 它甚至适用于部分行的选择。
状态 API
生成的（成功或失败）现已清楚地显示在代码资源管理器和提交详细信息视图中 （图 35） 。 只需一次单击即可了解更多详细信息，因此始终都可知悉提交中的更改是否通过了生成。 还可以在生成定义的存储库选项中自定义哪些生成发布生成状态。
文件类型图标
将看到新文件图标与资源管理器、拉取请求、提交详细信息、搁置集、变更集或显示文件列表的任何其他视图中的文件扩展名相匹配 （图 36） 。
在存储库创建过程中添加自述文件
通过为用户提供添加自述文件的功能改进了新的 Git 存储库创建（图 37）。 向存储库添加自述文件不仅可以帮助其他用户了解基本代码的用途，还可以允许你立即克隆存储库。
生成改进
在此版本中，我们增加了日志大小、添加了 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 生成的通知。 用户通过此冲刺 (sprint) 还可以接收来自生成 vNext 完成的通知。
启用 Git CI 触发器的路径筛选器
托管的 Git 存储库的 CI 触发器可以包括或排除某些路径。 这使得能够将生成定义配置为仅在特定路径中的文件更改后运行 （图 44） 。
Release Management 改进
自 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） 。
基于多个环境中的条件部署
直到上一版本前，你可以进行并行部署（分叉部署），但是不能根据多个环境的状态开始部署到环境（联接部署）。 你现在可以实现此操作。
有关详细信息，请参阅 并行分叉和联接部署文档。
适用于 Release Management 的 REST API
你可以使用 Release Management 的 REST API 服务来创建发布定义和发布，并管理部署发布的多个方面。
有关详细信息，请参阅 API 参考文档。
服务挂钩集成
在创建新发布、启动或完成部署或审批处于挂起或完成状态时发送发布通知。 与第三方工具（如 Slack）集成以接收此类通知。
部署到国内 Azure 云
在 Azure 经典服务终结点使用新的环境设置，将特定 Azure 云设为目标，包括预定义的国内云（如 Azure China 云、Azure US Government 云和 Azure German 云） （图 60） 。
有关详细信息，请参阅 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
现在可通过重新运行识别 bug 的测试来验证 bug（图 74）。 可从 bug 工作项窗体上下文菜单调用“验证”选项在 Web 运行程序中启动相关测试用例。 使用 Web 运行程序执行验证，并直接在 Web 运行程序中更新 bug 工作项。
适用于测试计划/测试套件克隆的 REST API
我们已添加用于测试计划克隆和测试套件克隆的 REST API。 你可以在我们的 Team Services 集成网站上的测试管理部分下找到它们。
看板卡中的测试进度
现在可以直接从看板上的情景添加、查看测试用例并与其进行交互。 使用新的“添加测试”菜单选项创建链接测试用例，然后在操作进行时直接从卡片监视状态 （图 75） 。
使用这项新功能，现在可以直接从看板上的卡片执行以下操作：
- 添加测试。
- 打开测试。
- 通过从一个用户情景拖/放到另一个来重新设置测试的父级。
- 使用 CTRL+ 拖/放将同一测试复制到另一个用户情景（适用于同一测试用例测试多个用户情景的方案）。
- 通过快速将其标记为通过/失败/等更新测试状态。
- 通过在 Web 测试运行程序中启动该测试来运行它，从中你可以使各个步骤通过或失败、归档 bug 等。
- 查看汇总状态摘要，该状态指示已通过的测试数量和该情景剩余的测试数量。
如果需要高级测试管理功能（比如分配测试程序、分配配置、集中的参数、导出测试结果等），你可以切换到测试中心，开始使用已自动为你创建的默认测试计划/基于要求的套件。 有关详细信息，请参阅添加、运行和更新内联测试。
从卡片遍历至测试计划/测试套件
你现在可以在测试创建的位置，直接从看板上的卡片轻松地遍历至基础测试计划/测试套件。 单击此链接 （图 76） 会转到测试中心，打开正确的测试计划，然后选择控制这些内联测试的特定套件。
看板的通用设置配置中的测试页
使用看板的常用设置配置对话框中的新测试页，在内联测试创建的位置控制测试计划（图 77）。 以前，卡片上创建的任何测试会被自动添加到新创建的测试计划（如果不存在与卡片的区域和迭代路径相匹配的测试计划）。 现在可以通过配置所选的现有测试计划来替代此行为，然后所有测试都将添加到所选的测试计划。 请注意，仅当测试批注打开时才启用此功能。
Web 运行程序增强功能
在手动测试过程中添加测试步骤附件
我们已增强 Web 测试运行程序，可在手动测试过程中添加测试步骤附件（图 78）。 这些步骤结果附件会自动显示在你在会话中归档的任意 Bug 内，并随后显示在“测试结果”窗格中。
Web 运行程序中的屏幕截图、屏幕录制、图像操作日志和系统信息支持（使用 Chrome 浏览器）
在 Chrome 中使用 Web 运行程序时，现可截取屏幕截图并对其进行内联批注（图 79）。 还可以捕获不只 Web 应用，还有桌面应用的点播屏幕录制。 会自动将这些屏幕截图和屏幕录制添加到当前测试步骤。 除了屏幕截图和屏幕录制以外，现在还可以从你的 Web 应用捕获点播图像操作日志。 需要在浏览器窗口上指定捕获操作的位置 - 该窗口（该窗口中打开的任何现有或新选项卡）上的所有操作或你启动的任何新的子浏览器窗口将自动被捕获，并与在 Web 运行程序中测试的测试步骤相关。 这些屏幕截图、屏幕录制和图像操作日志将随后被添加到运行期间归档的任何 bug，并被附加到当前测试结果。 同样，系统信息数据将作为从 Web 运行程序归档的所有 bug 的一部分自动进行捕获和包含。 所有这些都利用了基于 Chrome 的测试和反馈扩展中的功能。
有关详细信息，请参阅在测试过程中收集诊断数据。
作为子级归档的 bug - Web 运行程序/测试和反馈扩展
在 Web 运行程序中运行测试时，无论是从板上的卡片启动还是从测试中心内基于要求的套件启动，任何归档的新 Bug 现在都将被自动创建为该用户情景的子级。 同样，如果要从探索测试扩展浏览用户情景，任何存档的新 Bug 也将被创建为该用户情景的子级。 这一新行为使情景和 Bug 中的可跟踪性更简单。 只有在将“通用设置配置”页中的“处理 bug”设置设为“Bug 不出现在积压工作(backlog)或板上”或“Bug 出现在带有任务的积压工作(backlog)和板上”时，此行为才适用。 对于“处理 bug”选项的所有其他设置和在某些其他情况下（例如添加到已定义父级的现有 bug），则改为创建相关链接。
从 Web 运行程序更新现有 bug
除了从 Web 运行程序创建新 bug，现在还可以更新现有 bug（图 80）。 收集所有诊断数据后，重现步骤和现有会话中的可跟踪性链接将自动添加到现有 bug。
测试和反馈扩展 - 增强
可从 Visual Studio Marketplace 安装基于浏览器的测试和反馈扩展。 它支持 Visual Studio Team Services 和 Team Foundation Server（2015 或更高版本）。
探索工作项
现在，可以对特定的工作项进行探索测试（图 81）。 可将选定的工作项与正在进行的测试会话相关联，并从扩展内部查看验收条件和说明。 还可在存档于所选工作项上的 bug 或任务之间实现端到端可跟踪性。 可直接从工作项或从扩展内部探索工作项：
• 直接从工作项（图 81）：使用上下文菜单中的“执行探索测试”选项，从产品内直接启动特定工作项的探索测试会话。 我们已在所有卡片、网格上和测试中心内添加了入口点。
• 在扩展中（图 82）：从 XT 会话内搜索工作项，然后将其与正在进行的会话相关联。
有关详细信息，请参阅使用测试和反馈扩展探索工作项。
使用测试和反馈捕获图像操作日志、屏幕录制和网页加载数据
图像操作日志：扩展还提供了新选项，只需单击一下即可自动添加引导至 bug 的步骤。 选择“包括图像操作日志”选项（图 83）来捕获鼠标、键盘和触控操作，并将相应的文本和图像直接添加到 bug 或任务中。
屏幕录制（即视频）：还可以使用扩展捕获点播屏幕录制。 这些屏幕录制不仅可以从 Web 应用捕获，还可以从你的桌面应用捕获。 可使用扩展的“选项”页将扩展配置为自动停止屏幕录制并将其附加到要存档的 bug。
网页加载数据：我们已向扩展添加新的背景捕获功能，即“网页加载”数据的捕获。 “图像操作日志”在背景中以图像形式捕获在探索 Web 应用时执行的操作，与此类似，“网页加载”功能自动捕获网页的详细信息以完成加载操作。 你现在可以客观地量化 bug 中的慢速，而无需以依赖网页加载的主观/感知慢速。 报告 bug 后，除平铺视图外，一份详细的报表也会附加到 bug，可以帮助开发人员进行调查的初始设置。
基于图像操作日志数据创建测试用例
在探索会话期间创建测试用例时，包含图像的测试步骤会自动填充（图 84）。 同步测试设计和测试执行是真正探索测试的基础，而这项新功能使之成为现实。 可以编辑捕获的文本、添加所需的结果、取消选中不相关的行并将其保存用于即将到来的测试轮次/运行。
有关详细信息，请参阅创建基于图像操作日志数据的测试用例。
探索测试会话见解
现在可以查看给定时间段内使用测试和反馈扩展创建的已完成探索测试会话（在团队或个人级别）。 单击 Web 访问中测试中心组内运行中心的“最近的探索会话”链接，可以转到此见解页面。 此新视图可帮助你获得有意义的见解，包括：
- 显示所浏览工作项的分解、创建的工作项、会话所有者，以及在这些会话上所花费的总时间的摘要视图 （图 85） 。
- 可按照浏览的工作项、会话、会话所有者或者不按照任意项来透视分组依据视图。 对于任何透视，可以查看创建的所有工作项（Bug、任务、测试用例）的列表或将列表的范围缩小到特定工作项类型。
- 根据分组依据视图中所选内容显示信息的详细信息窗格视图。 对于选定的透视行（假设浏览的工作项），你可以在详细信息窗格中查看其摘要信息，如总会话数、在这些会话上所花费的总时间、浏览它的会话所有者、针对其创建的 Bug/任务/测试用例，以及它们的状态和优先级。 对于选定的工作项行，可以查看其工作项窗体内联并视情况进行相应更改。
有关详细信息，请参阅获取跨探索测试会话的见解。
探索测试会话：查看未探索的工作项
除了在“最近的探索会话”视图中查看所有探索的工作项的详细信息（按给定的数据范围的所有/我的会话筛选），我们现在还在同一视图中添加了查看所有未探索的工作项列表的功能（图 86） 。 通过为你感兴趣的工作项指定共享查询开始，会话页显示来自查询的所有工作项的列表，并对摘要部分中的已探索和未探索项进行了细分。 此外，通过透视使用“未探索工作项”组可以查看尚未探索的项目列表。 对于跟踪尚未探索或尚未进行 bug 大扫除的情景数量，此功能非常有用。
端到端利益干系人反馈流
请求反馈
具有基本访问级别的用户现在可以使用工作项菜单中的“请求反馈”选项直接从利益干系人针对正在进行或已完成的功能/情景请求反馈 （图 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 部署时，需要为 Windows 身份验证选择 NTLM 或 Negotiate 安全支持提供程序。 在 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（图 104）。 如果你在 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/包管理时，如果代理作为“网络服务”用户运行，则 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 上了解相关建议。