Team Foundation Server 2018 发行说明
开发者社区 | 系统要求和兼容性 | 许可条款 | TFS DevOps 博客 | SHA-1 哈希 | 最新 Visual Studio 2019 发行说明
本文将介绍 Team Foundation Server 2018 的相关信息。 单击此按钮下载。
要详细了解 Team Foundation Server 2018，请参阅 Team Foundation Server 要求和兼容性页面。 请访问 visualstudio.com/downloads 页面，下载其他 TFS 2018 产品。
请参阅 TFS 安装页以获取详细信息。
发布日期：2017 年 11 月 15 日
TFS 2018 中的最近更新汇总
我们已在 Team Foundation Server 2018 中新增了许多有价值的更新。 其中一些重要内容包括：
- 我们改进了 Web 版项目创建向导和过程模板管理器。
- 现在可以自定义工作项窗体标头。
- 我们优化了移动工作项表单。
- 我们现已开始支持 Git 分叉。
- 可以使用 GVFS 管理大量的 Git 存储库。
- 可以查看、筛选、删除 Git 标记，并能设置标记安全性。
- 向 Web 代码编辑添加了文件一览、括号匹配和切换空格功能。
- 我们对拉取请求进行了诸多改进。
- 我们推出了改进后的全新 Wiki 体验。
- 我们已开始支持 Maven 包。
- 可以导入和导出以及暂停生成定义。
- 全新的发布定义编辑器默认处于启用状态。
- 你可通过虚拟机部署进行部署。
- 我们提升了探索测试可跟踪性。
- 添加了测试批处理。
- 现可查看测试计划和测试套件的图表小组件。
“TFS 2018 中的新增功能”视频
XAML 生成
我们最初将 XAML 生成列为已从 TFS 2018 RTW 和 Update 1 中删除。 但是，这导致过多客户无法升级或在升级已完成后必须与支持人员联系以重新启用它。 在 TFS 2018 Update 2 中，启用了 XAML 生成，但已不再提供支持。 这表示不再对 XAML 生成进行进一步的投入，且 Microsoft 测试管理器 (MTM) 不再支持使用 XAML 生成。 强烈建议转换为更新的生成定义格式。 可继续使用 TFS 2018 Update 2 连接 XAML 控制器和运行 XAML 生成。 详细信息
在 TFS 2018 RTW 中删除的功能
- 不再支持 Microsoft 测试管理器中的实验室中心和自动测试流。
- 我们停止提供适用于 SharePoint 的 TFS 扩展。
- 我们删除了团队聊天室功能。
TFS 2018 中的最近更新详情
工作项跟踪
Web 版项目创建向导
我们改进了通过连接 Web 创建团队项目的体验。 现在，可以在 Visual Studio 客户端中创建团队项目时使用大多数功能。 使用 Web 界面的优势在于，无需使用匹配的 Visual Studio 版本。 使用 Visual Studio 和 Web 版的区别在于，Web 版不在 SSRS 中预配报表。 如果使用了 Web 版团队项目创建向导，可以对应用程序层运行 tfsconfig 命令，从而预配或更新 SSRS 报表。
Web 版过程模板管理器
使用 TFS 2018，可以通过连接 Web 上传过程模板。 Web 界面更易于使用，因为无需安装正确的 Visual Studio 版本，即可与过程模板进行交互。 Visual Studio 2017 Update 4 及更低版本仍显示“过程模板管理器”对话框，尽管我们建议使用 Web 界面。 Visual Studio 2017 Update 5 及更高版本会自动重定向到 Web。
自定义工作项窗体标头
现可通过替换现有控件或隐藏与进程无关的控件来自定义工作项窗体标头区域。 这可支持使用自定义团队字段替换区域路径、隐藏迭代（如果团队更专注于看板）以及使用自定义字段替换原因。 “状态”字段无法隐藏或替换。
提示
有关详细信息，请参阅 WebLayout 和控件元素文档。
移动工作项表单
我们提供完整的端到端体验，包括已经过优化的工作项观感（图 1）。 这样就可以通过手机与分配到的、正在跟踪的、访问过的或最近编辑过的工作项轻松进行交互。
除了改进了外观之外，此体验还优化了所有字段类型的控件（图 2）。
通过全新的移动导航（图 3），用户可以到达其他任何支持移动导航的 TFS 部分，并在需要与其他中心进行交互时返回到完整桌面版站点。
筛选积压工作 (backlog)、看板、冲刺 (sprint) 和查询
我们的所有工作项跟踪网格体验（查询、积压工作 (backlog)、看板、冲刺 (sprint) 积压工作 (backlog) 和测试用例管理）现在都利用常见的一致性筛选组件（图 4）。 除了可以跨显示的列应用关键字筛选器和选择标记之外，还可以按工作项类型、状态和分配目标进行筛选，从而快速获取要找的工作项。
在看板卡上展开显示空字段
目前，可以根据需要向看板卡添加其他字段，并在看板设置中隐藏空字段（图 5），让看板保持整齐有序。 此功能的缺点是，一旦隐藏空字段，只能通过打开工作项表单来更新此字段。 使用看板卡上新增的展开选项，现在不仅可以隐藏看板中的空字段，还可以一键式更新看板卡上的特定字段。 只需将鼠标悬停在看板卡上，并使用看板卡底部的倒 V 形图标，即可更新隐藏的字段。
单击看板卡底部的倒 V 形图标，即可更新字段（图 6）。
阻止保存工作项的扩展
工作项表单自定义控件、组和页现在可以阻止保存工作项，以便验证数据，并确保用户在保存工作项表单之前填写所需的全部信息。
内联添加交付计划
关于新功能的灵感随时可能迸发，因此我们简化了向“交付计划”直接添加新功能的流程（图 7）。 只需在光标悬停时单击出现的“新建项”，输入名称，然后按 Enter。 随即将使用预期的区域路径和迭代路径创建新功能。
版本控制
分叉
TFS 2018 现已开始支持 Git 分支（图 8）。 分叉是存储库的服务器端副本。 使用分叉，可以让大量人员参与存储库，而无需向他们授予直接提交访问权限。 相反，他们将工作提交到自己的存储库分支。 这样一来，可以先在拉取请求中评审他们的更改，然后再接受将这些更改提交到中央存储库。
GVFS
现支持 Git 虚拟文件系统 (GVFS)。 通过虚拟化和优化 Git 在该文件系统上的操作方式，GVFS 支持 Git 存储库扩大至数百万文件。
使用 Web 在存储库中创建文件夹
现可通过 Web 在 Git 和 TFVC 存储库中创建文件夹（图 9）。 这会替换目前处于弃用过程的文件夹管理扩展。
若要创建文件夹，请在命令栏或上下文菜单中单击“新建”>“文件夹”：
对于 TFVC，可指定文件夹名称，然后将其签入。 对于 Git，由于不允许空文件夹，因此也将需要指定文件名或者编辑文件，然后提交。
此外，对于 Git，“新建文件”对话框（图 10）已改进为接受斜杠，以创建子文件夹。
文件 Minimap
现在查看或编辑文件时可查看文件的 Minimap，快速概览代码（图 11）。 若要启用 Minimap，打开“命令面板”（F1 或右键单击），然后选择“切换 Minimap”。
括号匹配
现在编辑或查看文件时，左侧会有参考线，可与括号轻松匹配（图 12）。
切换空格
现在，查看或编辑文件时，可将空格切换为“开”或“关”。 我们仍在开发让你能在比较时切换空格的功能。 若要查看空格（图 13），请打开“命令面板”（F1 或右键单击），然后选择“切换空格”，以便区分空格和制表符。
设置为对 TFVC 存储库禁用 Web 编辑
使用 TFVC 的团队经常在 Visual Studio 中使用签入策略，以确保代码质量。 不过，由于签入策略是在客户端上强制实施的，因该策略不对接受过 Web 编辑的代码造成任何影响。
多个用户曾要求过，能否禁用 Web 编辑，以免受忽略签入策略的更改影响。 我们现已支持按项目/存储库对 TFVC 禁用 Web 编辑（即禁用添加、删除、重命名和编辑操作）。
要在“文件”页面中禁用 Web 编辑，请依次转到“设置”和“版本控制”（图 14）。 单击树中的 TFVC 存储库，转到“选项”透视区域，并取消选中“为此 TFVC 存储库启用 Web 编辑”。 Web 编辑默认处于启用状态。
注意
从“项目概述”页编辑 README 不受影响。
如果在禁用了 Web 编辑的项目中尝试执行 Web 编辑，则会看到提示禁止进行 Web 编辑的通知（图 15）。
识别过时分支
通过删除不再需要的分支让存储库保持整齐有序，这样团队就能找到所关心的分支，并在合适的级别收藏分支。 不过，如果存储库中有大量分支，便很难确定哪些是可以删除的非活动分支。 现可让轻松地识别“过时”分支（即指向 3 个月前的提交的分支）。 若要查看过时分支，请转到“分支”页上的“过时”透视区域（图 16）。
搜索已删除的分支并重新创建
如果从服务器中意外删除分支，便很难弄清楚此分支的具体情况。 现在，可以搜索已删除的分支，并查看此分支的删除者和删除时间，还能根据需要重新创建此分支。
若要搜索已删除的分支，请在分支搜索框中输入完整的分支名称。 这将返回与搜索文本匹配的全部现有分支。 还会看到一个选项，用于在已删除的分支列表中搜索完全匹配项。 单击链接即可搜索已删除的分支（图 17）。
如果找到了匹配项，将会看到此分支的删除者和删除时间。 还可以还原此分支（图 18）。
如果还原此分支，将在它最后指向的提交中重新创建它。 不过，将不会还原策略和权限。
在开头有前缀的分支中搜索提交
如果分支结构采用分层格式，其中所有分支都以文本为前缀，可以使用此功能，在开头有此前缀文本的全部分支中查找提交。 例如，要确定提交是否已被引入所有以“dev”为前缀的分支，只需在搜索框中键入“dev”，再选择“在以‘dev’开头的分支中搜索”即可（图 19）。
提交详细信息页上的拉取请求标注更丰富
提交详细信息页上的拉取请求标注会显示更多相关信息，有助于更好地进行诊断（图 20）。 现在，我们还在标注中显示将提交引入任何分支的首个拉取请求，以及与默认分支相关的拉取请求。
在“代码”中筛选树状视图
现在，无需滚动浏览提交可能已修改的所有文件，即可找到自己的文件。 提交详细信息页、拉取请求页、搁置集详细信息页和变更集详细信息页上的树状视图现在支持筛选文件和文件夹。 此为智能筛选器，可以在用户按文件夹名称筛选时显示文件夹的子文件，并能在用户按文件名筛选时显示文件的折叠式树状视图，以呈现文件层次结构。
在提交树上找到文件或文件夹筛选器（图 21）和（图 22）：
“分支更新”页现为“推送”
“分支更新”页具有巨大价值。 不过，它已隐藏为“历史记录”中心下的透视区域。 “分支更新”页面现在称为“推送”中心（图 23），它位于“代码”下方，就在“提交”、“分支”、“标记”和“拉取请求”的旁边。 推送页的新 URL 为：\<tfsserverurl\>/\<projectname\>/_git/\<reponame\>/pushes。 旧 URL 仍能正常发挥作用。
同时，“历史记录”中心现重命名为“提交”（图 24），因为此中心仅显示提交。 用户向我们反馈过，很难排查与提交相关的问题，因为提交列表视图仅在有鼠标悬停时才显示详细时间。 现在，跨实例的提交列表视图以 dd/mm/yy hh:mm 格式显示日期和时间。 提交页的新 URL 为：\<tfsserverurl\>/\<projectname\>/_git/\<reponame\>/commits。 旧 URL 仍能正常发挥作用。
从“文件”切换到“提交”时保留文件名
用户向我们反馈过，如果在目录中筛选出“代码”中心的“文件”透视区域中的特定文件，稍后又翻转到“历史记录”透视区域，则当提交更改的文件数超过 1,000 个时，文件名将丢失。 这样一来，用户需要加载更多文件并筛选内容才能找到文件，影响了工作效率。 开发者通常在同一目录中进行工作，并且希望在跟踪更改时一直留在他们工作的目录中。 现在，可以在“代码”中心透视区域之间切换时保留文件名，无论提交更改了多少个文件。 也就是说，无需单击“加载更多”，即可找到所需的文件。
查看 Git 标记
可以在“标记”页上查看存储库中的所有标记（图 25）。 如果将所有标记作为发布进行管理，则用户可访问“标记”页来简要了解所有产品发布。
可以轻松区分轻量级标记和已加批注的标记。 已加批注的标记在相关提交旁边显示标记器和创建日期，而轻量级标记仅显示提交信息。
删除 Git 标记
有时，可能需要从远程存储库中删除标记。 可能是因为标记名称中有拼写错误，或标记了错误的提交。 可以在“标记”页面上单击标记的上下文菜单，并选择“删除标记”（图 26），即可轻松地从 Web UI 中删除标记。
警告
应谨慎地删除远程存储库中的标记。
筛选 Git 标记
对于旧存储库，标记数量可能会随着时间的推移而大幅增多；存储库中创建的标记可能还会采用层次结构，令标记查找起来更加困难。
如果无法在“标记”页上找到要找的标记，可以使用“标记”页顶部的筛选器，直接搜索标记名称（图 27）。
Git 标记安全性
现在，可以向存储库用户授予精细权限，方便其管理标记。 可以向用户授予权限，允许他们从此界面删除或管理标记（图 28）。
提示
有关 Git 标记的详细信息，请阅读 Microsoft DevOps 博客。
完成拉取请求时自动完成工作项
若将工作项与拉取请求相关联，就可更加轻松地更新所有内容。 现在，完成拉取请求时，可以选择在拉取请求合并成功后自动完成关联的工作项（图 29）。 若使用策略并将拉取请求设置为自动完成，可看到相同的选项。 完成拉取请求后，不用再重新访问工作项来更新状态。 系统会自动完成。
在推送/新迭代发生时重置投票
如果团队决定在 PR 中采用更严格的审批工作流，现在可以在新更改进行推送时重置投票（图 30）。 新设置为“至少需要的审阅者人数”策略下的一个选项。
设置此选项后，每当 PR 的源分支更新时，所有审阅者的全部投票都会进行重置。 只要投票因此选项而重置，PR 时间线都会记录一个条目（图 31）。
按文件名筛选拉取请求树
在拉取请求中查找特定文件变得空前简单。 使用“文件”视图中的新筛选器框，用户可以筛选树状视图中的文件列表（图 32）。
筛选器会匹配拉取请求中文件的任意路径部分，因此可以按文件夹名称、部分路径、文件名或扩展进行搜索（图 33）。
更多拉取请求注释筛选选项
在拉取请求概述和“文件”视图中，现在可以使用相同的注释选项（图 34）。 还可以进行筛选，仅查看自己参与的讨论。
在拉取请求详细信息中查看已添加注释的代码与原始版本的差异
有时，在拉取请求注释引用的代码发生更改后（很多时候是在做出了请求的更改时），就很难理解拉取请求注释了（图 35）。
现在如果出现这种情况，可看到一个包含更新编号的徽章，单击该徽章即可查看最初创建注释时的代码（图 36）。
可折叠的拉取请求注释
代码评审是拉取请求体验的关键所在，因此我们添加了新功能，以便审阅者可以将重心放在代码上。 代码审阅者可以轻松地隐藏注释，以便能够在首次评审新代码时腾出空间（图 37）。
隐藏注释（图 38）可以对树状视图隐藏注释，并在文件视图中折叠注释线程：
折叠注释后，单击边距中的图标即可轻松展开注释，再单击一下又可以再次折叠。 借助工具提示（图 39），可以轻松快速地概览注释，而无需查看整个线程。
拉取请求说明和注释中的任务列表
准备 PR 或进行注释时，有时会有一些要跟踪的事项，但最终会编辑文本或添加多个注释。 使用轻量级任务列表，可以在说明或合并后的一个注释中，作为 PR 创建者或审阅者跟踪待办事项列表的完成进度。 单击 Markdown 工具栏，即可开始使用或将格式应用于选定文本（图 40）。
添加任务列表（图 41）后，只需选中框，即可将项标记为完成。 这些项在 Markdown 注释中表示和存储为 [ ] 和 [x]。 有关详细信息，请参阅 Markdown 指南。
可以为拉取请求中的注释点“赞”
单击一下“赞”按钮，即表示支持 PR 注释（图 42）。 可以将鼠标悬停在此按钮之上，查看已点赞注释的其他所有点赞人员列表。
改进了批准并附加建议时的工作流
结合使用“自动完成”选项（图 43）与拉取请求可有效提升工作效率，而又不打断与代码审阅者的积极讨论。 为了更好地促进这些讨论，现在会在拉取请求设置为自动完成时，提示“批准并附加建议”投票。 用户可以根据需要取消自动完成，这样他们的反馈意见就可以被聆听；也可以保持自动完成设置不变，但要求在符合所有策略要求的情况下才自动完成拉取请求。
Git 通知支持路径筛选
现在可以选择收到通知的条件，即仅当团队成员在关心的文件夹中创建拉取请求或推送代码时，而不会收到存储库中所有文件夹的通知。 创建自定义 Git 推送或拉取请求的电子邮件通知订阅时，可以使用新选项，按文件夹路径筛选这些通知（图 44）。
更新了拉取请求工作流的电子邮件模板
拉取请求电子邮件警报已刷新，不仅清晰简洁，还可操作（图 45）。 主题行的开头是拉取请求标题和次要信息（如存储库名称），而 ID 移到了末尾。 创建者的姓名已添加到主题中，以便可以更轻松地应用规则，并按 PR 创建者进行筛选。
警报电子邮件正文模板刷新为，先总结警报发送原因，后跟关键的元数据（标题、分支名称和说明）以及主要的号召性用语按钮。 再往下，电子邮件包含审阅者、文件和提交等更多详细信息。
对于大多数警报，单击号召性用语按钮（图 46）可以在 Web 中查看拉取请求。 不过，收到有关特定注释的通知时，单击号召性用语按钮会直接链接到相应注释，让你能够轻松找到代码和先前对话，了解上下文相关信息。
已更新用于推送通知的电子邮件模板
推送通知已更新，以匹配经优化而变得清晰、简洁和可操作的新电子邮件模板（图 47）。 主题行有助于清晰区分推送电子邮件，标识分支、存储库和创建者以及汇总推送中包含的提交数。 这些更改还使创建规则和筛选器更加简单，从而有助于管理这些电子邮件通知。
电子邮件正文与其他电子邮件一致，强调发送电子邮件的原因、操作发起人员以及具体内容。 特定于推送警报，包含所有关于存储库、分支、文件和提交的详细信息，以帮助通知收件人更改范围。 对推送警报操作的主调用为“查看推送”，这将打开生成警报的特定推送的推送视图。
Wiki
每个项目现在都支持自己的 Wiki（图 48）。 现在，可以方便地编写 Wiki 页，帮助团队成员了解、使用和参与项目。
新 Wiki 的一些主要功能包括：
- 简化了使用 Markdown 语法进行编辑的体验。
- 使用新页，可以指定标题，并添加内容。 （图 49）
- 支持在 Markdown 中使用 HTML 标记（图 50）。
- 方便地重设 Markdown 文件夹中图像的大小（图 51）。
- 功能强大的页管理窗格，支持对页进行重新排序、重新设置父级和管理。
- 对于大型 Wiki，可以按标题筛选页（图 52）。
- 高级用户可离线更新 Wiki。
提示
详细了解 Wiki 入门。
使用 Wiki 的次数越多，保存意外更改的可能性就越大。 现在，可以还原 Wiki 页修订，具体方法是转到修订详细信息，并单击“还原”按钮（图 53）。
通过断开的链接创建 Wiki 页
我们在创建 Wiki 时观察到一种模式：Wiki 页上的表格内容中包含不存在的链接（图 54）。 用户可能会单击这些链接，尝试创建一个实际页。 我们以前处理这种情况的方法是发出警告，提示链接断开或页不存在。 现在，我们改为支持创建页，将这种情况作为 Wiki 的主要方案进行处理。
Wiki 页面深层链接
Wiki 现支持页内和跨页深层链接部分，这对创建目录非常有用。 可使用以下语法引用同一页面或不同页面的标题：
- 同一页面：
[text to display](#section-name) - 不同页面：
[text to display](/page-name#section-name)
市场上的 Wiki 扩展现已弃用。 如果是现有 Wiki 扩展用户，可以使用此迁移工具，将 Wiki 页迁移到新 Wiki。 详细了解如何将现有 Wiki 页迁移到新 Wiki。
包管理
包管理体验更新
包 URL 现在支持使用包名称和版本，而不使用 GUID。 这样，可以更轻松地手动创建包 URL（图 55）。 格式为：\<tfsserverurl\>/\<project|team\>/_packaging?feed=\<feed\>&package=\<package\>&version=\<version\>&protocolType=\<NuGet|Npm|Maven\>&_a=package。
现在可以对所有源用户隐藏已删除的包版本（图 56）（不用再为包添加删除线！）。
在包详细信息页上执行的任何操作，现在都可以通过包列表的上下文菜单执行。
包列表新增了“上次推送时间”列（图 57），内含人性化日期，以便用户可以轻松找到最近更新的包。
Maven 包
我们现已开始支持在 TFS 2018 中托管 Maven 项目（图 58）。 使用 Maven 项目，Java 开发者可无缝共享代码和组件。 请查看我们的入门指南，了解如何使用包管理源共享 Maven 项目。
新增统一的 NuGet 任务
我们已将“NuGet 还原”、“NuGet 包装程序”和“NuGet 发布服务器”任务合并到统一的 NuGet 生成任务中，以便与生成任务库的其余部分更好地保持一致；新任务默认使用 NuGet 4.0.0。 因此，我们弃用了旧任务，并建议用户在方便时迁移到新增的 NuGet 任务。 此更改与下面所述的一系列改进保持一致，只有在使用合并的任务时，这些改进才生效。
在改进期间，我们还发布了新任务“NuGet 工具安装程序”，它用于控制 PATH 上可用的以及 NuGet 新任务所使用的 NuGet 版本。 因此，若要使用最新版 NuGet，只需在生成开始时添加“NuGet 工具安装程序”任务即可（图 59）。
NuGet“允许跳过重复项”选项
许多 NuGet 客户向我们反馈过，生成的一组包中只有一些可能有更新（即更新后的版本号）。 NuGet 生成任务新增了“允许跳过重复项”选项，在任务尝试将包推送到已在使用此版本的 VSTS/TFS 源时，此选项让任务能够继续执行。
npm 生成任务更新
无论是在 Windows、Linux 还是在 Mac 上生成 npm 项目，都可以无缝使用新增的 NPM 生成任务。 我们还调整了此任务，以便用户可以更轻松地运行 npm install 和 npm publish。 对于 install 和 publish，我们简化了凭据获取操作，这样项目的 .npmrc 文件中列出的注册表凭据就可以安全地存储在服务终结点中。 或者，如果使用的是 VSTS/TFS 源，则可通过选取器可以选择一个源，然后生成具备生成代理所用必要凭据的 .npmrc。
Maven 现在支持已验证的源
与 NuGet 和 npm 不同，Maven 生成任务以前无法与已验证的源配合使用。 我们已更新 Maven 任务，让用户能够轻松使用 VSTS/TFS 源（图 60）。
.Net 任务支持已验证的源（Web 项目）
.Net 任务的下一个主版本 (2.x) 实现了许多反馈请求，并修复了我们一直在跟踪的一组 bug。 这包括：
- 首先，.Net 现支持已验证的包源（如包管理），因此无需再使用 NuGet 任务即可从私有包源还原包。
- “项目路径”字段的行为已在 2.0 版任务中发生变化。 在旧版任务中，如果找不到与指定模式匹配的项目文件，任务常常会记录警告，然后成功完成。 在这种情况下，有时可能会很难理解，为什么生成已成功，但依赖项并未还原。 现在，如果找不到与指定模式匹配的项目文件，任务会失败。 这不仅与其他任务的行为保持一致，而且还易于理解和使用。
- 在旧版任务的 publish 命令中，任务将所有文件放入以项目文件名命名的文件夹中，从而修改输出路径，即使传递的是明确的输出路径，也不例外。 这样，很难将命令链接在一起。 现在可以控制输出路径文件。
我们还发布了新任务“.Net 工具安装程序”，它用于控制 PATH 上可用的以及 dotnet 新任务所使用的 dotnet 版本。 因此，若要使用最新版 .Net，只需在生成开始时添加“.Net 工具安装程序”任务即可。
在帐户/集合之外工作
现在可以更轻松地在 TFS 服务器或 VSTS 帐户之外使用源（图 61），无论是其他 VSTS 帐户或 TFS 服务器中的包管理源，还是非包管理源（如 NuGet.org/npmjs.com、Artifactory 或 MyGet）（图 60）。 借助 NuGet 和 npm 的专用服务终结点类型，可以轻松地输入正确的凭据，并能跨包下载和包推送操作无缝使用生成任务。
VSTS/TFS 源选取器
我们一直建议签入配置文件（例如，NuGet.Config、.npmrc 等），以便源存储库可以记录包的源位置。 不过，我们也收到一些反馈意见，了解到这样做并不理想的一系列情形。因此，我们新增了“使用此 VSTS/TFS 源中的包”选项，以便用户能够选择源，并自动生成用于相应生成步骤的配置文件（图 62）。
生成和发布
XAML 生成
在 TFS 2015 中，我们引入了基于 Web 的跨平台生成系统。 TFS 2018 RTW 或 Update 1 中不支持 XAML 生成，但已在 TFS 2018 Update 2 中重新启用 XAML 生成。 建议迁移 XAML 生成。 如果尚未准备好进行迁移并需要继续使用 XAML 生成，请升级到 TFS 2018 Update 2。
升级到 TFS 2018 RTW 或 Update 1 后：
如果团队项目集合中有任何 XAML 生成数据，则会收到有关删除 XAML 生成功能的警告。
可以查看已完成的 XAML 生成，但无法将新生成排入队列。
TFS 2018 中没有新版本的 XAML 生成控制器或代理。
升级到 TFS 2018 Update 2 后：
如果团队项目集合中有任何 XAML 生成数据，则会收到有关弃用 XAML 生成功能的警告。
需要使用 Visual Studio 或团队资源管理器 2017 编辑 XAML 生成定义或将新的 XAML 生成排入队列。
如需创建新的 XAML 生成代理，需要使用 TFS 2015 生成代理安装程序安装它们。
提示
有关我们的 XAML 生成弃用计划的说明，请参阅博客文章 Evolving TFS/Team Services build automation capabilities（不断发展的 TFS/Team Services 生成自动化功能）。
导出和导入生成定义
生成定义在内部实现为 .json 文件，因此你可在文件历史记录中查看更改详细信息。 虽然已可以克隆生成定义并据此生成模板，但许多用户仍希望获取 CI 生成逻辑的副本，并将它重用于其他团队项目。 这是 UserVoice 上的十大请求之一。
我们很高兴向大家宣布，现在图 63 和图 64 所示功能已成为现实！
扩展中包含生成模板
使用生成模板，可以为用户创建基线，以便开始定义生成过程。 目前，我们提供大量现成的生成模板。虽然可以将新模板上传到帐户中，但扩展创建者以前却永远无法将新模板添加到扩展中。 现在可以在扩展中添加生成模板。 例如：
{ "id": "Template1",
"type": "ms.vss-build.template",
"targets": [ "ms.vss-build.templates" ],
"properties": { "name": "Template1" } }
有关完整示例，请访问 https://github.com/Microsoft/vsts-extension-samples/tree/master/fabrikam-build-extension。
提示
可以使用此功能，跨所有团队项目提供和共享同一个自定义模板。
弃用扩展中的任务
现在可以弃用扩展中的任务。 为此，必须将以下变量添加到最新版任务中：
"deprecated": true
当用户搜索弃用的任务（图 65）时，我们将这些任务推送到最后，并将它们整合到默认折叠的可折叠部分下。 如果定义已经使用弃用的任务，我们会显示弃用的任务徽章，建议用户切换到替换任务。
可以在任务说明中提及替换任务，从而帮助用户了解替换任务（图 66）。 然后，说明会指导用户通过任务目录和现有生成/发布定义，按正确方式使用任务。
允许参与的生成部分控制部分公开范围
以前，如果使用包含生成任务和生成摘要部分的扩展，即使未在相应生成中使用生成任务，也会看到生成摘要部分。 现在，可以在扩展代码中添加以下代码行，并将值设置为 true 或 false，从而选择在生成摘要页中隐藏或显示相应部分：
VSS.getConfiguration().setSectionVisibility("$(publisherId).$(extensionId).$(sectionId)", false);
请查看 Microsoft vsts-extension-samples 存储库中的示例。
变量组支持
已经可以在发布定义中使用变量组，现在也可以在生成定义中使用变量组。 详细了解如何创建变量组。 这是根据项目级生成/发布变量和生成定义中的变量组的相关建议进行开发和优先处理。
使用 Apple 证书等安全文件
我们添加了具有常规用途的安全文件库（图 67）。
使用安全文件库，可以在服务器上存储签名证书、Apple 预配配置文件、Android 密钥存储文件和 SSH 密钥等文件，而无需将它们提交到源存储库。
安全文件的内容已加密，只能在生成或发布过程中通过任务引用它们。 根据安全设置，安全文件可用于团队项目中的多个生成和发布定义。 安全文件遵循库安全模型。
我们还添加了一些 Apple 任务来利用这项新功能：
暂停生成定义
现可暂停或禁用生成定义。 如果计划更改生成定义且希望在完成之前避免任何新生成排队，只需禁用生成定义即可。 同样，如果计划升级代理计算机，可选择暂停生成定义，这会使 VSTS 依然接受新的生成请求，但将其保留在队列中而不运行，直到继续生成定义。
任务输入验证支持
有时候，在生成定义任务中键入参数容易出现错误。 通过任务输入验证，任务创建者可确保指定适当的值。 验证表达式遵循用于任务条件的常见表达式语法，除了任务条件支持的常用函数外，还可使用任何受支持的函数，包括 URL、IPV4、电子邮件、数字范围、sha1、长度或匹配。
提示
有关目标和使用情况的更多信息，请访问 vsts-tasks 存储库页面。
全新的发布定义编辑器
我们一直在不断更新生成和发布体验。我们已重新设计发布定义编辑器以提供更加直观的体验，消除了一些痛点并添加了新功能。 新编辑器的最强大功能之一是能可视化呈现环境部署的进展情况。 除此之外，审批、环境属性和部署设置现在都可视情况使用，配置起来非常容易。
管道的可视化效果
编辑器中的管道（图 68）提供了一个图形视图，用于呈现部署在发布中的进展。 项目供发布使用，然后会部署到环境中。 环境的布局和链接反映了为每个环境定义的触发器设置。
可视情况使用的配置 UI
项目、发布触发器、部署前和部署后审批、环境属性和部署设置现在都可视情况使用，配置起来非常容易（图 69）。
开始使用部署模板
所有内置部署模板均具备进程参数，用户可通过指定最重要的参数，更轻松地开始使用，无需深入了解任务的情况（图 70）。
简化发布和环境变量管理
使用“列表”视图快速添加发布或环境变量，使用“网格”视图跨范围并排比较和编辑变量。 此外，可在这两种视图中使用筛选器和关键字搜索来管理要处理的变量集。
改进了任务和阶段编辑器
全新的生成定义编辑器中的所有增强功能现也适用于发布定义编辑器（图 72）。 可以搜索任务，并使用“添加”按钮或拖放操作进行添加。 可以使用拖放操作，重新排列或克隆任务。
变量组、保留策略和“选项”选项卡
现在可以链接/取消链接到变量组（图 73），为各个环境设置保留策略，并从“选项”选项卡中修改发布定义级别设置，例如版本号格式。还可以将环境另存为部署模板、设置环境级别权限以及“任务”选项卡中的重新排序阶段。
执行环境级操作可另存为模板并设置安全性（图 74）。
使用部署组的虚拟机部署
Release Management 现在支持现成可靠的多计算机部署。 现在，可以安排跨多台计算机进行部署，并执行滚动更新，同时确保整个应用程序的高可用性。
基于代理的部署功能依赖相同的生成和部署代理。 不过，不同于现行方法（在代理池中的一组代理服务器上安装生成和部署代理，并促使部署到远程目标服务器），可以直接在每个目标服务器上安装代理，并促使滚动部署到这些服务器。 可以在目标计算机上使用完整的任务目录。
部署组（图 75）是一个目标（计算机）逻辑组，其中每个目标上都安装了代理。 部署组表示物理环境，例如单机开发、多计算机 QA 和 UAT/Prod 计算机场。它们还指定物理环境的安全上下文。
可以对向其注册了代理的任何虚拟机使用此功能。 我们还支持一个可在虚拟机启动时自动安装代理的 Azure 虚拟机扩展，这让用户很方便就可向 Azure 进行注册。 注册 Azure 虚拟机时，会自动继承标记。
拥有部署组后，只需配置要我们在相应部署组上执行的操作即可（图 76）。 可以使用标记控制在哪些计算机上运行什么部署，并控制滚动部署的速度快慢。
运行部署时，日志显示跨整个目标计算机组的部署进展情况（图 77）。
此功能现已集成到 Release Management。 不需要其他许可证。
改进了部署组 UI
我们一直在不断更新生成和发布体验。我们已重新设计部署组页面，使其可提供更加简洁直观的体验（图 78）。 从登录页面可查看部署组中目标的运行状况。 还可管理各个部署组的安全性，或者跨部署组设置默认权限。
对于部署组中的目标，可以查看摘要、最近部署和目标的功能（图 79）。 可以对目标设置标记，控制每个目标上的运行内容。 我们将在即将发布的版本中添加部署组筛选器支持。
任务组引用
使用任务组，可以定义一组能够添加到生成或发布定义的任务（图 80）。 如果需要在多个生成或发布中使用同一组任务，这就非常方便。 为了帮助用户跟踪任务组的使用者，现在支持查看引用任务组的生成定义、发布定义和任务组（图 79）。
尝试删除仍被引用的任务组时，我们会发出警告，并提供指向此页的链接。
任务组版本控制
更改任务组时，可能会觉得这样做有风险，因为更改会应用于使用任务组的所有定义。 通过任务组版本控制，现在可以组建和预览任务组版本，在能够切换前，仍向最重要的定义提供稳定版本。 经过一些组建和迭代后，可以发布稳定版本。发布时，如果更改属于重大更改，可以选择将任务组发布为预览版（新主版本）。 也可以直接发布为更新后的稳定版本（图 81）。
当任务组的新主版本（或预览版）可用时，定义编辑器会通知用户有新版本。 如果主版本是预览版，甚至还会看到内容为“试一试”的消息。 当任务组不再是预览版时，使用此版本的定义会自动更新（遵循主要通道）（图 82）。
任务组导入和导出
虽然可以在项目中重用任务组，但我们知道，跨项目和帐户重新创建任务组可能会非常痛苦。 现在，借助任务组导入/导出功能（图 83），可将任务组导出为 JSON 文件并在所需位置导入，就像我们对发布定义所做的那样。 我们还启用了嵌套的任务组，导出时它们会先展开。
服务器端（无代理）任务中的多配置支持
通过为服务器端（无代理）任务指定变量乘数（图 84），现在可以在并行运行的多个配置上的阶段中运行一组相同的任务。
手动干预任务中的变量支持
手动干预任务（图 85）现在支持在任务运行时向用户显示的说明文本中使用变量，以便用户可以继续执行发布过程或拒绝它。 可添加发布中定义的任何可用变量，这些值在通知以及发送给用户的电子邮件中使用（图 86）。
根据源分支控制部署到环境的发布
发布定义可以配置为，在新建发布时（通常是在源生成成功后）自动触发部署。 不过，不妨仅部署来自特定源分支的生成，而不是在任何生成成功时部署。
例如，不妨将所有生成部署到开发和测试环境，但只将特定的生成部署到生产环境。 以前，需要为此维护两个发布管道，一个用于开发和测试环境，另一个用于生产环境。
Release Management 现在支持对每个环境使用项目筛选器。 也就是说，可指定在满足部署触发器条件（如生成成功和新建发布）时向每个环境部署哪些发布。 在环境“部署条件”对话框（图 87）的“触发器”部分，选择触发向相应环境进行新部署的项目条件，如生成的源分支和标记。
此外，“发布摘要”页（图 88）现在会弹出提示，指明所有“未启动”部署处于这种状态的原因，并建议如何或何时启动部署。
作为项目源的 Git 存储库的发布触发器
Release Management 现在支持，为与同一帐户中任何团队项目中的发布定义相关联的 Git 存储库，配置持续部署触发器（图 89）。 这样就可以在对存储库进行新提交时自动触发发布。 还可以指定提交会触发发布的 Git 存储库分支。
发布触发器：持续部署推送到 Git 存储库的更改
Release Management 一直支持在生成完成时配置持续部署。 不过，现在还可以对 Git 推送配置持续部署。 也就是说，可以将 GitHub 和 Team Foundation Git 存储库作为项目源与发布定义相关联，再自动为不是通过生成制作的 Node.JS 和 PHP 等应用程序触发发布，因此无需适用于持续部署的生成操作。
环境触发器中的分支筛选器
在新的发布定义编辑器中，现可为特定环境指定项目条件。 通过使用项目条件，可以更加精细地控制哪些项目应部署到特定环境。 例如，对于生产环境，可能需要确保仅部署从主分支产生的生成。 需要对你认为应满足此条件的所有项目设置此筛选器。
也可对链接到发布定义的每个项目添加多个筛选器（图 90）。 仅当成功满足所有项目条件时，才对此环境触发部署。
增强了服务器端任务
我们对服务器端任务（在服务器阶段内运行的任务）进行了两项增强。
我们新增了一个任务，可在自动管道中调用任何常规 HTTP REST API（图 91）。 例如，可用于使用 Azure 函数调用特定的处理，并等待它完成。
我们还向所有服务器端任务添加了“控制选项”（图 92）部分。 任务行为现在包括设置“已启用”、“出错时继续”、“始终运行”和“超时”选项。
代码中心内的发布状态徽章
目前，若要确定是否已将提交部署到客户生产环境中，请先确定哪个生成使用此提交，再检查部署该生成的所有发布环境。 现在，操作大大简化了。“代码”中心状态徽章中集成了部署状态，可以列出代码已部署到的环境。 对于每个部署，状态都会发布到已部署的最新提交。 如果将提交部署到多个发布定义（包含多个环境），每个提交都会在徽章中记录一个条目，并显示针对每个环境的状态（图 93）。 这提升了已部署的代码提交的可跟踪性。
默认情况下，创建发布定义时，部署状态会针对所有环境进行发布。 不过，可以有选择地选择应在状态徽章中显示哪些环境的部署状态（例如，仅显示生产环境的部署状态）（图 94）。
增强了添加项目时使用的“生成定义”菜单
将生成项目添加到发布定义时，现在可以查看定义及其文件夹组织信息，并轻松选择所需的定义（图 95）。 这样，可以很容易区分不同文件夹中同名的生成定义。
定义列表的筛选依据为是否包含筛选词。
将发布定义还原为旧版
目前，如果发布定义已更新，便无法直接还原为旧版。 唯一的方法是，查看发布定义历史记录，找出更改的差异，再手动编辑发布定义。 现在，使用“还原定义”功能（图 96），可以选择并还原为发布定义“历史记录”选项卡中的任意旧版发布定义。
个性化发布通知
发布通知现已与 VSTS 通知设置体验集成。 现在，这些管理版本自动获取有关挂起的操作（审核或手动干预）以及重要部署故障的通知。 通过导航至配置文件菜单下的“通知”设置并将“发布订阅”切换为“关闭”可关闭这些通知。 通过创建自定义订阅还可订阅其他通知。 管理员可通过“团队”下的“通知”设置和“帐户”设置控制团队和组的订阅。
发布定义创建者不再需要手动发送关于审核和部署完成的电子邮件。
对于具有多个发布利益干系人的大型帐户以及除审核者、发布创建者和环境所有者之外希望接收通知的人员，这尤为有用（图 97）。
提示
有关详细信息，请参阅管理发布通知一文。
测试
不再支持 Microsoft 测试管理器中的实验室中心和自动测试流
随着 Build Management 和 Release Management 的发展，TFS 2018 不再支持 XAML 生成，因此我们要更新有关结合使用 Microsoft 测试管理器 (MTM) 与 TFS 的支持。 自 TFS 2018 起，TFS 不再支持在 MTM 中使用测试中心/实验室中心进行自动测试。 如果尚未准备从 XAML 生成和实验室中心迁移，则不应升级到 TFS 2018。
请阅读以下内容，了解升级到 TFS 2018 的影响：
实验室中心：
- 不再支持：
- 无法向 TFS 注册用于创建和管理实验室环境的 Test Controller。
- 向 TFS 注册的任何现有 Test Controller 离线，现有实验室环境显示为“未就绪”。
- 建议的替代方法：
- 可使用 SCVMM TFS 扩展连接到 SCVMM 服务器、创建和管理虚拟机，还可在上面运行工作流。 如需了解更多详情，请参阅如何在生成和发布中执行实验室管理操作。
自动测试：
- 不再支持：
- 不再支持依赖 Test Controller 和实验室环境的自动测试工作流（如 XAML Build-Deploy-Test 工作流），也不再支持使用 MTM 根据测试计划运行自动测试。
- 建议的替代方法：
手动测试：
- 继续完全支持所有手动测试方案。 虽然可以结合使用 MTM 与 TFS 2018 进行手动测试，但实验室环境不能用于运行手动测试。
- 对于所有手动测试方案，我们强烈建议将 TFS 连接到 Web 以使用测试中心。
提升了工作项链接、迭代和区域路径的探索测试可跟踪性
根据探索测试团队向我们提供的反馈意见，我们一直在改进可跟踪性链接，同时从测试和反馈扩展提交 bug、任务或测试用例。 对于探索需求时创建的 bug 和任务，现在使用与需求相同的区域路径和迭代（而不是团队默认值）进行创建。 对于探索需求时创建的测试用例，它们现在使用“测试 <-> 测试方”链接（而不是“父级 <-> 子级”链接）进行链接，以便将创建的测试用例自动添加到以需求为依据的测试套件。 最后，在没有具体了解任何需求时创建的工作项被提交到团队的默认迭代中，而不是当前迭代中，这样在冲刺 (sprint) 计划完成后，就没有任何新工作项进入当前迭代了。
筛选测试中心内的“测试计划和套件”中的测试用例工作项
除了可以筛选“结果”、“配置”和“测试程序”等“测试”字段之外，现在还可以筛选“标题”、“状态”和“分配到”（图 98）等测试用例工作项字段。
“发布环境”和“测试运行”的测试趋势图
我们现已开始支持“测试结果趋势”小组件（图 99）中的“发布环境”，这样用户便可以在 VSTS 仪表板上跟踪测试环境的状态。 就像在“生成”中处理测试结果一样，现在可以创建趋势图，针对“发布环境”显示测试通过率、总数、通过或未通过测试和测试持续时间。 还可以使用“测试运行”标题筛选器，从图表中筛选出环境内的特定测试运行。
“测试运行”和“测试结果”注释的 Markdown 格式支持
我们现已开始支持使用 Markdown 语法设置“测试运行”和“测试结果”注释的格式。 可以使用此功能，在注释中创建格式化文本或指向 URL 的快速链接。 可以使用“更新分析”更新“结果摘要”页中的“测试结果”注释，并使用“测试”中心内的“更新注释”更新“运行摘要”页中的“测试运行”注释。
添加链接指向未通过测试的现有 bug
在“生成”/“发布”摘要页或“测试”中心内分析测试结果时，现在可以将现有 bug 与未通过测试相关联。 当测试由于已知原因而未通过且 bug 已提交时，这就非常有用。
上传附件以测试运行和测试结果
现在可将屏幕截图和日志文件等文件作为其他信息附加，以测试运行或测试结果。 目前仅通过 Microsoft 测试管理器 (MTM) 客户端提供此功能，因此必须在 VSTS/TFS 的“测试”中心和 MTM 客户端之间切换上下文。
测试批处理
在生成/发布管理的 Visual Studio 测试任务中，为实现高效执行，可以选择控制测试的分组（批处理）方式。 测试可按两种方式分组：
- 基于参与运行的测试和代理数量，这种方式仅将测试分组为具有指定大小的批次数。
- 基于过去的测试运行时间，这种方法使用过去的运行时间创建测试批，从而使每个批具有大致相等的运行时间（图 100）。 对快速运行的测试一起进行批处理，而单独的批可能会需要更长的时间运行测试。 此选项可与多代理阶段设置结合，将总测试时间降至最短。
使用 VSTest 任务运行 webtest
通过使用 Visual Studio 测试任务，现可在 CI/CD 管道中运行 webtest（也称为 Web 性能测试）。 可通过指定要在任务程序集输入中运行的测试来运行 Webtest。 还可通过选择任务中的测试计划/测试套件运行其“关联自动化”链接到 webtest 的任何测试用例工作项（图 101）。
Webtest 结果以测试结果附件形式提供（图 102）。 可下载此结果以在 Visual Studio 中进行脱机分析。
此功能依赖于 Visual Studio 测试平台的更改，并且需要在生成/发布代理上安装 Visual Studio 2017 Update 4。 使用 Visual Studio 的以前版本无法运行 Webtest。
同样，可使用“运行功能测试”任务运行 webtest。 此功能依赖于测试代理的更改，将在 Visual Studio 2017 Update 5 中提供。
提示
有关如何结合使用此功能和负载测试的示例，请参阅使用 Visual Studio 和 VSTS 在云中加载测试应用快速入门。
测试计划和测试套件的图表小组件
以前可在“测试”中心为测试计划和套件创建图表并将其固定到仪表板。 现已添加一个小组件，该组件支持从仪表板上的小组件目录为测试计划和套件创建图表。 可以创建测试创作状态或测试执行状态的图表。 此外，图表上需要显示大量数据时，通过从小组件添加图表可以创建更大的图表（图 103）。
增添了对使用 Chrome 浏览器的桌面应用的屏幕截图和注释支持，以进行手动测试。
我们将添加对一条手动测试热门建议的支持，即从“测试”中心的“Web 测试运行程序”捕获桌面应用程序屏幕截图。 到目前为止，必须使用“Microsoft 测试管理器”中的“测试运行程序”捕获桌面应用的屏幕截图。 使用此功能需要安装测试和反馈扩展。 我们即将推出对 Chrome 浏览器的支持，并在不久后推出对 Firefox 的支持。
停止提供适用于 SharePoint 的 TFS 扩展
TFS 2018 及更高版本不再支持适用于 SharePoint 的 TFS 扩展。 此外，用于配置 TFS 服务器与 SharePoint 服务器集成的屏幕，已从 Team Foundation 管理控制台中删除。
注意
如果从配置为与 SharePoint 集成的先前版本升级到 TFS 2018，升级后需要禁用 SharePoint 集成，否则 TFS SharePoint 站点将加载失败。
我们已创建一个解决方案，通过该方案可在 SharePoint 服务器上禁用集成。 有关详细信息，请参阅有关 TFS/SharePoint 集成的未来的文章。
停止提供团队聊天室
新式开发团队主要依靠协作。 团队成员希望（且需要）有地方来监视活动（通知），并进行讨论（聊天）。 几年前，我们认识到这种趋势，并着手构建团队聊天室，以支持实现这些方案。 自那以后，市场中出现了更多协作解决方案。 最突出的是，Slack 的兴起。 近期，我们宣布推出 Microsoft Teams。
有这么多优质的解决方案可与 TFS 和 Visual Studio Team Services 完美集成，我们在 1 月宣布，计划从 TFS 2018 和 Visual Studio Team Services 中删除团队聊天室功能。
我们做得怎么样？
我们期待你的宝贵意见和建议！ 可以通过开发者社区门户报告并跟踪问题，并能在 Stack Overflow 上了解相关建议。