Team Foundation Server 2018 RC1 发行说明

Last Update: 2017/9/25

本文将介绍最新发布的 Team Foundation Server 2018 RC1。 单击此按钮下载。

下载最新版 Team Foundation Server

若要详细了解 Team Foundation Server 2018,请参阅 Team Foundation Server 要求和兼容性页。


反馈

我们期待你的宝贵意见和建议! 可以通过开发者社区门户报告并跟踪问题,并能在 Stack Overflow 上了解相关建议。 和以往一样,若要向我们提供反馈意见,告诉我们要优先开展哪些工作,请前往 UserVoice,添加反馈意见或为现有反馈意见投上一票。


发布日期:2017 年 8 月 30 日

摘要:TFS 2018 RC1 中的 Team Foundation Server 更新

Team Foundation Server 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。

移动工作项表单

我们提供完整的端到端体验,不仅优化了工作项外观(图 1),还方便用户通过手机与所分配的项目、关注的项目或最近访问或编辑过的项目轻松进行交互。

移动工作项查询

(图 1)移动工作项查询

除了改进了外观之外,此体验还优化了所有字段类型的控件(图 2)。

移动工作项表单

(图 2)移动工作项表单

通过全新的移动导航(图 3),用户可以到达其他任何支持移动导航的 TFS 部分,并在需要与其他中心进行交互时返回到完整桌面版站点。

移动导航

(图 3)移动导航

筛选积压工作 (backlog)、看板、冲刺 (sprint) 和查询

我们的所有工作项跟踪网格体验(查询、积压工作 (backlog)、看板、冲刺 (sprint) 积压工作 (backlog) 和测试用例管理)现在都利用常见的一致性筛选组件(图 4)。 除了可以跨显示的列应用关键字筛选器和选择标记之外,还可以按工作项类型、状态和分配目标进行筛选,从而快速获取要找的工作项。

筛选查询

(图 4)筛选查询

在看板卡上展开显示空字段

目前,可以根据需要向看板卡添加其他字段,并在看板设置中隐藏空字段(图 5),让看板保持整齐有序。 此功能的缺点是,一旦隐藏空字段,只能通过打开工作项表单来更新此字段。 使用看板卡上新增的展开选项,现在不仅可以隐藏看板中的空字段,还可以一键式更新看板卡上的特定字段。 只需将鼠标悬停在看板卡上,并使用看板卡底部的倒 V 形图标,即可更新隐藏的字段。

隐藏的字段

(图 5)看板卡上的隐藏字段

单击看板卡底部的倒 V 形图标,即可更新隐藏的字段(图 6)。

更新隐藏的字段

(图 6)更新看板卡上的隐藏字段

阻止保存工作项的扩展

工作项表单自定义控件、组和页现在可以阻止保存工作项,以便验证数据,并确保用户在保存工作项表单之前填写所需的全部信息。

版本控制

分叉

TFS 2018 现已开始支持 Git 分叉(图 7)。 分叉是存储库的服务器端副本。 使用分叉,可以让大量人员参与存储库,而无需向他们授予直接提交访问权限。 相反,他们将工作提交到自己的存储库分叉(图 7)。 这样一来,可以先在拉取请求中评审他们的更改,然后再接受将这些更改提交到中央存储库。

Git 分叉

(图 7)Git 分叉

设置为对 TFVC 存储库禁用 Web 编辑

使用 TFVC 的团队经常在 Visual Studio 中使用签入策略,以确保代码质量。 不过,由于签入策略是在客户端上强制实施,因此签入策略不会对接受过 Web 编辑的代码造成任何影响。

多个用户曾要求过,能否禁用 Web 编辑,以免受忽略签入策略的更改影响。 我们现已支持按项目/存储库对 TFVC 禁用 Web 编辑(添加、删除、重命名和编辑)。

若要从“文件”页禁用 Web 编辑,请依次转到“设置”和“版本控制”(图 8)。 单击树中的 TFVC 存储库,转到“选项”透视区域,并取消选中“为此 TFVC 存储库启用 Web 编辑”。 Web 编辑默认处于启用状态。 注意:从“项目概述”页编辑 README 不受影响。

禁用 Web 编辑

(图 8)禁用 Web 编辑

如果在禁用 Web 编辑的项目中尝试执行 Web 编辑,将会看到提示不允许进行 Web 编辑的通知(图 9)。

提示不允许进行 Web 编辑的对话框

(图 9)提示不允许进行 Web 编辑的对话框

这是根据相关建议进行开发。

识别过时分支

通过删除不再需要的分支让存储库保持整齐有序,这样团队就能找到所关心的分支,并在合适的级别收藏分支。 不过,如果存储库中有大量分支,便很难确定哪些是可以删除的非活动分支。 我们现在可以更容易地识别“过时”分支(指向超过 3 个月前生成的提交的分支)。 若要查看过时分支,请转到“分支”页上的“过时”透视区域(图 10)。

过时分支

(图 10)过时分支

搜索已删除的分支并重新创建

如果意外从服务器中删除分支,便很难弄清楚此分支发生了什么。 现在,可以搜索已删除的分支,并查看此分支的删除者和删除时间,还能根据需要重新创建此分支。

若要搜索已删除的分支,请在分支搜索框中输入完整的分支名称。 这将返回与搜索文本匹配的全部现有分支。 还会看到一个选项,用于在已删除的分支列表中搜索完全匹配项。 单击链接即可搜索已删除的分支(图 11)。

搜索已删除的分支

(图 11)搜索已删除的分支

如果找到了匹配项,将会看到此分支的删除者和删除时间。 还可以还原此分支(图 12)。

还原已删除的分支

(图 12)还原已删除的分支

如果还原此分支,将在它最后指向的提交中重新创建它。 不过,将不会还原策略和权限。

在开头有前缀的分支中搜索提交

如果分支结构采用分层格式,其中所有分支都以文本为前缀,可以使用此功能,在开头有此前缀文本的全部分支中查找提交。 例如,若要确定提交是否已被引入所有以“dev”为前缀的分支,只需在搜索框中键入“dev”,再选择“在以‘dev’开头的分支中搜索”即可(图 13)。

搜索提交

(图 13)搜索提交

提交详细信息页上的拉取请求标注更丰富

提交详细信息页上的拉取请求标注显示更多相关信息,有助于更好进行诊断(图 14)。 现在,我们还在标注中显示将提交引入任何分支的首个拉取请求,以及与默认分支相关的拉取请求。

拉取请求标注

(图 14)拉取请求标注

在“代码”中筛选树状视图

现在,无需滚动浏览提交可能已修改的所有文件,即可找到自己的文件。 提交详细信息页、拉取请求页、搁置集详细信息页和变更集详细信息页上的树状视图现在支持筛选文件和文件夹。 此为智能筛选器,可以在用户按文件夹名称筛选时显示文件夹的子文件,并能在用户按文件名筛选时显示文件的折叠式树状视图,以呈现文件层次结构。

在提交树上找到文件或文件夹筛选器(图 15 和图 16):

查找文件或文件夹

(图 15)查找文件或文件夹

筛选视图

(图 16)提交树上的筛选视图

“分支更新”页现为“推送”

“分支更新”页具有巨大价值。 不过,它已隐藏为“历史记录”中心下的透视区域。 “分支更新”页现为“代码”下的“推送”中心(图 17),位于“提交”、“分支”、“标记”和“拉取请求”旁边。 “推送”页的新 URL 是:<tfsserverurl>/<projectname>/_git/<reponame>/pushes。 旧 URL 仍能正常发挥作用。

“推送”页

(图 17)“推送”页

同时,“历史记录”中心现重命名为“提交”(图 18),因为此中心仅显示提交。 用户向我们反馈过,很难排查与提交相关的问题,因为提交列表视图仅在有鼠标悬停时才显示详细时间。 现在,跨实例的提交列表视图以 dd/mm/yy hh:mm 格式显示日期和时间。 “提交”页的新 URL 是:<tfsserverurl>/<projectname>/_git/<reponame>/commits。 旧 URL 仍能正常发挥作用。

“提交”页

(图 18)“提交”页

从“文件”切换到“提交”时保留文件名

用户向我们反馈过,如果在目录中筛选出“代码”中心的“文件”透视区域中的特定文件,稍后又翻转到“历史记录”透视区域,当提交更改了超过 1,000 个文件时,文件名不会得到保留。 这样一来,用户不得不加载更多文件并筛选内容才能找到文件,工作效率受到影响。 开发者通常在同一目录中进行工作,并且希望在跟踪更改时一直留在他们工作的目录中。 现在,可以在“代码”中心透视区域之间切换时保留文件名,无论提交更改了多少个文件。 也就是说,无需单击“加载更多”,即可找到所需的文件。

查看 Git 标记

可以在“标记”页上查看存储库中的所有标记(图 19)。 如果将所有标记作为发布进行管理,用户可以访问“标记”页,概览所有产品发布。

查看 Git 标记

(图 19)查看 Git 标记

在此页上,可以轻松区分轻量级标记和已加批注的标记,因为已加批注的标记在相关提交旁边显示标记器和创建日期,而轻量级标记仅显示提交信息。

删除 Git 标记

有时,可能需要从远程存储库中删除标记。 原因可能是,标记名称中有拼写错误,或标记了错误的提交。 可以在“标记”页上单击标记的上下文菜单,并选择“删除标记”,即可轻松地从 Web UI 中删除标记(图 20)。

注意:应谨慎地删除远程存储库中的标记。

删除 Git 标记

(图 20)删除 Git 标记

筛选 Git 标记

对于旧存储库,标记数量可能会随着时间的推移而大幅增多;存储库中创建的标记可能还会采用层次结构,令标记查找起来更加困难。

如果无法在“标记”页上找到要找的标记,可以使用“标记”页顶部的筛选器,直接搜索标记名称(图 21)。

筛选 Git 标记

(图 21)筛选 Git 标记

Git 标记安全性

现在,可以向存储库用户授予精细权限,方便其管理标记。 可以向用户授予权限,允许他们从此界面删除或管理标记(图 22)。

Git 标记安全性

(图 22)Git 标记安全性

有关 Git 标记的详细信息,请阅读 Microsoft DevOps 博客

完成拉取请求时自动完成工作项

若要将工作项与 PR 相关联,可以让更新所有内容变得更简单。 现在,完成 PR 时,可以根据需要在 PR 合并成功后自动完成关联的工作项(图 23)。 若要使用策略并将 PR 设置为自动完成,也可以这么做。 完成 PR 后,不用再重新访问工作项来更新状态了。 系统会自动完成。

完成关联的工作项

(图 23)完成关联的工作项

在推送/新迭代发生时重置投票

如果团队决定在 PR 中采用更严格的审批工作流,现在可以在新更改进行推送时重置投票(图 24)。 新设置为“至少需要的审阅者人数”策略下的一个选项。

重置投票设置

(图 24)重置投票设置

设置此选项后,每当 PR 的源分支更新时,所有审阅者的全部投票都会进行重置。 只要投票因此选项而重置,PR 时间线都会记录一个条目(图 25)。

时间线中的投票重置

(图 25)时间线中的投票重置

按文件名筛选拉取请求树

在拉取请求中查找特定文件变得空前简单。 使用“文件”视图中的新筛选器框,用户可以筛选树状视图中的文件列表(图 26)。

在拉取请求中查找文件或文件夹

(图 26)在拉取请求中查找文件或文件夹

筛选器会匹配拉取请求中文件的任意路径部分,因此可以按文件夹名称、部分路径、文件名或扩展进行搜索(图 27)。

查找结果

(图 27)查找结果

更多拉取请求注释筛选选项

在拉取请求概述和“文件”视图中,现在可以使用相同的注释选项(图 28)。 还可以进行筛选,仅查看自己参与的讨论。

PR 注释筛选

(图 28)PR 注释筛选

在拉取请求详细信息中查看已添加注释的代码与原始版本的差异

有时,在 PR 注释引用的代码发生更改后(大多数情况下,是在执行过请求的更改时),就很难理解 PR 注释(图 29)。

查看与原始版本的差异

(图 29)查看与原始版本的差异

如果出现这种情况,现在可以看到一个包含更新编号的徽章,单击便能查看在最初创建注释时的代码(图 30)。

更新徽章

(图 30)更新徽章

可折叠的拉取请求注释

代码评审是拉取请求体验的关键所在,因此我们添加了新功能,以便审阅者可以将重心放在代码上。 代码审阅者可以轻松地隐藏注释,以便能够在首次评审新代码时腾出空间(图 31)。

隐藏注释

(图 31)隐藏注释

隐藏注释(图 32)可以对树状视图隐藏注释,并在文件视图中折叠注释线程:

折叠的注释

(图 32)折叠的注释

折叠注释后,单击边距中的图标即可轻松展开注释,再单击一下又可以再次折叠。 借助工具提示(图 33),可以轻松快速地概览注释,而无需查看整个线程。

折叠的注释工具提示

(图 33)折叠的注释工具提示

拉取请求说明和注释中的任务列表

准备 PR 或进行注释时,有时会有一些要跟踪的事项,但最终会编辑文本或添加多个注释。 使用轻量级任务列表,可以在说明或合并后的一个注释中,作为 PR 创建者或审阅者跟踪待办事项列表的完成进度。 单击 Markdown 工具栏,即可开始使用或将格式应用于选定文本(图 34)。

任务列表工具栏

(图 34)任务列表工具栏

添加任务列表(图 35)后,只需选中框,即可将项标记为完成。 这些项在 Markdown 注释中表示和存储为 [ ][x]。 有关详细信息,请参阅 Markdown 指南

任务列表

(图 35)任务列表

可以为拉取请求中的注释点“赞”

单击一下“赞”按钮,即表示支持 PR 注释(图 36)。 可以将鼠标悬停在此按钮之上,查看已点赞注释的其他所有点赞人员列表。

为拉取请求注释点赞

(图 36)为拉取请求注释点赞

改进了批准并附加建议时的工作流

结合使用“自动完成”选项(图 37)与拉取请求可以有效提升工作效率,但不得缩减与代码审阅者的积极讨论。 为了更好地促进这些讨论,现在会在拉取请求设置为自动完成时,提示“批准并附加建议”投票。 用户可以根据需要取消自动完成,这样他们的反馈意见就可以被聆听;也可以保持自动完成设置不变,但要求在符合所有策略要求的情况下才自动完成拉取请求。

取消自动完成的对话框

(图 37)取消自动完成的对话框

Git 通知支持路径筛选

现在可以选择收到通知的条件,即仅当团队成员在关心的文件夹中创建拉取请求或推送代码时,而不会收到存储库中所有文件夹的通知。 创建自定义 Git 推送或拉取请求的电子邮件通知订阅时,可以使用新选项,按文件夹路径筛选这些通知(图 38)。

按路径筛选通知

(图 38)按路径筛选通知

拉取请求工作流的精美电子邮件模板

拉取请求电子邮件警报已刷新,不仅清晰简洁,还可操作(图 39)。 主题行以 PR 标题和次要信息(如存储库名称)开头,并将 ID 顺延至结尾。 创建者的姓名已添加到主题中,以便可以更轻松地应用规则,并按 PR 创建者进行筛选。

警报电子邮件正文模板刷新为,先总结警报发送原因,后跟关键的元数据(标题、分支名称和说明)以及主要的号召性用语按钮。 再往下,电子邮件包含审阅者、文件和提交等更多详细信息。

改进后的电子邮件模板

(图 39)改进后的电子邮件模板

对于大多数警报,单击号召性用语按钮(图 40)可以在 Web 中查看拉取请求。 不过,如果收到有关特定注释的通知,单击号召性用语按钮会直接链接到相应注释,从而可以轻松地找到代码和先前对话,了解上下文相关信息。

电子邮件号召性用语

(图 40)电子邮件号召性用语

拉取请求状态扩展性

使用分支策略可以有效提升代码质量。 不过,这些策略只适用于 VSTS 本机提供的集成。 使用新的 PR 状态 API 和相应的分支策略,第三方服务可以参与 PR 工作流,就像本机 VSTS 功能一样。

当服务发布到拉取请求状态 API 时,它会立即出现在“PR 详细信息”视图中新增的“状态”部分内(图 41)。 “状态”部分显示说明,并创建指向服务提供 URL 的链接。 “状态”条目还支持可扩展的操作菜单 (...),以便通过 Web 扩展添加新操作。

PR“状态”部分

(图 41)PR“状态”部分

光是“状态”,并不会阻止 PR 的完成,此时策略就派上用场了。 在 PR 状态发布后,便可以配置策略。 使用分支策略时,可以使用新策略“需要外部服务的批准”。 选择“+ 添加服务”,开始执行此过程(图 42)。

添加新策略

(图 42)PR 添加新策略

在对话框中,从列表中选择要发布状态的服务,再选择所需的策略选项(图 43)。

设置状态策略

(图 43)PR 设置状态策略

在策略处于活动状态后,状态便会显示在“策略”部分中相应的“必需”或“可选”下,并会根据需要强制完成 PR。

若要详细了解状态 API 并试用,请参阅文档示例

Wiki

每个项目现在都支持自己的 Wiki(图 44)。 现在,可以方便地编写 Wiki 页,帮助团队成员了解、使用和参与项目。

Wiki 页

(图 44)PR Wiki 页

新 Wiki 的一些主要功能包括:

  • 简化了使用 Markdown 语法进行编辑的体验。
  • 使用新页,可以指定标题,并添加内容。 (图 45)标题 Wiki

    (图 45)PR 标题 Wiki

  • 支持在 Markdown 中使用 HTML 标记(图 46)。

Wiki HTML 标记

(图 46)PR Wiki HTML 标记

  • 方便地重设 Markdown 文件夹中图像的大小(图 47)。

重设图像大小

(图 47)PR 重设图像大小

  • 功能强大的页管理窗格,支持对页进行重新排序、重新设置父级和管理。
  • 对于大型 Wiki,可以按标题筛选页(图 48)。

Wiki 菜单

(图 48)PR Wiki 菜单

详细了解 Wiki 入门

  • 随着使用 Wiki 的次数越多,就越有可能会保存意外更改。 现在,可以还原 Wiki 页修订,具体方法是转到修订详细信息,并单击“还原”按钮(图 49)。

Wiki“还原”按钮

(图 49)PR Wiki“还原”按钮

从断开的链接创建 Wiki 页 - 在 Wiki 创建过程中,我们已发现一种模式,以便用户可以在包含不存在的链接的 Wiki 页上创建目录(图 50)。 然后,用户可以单击这些链接创建实际页。 在早期,我们处理这种情况的方法是,通过发出警告,提示链接断开或页不存在。 现在,我们改为支持创建页,将这种情况作为 Wiki 的主要方案进行处理。

创建 Wiki 页

(图 50)PR 创建 Wiki 页

Marketplace 上的 Wiki 扩展现已弃用。 如果是现有 Wiki 扩展用户,可以使用此迁移工具,将 Wiki 页迁移到新 Wiki。 详细了解如何将现有 Wiki 页迁移到新 Wiki

包管理

包管理体验更新

包 URL 现在支持使用包名称和版本,而不使用 GUID。 这样,可以更轻松地手动创建包 URL(图 50)。 格式为:<tfsserverurl>/<project|team>/_packaging?feed=<feed>&package=<package>&version=<version>&protocolType=<NuGet|Npm|Maven>&_a=package。

包 URL

(图 51)PR 包 URL

根据这条 UserVoice 建议,现在可以对所有源用户隐藏已删除的包版本(图 52)(不用再为包添加删除线!)。

隐藏已删除的包

(图 52)隐藏已删除的包

在包详细信息页上执行的任何操作,现在都可以通过包列表的上下文菜单执行。

包列表新增了“上次推送时间”列(图 53),内含人性化日期,以便用户可以轻松找到最近更新的包。

“上次推送时间”列

(图 53)“上次推送时间”列

Maven 包

我们现已开始支持在 TFS 2018 中托管 Maven 项目(图 54)! 使用 Maven 项目,Java 开发者可以轻松地共享代码和组件。 请查看我们的入门指南,了解如何使用包管理源共享 Maven 项目。

Maven 包

(图 54)Maven 包

新增统一的 NuGet 任务

我们已将“NuGet 还原”、“NuGet 包装程序”和“NuGet 发布服务器”任务合并到统一的 NuGet 生成任务中,以便与生成任务库的其余部分更好地保持一致;新任务默认使用 NuGet 4.0.0。 因此,我们弃用了旧任务,并建议用户在有时间时迁移到新增的 NuGet 任务。 此更改与下面概述的一系列改进保持一致,只有在使用合并的任务时,这些改进才生效。

在改进期间,我们还发布了新任务“NuGet 工具安装程序”,用于控制新增的 NuGet 任务可以在 PATH 上使用的 NuGet 版本。 因此,若要使用最新版 NuGet,只需在生成开始时添加“NuGet 工具安装程序”任务即可(图 55)。

NuGet 任务

(图 55)NuGet 任务

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 源(图 56)。

.Net 任务

(图 56).Net 任务

.Net 任务支持已验证的源(Web 项目)

.Net 任务的下一个主版本 (2.x) 实现了许多反馈请求,并修复了我们一直在跟踪的一组 bug。

  1. 首先,.Net 现在支持已验证的包源(如包管理),因此无需再使用 NuGet 任务,即可从私有包源还原包。
  2. “项目路径”字段的行为已在 2.0 版任务中发生变化。 在旧版任务中,如果找不到与指定模式匹配的项目文件,任务常常会记录警告,然后成功完成。 在这种情况下,有时可能会很难理解,为什么生成已成功,但依赖项并未还原。 现在,如果找不到与指定模式匹配的项目文件,任务将会失败。 这不仅与其他任务的行为保持一致,而且还易于理解和使用。
  3. 在旧版任务的 publish 命令中,任务将所有文件放入以项目文件名命名的文件夹中,从而修改输出路径,即使传递的是明确的输出路径,也不例外。 这样,很难将命令链接在一起。 现在可以控制输出路径文件。

我们还发布了新任务“.Net 工具安装程序”,用于控制新增的 .Net 任务可以在 PATH 上使用的 .Net 版本。 因此,若要使用最新版 .Net,只需在生成开始时添加“.Net 工具安装程序”任务即可。

在帐户/集合之外工作

现在可以更轻松地在 TFS 服务器或 VSTS 帐户之外使用源,无论是其他 VSTS 帐户或 TFS 服务器中的包管理源,还是非包管理源(如 NuGet.org/npmjs.com、Artifactory 或 MyGet)(图 57)。 借助 NuGet 和 npm 的专用服务终结点类型,可以轻松地输入正确的凭据,并能跨包下载和包推送操作无缝使用生成任务。

要使用的源

(图 57)要使用的源

VSTS/TFS 源选取器

我们一直建议签入配置文件(例如,NuGet.Config、.npmrc 等),以便源存储库可以记录包的源位置。 不过,我们也收到一些反馈意见,了解到这样做并不理想的一系列情形。因此,我们新增了“使用此 VSTS/TFS 源中的包”选项,以便用户能够选择源,并自动生成用于相应生成步骤的配置文件(图 58)。

源选取器

(图 58)源选取器

生成和发布

不再支持 XAML 生成

在 TFS 2015 中,我们引入了基于 Web 的跨平台生成系统。 在 TFS 2018 中,这是我们唯一支持的模型。 TFS 2018 不支持 XAML 生成。 建议迁移 XAML 生成。 如果尚未准备迁移并需要继续使用 XAML 生成,则不应升级到 TFS 2018。

升级到 TFS 2018 后:

  • 如果团队项目集合中有任何 XAML 生成数据,将看到警告,提示删除 XAML 生成功能。

  • 在 TFS 2018 中,可以查看已完成的 XAML 生成,但无法将新生成排入队列。

  • TFS 2018 中没有新版 XAML 生成控制器或代理,而且也无法将旧版 XAML 生成控制器或代理配置为与 TFS 2018 配合使用。

有关我们的 XAML 生成弃用计划的说明,请参阅这篇博文

导出和导入生成定义

生成定义在内部实现为 .json 文件,因此可以在文件历史记录中查看更改详细信息。 虽然已可以克隆生成定义并据此生成模板,但许多用户仍希望获取 CI 生成逻辑的副本,并将它重用于其他团队项目。 实际上,这已成为 UserVoice 上的十大请求之一。

我们很高兴地向大家宣布,现在可以这样做了(图 59 和图 60)!

导出生成定义

(图 59)导出生成定义

导入生成定义

(图 60)导入生成定义

扩展中包含生成模板

使用生成模板,可以为用户创建基线,以便开始定义生成过程。 目前,我们提供大量现成的生成模板。虽然可以将新模板上传到帐户中,但扩展创建者以前却永远无法将新模板添加到扩展中。 现在可以在扩展中添加生成模板。 例如:

{  "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

当用户搜索弃用的任务(图 61)时,我们将这些任务推送到最后,并将它们整合到默认折叠的可折叠部分下。 如果定义已经使用弃用的任务,我们会显示弃用的任务徽章,建议用户切换到替换任务。

弃用的任务徽章

(图 61)弃用的任务徽章

可以在任务说明中提及替换任务,从而帮助用户了解替换任务(图 62)。 然后,说明会指导用户通过任务目录和现有生成/发布定义,按正确方式使用替换任务。

弃用的任务说明

(图 62)弃用的任务说明

允许参与的生成部分控制部分公开范围

以前,若要使用包含生成任务和生成摘要部分的扩展,即使未在相应生成中使用生成任务,也会看到生成摘要部分。 现在,可以在扩展代码中添加以下代码行,并将值设置为 true 或 false,从而选择在生成摘要页中隐藏或显示相应部分:

VSS.getConfiguration().setSectionVisibility("$(publisherId).$(extensionId).$(sectionId)", false);

请查看 Microsoft vsts-extension-samples 存储库中的示例。

变量组支持

已经可以在发布定义中使用变量组,现在也可以在生成定义中使用变量组。 详细了解如何创建变量组。 这是根据项目级生成/发布变量生成定义中的变量组的相关建议进行开发和优先处理。

使用 Apple 证书等安全文件

我们添加了常规用途安全文件库(图 63)。

安全文件库

(图 63)安全文件库

使用安全文件库,可以在服务器上存储签名证书、Apple 预配配置文件、Android 密钥存储文件和 SSH 密钥等文件,而无需将它们提交到源存储库。

安全文件的内容已加密,只能在生成或发布过程中通过任务引用它们。 根据安全设置,安全文件可用于团队项目中的多个生成和发布定义。 安全文件遵循库安全模型。

我们还添加了一些 Apple 任务来利用这项新功能:

全新的发布定义编辑器

默认处于启用状态:全新的发布定义编辑器默认对所有用户启用。 用户或 TFS 管理员仍可以根据需要禁用此功能,具体方法是转到配置文件菜单下的“预览功能”选项。 请参阅预览功能,以获取更多详细信息。

我们一直在不断更新生成和发布体验。在我们推出全新的生成定义编辑器后,现在发布定义编辑器旧貌换新颜,更加清晰直观,我们解决了一些让人头痛的棘手问题,并添加了新功能。 新编辑器的最强大功能之一是,能够帮助用户创建心理模型,或直观地呈现部署到环境的进展情况。 除此之外,审批、环境和部署设置现在都可视情况使用,配置起来非常容易(图 65)。

管道的可视化效果

编辑器中的管道(图 64)提供了一个图形视图,用于呈现部署在发布中的进展。 项目会由发布使用,并部署到环境中。 环境的布局和链接反映了为每个环境定义的触发器设置。

管道

(图 64)发布管道

可视情况使用的配置 UI

项目、发布触发器、部署前和部署后审批、环境属性和部署设置现在都可视情况使用,配置起来非常容易(图 65)。

发布配置

(图 65)发布配置

开始使用部署模板

新建环境时,可以看到模板列表(现成的自定义模板),以便能够轻松地开始使用(图 66)。

部署模板

(图 66)部署模板

改进了任务和阶段编辑器

全新的生成定义编辑器中的所有增强功能现也适用于发布定义编辑器(图 67)。 可以搜索任务,并使用“添加”按钮或拖放操作进行添加。 可以使用拖放操作,重新排列或克隆任务。

任务编辑器

(图 67)任务编辑器

变量组、保留策略和“选项”选项卡

现在可以关联/取消关联到变量组(图 68),并为各个环境设置保留策略,同时还能在“选项”选项卡中修改发布定义级设置(如发行版号格式)。此外,还可以将环境保存为部署模板、设置环境级权限,并在“任务”选项卡中对阶段重新排序。

变量组

(图 68)变量组

执行环境级操作可以另存为模板并设置安全性(图 69)。

环境菜单

(图 69)环境菜单

使用部署组的 VM 部署

Release Management 现在支持现成可靠的多计算机部署。 现在,可以安排跨多台计算机进行部署,并执行滚动更新,同时确保整个应用程序的高可用性。

基于代理的部署功能依赖相同的生成和部署代理。 不过,不同于现行方法(在代理池中的一组代理服务器上安装生成和部署代理,并促使部署到远程目标服务器),可以直接在每个目标服务器上安装代理,并促使滚动部署到这些服务器。 可以在目标计算机上使用完整的任务目录。

部署组(图 70)是一个目标(计算机)逻辑组,其中每个目标上都安装了代理。 部署组表示物理环境,如单盒开发、多计算机 QA 和用于 UAT/Prod 的计算机场。它们还指定物理环境的安全性上下文。

部署组

(图 70)部署组

可以对向其注册了代理的任何 VM 使用此功能。 我们还支持在 VM 启动时自动安装代理的 Azure VM 扩展,极大地方便用户向 Azure 注册。 我们将自动继承已注册 Azure VM 上的标记。

拥有部署组后,只需配置要我们在相应部署组上执行的操作即可(图 71)。 可以使用标记控制在哪些计算机上运行什么部署,并控制滚动部署的速度快慢。

配置部署组

(图 71)配置部署组

运行部署时,日志显示跨整个目标计算机组的部署进展情况(图 72)。

部署组进展情况

(图 72)部署组进展情况

此功能现已集成到 Release Management。 无需其他任何附加许可证,即可使用此功能。

任务组引用

使用任务组,可以定义一组能够添加到生成或发布定义的任务。 如果需要在多个生成或发布中使用同一组任务,这就非常方便。 为了帮助用户跟踪任务组的使用者,现在支持查看引用任务组的生成定义、发布定义和任务组(图 73)。

任务组引用

(图 73)任务组引用

当用户尝试删除仍被引用的任务组时,我们会发出警告,并提供指向此页的链接。

任务组版本控制

更改任务组时,可能会觉得这样做有风险,因为更改会应用于使用任务组的所有定义。 通过任务组版本控制,现在可以组建和预览任务组版本,在能够切换前,仍向最重要的定义提供稳定版本。 经过一些组建和迭代后,可以发布稳定版本。发布时,如果更改属于重大更改,可以选择将任务组发布为预览版(新主版本)。 也可以直接发布为更新后的稳定版本(图 74)。

当任务组的新主版本(或预览版)可用时,定义编辑器会通知用户有新版本。 如果主版本是预览版,甚至会看到内容为“试一试”的消息。 当任务组不再是预览版时,使用此版本的定义会自动更新(遵循主要通道)(图 75)。

另存为草稿

(图 74)将任务组另存为草稿

将任务组发布为预览版

(图 75)将任务组发布为预览版

任务组导入和导出

虽然可以在项目中重用任务组,但我们知道,跨项目和帐户重新创建任务组可能会非常痛苦。 使用任务组导入/导出(图 76),现在可以将任务组导出为 JSON 文件,并在所需的位置导入,就像我们对发布定义所做的那样。 我们还启用了嵌套的任务组,导出时它们会先展开。

导出任务组

(图 76)导出任务组

服务器端(无代理)任务中的多配置支持

通过为服务器端(无代理)任务指定变量乘数(图 77),现在可以在并行运行的多个配置上的阶段中运行一组相同的任务。

无代理任务的多配置支持

(图 77)无代理任务的多配置支持

手动干预任务中的变量支持

手动干预任务(图 78)现在支持在任务运行时向用户显示的说明文本中使用变量,以便用户可以继续执行发布过程或拒绝它。 可以添加发布中定义的任何可用变量,这些值用于通知以及发送给用户的电子邮件(图 79)。

手动干预任务

(图 78)手动干预任务

手动干预挂起对话框

(图 79)手动干预挂起对话框

根据源分支控制部署到环境的发布

发布定义可以配置为,在新建发布时(通常是在源生成成功后)自动触发部署。 不过,不妨仅部署来自特定源分支的生成,而不是在任何生成成功时部署。

例如,不妨将所有生成部署到开发和测试环境,但只将特定的生成部署到生产环境。 以前,需要为此维护两个发布管道,一个用于开发和测试环境,另一个用于生产环境。

Release Management 现在支持对每个环境使用项目筛选器。 也就是说,可以指定在满足部署触发器条件(如生成成功和新建发布)时,将哪些发布部署到每个环境。 在环境“部署条件”对话框(图 80)的“触发器”部分中,选择触发向相应环境进行新部署的项目条件,如生成的源分支和标记。

“部署条件”对话框

(图 80)“部署条件”对话框

此外,“发布摘要”页(图 81)现在会弹出提示,指明所有“未启动”部署处于这种状态的原因,并建议如何或何时启动部署。

“发布摘要”页上的提示

(图 81)“发布摘要”页上的提示

作为项目源的 Git 存储库的发布触发器

Release Management 现在支持,为与同一帐户中任何团队项目中的发布定义相关联的 Git 存储库,配置持续部署触发器(图 82)。 这样一来,就可以在对存储库进行新提交时自动触发发布。 还可以指定提交会触发发布的 Git 存储库分支。

发布触发器

(图 82)发布触发器

发布触发器:持续部署推送到 Git 存储库的更改

Release Management 一直支持在生成完成时配置持续部署。 不过,现在还可以对 Git 推送配置持续部署。 也就是说,可以将 GitHub 和 Team Foundation Git 存储库作为项目源与发布定义相关联,再自动为不是通过生成制作的 Node.JS 和 PHP 等应用程序触发发布,因此无需适用于持续部署的生成操作。

增强了服务器端任务

我们对服务器端任务(在服务器阶段内运行的任务)进行了两项增强。

我们新增了一个任务,可用于在自动管道中调用任何常规 HTTP REST API(图 83)。 例如,可用于使用 Azure 函数调用特定的处理,并等待它完成。

REST API 任务

(图 83)REST API 任务

我们还向所有服务器端任务添加了“控制选项”(图 84)部分。 任务行为现在包括设置“已启用”、“出错时继续”、“始终运行”和“超时”选项。

任务控制选项

(图 84)任务控制选项

代码中心内的发布状态徽章

目前,若要确定是否已将提交部署到客户生产环境中,请先确定哪个生成使用此提交,再检查部署该生成的所有发布环境。 现在,操作大大简化了。“代码”中心状态徽章中集成了部署状态,可以列出代码已部署到的环境。 对于每个部署,状态都会发布到已部署的最新提交。 如果将提交部署到多个发布定义(包含多个环境),每个提交都会在徽章中记录一个条目,并显示针对每个环境的状态(图 85)。 这提升了已部署的代码提交的可跟踪性。

发布状态徽章

(图 85)发布状态徽章

默认情况下,创建发布定义时,部署状态会针对所有环境进行发布。 不过,可以有选择地选择应在状态徽章中显示哪些环境的部署状态(例如,仅显示生产环境的部署状态)(图 86)。

部署选项对话框

(图 86)部署选项对话框

增强了添加项目时使用的“生成定义”菜单

将生成项目添加到发布定义时,现在可以查看定义及其文件夹组织信息,并轻松选择所需的定义(图 87)。 这样,可以很容易区分不同文件夹中同名的生成定义。

添加项目

(图 87)添加项目

定义列表的筛选依据为是否包含筛选词。

将发布定义还原为旧版

目前,如果发布定义已更新,便无法还原为旧版。 唯一的方法是,查看发布定义历史记录,找出更改的差异,再手动编辑发布定义。 现在,使用“还原定义”功能(图 88),可以选择并还原为发布定义“历史记录”选项卡中的任意旧版发布定义。

还原发布定义

(图 88)还原发布定义

测试

不再支持 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 离线,现有实验室环境显示为“未就绪”。
  • 推荐备用方案:
自动测试:
手动测试:

提升了工作项链接、迭代和区域路径的探索测试可跟踪性

根据探索测试团队向我们提供的反馈意见,我们一直在改进可跟踪性链接,同时从测试和反馈扩展提交 bug、任务或测试用例。 对于探索需求时创建的 bug 和任务,它们现在使用与需求相同的区域路径和迭代(而不是团队默认值)进行创建。 对于探索需求时创建的测试用例,它们现在使用“测试 <-> 测试方”链接(而不是“父级 <-> 子级”链接)进行链接,以便将创建的测试用例自动添加到以需求为依据的测试套件。 最后,在没有具体探索任何需求时创建的工作项被提交到团队的默认迭代中,而不是当前迭代中,这样在冲刺 (sprint) 计划完成后,就没有任何新工作项进入当前迭代了。

筛选测试中心内的“测试计划和套件”中的测试用例工作项

除了可以筛选“结果”、“配置”和“测试程序”等“测试”字段之外,现在还可以筛选“标题”、“状态”和“分配到”等测试用例工作项字段(图 89)。

测试用例筛选器

(图 89)测试用例筛选器

“发布环境”和“测试运行”的测试趋势图

我们现已开始支持“测试结果趋势”小组件(图 90)中的“发布环境”,这样用户便可以在 VSTS 仪表板上跟踪测试环境的状态。 就像在“生成”中处理测试结果一样,现在可以创建趋势图,针对“发布环境”显示测试通过率、总数、通过或未通过测试和测试持续时间。 还可以使用“测试运行”标题筛选器,从图表中筛选出环境内的特定测试运行。

测试趋势图

(图 90)测试趋势图

“测试运行”和“测试结果”注释的 Markdown 格式支持

我们现已开始支持使用 Markdown 语法设置“测试运行”和“测试结果”注释的格式。 可以使用此功能,在注释中创建格式化文本或指向 URL 的快速链接。 可以使用“更新分析”更新“结果摘要”页中的“测试结果”注释,并使用“测试”中心内的“更新注释”更新“运行摘要”页中的“测试运行”注释。

在“生成”/“发布”摘要页或“测试”中心内分析测试结果时,现在可以将现有 bug 与未通过测试相关联。 当测试由于已知原因而未通过且 bug 已提交时,这就非常有用。

停止提供适用于 SharePoint 的 TFS 扩展

TFS 2018 及更高版本不再支持适用于 SharePoint 的 TFS 扩展。 此外,用于配置 TFS 服务器与 SharePoint 服务器集成的屏幕,已从 Team Foundation 管理控制台中删除。

今后,我们不支持服务器间集成,将使用公共 API 和扩展性框架进行集成。

若要升级配置了 TFS/SharePoint 集成的服务器,可以使用我们提供的解决方案,脱离服务器间集成进行升级。 TFS SharePoint 站点将在升级后继续显示,但集成功能将被禁用。 有关详细信息和说明,请转到此处

停止提供团队聊天室

新式开发团队主要依靠协作。 团队成员希望(且需要)有地方来监视活动(通知),并进行讨论(聊天)。 几年前,我们认识到这种趋势,并着手构建团队聊天室,以支持实现这些方案。 自那以后,市场中出现了更多协作解决方案。 最突出的是,Slack 的兴起。 近期,我们宣布推出 Microsoft Teams

有这么多优质的解决方案可与 TFS 和 Visual Studio Team Services 完美集成,我们在 1 月宣布,计划从 TFS 2018 和 Visual Studio Team Services 中删除团队聊天室功能。


已知问题

TFS 数据库导入服务不支持 RC 版本

适用于 Visual Studio Team Services 的 TFS 数据库导入服务不支持从 TFS 的 RC 版本中导入。 如果计划使用此服务将集合数据库导入 Team Services,不得将生产数据库升级到此 RC 版本。 如果确实要升级,则需要等待,然后升级到此次发布的 RTW 版本,或从以前的 TFS 版本还原数据库备份副本,以便导入。

生成/发布中的 Visual Studio Test v1 任务无法使用 Visual Studio 2017 Update 3 运行测试

生成/发布中的 Visual Studio Test v1 任务无法使用 Visual Studio 2017 Update 3 运行测试。 任务失败,并显示内容为“无法确定 vstest.console.exe 位置”的消息。 解决方法是使用 Visual Studio Test v2 任务。