Team Foundation Server 2018 发行说明

Last Update: 2017/11/22

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

Download the latest version of Team Foundation Server

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


“TFS 2018 中的新增功能”视频


反馈

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


发布日期:2017 年 11 月 15 日

摘要:Team Foundation Server 2018 更新

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。

自定义工作项窗体标头

现可通过替换现有控件或隐藏与进程无关的控件来自定义工作项窗体标头区域。 这可支持使用自定义团队字段替换区域路径、隐藏迭代(如果团队更专注于看板)以及使用自定义字段替换原因。 “状态”字段无法隐藏或替换。

有关详细信息,请参阅 WebLayout 和控件元素文档

移动工作项表单

我们提供完整的端到端体验,包括已经过优化的工作项观感(图 1)。 这样,你可通过手机与分配给你的、你正在跟踪的、你访问过的或最近编辑过的工作项轻松进行交互。

Mobile work item query

(图 1)移动工作项查询

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

Mobile work item form

(图 2)移动工作项表单

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

Mobile navigation

(图 3)移动导航

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

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

Filtering on query

(图 4)对查询的筛选

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

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

Hidden field

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

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

Update hidden field

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

阻止保存工作项的扩展

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

内联添加交付计划

新的功能想法可能随时出现,我们简化了直接向“交付计划”添加新功能的过程(图 7)。 只需在光标悬停时单击出现的“新建项”,输入名称,然后按 Enter。 随即将使用所预期的区域路径和迭代路径创建新的功能。

Inline add on delivery plans

(图 7)内联添加交付计划

版本控制

分叉

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

Git forks

(图 8)Git 分支

GVFS

现支持 Git 虚拟文件系统 (GVFS)。 通过虚拟化和优化 Git 在该文件系统上的操作方式,GVFS 支持 Git 存储库扩大至数百万文件。

使用 Web 在存储库中创建文件夹

现可通过 Web 在 Git 和 TFVC 存储库中创建文件夹(图 9)。 这会替换目前处于弃用过程的文件夹管理扩展

若要创建文件夹,请在命令栏或上下文菜单中单击“新建”>“文件夹”:

New folder option

(图 9)新建文件夹选项

对于 TFVC,指定文件夹名称,然后将其签入。 对于 Git,由于不允许空文件夹,因此也需指定文件名,或者编辑文件,然后提交。

此外,对于 Git,“新建文件”对话框(图 10)已改进为接受斜杠,以创建子文件夹。

New file dialog

(图 10)新建文件对话框

文件 Minimap

现在查看或编辑文件时可查看文件的 Minimap,快速概览代码(图 11)。 若要启用 Minimap,打开“命令面板”(F1 或右键单击),然后选择“切换 Minimap”。

File minimap

(图 11)文件 minimap

括号匹配

现在编辑或查看文件时,左侧会有参考线,可与括号轻松匹配(图 12)。

Bracket matching

(图 12)括号匹配

切换空格

现在,查看或编辑文件时,可将空格切换为“开”或“关”。 我们仍在开发一种可在比较时切换空格的功能。 若要查看空格(图 13),请打开“命令面板”(F1 或右键单击),然后选择“切换空格”,以便区分空格和制表符。

Toggle white space

(图 13)切换空格

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

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

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

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

注意

从“项目概述”页编辑 README 不受影响。

Turn off web editing

(图 14)关闭 Web 编辑

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

Web editing not allowed dialog

(图 15)禁用 Web 编辑的对话框

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

识别过时分支

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

Stale branches

(图 16)过时分支

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

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

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

Search for deleted branches

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

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

Restore deleted branches

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

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

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

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

Search for a commit

(图 19)搜索提交

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

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

Pull request callout

(图 20)拉取请求标注

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

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

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

Find a file or folder

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

Filtered view

(图 22)提交树的筛选视图

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

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

Pushes page

(图 23)推送页

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

Commits page

(图 24)提交页

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

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

查看 Git 标记

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

View Git tags

(图 25)查看 Git 标记

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

删除 Git 标记

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

警告

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

Delete git tags

(图 26)删除 Git 标记

筛选 Git 标记

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

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

Filter Git tags

(图 27)筛选 Git 标记

Git 标记安全性

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

Git tag security

(图 28)Git 标记安全性

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

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

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

Complete linked work items

(图 29)完成链接的工作项

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

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

Reset votes setting

(图 30)重置投票设置

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

Reset votes in timeline

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

按文件名筛选拉取请求树

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

Find file or folder in pull request

(图 32)查找拉取请求中的文件或文件夹

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

Find results

(图 33)查找结果

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

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

PR comment filtering

(图 34)PR 注释筛选

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

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

View original diff

(图 35)查看原始差异

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

Update badge

(图 36)更新徽章

可折叠的拉取请求注释

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

Hide comments

(图 37)隐藏注释

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

Collapsed comments

(图 38)折叠的注释

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

Collapsed comment tooltip

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

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

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

Task list toolbar

(图 40)任务列表工具栏

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

Task list

(图 41)任务列表

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

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

Like pull request comments

(图 42)点赞拉取请求注释

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

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

Cancel auto-complete dialog

(图 43)取消自动补全对话框

Git 通知支持路径筛选

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

Path filtering for notifications

(图 44)通知的路径筛选

更新了拉取请求工作流的电子邮件模板

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

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

Improved email template

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

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

Email call-to-action

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

已更新用于推送通知的电子邮件模板

推送通知已更新,以匹配经优化而变得清晰、简洁和可操作的新电子邮件模板(图 47)。 主题行有助于清晰区分推送电子邮件,标识分支、存储库和创建者以及汇总推送中包含的提交数。 这些更改还使创建规则和筛选器更加简单,从而有助于管理这些电子邮件通知。

电子邮件正文与其他电子邮件一致,强调发送电子邮件的原因、操作发起人员以及具体内容。 特定于推送警报,包含所有关于存储库、分支、文件和提交的详细信息,以帮助通知收件人更改范围。 对推送警报操作的主调用为“查看推送”,这将打开生成警报的特定推送的推送视图。

Push template

(图 47)推送模板

Wiki

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

Wiki page

(图 48)PR Wiki 页

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

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

Title wiki

(图 49)PR 标题 Wiki

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

Wiki HTML tags

(图 50)PR Wiki HTML 标记

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

Image resize

(图 51)调整 PR 图像的大小

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

Wiki menu

(图 52)PR Wiki 菜单

详细了解 Wiki 入门

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

Wiki revert button

(图 53)PR Wiki 还原按钮

我们在创建 Wiki 时观察到一种模式:Wiki 页上的表格内容中包含不存在的链接(图 54)。 用户可能会单击这些链接,尝试创建一个实际页。 我们以前处理这种情况的方法是发出警告,提示链接断开或页不存在。 现在,我们改为支持创建页,将这种情况作为 Wiki 的主要方案进行处理。

Create wiki page

(图 54)PR 创建 Wiki 页

Wiki 页面深层链接

Wiki 现支持页内和跨页深层链接部分,这对创建目录非常有用。 可使用以下语法引用同一页面或不同页面的标题:

  • 同一页面:[text to display](#section-name)
  • 不同页面:[text to display](/page-name#section-name)

Marketplace 上的 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

Package URL

(图 55)PR 包 URL

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

Hide deleted packages

(图 56)隐藏已删除的包

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

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

Last pushed column

(图 57)上一个推送的列

Maven 包

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

Maven packages

(图 58)Maven 包

新增统一的 NuGet 任务

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

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

Nuget task

(图 59)NuGet 任务

详细了解 Microsoft DevOps 博客上有关在生成中使用最新 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 源(图 60)。

dotnet task

(图 60)dotnet 任务

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

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

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

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

在帐户/集合之外工作

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

Feeds to use

(图 61)要使用的源

VSTS/TFS 源选取器

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

Feed picker

(图 62)源选取器

生成和发布

不再支持 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 生成弃用计划的说明,请参阅博客文章 Evolving TFS/Team Services build automation capabilities(不断发展的 TFS/Team Services 生成自动化功能)。

导出和导入生成定义

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

我们很高兴地向大家宣布,现在这已成为现实(图 63)和(图 64)!

Export build definition

(图 63)导出生成定义

Import build definition

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

Deprecated task badge

(图 65)弃用的任务徽章

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

Deprecated task description

(图 66)弃用的任务说明

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

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

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

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

变量组支持

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

使用 Apple 证书等安全文件

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

Secure files library

(图 67)安全文件库

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

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

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

暂停生成定义

现可暂停或禁用生成定义。 如果计划更改生成定义且希望在完成之前避免任何新生成排队,只需禁用生成定义即可。 同样,如果计划升级代理计算机,可选择暂停生成定义,这会使 VSTS 依然接受新的生成请求,但将其保留在队列中而不运行,直到继续生成定义。

任务输入验证支持

有时候,在生成定义任务中键入参数容易出现错误。 通过任务输入验证,任务创建者可确保指定适当的值。 验证表达式遵循用于任务条件的常见表达式语法,除了任务条件支持的常用函数外,还可使用任何受支持的函数,包括 URL、IPV4、电子邮件、数字范围、sha1、长度或匹配。

有关目标和使用情况的更多信息,请访问 vsts-tasks 存储库页面

全新的发布定义编辑器

我们一直在不断更新生成和发布体验。我们已重新设计发布定义编辑器以提供更加直观的体验,消除了一些痛点并添加了新功能。 新编辑器的最强大功能之一是能可视化呈现环境部署的进展情况。 除此之外,审批、环境属性和部署设置现在都可视情况使用,配置起来非常容易。

管道的可视化效果

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

Pipeline

(图 68)发布管道

可视情况使用的配置 UI

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

Release configuration

(图 69)发布配置

开始使用部署模板

所有内置部署模板均具备进程参数,用户可通过指定最重要的参数,更轻松地开始使用,无需深入了解任务的情况(图 70)。

Deployment templates

(图 70)部署模板

简化发布和环境变量管理

使用“列表”视图快速添加发布或环境变量,使用“网格”视图跨范围并排比较和编辑变量(图 71)。 此外,可在这两种视图中使用筛选器和关键字搜索来管理要处理的变量集。

Simplified management of variables

(图 71)简化的变量管理

改进了任务和阶段编辑器

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

Task editor

(图 72)任务编辑器

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

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

Variable groups

(图 73)变量组

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

Environment menu

(图 74)环境菜单

有关更多信息,请参阅发布定义编辑器文档

使用部署组的 VM 部署

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

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

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

Deployment groups

(图 75)部署组

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

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

Configure deployment groups

(图 76)配置部署组

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

Deployment group progress

(图 77)部署组进度

此功能现已集成到 Release Management。 不需要其他许可证。

改进了部署组 UI

我们一直在不断更新生成和发布体验。我们已重新设计部署组页面,使其可提供更加简洁直观的体验(图 78)。 从登录页面可查看部署组中目标的运行状况。 还可管理各个部署组的安全性,或者跨部署组设置默认权限。

Deployment groups UI

(图 78)部署组 UI

对于部署组中的目标,可以查看摘要、最近部署和目标的功能(图 79)。 可以对目标设置标记,控制每个目标上的运行内容。 我们将在即将发布的版本中添加部署组筛选器支持。

Deployment groups UI tags

(图 79)部署组 UI 标记

任务组引用

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

Task group references

(图 80)任务组引用

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

任务组版本控制

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

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

Save as draft

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

Publish task group as preview

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

任务组导入和导出

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

Export task group

(图 83)导出任务组

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

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

Multi configuration of agentless tasks

(图 84)无代理任务的多个配置

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

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

Manual intervention task

(图 85)手动干预任务

Manual intevention pending dialog

(图 86)手动干预待定对话框

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

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

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

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

Deployment conditions dialog

(图 87)部署条件对话框

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

Release summary tip

(图 88)发布摘要提示

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

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

Release triggers

(图 89)发布触发器

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

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

环境触发器中的分支筛选器

在新的发布定义编辑器中,现可为特定环境指定项目条件。 通过使用项目条件,可以更加精细地控制哪些项目应部署到特定环境。 例如,对于生产环境,可能需要确保仅部署从主分支产生的生成。 需要对你认为应满足此条件的所有项目设置此筛选器。

也可对链接到发布定义的每个项目添加多个筛选器(图 90)。 在此环境中,仅当成功满足所有项目条件时,才会触发部署。

Branch filters

(图 90)分支筛选器

增强了服务器端任务

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

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

REST API task

(图 91)REST API 任务

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

Task control options

(图 92)任务控件选项

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

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

Release status badge

(图 93)发布状态徽章

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

Deployment options dialog

(图 94)部署选项对话框

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

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

Add artifact

(图 95)添加项目

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

将发布定义还原为旧版

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

Revert release definition

(图 96)还原发布定义

个性化发布通知

发布通知现已与 VSTS 通知设置体验集成。 现在,这些管理版本自动获取有关挂起的操作(审核或手动干预)以及重要部署故障的通知。 通过导航至配置文件菜单下的“通知”设置并将“发布订阅”切换为“关闭”可关闭这些通知。 通过创建自定义订阅还可订阅其他通知。 管理员可通过“团队”下的“通知”设置和“帐户”设置控制团队和组的订阅。

发布定义创作者不再需要手动发送有关审核和部署完成的电子邮件。

对于具有多个发布利益干系人的大型帐户以及除审核者、发布创建者和环境所有者之外希望接收通知的人员,这尤为有用(图 97)。

Release notifications

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

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

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

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

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

Test case filters

(图 98)测试用例筛选器

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

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

Test trend chart

(图 99)测试趋势图表

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

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

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

上传附件以测试运行和测试结果

现在可将屏幕截图和日志文件等文件作为其他信息附加,以测试运行或测试结果。 目前仅通过 Microsoft 测试管理器 (MTM) 客户端提供此功能,因此必须在 VSTS/TFS 的“测试”中心和 MTM 客户端之间切换上下文。

测试批处理

在生成/发布管理的 Visual Studio 测试任务中,为实现高效执行,可以选择控制测试的分组(批处理)方式。 测试可按两种方式分组:

  1. 基于参与运行的测试和代理数量,这种方式仅将测试分组为具有指定大小的批次数。
  2. 基于过去的测试运行时间,这种方法使用过去的运行时间创建测试批,从而使每个批具有大致相等的运行时间(图 100)。 快速运行测试会一起批处理,而较长时间的运行测试可能属于单独的批。 此选项可与多代理阶段设置结合,将总测试时间降至最短。

Test batching

(图 100)测试批处理

使用 VSTest 任务运行 webtest

通过使用 Visual Studio 测试任务,现可在 CI/CD 管道中运行 webtest(也称为 Web 性能测试)。 可通过指定要在任务程序集输入中运行的测试来运行 Webtest。 还可通过选择任务中的测试计划/测试套件运行其“关联自动化”链接到 webtest 的任何测试用例工作项(图 101)。

Test selection

(图 101)测试选项

Webtest 结果以测试结果附件形式提供(图 102)。 可下载此结果以在 Visual Studio 中进行脱机分析。

Test summary

(图 102)测试摘要

此功能依赖于 Visual Studio 测试平台的更改,并且需要在生成/发布代理上安装 Visual Studio 2017 Update 4。 使用 Visual Studio 的以前版本无法运行 Webtest。

同样,可使用“运行功能测试”任务运行 webtest。 此功能依赖于测试代理的更改,将在 Visual Studio 2017 Update 5 中提供。

有关如何结合使用此功能和负载测试的示例,请参阅使用 Visual Studio 和 VSTS 在云中加载测试应用快速入门

测试计划和测试套件的图表小组件

以前可在“测试”中心为测试计划和套件创建图表并将其固定到仪表板。 现已添加一个小组件,该组件支持从仪表板上的小组件目录为测试计划和套件创建图表。 可以创建测试创作状态或测试执行状态的图表。 此外,图表上需要显示大量数据时,通过从小组件添加图表可以创建更大的图表(图 103)。

Chart widget

(图 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 中删除团队聊天室功能。


返回页首