Team Foundation Server 2017 Update 2 发行说明

Last Update: 2017/9/25

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

Download the latest version of Team Foundation Server

有关其他格式或语言,请参阅下载站点

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


反馈

我们期待你的宝贵意见和建议! 你可以报告问题并通过开发人员社区门户进行跟踪。 通过 Visual Studio Team Services 产品更新站点向我们发送建议。


发布日期:2017 年 7 月 24 日

TFS 2017 Update 2 的更新摘要

我们在 Team Foundation Server 2017 Update 2 中增加了许多新值。 其中一些要点包括:

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


此版本中的新增功能

工作项跟踪改进

工作项类型图标

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

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

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

Wit icons in query(图 1)查询中的彩色图标

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

Board with icon type(图 2) 带有图标类型的看板

交付计划

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

查看交付计划的商城页,以了解详细信息并安装扩展。

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

从工作项自动链接到生成

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

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

WIT build linking(图 3) WIT 生成链接

弃用旧的工作项窗体

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

工作项搜索

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

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

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

Workitem search(图 4)工作项搜索

版本控制改进

新的分支策略配置体验

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

Configure branch policies(图 5)配置分支策略

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

Policies page(图 6)策略页

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

Manual build(图 7)手动生成

配置手动触发策略后,可以通过选择“策略”部分中的“队列生成”选项运行它来获取拉取请求(图 8)。

Manual build queue(图 8)手动生成队列

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

Required reviewer dialog(图 9)必需的审阅者对话框

Required reviewer note(图 10)必需的审阅者注解

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

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

文件中心改进

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

对于查看,我们添加了透视,以便用户可以查看当前文件夹中的“README”(图 11),预览 Markdown 文件,将文件与此前的版本进行比较(图 12),并查看指责。

Files viewing(图 11)文件查看

Files compare(图 12)文件比较

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

Files editing(图 13)文件编辑

可视化 Git 存储库

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

Git graph(图 14)Git 图

Git 图的关键元素包括(图 15):

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

Git graph elements (图 15) Git 图元素

在提交上查看 Git 标记

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

Show tags(图 16)显示标记

将标记添加到提交

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

Create tag details(图 17)创建标记详细信息

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

Create tag history(图 18)创建标记历史记录

Tag branch(图 19)标记分支

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

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

Changeset page(图 20)变更集页

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

Changeset discussion(图 21)变更集讨论

改进的提交筛选

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

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

Improved commit filtering(图 22)改进的提交筛选

将存储库从 TFVC 导入到 Git

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

Repository selector drop-down(图 23)存储库选择器下拉列表

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

Import repo complete(图 24)导入存储库完成

Git LFS 文件锁定

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

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

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

新的树视图控件

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

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

New tree view(图 25)新树视图

拉取请求的改进

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

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

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

 Auto-complete feature(图 26)自动完成功能

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

CTA approve(图 27)CTA 批准

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

可操作注释

在具有多个注释的 PR 中,很难跟踪所有对话。 为了帮助用户更好地管理注释,我们简化了解决项目的过程,这些项目已经通过若干增强功能进行处理:

  • 在每个 PR 的标头处,现在将看到已解决的注释计数(图 28)。

PR header(图 28)PR 标头

  • 处理注释后,可以通过单击进行解决(图 29)。

Resolve button(图 29)解决按钮

  • 在解决过程中,如果要添加注释,则可以一次性进行回复并解决(图 30)。

Reply and resolve(图 30)回复并解决

  • 解决注释时,将看到计数上升直到处理完所有注释(图 31)。

Comment count address rate(图 31)注释计数处理率

  • 已改进概述中的筛选器,以通过各种注释状态进行筛选,并显示每个筛选器选项的注释计数。(图 32)。

Filter improvements(图 32)筛选器改进

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

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

Updates views(图 33)更新视图

按人员筛选拉取请求

现在更容易查找拉取请求! 我们添加了新的筛选选项,以便可以找到由特定作者创建或分配给特定的审阅者的 PR(图 34)。 只需从作者或审阅者筛选器中选择一个用户,列表将进行更新以显示仅与该筛选器匹配的 PR。

Filtering by people(图 34)按人员筛选

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

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

Bypass dialog(图 35)绕过对话框

输入原因并完成拉取请求后,该消息将在“概述”中显示(图 36)。

Bypass message(图 36)绕过信息

与团队共享拉取请求

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

Share PR with teams(图 37)与团队共享 PR

团队的拉取请求改进

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

PR improvements for teams(图 38)团队的 PR 改进

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

拉取请求注释的默认通知

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

Default PR notifications(图 39)默认 PR 通知

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

包管理改进

更新的包管理体验

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

Package Management(图 40)包管理

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

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

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

Package Management npm README (图 41)包管理 npm README

NuGet 还原和 NuGet 命令生成任务

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

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

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

NuGet command(图 42)NuGet 命令

生成和发布改进

新的生成定义编辑器

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

搜索模板

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

Build template search(图 43)生成模板搜索

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

搜索想要使用的任务,然后在找到它之后,可以在左侧当前选择的任务之后添加它,或者将它拖放到想要的位置(图 44)。

Build task search(图 44)生成任务搜索

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

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

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

Process parameters(图 45)过程参数

如果从某些内置模板创建新的生成(例如 Visual Studio 和 Maven),则会看到说明工作原理的示例。

新编辑器还包含几个其他增强功能,例如可以使用户更快地访问源设置。

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

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

条件生成任务

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

Conditional build tasks(图 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 App Service 部署任务支持要部署的 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)。 例如,池将删除由已删除的生成和发布定义留下的工作区。

Agent maintenance(图 47)代理维护

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

生成代理升级状态

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

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

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

iOS DevOps 增强功能

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

Apple App Store connection(图 48)Apple App Store 连接

安装 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 生成摘要中。

Improved Jenkins integration(图 49)改进的 Jenkins 集成

Azure 虚拟机规模集部署

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

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

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

Azure RG parameters(图 50)Azure RG 参数

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

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

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

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

Default artifact version(图 51)默认项目版本

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

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

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

发布级别批准

现在可以选择自动批准在成功部署到另一个环境后自动触发的部署(图 52)。 如果选择不批准每一个部署,那么可以一次完成批准一个部署链(拥有相同的审批者)。

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

Release level approvals(图 52)发布级别批准

部署到 Azure 政府云

在政府云中具有 Azure 订阅的客户现在可以配置 Azure Resource Manager 服务终结点来针对各国云端。

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

Government cloud(图 53)政府云

设置最大并行部署数

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

Parallel deployments(图 54)并行部署

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

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

Release Management 并行执行

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

Parallel execution support(图 55)并行执行支持

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

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

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

测试改进

使用代理阶段运行测试

使用 Visual Studio 测试任务,现在可以使用代理阶段运行自动测试(图 56)。

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

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

Run tests using Agent Phases (图 56)使用代理阶段运行测试

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

自动测试的按需触发

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

On-demand automated tests trigger(图 57)按需自动测试触发器

仓库改进

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

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

不区分大小写的架构协调

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

管理改进

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

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

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

现成可用的通知

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

  • 在向某个用户分配了工作项时。
  • 在将某个用户或团队添加为拉取请求的审阅者时。
  • 在某个用户或团队成为更新的拉取请求的审阅者时。
  • 在另一个用户响应拉取请求注释时。
  • 在用户请求的生成操作完成时。
  • 在安装或请求扩展时(仅适用于管理员)。

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

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

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

扩展管理权限

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

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

Extension management permissions(图 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,然后安装此最终版本。


The Developer Community Portal请参阅针对 Team Foundation Server 2017 上报的客户报告的问题。


返回页首