Team Foundation Server 2018 Update 2 发行说明
开发者社区 | 系统要求和兼容性 | 许可条款 | TFS DevOps 博客 | SHA-1 哈希 | | 最新 Visual Studio 2019 发行说明
本文将介绍最新发布的 Team Foundation Server 2018。 单击此按钮下载。
要详细了解 Team Foundation Server 2018，请参阅 Team Foundation Server 要求和兼容性页面。 请访问 visualstudio.com/downloads 页面，下载其他 TFS 2018 产品。
从 TFS 2012 起，支持直接升级到 Team Foundation Server 2018 Update 2。 如果你的 TFS 部署为 TFS 2010 或更低版本，则需要在升级到 TFS 2018 Update 2 之前执行一些过渡步骤。 请参阅以下图表和 TFS 安装页以获取详细信息。
重要
不必先升级到 TFS 2018 Update 2，再升级到 TFS 2018 RTM。
发布日期：2018 年 5 月 7 日
现可升级到 TFS 2018 Update 2 并继续连接 XAML 控制器和运行 XAML 生成。 当我们在 TFS 2018 RTW 和 Update 1 中删除对 XAML 生成的支持时，你们一些人由于拥有旧版 XAML 生成而无法升级，现在我们要为你解除这个麻烦。 虽然 TFS 2018 Update 2 支持旧生成的 XAML 生成，但 XAML 生成已弃用，且不会有进一步的投入，因此，我们强烈建议转换为较新的生成定义格式。
TFS 2018 Update 2 中的新增功能摘要
我们已在 Team Foundation Server 2018 Update 2 中增加了许多新值。 其中一些重要内容包括：
- 查看拉取请求合并提交
- 帮助审阅者使用拉取请求标签
- 提及拉取请求
- 拉取请求注释通知包括线程上下文
- 拉取请求状态扩展性
- 在工作项跟踪通知中自定义字段和标记筛选器
- 优化列选项
- 添加对 Not In 查询运算符的支持
- Query for @MyRecentActivity and @RecentMentions
- 对计划进行筛选
- 发布入口
- 从 GitHub Enterprise 生成持续集成
- 多阶段生成的增强功能
- 如果存储库中未进行任何更改，则跳过计划生成
- 利用上游源无缝使用公共包
- TFS 源中的保留策略
- 在包管理中进行筛选
- Wiki 搜索
- 引用 wiki 中的工作项
- 在编辑 Wiki 页时预览内容
- 将丰富的 Wiki 内容粘贴为 HTML 格式
- 个人资料卡
- 圆形头像
TFS 2018 Update 2 中的新增功能详细信息
可以在每个区域中查找有关功能的详细信息：
代码
获取代码的永久链接
查看文件时，通常会在所选分支的提示处看到版本。 提示的文件版本会随着新提交的内容而更改。 如果从该视图复制链接，则会由于 URL 只包括分支名称而不包括提交 SHA，导致链接失效。 现在可以轻松切换“文件”视图，以更新引用提交而不是分支的 URL。 按下“y”键时，视图会切换到当前分支的提示提交处。 然后就可以复制永久链接了。
通过 API 恢复最近删除的存储库
在清除源代码管理中的旧存储库时，有时可能会出错。 如果是在最近 30 天内删除了 Git 存储库，则可以通过 REST API 将其恢复。 有关详细信息，请参阅列表和恢复中的文档。
SSH：支持其他密码/密钥并弃用过期密码
为增强安全性和兼容性，我们更新了 SSH 支持的密码列表。 为匹配 OpenSSH 的方向，我们添加了两组新密码并弃用了三组旧密码。 已弃用的密码仍能在此版本中使用。 随着使用量的减少，以后将删除这些密码。
已添加：
- AES128 CTR
- AES256 CTR
已弃用：
- AES128
- AES192
- AES256
使用存储库设置避免覆盖以及保护性能
此更新中包括两种有助于 Git 顺利运行的新存储库设置。
“大小写执行”用于将服务器从其默认的区分大小写模式（即“File.txt”和“file.txt”引用相同文件）切换到 Windows 和 MacOS 友好模式（即“File.txt”和“file.txt”是同一个文件）。 此设置会影响文件、文件夹、分支和标记。 还可以防止参与者意外引入区分大小写差异。 如果大部分参与者都运行 Windows 或 macOS，则推荐启用大小写执行。
限制文件大小，可以防止新的或已更新的文件超出所设置的文件大小。 Git 存储库历史记录中存在的大型文件数量越多，克隆和提取操作性能越差。 此设置可防止意外引入这些文件。
针对超过 1000 个修改文件的提交，增强了筛选功能
在超过 1000 个修改文件的提交或拉取请求中搜索文件效率很低；需要多次点击“加载更多”链接才能找到感兴趣的文件。 现在，在树状视图中筛选内容时，可以在该提交的所有文件中（而不仅仅是已加载的前 1000 个文件中）搜索所需文件。 当修改的文件数量超过 1000 时，提交详细信息页面的性能也有所改进。
查找由于强制推送而丢失的提交
可以执行 Git 强制推送并更新远程 ref，即使它不是本地 ref 的上级。但这会导致其他人丢失提交，并且很难确定根本原因。 在新的推送视图中，可以很明显地看到强制推送，这可以帮助解决与丢失提交有关的问题。
单击强制推送标记即可转到已删除的提交。
“意见”现在具有历史记录
“意见”视图非常适合用于确定更改代码行的最后一个人。 但有时需要确定先前更改代码行的人。 此时可以借助意见中的最新改进功能（在此提交前查看意见）实现。 顾名思义，此功能允许及时跳转到更改特殊行之前的文件版本，并查看此版本的意见信息。 可以继续及时返回查看已更改所选代码行的每个文件版本。
差异视图中的“切换自动换行”和“切换空格”
文件差异查看器提供了两个新功能：“切换自动换行”和“切换空格”。 第一个功能允许在差异视图中应用自动换行设置。 这非常适用于查看包含文件而又没有频繁换行符的 PR - Markdown 文件就是一个很好的例子。 当行或文件中仅更改了空格时，此项切换空格的功能便十分有帮助。 切换此设置会显示并突出显示差异中的空格字符（空格的点、标签的箭头等）。
若要管理这些设置，请在拉取请求编辑器或差异视图中单击编辑器首选项齿轮。 在“文件”视图中，选择右键菜单上的“用户首选项”选项。
选择各种编辑器功能，包括“显示和区分空格”、“启用自动换行”、“启用代码折叠”和“显示最小映射”。
在 Web 视图也启用代码折叠（在某些编辑器中称为“大纲显示”）。 启用代码折叠后，单击减号可折叠代码部分，单击加号可展开已折叠部分。 F1 命令面板还提供了用于在整个文件中折叠各种缩进级别的选项，从而可以更轻松地阅读和查看大型文件。
跟踪推送到 Git 存储库的代码来生成和发布
现在可以在“推送”页面中查看合并提交的生成和发布状态。 单击推送旁边的状态，便可找到包含推送的特定生成或发布，从而验证成功或调查失败。
在电子邮件通知中呈现 markdown
Markdown 非常适用于在拉取请求 (PR) 说明和注释中添加丰富的格式、链接和图像。 PR 的电子邮件通知现在显示已呈现的 markdown 而不是原始内容，提高了可读性。
内联图像还尚未呈现为内联（只是显示为链接），但我们已在积压工作 (backlog) 中准备了这些内容，便于以后添加。
从 Windows 资源管理器中直接执行 TFVC 命令
提供集成到 Windows 文件资源管理器中的轻量级版本控制体验的 TFVC Windows Shell 扩展，现支持 TFS 2018。 此工具可直接在 Windows 资源管理器的上下文菜单中方便地访问许多 TFVC 命令。
该工具以前是 TFS Power 工具的一部分，现已在 Visual Studio Marketplace 上作为独立工具发布。
控制可以参与拉取请求的人员
以前，任何人只要能够查看 Git 存储库，就能使用其拉取请求。 我们添加了称为“参与拉取请求”的新权限，控制对创建和注释拉取请求的访问。 之前拥有“读取”权限的所有用户和组都将默认授予此新权限。 引入此新权限使管理员可以更灵活地进行控制。 如果要让“读者”组为真正的只读，可以拒绝“参与拉取请求”权限。
请参阅设置存储库权限的快速入门文档，获取详细信息。
拉取请求注释通知包括线程上下文
很多时候，针对拉取请求 (PR) 注释的回复都非常简短，但现已确定即将或已经对此作出更改。 在 Web 视图中查看这些注释时，这不是什么问题，但如果在电子邮件通知中阅读注释，则将丢失原始注释的上下文。 一句简单的“我会修复”没有任何意义。
现在，无论何时回复 PR 注释，注释电子邮件都会在电子邮件正文中包含以前的回复。 这使线程参与者可以从收件箱查看注释的完整上下文 - 无需打开 Web 视图。
完成工作项设置
完成拉取请求时完成工作项的功能现在具有新的存储库设置来控制默认行为。 “记住用户使用拉取请求完成工作项的首选项”这一新设置默认启用，并在完成存储库中未来的拉取请求时优先记住用户的最后状态。 如果禁用了该新设置，则对于存储库中的所有拉取请求，都默认禁用“在合并后完成链接的工作项”选项。 用户仍然可以选择在完成 PR 时转换链接的工作项，但每次都需要选择加入。
拉取请求状态扩展性
使用分支策略可以有效提升代码质量。 不过，这些策略只适用于 TFS 本机提供的集成。 通过新的拉取请求状态 API 和相应的分支策略，第三方服务可参与拉取请求工作流，就像本机 TFS 功能一样。
当服务发布到拉取请求状态 API 时，它会立即出现在“PR 详细信息”视图中新增的“状态”部分内。 “状态”部分显示说明，并创建指向服务提供 URL 的链接。 “状态”条目还支持可扩展的操作菜单 (...)，以便通过 Web 扩展添加新操作。
光是“状态”，并不会阻止 PR 的完成，此时策略就派上用场了。 在 PR 状态发布后，便可以配置策略。 使用分支策略时，可以使用新策略“需要外部服务的批准”。 选择“+ 添加服务”，开始执行此过程。
在对话框中，从列表中选择要发布状态的服务，再选择所需的策略选项。
在策略处于活动状态后，状态便会显示在“策略”部分中相应的“必需”或“可选”下，并会根据需要强制完成 PR。
拉取请求服务挂钩合并事件
使用拉取请求服务挂钩的扩展现在具有更多针对合并事件的详细信息和筛选选项。 任何时候只要尝试合并，无论合并成功与否都会触发事件。 当尝试合并失败时，有关失败详细原因将会包含在内。
改进了针对使用拉取请求完成工作项的错误消息
尝试使用拉取请求完成工作项时，可能无法将相关的工作项转换为完成状态。 例如，可能需要特定字段和用户输入才能转换状态。 我们已改进了体验，在工作项转换受阻时会通知用户，以便用户采取措施进行必要的更改。
提及拉取请求
现在可以在 PR 注释和工作项讨论中提及拉取请求。 提及 PR 的过程与工作项的过程类似，但前者使用感叹号 ! 而不是哈希标记 #。
无论何时想提及 PR，只需输入 !，即可在最近的 PR 列表中看到选取 PR 的交互式体验。 输入关键字筛选建议列表，或输入想提及的 PR ID。 一旦提及到 PR，PR 就会与 ID 以及完整标题呈现内联，并且将链接到 PR 详细信息页面。
帮助审阅者使用拉取请求标签
有时，向审阅者传达与拉取请求有关的额外信息非常重要。 也许拉取请求仍在进行工作，或者它是即将发布版本的修补程序 - 因此需要在标题中追加一些额外文本，可能是“[WIP]”前缀或“不能合并”。 现在可以使用标签标记拉取请求，其中的额外信息可用于传达重要详情并帮助组织拉取请求。
拉取请求注释跟随重命名的文件
有时在激活拉取请求时会重命名或移动文件。 以前，如果这些重命名文件有注释，则代码的最新视图不会显示这些注释。 现在，我们已经改进了注释跟踪功能，跟随重命名的文件，从而在最新版本的重命名或移动文件上显示注释。
查看拉取请求合并提交
拉取请求差异视图非常适合突出显示源分支中引入的更改。 但是，更改目标分支会导致差异视图与预期不符。 现在可用新命令查看提取请求的“预览”合并提交差异 - 查看合并提交。 此合并提交创建用于检查合并冲突和使用拉取请求生成，还可反映在拉取请求最终完成时，合并提交的结果。 如果目标分支的变化未反映在差异中，则合并提交差异可用于查看源分支和目标分支中的最新更改。
与“查看合并提交”命令结合使用非常有效的另一个命令是“重启合并”（可在同一命令菜单上使用）。 如果最初创建拉取请求后目标分支已发生更改，则运行此命令会创建新的预览合并提交，更新合并提交差异视图。
最近使用的审阅者
如果经常由同一个人审阅你的代码，你会发现添加审阅者比以往都要容易。 将审阅者添加到拉取请求时，指针指向审阅者输入框，最近添加的审阅者列表将自动显示出来 - 无需搜索姓名。 选择所需的任何审阅者。
查看拉取请求自动完成的保留政策条件
对于使用分支策略的团队来说，自动完成是一项行之有效的功能，但在使用可选策略时，则可能不清楚阻止拉取请求完成的确切方式。 现在，当为拉取请求设置自动完成时，需要持续完成的策略条件确切列表就已明确地在标注框中列出。 满足每个要求后，将从列表中删除项，直到没有剩余要求并且拉取请求合并完毕。
讨论拉取请求中的数学
拉取请求注释中需要包含方程式或数学表达式吗？ 现在可以使用内联和块注释，在注释中包含 KaTeX 函数。 请参阅支持的函数列表，获取详细信息。
分支的拉取请求建议
每当在存储库中更新主题分支时，都会显示为主题分支创建新的拉取请求 (PR)“建议”。 这对创建新 PR 非常有效，我们也在分支存储库中启用了它。 如果更新了分支中的某个分支，那么下次访问“代码”中心的分支或上游存储库时，都会看到创建拉取请求的建议。 如果选择“创建拉取请求”链接，将会转到创建 PR 体验，并且已预选择源和目标分支以及存储库。
拉取请求策略的路径筛选器
很多时候，单个存储库包含由多个持续集成 (CI) 管道生成的代码，用于验证生成和运行测试。 集成的生成策略现在支持路径筛选器选项，可为每个 PR 轻松配置所要求的和自动触发的多个 PR 生成。 只需为每个所需要的生成指定一个路径，并且根据需要设置触发器和需求选项即可。
除了生成，状态策略还具有可用的路径筛选器选项。 由此，任何自定义或第三方策略都可为特定的路径配置策略执行。
工作
工作项窗体中的键盘快捷方式
将工作项分配给自己 (Alt + I)，跳转到讨论 (Ctrl + Alt + D)，以及使用键盘快捷方式将快速链接复制到工作项 (Shift + Alt + C)。 有关新快捷方式的完整列表，在工作项窗体打开的状态下键入“?”或查看下表。
优化列选项
“列选项”对话框用于配置“积压工作 (backlog)”中的工作项网格列，“查询”和“测试”中心已更新为使用新面板设计。 搜索以查找字段、拖放以重新设置列顺序或删除不再需要的现有列。
查询上次运行者信息
随着项目的“共享查询”树的增长，很难确定是否不再使用某个查询，是否可将其删除。 为了帮助管理“共享查询”，我们向查询 REST API 、上次执行者和上次执行日期添加了两种新的元数据，因此可编写清理脚本并删除过时查询。
在工作项网格中提取 HTML 标记
根据客户反馈，我们更新了 Web、Excel 和 Visual Studio IDE 中工作项查询结果视图的多行文本字段行为，以删除 HTML 格式。 当作为列添加到查询中时，多行文本字段现在会显示为纯文本。 以下是描述中带有 HTML 特性的一个示例。
在过去，查询结果呈现出类似于 <div><b><u>Customer Value</u>... 的内容
已添加对 Not In 查询运算符的支持
支持“In”查询运算符的字段现在支持“Not In”。 为工作项“Not In”ID 列表、“Not In”状态列表等编写查询都不需要创建多个嵌套的“Or”子句。
查询 @MyRecentActivity 和 @RecentMentions
我们为“ID”字段引入了两个新的查询宏，以便查找重要的工作项。 使用 @RecentMentions 查看在过去 30 天内所提到的项目，或使用 @MyRecentActivity 了解最近查看或编辑过的工作项。
工作项跟踪通知中的自定义字段和标记筛选器
现在可以使用自定义字段和标记上的条件来定义通知；不但在通知改变时适用，而且在满足某些值时也适用，同时还允许为工作项设置更可靠的一系列通知。
针对“我的工作项”页面的提及支持
我们已在“我的工作项”页面下添加了新的“提及”透视。 在此透视中，可以查看在最近 30 天内提及到的工作项。 有了这个新视图，可以快速执行需要输入的项并及时了解与自己有关的对话。
通过移动体验也能实现相同的透视功能，这样可以使移动端和桌面保持一致。
对计划进行筛选
现在，交付计划扩展使用我们的通用筛选组件，并且与我们针对工作项和“任务板”的网格筛选体验保持一致。 团队中的所有成员都可以享用该筛选控件带来的提升的易用性和一致性界面。
更新计划导航
许多人都很关注特定的计划或计划集，并使用收藏夹以快速访问这些内容。 首先，我们已更新了“计划”中心，可导航到最近访问过的计划而不是目录页。 其次，在计划中心还可以使用收藏夹选取器快速切换到另一个计划，或使用痕迹导航返回到目录页面。
在任务版上展开/折叠要求/人员
现在只需单击一次便可展开或折叠冲刺(sprint)“任务板”上的所有项。
向特定用户授予 bypassrule 权限
当从其他源迁移工作项时，组织通常希望保留工作项的所有原始属性。 例如，可能希望创建一个 bug，保留源系统中的初始创建日期和创建者值。
用于更新工作项目的 API 具有 bypassrule 标记来启用该方案。 以前，提出 API 要求的身份必须是项目集合管理员组中的成员。 我们已经在项目级别添加了一个权限，以使用 bypassrule 标记执行 API。
生成和发布
XAML 生成
在 TFS 2015 中，我们引入了基于 Web 的跨平台生成系统。 TFS 2018 RTW 或 Update 1 中不支持 XAML 生成，但已在 TFS 2018 Update 2 中重新启用 XAML 生成。 建议迁移 XAML 生成。
升级到 TFS 2018 Update 2 后：
如果团队项目集合中有任何 XAML 生成数据，则会收到有关弃用 XAML 生成功能的警告。
需要使用 VS 或团队资源管理器 2017 编辑 XAML 生成定义或将新的 XAML 生成排入队列。
如需创建新的 XAML 生成代理，需要使用 TFS 2015 生成代理安装程序安装它们。
有关我们的 XAML 生成弃用计划的说明，请参阅博客文章 Evolving TFS/Team Services build automation capabilities（不断发展的 TFS/Team Services 生成自动化功能）。
多阶段生成的增强功能
你已经能够使用阶段来组织生成步骤，并针对每个阶段根据不同需求选择不同代理。 我们已添加了几个功能来生成阶段，以便现在可以：
为每个阶段指定一个不同的代理队列。 这意味着可以执行下列操作，例如：
- 在 macOS 代理上运行生成的一个阶段，在 Windows 代理上运行另一个阶段。 请观看 Connect (); 2017 视频：CI/CD DevOps Pipeline for mobile apps and services（用于移动应用和服务的 CI/CD DevOps 管道），参阅一个很棒的示例，体会这项功能的强大之处。
- 在生成代理池中运行生成步骤，在测试代理池中运行测试步骤。
通过并行运行这两个步骤，更快地运行测试。 现在，已并行配置为“多个代理”并包含“VSTest”任务的阶段都将自动通过配置的代理计数并行执行测试。
允许或拒绝脚本访问 OAuth 标记的每个阶段。 这意味着，例如，现在可以允许脚本在生成阶段运行，通过 REST API 与 VSTS 进行通信，并在相同的生成定义中阻止脚本在测试阶段运行。
仅在特定条件下运行某个阶段。 例如，可以将某个阶段配置为仅在上一个阶段成功完成后运行，或仅在主分支中生成代码时运行。
有关详细信息，请参阅Phases in Build and Release Management（生成和发布管理中的阶段）。
如果存储库中未发生更改，则跳过计划生成
通过常见请求，现在可以指定代码无变化时，不运行计划生成。 可以使用计划上的选项控制这一行为。 默认情况下，如果上一个计划生成（源自同一个计划）已通过并且存储库没有签入进一步的更改，则不会计划新的生成。
从 GitHub Enterprise 生成持续集成
如果使用“GitHub Enterprise”进行版本控制，则可以用更好地集成方式执行持续集成 (CI) 生成。 之前，仅限于使用“外部 Git”连接器轮询代码更改，这会增加服务器负载并在触发生成前造成延迟。 现在，借助官方“GitHub Enterprise” 的支持，可以立即触发团队 CI 生成。 此外，还可以使用各种身份验证方法配置连接，例如 LDAP 或内置帐户。
在生成或发布期间，可以将安全文件下载到代理
新的“下载安全文件”任务支持从 VSTS 安全文件库“下载加密文件”（到代理计算机）。 文件下载后，将被解密并存储在代理磁盘上。 生成或发布完成后，将从代理删除该文件。 这允许生成或发布使用敏感文件（例如证书或私钥），否则这些文件将被安全加密并存储在 VSTS 中。 有关详细信息，请参阅安全文件文档。
可以从源存储库安装 Apple 预配配置文件
“安装 Apple 预配配置文件”任务已支持（在代理计算机上）安装存储在“VSTS 安全文件”库中的预配配置文件。 Xcode 使用预配配置文件签署和打包 Apple 应用，例如 iOS、macOS、tvOS 和 watchOS。 现在，可以从源代码存储库安装预配配置文件。 尽管建议使用安全文件库以提高这些文件的安全性，但这项改进解决了存储在源代码管理中的配置文件的安全问题。
使用生成标记跟踪 GitHub 源生成
GitHub 或 GitHub Enterprise 的生成已链接到相关提交。 能够跟踪生成它的生成的提交同样重要。 现在可以通过启用 TFS 中的源标记，实现这一点。 在生成定义中选择 GitHub 存储库时，选择想要标记的生成类型以及标记格式。
然后，监视出现在 Enterprise 或 GitHub Enterprise 存储库中的生成标记。
可在生成或发布期间安装特定的 Java 开发工具包 (JDK)
生成某些 Java 项目时，可能会需要特定但代理计算机上不可用的 JDK。 例如，项目可能需要旧版或不同版本的 IBM、Oracle 或开源 JDK。 “Java 工具安装程序”任务可下载并安装在生成或发布期间项目所需要的 JDK。 根据生成或发布的持续时间设置 JAVA_HOME 环境变量。 使用文件共享、源代码存储库或 Azure Blob 存储，可以让“Java 工具安装程序”使用特定 JDK。
改进了 Xcode 生成配置
已使用新的主版本 (4.*) 更新 Xcode 任务，该版本改进了 Xcode 生成、测试和打包的相关配置。 如果 Xcode 项目有单个共享方案，则将自动使用该方案。 已添加附加的内联帮助。 已从 Xcode 任务的属性中删除弃用的功能（例如 xcrun 打包）。 必须将现有生成和发布定义修改为使用 Xcode 任务的最新 4.* 版本。 对于新定义，如果需要之前的 Xcode 任务版本中已弃用的功能，可以在定义中选择该版本。
发布入口
持续监视是 DevOps 管道中不可分割的一部分。 在部署后确保发布中的应用处于正常状态，这一步与成功部署同样重要。 企业已采用各种工具来自动检测生产过程中应用的运行状况，并持续跟踪客户反映的事件。 到目前为止，审批者在推广发布之前仍必须手动监视所有系统的应用运行状况。 但是，发布管理现在支持将连续监视集成到发布管道。 在继续发布前，使用此功能确保系统重复查询应用的所有运行状况信号，直到同时成功运行全部应用。
以在发布定义中定义预先部署或后期部署入口开始。 每个入口都可监视与应用系统相对应的一个或多个运行状况信号。 内置入口可用于“Azure Monitor（应用程序见解）警报”和“工作项”。 可以利用 Azure Functions 提供的灵活性来与其他系统集成。
在执行时，“发布”开始对所有入口进行采样，并从每个入口收集运行状况信号。 它在每个间隔重复采样，直到在相同间隔内成功收集所有入口的信号为止。
因为用于新部署的信息不足，所以来自监视系统的初始样本可能不准确。 即使成功完成所有采样，“在计算前延迟”选项也可确保在此期间不会进行“发布”。
在入口采样期间，不会消耗代理或管道。 请参阅发布入口文档获取详细信息。
根据触发发布的项目有选择地部署
可以将多个项目源添加到发布定义并配置为触发发布。 当新生成可用于任一源时，即为创建新发布。 无论是哪个源触发了发布，都将执行相同的部署过程。 现在可以触发源，自定义部署过程。 对于自动触发的发布，现在填充了发布变量“Release.TriggeringArtifact.Alias”，以确定触发发布的项目源。 可以在任务条件、阶段条件和任务参数中使用这一功能，从而动态调整过程。 例如，可用于仅需要部署在环境中发生更改的项目。
管理特定实体的安全性
以前，在基于角色的安全性中，设置安全访问角色时，这些角色都设置为部署组、变量组、代理队列和服务终结点的中心级别用户或组。 现在可以打开或关闭特定实体的继承，因此可以按照自己的方式配置安全性。
审批多个环境
使用发布管理审批现在变得更加简单。 对于并行部署在多个环境且具有相同审批者的管道，审批者当前需要分别处理每个审批。 借助此功能，现在可以同时完成多个待处理的审批。
发布模板可扩展性
使用发布模板，可以在定义发布过程的开始时创建基线。 以前，可以将新的发布模板上传到帐户，但现在作者可以在自己的扩展中包含发布模板。 请参阅 GitHub 存储库上的示例。
有条件地发布任务和阶段
与有条件地生成任务类似，现在如果满足条件，则可以运行任务或阶段。 这有助于建模回退方案。
如果内置条件不能满足需求，或在任务或阶段运行时需要更精细地控制，可以指定自定义条件。 将条件表示为一组嵌套函数。 代理从最内层的函数开始向外进行计算。 最终结果是一个布尔值，用于确定是否要运行任务。
服务终结点的请求历史记录
服务终结点允许连接到外部和远程服务，从而为生成或部署执行任务。 终结点在项目范围内进行配置，并在多个生成和发布定义中进行共享。 服务终结点所有者现可使用终结点获取生成和部署的合并视图，这有助于改进审核和治理。
现在可编辑 Git 和 GitHub 项目类型的默认属性
即使在项目链接后，也可编辑 Git 和 GitHub 项目类型的默认属性。 对于已更改项目的稳定版本的分支，这非常有帮助，未来的持续交付发布应使用该分支获取项目的更新版本。
从发布视图手动批量部署环境
现在可以对发布的多个环境同时手动触发“部署”操作。 这样便可以在配置或部署失败时在一个发布中选择多个环境，并通过一个操作重新部署所有环境。
Jenkins 多分支管道支持和链接在文件夹中组织的作业
使用 Jenkins 项目得到了进一步的完善。
首先，现在可以将 Jenkins 多分支管道项目用于发布定义中的项目源。
其次，以前只能从 Jenkins 服务器的根文件夹将 Jenkins 项目链接为项目，现在可以在 Jenkins 项目组织为文件夹级别时使用该项目。 可以在源列表（从其中选择要作为项目源使用的项目）中看到 Jenkins 项目列表以及文件夹路径。
Docker 中心或 Azure 容器注册表作为项目源
此功能使发布能够使用存储在 Docker 中心注册表或 Azure 容器注册表 (ACR) 中的映像。 这是支持以下方案迈出的第一步：通过使用 ACR 的异地复制功能按区域推出新更改，或者从仅具有生产环境映像的容器注册表部署到环境（如生产）。
现在可以将 Docker 中心或 ACR 配置为发布定义的“+ 添加”项目体验中的第一类项目。 现在，必须手动或由其他项目触发发布，但我们希望立即将基于新映像推送的触发器添加到注册表。
默认项目版本
现在将版本控制项目链接到发布定义时，有多种默认版本可供选择。 可以配置特定命令/变更集或仅配置从默认分支中挑选出的最新版本。 通常情况下配置为选取最新版本，但在需要为将来所有的持续部署指定黄金项目版本的某些环境中，这项功能特别有用。
发布触发器分支增强功能
现在可以根据生成定义指定的默认分支配置发布触发器筛选器。 如果默认生成分支更改了每个冲刺 (sprint) 并且需要在所有发布定义更新发布触发器筛选器，这一点尤为有用。 现在，只需要更改生成定义中的默认分支，所有发布定义便会自动使用此分支。 例如，如果团队正在为每个冲刺 (sprint) 发布有效负载创建发布分支，则你需要在构建定义中更新此分支，使其指向新的冲刺 (sprint) 发布分支，而随后发布会自动选择此分支。
包管理项目的发布触发器
现在可以在发布定义的包管理项目上设置触发器，以便发布包的新版本时，自动创建新发布。 请参阅发布管理中的触发器文档获取详细信息。
将变量组限定为特定环境范围
以前，将变量组添加到发布定义时，发布中的所有环境都可使用该变量组所包含的变量。 现在，可灵活地将变量组的范围限定到特定的环境。 这样它们便可用于某个环境，而非同一版本的其他环境。 如果具有环境之间存在差异的外部服务，例如 SMTP 电子邮件服务，这将非常有用。
从 Azure 容器注册表和 Docker 中心自动发布
当部署容器化的应用时，首先将容器映像推送到容器注册表。 在完成推送后，可以将容器映像部署到用于容器的 Web 应用或 Kubernetes 群集。 现在，可以通过将存储在“Docker 中心”或“Azure 容器注册表”中的映像添加为项目源，自动创建发布并进行更新。
指定 Jenkins 项目的默认版本
当自动触发具有多个项目的发布时，将选取保存在发布定义中的默认版本用于所有项目。 之前，Jenkins 项目没有默认版本设置，因此无法在发布上将 Jenkins 用于辅助项目设置持续部署触发器。
现在，可使用熟悉的选项指定 Jenkins 项目的默认版本：
- 最新
- 在创建发布时指定
- 特定版本
通过扩展提供发布入口
发布入口允许将信息驱动的审批添加到发布管道。 在部署之前或之后重复收集一组运行状况信号，确定发布是否应升级到下一阶段。 提供一组内置入口，并且“调用 Azure 函数”到目前为止已推荐为与其他服务集成的方式。 我们现在简化了与其他服务集成的路由，并通过市场扩展添加了入口。 现在可以提供自定义入口任务，并为发布定义作者提供改进的配置入口体验。
详细了解创建入口任务。
使用部署组对虚拟机进行大规模部署
部署组现已正式发布，可提供可靠、现成可用的多计算机部署。 使用部署组，可以安排跨多台服务器进行部署，并执行滚动更新，同时确保整个应用程序的高可用性。 也可以在本地对服务器进行部署或在 Azure 或任何云中对虚拟机进行部署，并对部署到服务器级别的项目版本进行端到端跟踪。
基于代理的部署功能依赖已使用的相同的生成和部署代理。 在部署组阶段，可以在目标计算机上使用完整的任务目录。 从扩展性角度来看，也可以为部署组使用 REST API 和为编程访问使用目标。
程序包
利用上游源无缝使用公共包
现在可使用 nuget.org 和 npmjs.com 上游源。 其优势包括管理（取消列表、启用、取消发布和删除等）保存在上游源的包以及保证使用的每个上游包的保存功能。
TFS 源中的保留策略
到目前为止，TFS 包源还未提供任何方式来自动清理旧的、未使用的包版本。 对于频繁发布包的作者来说，这可能会导致 NuGet 包管理器和其他客户端中的源查询速度较慢，除非手动删除某些版本。
我们现已在 TFS 源上启用了保留策略。 一旦满足保留阈值，保留策略将自动删除最旧版本的包。 升级到视图的包将无限期地保留下来，从而能够保护在生产中使用的版本或在组织中广泛使用的版本。
要启用保留策略，请编辑源并在“保留策略”部分中的“每个包的最大版本数”中输入一个值。
在包管理中进行筛选
“包”页面已更新为使用我们的标准页面布局、命令栏控件和和新的标准筛选器栏。
使用徽章共享包
在开源社区中，常会使用徽章链接到存储库 README 中的包最新版本。 现在可以为源中的包创建徽章。 只需选中源设置中的“启用包徽章”选项，选择包然后单击“创建徽章”即可。 可以直接复制徽章 URL 或复制预生成的 Markdown，将徽章链接转到包的详细信息页面。
之前的包版本现在是完整页面列表
我们收到了很多关于更新的包管理体验的反馈，我们将之前包版本的列表移动到了包详细信息页面上的痕迹选取器中。 我们添加了新的“版本”透视，可以提供更多关于以前版本的信息，并且可以更轻松地复制版本号或获取旧版本的链接。
查看包列表中的包版本质量
在包列表中，现在可以看到每个包版本的视图，以便快速确定其质量。 有关详细信息，请参阅发布视图文档。 以获取详细信息。
支持 Gulp、Yarn 以及更多身份验证源
现在，npm 任务可以与通过身份验证的 npm 源（在“包管理”或类似于“npm Enterprise”和“Artifactory”等外部注册表中）无缝协作，但直到现在，使用像“Gulp”这样的任务运行程序或像“Yarn”这样的备用 npm 客户端仍是一项挑战，除非该任务也支持通过身份验证源。 我们添加了新的“npm 身份验证”生成任务，该任务会向 .npmrc 添加凭据，以便后续任务可以成功使用已验证的源。
包源默认权限现在包含项目管理员
过去，创建源会将创建用户设置为唯一的源所有者，如果该用户调换团队或离开组织，将造成大型组织面临管理挑战。 为消除此单一故障点，现在创建源将使用用户当前的项目上下文来获取“项目管理员”组，并使其成为源的所有者。 与任何权限一样，可以使用源设置对话框删除此组并进一步自定义源权限。
回收和还原包
删除未使用的包有助于保持包列表的简洁性，但难免会误删除。 现在可以从“回收站”恢复已删除的包。 删除的包会在回收站中保留 30 天，如果需要，可以有充足的时间进行还原。
从任何位置链接到包
尽管可以将 URL 与过去在“包”中心找到的包共享，但通常难以使用，因为 URL 中需要包含项目，这对于使用链接可能并不适用。 通过此更新，现在可以使用 URL 自动选择接收方访问的项目来共享包。
URL 格式为：`https://<TFSserverURL>/_packaging?feed=<feed>&package=<package>&version=<version>&protocolType=<NuGet|Npm|Maven>&_a=package`。
除了 <TFSserverURL>，所有参数都是可选的，但如果是自己提供包，则必须提供协议类型。测试
Visual Studio 测试任务不需要完整的 Visual Studio
生成/发布中的“Visual Studio 测试”任务需要代理上的 Visual Studio 运行测试。 可以使用新的“Visual Studio 测试平台安装程序”任务，而不是安装 Visual Studio，在生产环境中运行测试或仅向多个代理分发测试。 此任务需要 nuget.org 的测试平台并将其添加到工具缓存。 此安装程序任务满足“vstest”要求，并且定义中的后续“Visual Studio 测试”任务无需在代理上安装完整的 Visual Studio 也可运行。
从任务目录中，添加定义中的安装程序任务。
配置后续的“Visual Studio 测试”任务以使用通过安装程序获取的位。
注意
限制：NuGet 上的测试平台包当前不支持运行编码的 UI 测试。 在积压工作 (backlog) 上支持编码的 UI 测试。 NuGet 上的测试平台包是跨平台，但 VSTest 任务当前不支持运行 .NET core 测试。 若要运行 .NET core 测试，请使用“dot net”任务。
现已弃用“运行功能测试”和“部署测试代理”任务
去年，我们开始了统一生成、发布和测试的代理之旅。 这旨在解决与使用基于 WinRM 的“部署测试代理”和“运行功能测试”任务相关的各种痛点。 还可用于根据所有测试需求使用“Visual Studio 测试”(VSTest) 任务，包括：
- 单元测试
- 功能（UI/非 UI）测试
- 基于 MSTest 的测试
- 基于第三方框架的测试
- 基于程序集的测试规范或使用测试计划/测试套件运行的测试
- 单个代理测试执行以及多代理的分布式测试
统一的代理方法还允许管理员以统一的方式管理所有用于 CI/CD 的计算机。
我们已发送了几个关键部分以启用此功能，包括：
- 代理可配置为用于 UI 测试
- Visual Studio 测试平台安装程序允许 VSTest 任务运行而无需预安装 Visual Studio
- 生成和发布定义都可以使用多个阶段创建，并且可以在每个阶段使用不同的代理队列
- 使用 VSTest 测试可以从测试中心运行自动测试事例
现在已完成上述所有内容，因此我们准备弃用这两个任务。 虽然使用已弃用任务的现有定义仍将继续有效，但我们鼓励转为使用 VSTest，因为随着时间的推移，VSTest 的优势将逐渐显现出来。
筛选大型的测试结果
日积月累下，测试资产将逐渐增多，而大型应用程序的测试量可以轻松增长到数以千计。 团队正在寻找更好的方法来浏览大量测试结果，在确定测试失败、相关根本原因或所有权问题的同时提高效率。 为了实现这一点，我们在“测试名称”、“容器”(DLL) 和“所有者”（容器所有者）的生成和发布的“测试选项卡”下添加了三个新筛选器。
此外，现有“结果”筛选器现在提供针对多个结果进行筛选的功能。 各种筛选器条件在本质上是累积的。 对于用户而言，想要就刚提交的更改查看测试结果时，可筛选“容器”（DLL 名称）、“所有者”（DLL 所有者）、“测试名称”或全部，以获取相关结果。
确定异常测试
有时测试会发生异常 - 这些测试在某次测试时显示失败，而在另一次测试时又显示通过，但这期间未发生任何更改。 异常测试往往让人感到沮丧，并且让测试效果的可信度也大打折扣 - 忽略了错误也未发现 bug。 在此更新中，我们已经部署了第一个解决方案，处理异常测试问题。 现在可以配置“Visual Studio 测试”任务来重新运行失败的测试。 此测试结果会指出最初运行失败但在重新运行时通过的那些测试。 支持数据驱动的重新运行并在稍后按顺序进行测试。
可以将“Visual Studio 测试”任务配置为控制尝试重新运行失败测试的最大数和失败的阈值百分比（例如，仅在所有失败测试小于 20% 的情况下重新运行测试），避免在大范围失败的事件中重新运行测试。
在“生成和发布”下的“测试”选项卡中，可以筛选结果为“重新运行时通过”的测试结果，确定在运行期间有不可靠行为的测试。 当前，这将显示出重新运行时通过的每个测试的最近一次尝试。 “摘要”视图也进行了修改：在“总测试次数”下显示“重新运行时通过 (n/m)”，其中 n 表示重新运行时通过的测试计数，而 m 表示通过的测试总数。 所有尝试的结构层次视图将在接下来的几次冲刺 (sprint) 中发布。
预览 Visual Studio 测试任务生成的不同日志类型的改进和支持
我们进一步完善了 VSTest 任务发布针对与失败测试的标准输出和常规错误相对应的各种日志语句生成的日志体验。 我们还改进了预览体验，支持查看文本和日志文件格式，并能够在日志文件中进行搜索。
Wiki
Wiki 搜索
可以在代码和工作项的右侧按标题和内容搜索收藏的 Wiki 页面。 在 Microsoft DevOps 博客中可以详细了解 Wiki 搜索。
打印 Wiki 页面
Wiki 适用于各式内容。 有时 Wiki 会非常有用，你可以从 Wiki 打印一些文章，在业余时间阅读，可以使用纸笔添加注释，甚至还可以将离线 PDF 副本从 VSTS 项目中复制出来，进行共享。 现在，只需单击页面的上下文菜单，并选择“打印页面”即可。
注意
此功能当前不支持在 Firefox 上使用。
使用键盘快捷方式可以轻松地参与到 Wiki 页面
现在可以使用快捷方式执行 Wiki 中常用的编辑和视图操作，这样甚至比仅使用键盘速度更快。
查看页面时，可以添加、编辑或创建子页，例如：
编辑页面时，可以快速保存、保存和关闭或仅关闭。
这些是除了标准快捷方式以外的快捷方式，例如 Ctrl+B 表示粗体，Ctrl+I 表示斜体，Ctrl+K 表示插入超链接等。请参阅键盘快捷方式的完整列表，获取详细信息。
代码存储库 markdown 中的丰富 Markdown 渲染
现在可以在代码存储库中创建丰富的 README.MD 文件。 代码存储库中 MD 文件的 markdown 渲染现在支持 HTML 标记、块引号、表情符号、图像大小调整和数学公式。 Wiki 中的 markdown 渲染和代码中的 MD 文件有奇偶校验。
Wiki 支持数学公式
如果你的应用程序需要处理数学公式和方程式，则现在可以通过 LaTeX 公式在 Wiki 中进行处理。
引用 Wiki 中的工作项
现在，可以通过按“#”键获取最近访问的工作项列表并选择感兴趣的工作项，以便在 Wiki 页面中引用这些工作项。 这在编写发行说明、长篇故事、规格或其他需要引入工作项的页面时尤为有用。
链接工作项和 Wiki 页面
现在可以将工作项链接到 Wiki，反之亦然。 可将工作项链接到 Wiki 来创建长篇故事、发行说明和计划内容，这样有助于跟踪与 Wiki 页面相关的工作项并验证长篇故事的完成情况。
链接的工作项稍后将显示在 Wiki 页面上。
通过新的“Wiki 页面”链接类型，将链接从工作项添加到 Wiki 页面。
按 Ctrl+S 保存 Wiki 页面
我们了解到你希望以一种更快更简单的方式保存 Wiki 页面。 现在只需使用 Ctrl+S 键盘快捷方式即可使用默认修改信息保存页面并继续编辑。 如果想要添加自定义修改信息，只需单击保存按钮旁边的 V 形按钮。
将丰富的 Wiki 内容粘贴为 HTML 格式
现在可以在“Wiki”的 markdown 编辑器中从任何基于浏览器的应用程序（例如 Confluence、OneNote、SharePoint 和 MediaWiki）粘贴丰富的文本。 这对于创建丰富内容（例如复杂表）并希望在“Wiki”中显示的用户来说，非常有帮助。 只需复制内容即可将其粘贴为 HTML 格式。
使用键盘移动 Wiki 中的页面
在早期的“Wiki”中，用户无法使用键盘重新排序页面或重新设置父级页面，这势必会影响到偏好使用键盘操作的用户。 现在可以使用 Ctrl + Up 或 Ctrl + Down 命令对页面进行重新排序。 还可通过单击页面上下级菜单中的“移动页面”并选择要移动的新父级页面，来重新设置父级页面。
突出显示筛选文本
在“Wiki”中筛选导航窗格可显示整个页面的层次结构。 例如，如果筛选标题为“foobar”的页面，则筛选的导航窗格也会显示所有父级页面。 这往往让人感到疑惑，为什么标题不是“foobar”的页面也会出现在筛选后的结果集中呢。 现在，筛选 Wiki 中的内容会突出显示正在搜索的文本，清楚地显示已筛选和未筛选的标题。
你还将看到所有代码导航窗格中的相似行为。 例如，拉取请求、提交、变更集和搁置集中的文件导航窗格。
在编辑 Wiki 页时预览内容
数据显示用户在编辑内容时总是多次预览 Wiki 页面。 对于每个页面编辑，用户平均单击 1~2 次“预览”。 这会导致编辑速度变慢且达不到最佳状态，并且对于那些新接触 markdown 的人来说可能特别耗时。 现在可以在编辑时查看页面预览。
常规
个人资料卡
TFS 中有多个区域显示与特定个人相关的信息，例如但不限于：个人创建的拉取请求以及分配给个人的工作项等。 但是，关于个人本身的信息有限，无法获得完整的上下文。 新的个人资料卡会替换 TFS 中现有的个人资料卡。 更新后的个人资料卡允许与 TFS 帐户内的用户进行交互并了解更多信息。 通过与默认电子邮件和 IM 客户端的集成，Active Directory (AD) 用户可以发送电子邮件并直接从个人资料卡开始聊天。 AD 用户还可以在个人资料卡中查看组织层次结构。 可在项目主页 - 团队成员部分、版本控制、工作项和 Wiki 部分中，通过单击联系人卡图标，个人资料图片或评论中的用户名激活个人资料卡。
圆形头像
圆形虚拟形象在此处！ 服务中的所有个人资料图片现在都显示为圆形头像，而不是方形。 例如，这是此次更改的实际拉取请求（注意这是圆形而不是方形头像）。
项目标记
现在可以用重要的关键字（标记）来修饰项目。 （管理员）可以直接从项目主页轻松添加和删除标记，以便用户能够更快地详细了解项目的目的和范围。 我们已经就如何利用项目标记制定了诸多计划，敬请期待更多新闻。
重新排序收藏夹组
现在可以使用每个组标头中的向上和向下箭头对帐户“我的收藏夹”页面上的组进行重新排序。
反馈和建议
我们期待你的宝贵意见和建议！ 可以通过开发者社区门户报告并跟踪问题，并能在 Stack Overflow 上了解相关建议。