Team Foundation Server 2017.0.1 Team Foundation Server 2017.0.1


如果正在从一个非英语的语言版本访问此页,并想要查看最新内容,请访问此“发行说明”页(英文版)。If you are accessing this page from a non-English language version, and want to see the most up-to-date content, please visit this Release Notes page in English.


可在本页底部切换页面语言。You can switch the page language at the bottom of this page. 单击Click the 图标搜索语言,或从可用语言列表中选择。 icon, search for your language, or select from the list of available languages.

Team Foundation Server 2017.0.1 发布日期:2018 年 2 月 28 日Team Foundation Server 2017.0.1 Release Date: February 28, 2018

Team Foundation Server 2017.0.1 新变化What's New in Team Foundation Server 2017.0.1

此更新修复了潜在的跨站点脚本 (XSS) 和其他安全漏洞。This update fixes potential cross site scripting (XSS) and other security vulnerabilities. 请参阅博客文章以获取详细信息。See the blog post for more information. 由于是完全升级,因此可以直接升级到 TFS 2017.0.1。It is a full upgrade, so you can upgrade directly to TFS 2017.0.1.

单击下面的按钮即可下载 Team Foundation Server 2017.0.1。Click the button to download Team Foundation Server 2017.0.1.

Download the Team Foundation Server 2017

若要了解有关其他相关下载的详细信息,请参阅下载页。To learn more about other related downloads, see the Downloads page.

Team Foundation Server 2017 发布日期:2016 年 11 月 16 日Team Foundation Server 2017 Release Date: November 16, 2016

本文将介绍 Team Foundation Server 2017 的相关信息。In this article, you will find information regarding Team Foundation Server 2017. 此版本包括我们最新的功能创新和改进。This release includes our most recent feature innovations and improvements. 请注意,Team Foundation Server 2017 的要求已更改。Note that the requirements have changed for Team Foundation Server 2017. 可在 Team Foundation Server 要求和兼容性 页上查找更多详细信息。You can find more details on the Team Foundation Server Requirements and Compatibility page. 如果这些不是你想了解的发行说明,表示你查看了发行说明的最新版本。If these were not the release notes you were expecting, you have reached the release notes for the most current version.

Team Foundation Server 2017 有什么新变化?What's New in Team Foundation Server 2017?

已知问题Known Issues

新增功能What's New

代码搜索提供在所有代码中快速、灵活且准确的搜索。Code Search provides fast, flexible, and accurate search across all your code. 随着代码库扩展,以及跨多个项目和存储库划分,查找所需内容变得越来越困难。As your codebase expands and is divided across multiple projects and repositories, finding what you need becomes increasingly difficult. 为了最大程度实现跨团队协作和代码共享,代码搜索可以跨所有项目快速高效地找到相关信息。To maximize cross-team collaboration and code sharing, Code Search can quickly and efficiently locate relevant information across all your projects.

从发现 API 实现的示例、浏览其定义,到搜索错误文本,代码搜索为所有代码研究和故障排除需求提供了一个一站式解决方案(图 1)。From discovering examples of an API's implementation, browsing its definition, to searching for error text, Code Search delivers a one-stop solution for all your code exploration and troubleshooting needs (Figure 1).

代码搜索提供:Code Search offers:

  • 在一个或多个项目中搜索Search across one or more projects
  • 语义排名Semantic Ranking
  • 丰富筛选Rich filtering
  • 代码协作Code collaboration
Code Search
(图 1)代码搜索(Figure 1) Code Search

有关详细信息,请参阅 搜索全部代码For details, see Search across all your code.

包管理 Package Management

包可让你在组织中共享代码:可以构造大型产品、基于常见共享框架开发多个产品或创建和共享可重用的组件和库。Packages enable you to share code across your organization: you can compose a large product, develop multiple products based on a common shared framework, or create and share reusable components and libraries. 包管理(图2)通过托管包、将其与所选人员共享并使 Team Build 和 Release Management 易于访问这些包,让代码共享变得容易。Package Management (Figure 2) facilitates code sharing by hosting your packages, sharing them with the people you select, and making them easily accessible to Team Build and Release Management.

使用包管理,不再需要通过直接在 Team Foundation Server 中托管 NuGet 包,来托管单独的 NuGet 服务器或文件共享。Package Management eliminates the need to host a separate NuGet server or file share by hosting NuGet packages directly in your Team Foundation Server. 它为 NuGet 3.x 提供了最佳支持,同时也为 NuGet 2.x 旧版客户端提供支持。It has best-in-class support for NuGet 3.x as well as support for NuGet 2.x legacy clients. 它可与现有 TFS 基础结构、团队和权限无缝协作,因此无需处理同步标识、在多个位置管理组等。它还可轻松与 Team Build 集成,以便你可以在连续的集成工作流中创建和使用包。It works seamlessly with your existing TFS infrastructure, teams, and permissions, so there’s no need to deal with synchronizing identities, managing groups in multiple places, etc. It also integrates easily with Team Build so you can create and use packages in continuous integration workflows.

有关详细信息,请参阅包管理概述For more details, see the Package Management overview.

Package Management
(图 2)包管理(Figure 2) Package Management

敏捷改进 Agile Improvements

在 Team Foundation Server 2017 中,我们已向工作项和看板添加了新特性和功能。In Team Foundation Server 2017, we've added new features and functionality to work items and Kanban boards.

新工作项窗体New work item form

新工作项*(图 3)*窗体具有全新的界面外观。The new work item (Figure 3) form has a new look and feel. 它还添加了一些出色的新功能:It also adds some great new features:

  • 丰富的工作项讨论体验。A rich work item discussion experience.
  • 支持拖放附件。Drag and drop support for attachments.
  • 改进的历史记录体验(History & auditing(历史记录和审核))。Improved history experience (History & auditing).
  • 改进的代码和生成集成。Improved code and build integration.
  • 状态着色。State coloring.
  • 响应式设计。Responsive design.


仅当用于新集合时,才默认为新工作项窗体。The new work item form is the default for new collections only. 如果要迁移现有集合,则必须通过管理员设置启用新工作项窗体。If you’re migrating an existing collection you will have to enable the new work item form from the admin settings. 有关详细信息,请参阅 Manage roll out of the new web form(管理新 Web 窗体的推出)。For more information, see Manage roll out of the new web form.

New WIT Form
(图 3)新 WIT 窗体(Figure 3) New WIT Form

跟踪工作项Follow a work item

现在只需通过单击窗体中的新“关注”按钮(图 4),就可以设置用于跟踪单个工作项的更改的警报。You can now setup an alert for tracking changes to a single work item just by clicking on the new "Follow" button (Figure 4) in the form. 在跟踪工作项时,将随时通知你工作项的更改,包括字段更新、链接、附件和注释。When you follow a work item, you'll be notified any time the work item changes – including field updates, links, attachments, and comments.

New WIT Form
(图 4)新 WIT 窗体(Figure 4) New WIT Form

有关详细信息,请参阅跟踪工作项For details, see Follow a work item.

看板实时更新Kanban board live updates

你的看板现在是实时的!Your Kanban board is now live!

你是否按了 F5 键来了解这一整天你的看板都发生了什么?Have you been hitting F5 to figure out what's going on throughout the day with your Kanban board? 请尝试使用下面屏幕截图*(图 5)*中的图标。Try the icon in the screenshot below (Figure 5).

Kanban live updates
(图 5)看板实时更新(Figure 5) Kanban live updates

当你团队中的任何人在板上创建、更新或删除工作项时,你将立即在板上收到实时更新。When anyone in your team creates, updates, or deletes a work item on the board, you will receive live updates on your board immediately. 此外,如果管理员进行看板或团队级别更新,如添加新列或启用积压工作上的 Bug,将通知你刷新看板以更新看板布局。Also, if the administrator makes board or team level updates such as adding a new column or enabling bugs on backlog, you will be notified to refresh the board to update your board layout. 现在只需启用看板上的“塔”图标并开始与团队协作。All you need to do now, is enable the tower icon on your Kanban board and start collaborating with your team.

有关详细信息,请参阅看板基础知识For more information, see Kanban basics.

清单改进Checklist improvements

我们已经对清单的工作方式做出了几处改进。We’ve made several improvements to how Checklists work.

清单标题现在显示为超链接(图 6)。Checklists titles now appear as hyperlinks (Figure 6). 你可以单击标题以打开工作项窗体。You can click on the title to open the work item form.

Checklist improvements
(图 6)清单超链接(Figure 6) Checklist hyperlinks

清单现在还支持上下文菜单,可通过其打开、编辑或删除清单项*(图 7)*。Checklists now also support context menus that allow you to open, edit, or delete checklist items (Figure 7).

Checklist context menu
(图 7)清单快捷菜单(Figure 7) Checklist context menu

有关详细信息,请参阅添加任务清单For details, see Add task checklists.

长篇故事和功能板向下钻取Epic and Feature Board Drill-down

现在可以向下钻取长篇故事和功能板(图 8)。You now have the ability to drill down on your Epic and Feature boards (Figure 8). 清单格式可让你轻松将工作标记为已完成,并提供已完成工作与未完成工作的便利鸟瞰视图。The checklist format lets you easily mark work as completed, and provides a handy bird’s eye view of the completed versus outstanding work.

Epic Feature drilldown
(图 8)长篇故事和功能板向下钻取(Figure 8) Epic Feature drilldown

有关详细信息,请参阅看板功能和长篇故事For more information, see Kanban features and epics.

打开/关闭看板批注Turning board annotations on/off

我们为你提供了对显示在看板上卡片中的附加信息的更多控制。We are giving you more control of the additional information that shows on the cards on your boards. 现在可以选择想要在看板卡上查看的批注(图 9)。You can now select annotations that you want to view on your Kanban cards (Figure 9). 只需取消选中批注,它将从看板上的卡片中消失。Simply unselect an annotation and it will disappear from the cards on your Kanban board. 将在此处显示的前两个批注是子工作项(此示例中的任务)和测试批注。The first two annotations to show up here are child work items (tasks in this example) and the Test annotation.

Turn on/off board annotations
(图 9)启用/禁用板注释(Figure 9) Turn on/off board annotations

有关详细信息,请参阅自定义卡片For more information, see Customize Cards.

清除格式命令Clear formatting command

我们已向工作项上的所有 RTF 控件添加了一个新的命令,它可让你清除所选文本中的所有格式。We’ve added a new command to all rich text controls on work items that lets you clear all formatting from selected text. 如果你和我一样,那么你过去可能也因为将带格式的文本复制粘贴到这一不能撤消(或清除)的字段中而抓狂。If you’re like me, you’ve probably been burned in the past by copying and pasting formatted text into this field that you can’t undo (or clear). 现在,你只需突出显示任何文本、选择“清除格式”工具栏按钮(或按 CTRL+空格键),就将看到文本返回到其默认格式。Now you can simply highlight any text, select the Clear Formatting toolbar button (or press CTRL+Spacebar), and you'll see the text return to its default format.

在看板中进行筛选Filtering in Kanban board

通过对用户、迭代、工作项类型和标记设置筛选器,对看板进行个性化设置(图 10)。Personalize your Kanban boards by setting filters on users, iterations, work item types, and tags (Figure 10). 这些筛选器将保留,以便你可以查看你的个性化看板,即使从多台设备连接时也是如此。These filters will persist so that you can view your personalized board, even when you connect from multiple devices.

Filtering in Kanban
(图 10)看板筛选(Figure 10) Filtering in Kanban

团队成员也可以筛选其看板以查看计入到特定父工作项的进度。Team members can also filter their boards to view progress accruing to a specific parent work item. 例如,用户可以查看链接到功能的用户情景,或查看汇总到长篇故事的两个或多个功能的工作。For example, a user can view user stories that are linked to a feature, or view work across two or more features that roll up to an epic. 类似于清单,此项功能是我们为把可见性带入不同积压工作 (backlog) 级别所做的进一步努力。This feature, much like Checklists, is one more step in our effort to bring visibility through to the different backlog levels.

有关详细信息,请参阅筛选看板For details, see Filter Kanban board.

新工作项的默认迭代路径Default iteration path for new work items

当从“查询”选项卡或从“新工作项”仪表板小组件创建新工作项时,该工作项的迭代路径将始终设置为当前迭代。When you create a new work item from the Queries tab or from the New Work Item dashboard widget, the iteration path of that work item is always set to the current iteration. 这并不是所有团队都想要的,因为这将意味着 bug 可能会立即显示在任务板上。This is not what all teams want, because it will mean that bugs could show up on the task board immediately. 利用此项改进,团队可以选择应用于新工作项的默认迭代路径(一个特定迭代或当前迭代)。With this improvement, teams can choose the default iteration path (a specific one or the current iteration) that should be used for new work items. 导航到你团队的管理区域以选择默认迭代。Navigate to the administration area for your team to choose a default iteration.

有关详细信息,请参阅自定义区域和迭代路径页。For more information, see the Customize area and iteration paths page.

复选框控件Checkbox control

现在可以向工作项添加复选框控件(图 11)。You can now add a checkbox control to your work items (Figure 11). 此新字段类型(布尔)具有普通字段的所有属性,并且可被添加到进程中的任何类型。This new field type (Boolean) has all the properties of normal fields and can be added to any type in your process. 当显示在卡上或查询结果中时,值显示为 True/False。When displayed on cards or in a query result, the value is shown as True/False.

Checkbox control
(图 11)复选框控件(Figure 11) Checkbox control

有关详细信息,请参阅自定义字段For details, see Customize a field.

标记的批量编辑Tags bulk editing

现可使用批量编辑对话框添加和删除多个工作项中的标记*(图 12)*。You can now add and remove tags from multiple work items using the bulk edit dialog (Figure 12).

Bulk edit dialog
(图 12)批量编辑对话框(Figure 12) Bulk edit dialog

有关详细信息,请参阅向工作项添加标记For details, see Add tags to work items.

新扩展点New extension points

我们在看板和积压工作 (backlog) 页上添加了新的贡献点,使你能够将扩展编写为“看板/积压工作/容量”选项卡旁的透视选项卡。We’ve added a new contribution point on the board and backlog pages to allow you to write extensions as a pivot tab next to Board/Backlog/Capacity tabs.

我们已公开了积压工作上的新的扩展点。We have exposed a new extension point on the backlog. 扩展可以将右侧窗格作为目标,映射和工作详细信息就位于右侧窗格中*(图 13)*。Extensions can target the pane on the right side, where mapping and work details are today (Figure 13).

Backlog extension points
(图 13)积压工作 (backlog) 扩展点(Figure 13) Backlog extension points

有关扩展的详细信息,请参阅扩展点For more information on extensions, see Extension Points.

电子邮件改进Email improvements

我们显著改进了 TFS 发送的工作项警报、关注和 @mention 电子邮件的格式和可用性(图 14)。We’ve significantly improved the formatting and usability of work item alerts, follows, and @mention emails sent by TFS (Figure 14). 电子邮件现在包含一致的标头、明确的操作调用和改进的格式,以确保邮件中的信息易于使用和理解。Emails now include a consistent header, a clear call to action, and improved formatting to make sure the information in the mail is easier to consume and understand. 此外,所有这些电子邮件旨在确保它们在移动设备上良好呈现。Additionally, all these emails are being designed to ensure they render well on mobile devices.

Email improvements
(图 14)电子邮件改进(Figure 14) Email improvements

有关详细信息,请参阅工作项警报For more information, see Work item alerts.

工作项模板Work item templates

我们增加了直接在本机 Web 体验中创建丰富的工作项模板的功能(图 15)。We added the ability to create rich work item templates directly into the native web experience (Figure 15). 此功能之前在 Web 中非常有限,且仅通过 Visual Studio 增强工具以这一新形式提供。This capability was previously very limited in the web, and only available in this new form through a Visual Studio power tool. 团队现在可以创建和管理一组模板,用于快速修改常见字段。Teams can now create and manage a set of templates for quickly modifying common fields.

Work item templates
(图 15)工作项模板(Figure 15) Work item templates

有关详细信息,请参阅工作项模板For details, see Work item templates.

不再支持 Project Server 集成Project server integration no longer supported

Team Foundation Server 2017 及更高版本将不再支持 Project Server 集成。Team Foundation Server 2017 and later versions no longer support Project Server integration. 自 RC2 起,如果升级已配置了 Project Server 集成的 TFS 数据库,将收到以下警告:As of RC2, if you upgrade a TFS database that has Project Server integration configured, you'll receive the following warning:

我们已检测到你为此数据库配置了 Project Server 集成。Team Foundation Server 2017 及更高版本将不再支持 Project Server 集成。We have detected that you have Project Server integration configured for this database. Team Foundation Server 2017 and later versions no longer support Project Server integration.

升级之后,Project Server 集成将不再起作用。After upgrade, the Project Server integration will no longer operate.

今后,我们将依赖于合作伙伴来提供集成解决方案。Going forward, we will be relying on Partners to provide integration solutions.

有关此更改的详细信息,请阅读以下主题:将 TFS 与 Project Server 同步For more information on this change, please read the following topic: Synchronize TFS with Project Server.

仪表板和小组件改进 Dashboards and Widgets Improvements

Team Foundation Server 2017 对多个小组件进行了改进,如查询磁贴和拉取请求小组件。Team Foundation Server 2017 has made improvements on multiple widgets, such as the Query Tile and Pull Request widgets.

经过重新设计的小组件目录Redesigned widget catalog

我们已重新设计了小组件目录,以便容纳不断增加的小组件集并提供更好的整体体验(图 16)。We’ve redesigned our widget catalog to accommodate the growing set of widgets and deliver a better overall experience (Figure 16). 新的设计包括改进的搜索体验,并改变了其样式以匹配小组件配置面板的设计。The new design includes an improved search experience and has been restyled to match the design of our widget configuration panels.

Widget catalog
(图 16)小组件目录(Figure 16) Widget catalog

有关详细信息,请参阅小组件目录For more details, see Widget Catalog.

小组件更新Widget updates

查询磁贴小组件现在支持最多 10 个条件规则,并且有可选择的颜色(图 17)。The Query Tile widget now supports up to 10 conditional rules and has selectable colors (Figure 17). 当你想要将这些磁贴用作 KPI 来确定运行状况和/或可能需要的操作时,这极为方便。This is extremely handy when you want to use these tiles as KPIs to identify health and/or action that may be needed.

Dashboard updates
(图 17)仪表板更新(Figure 17) Dashboard updates

拉取请求小组件现在支持多个大小,允许用户控制小组件的高度。The Pull Request widget now supports multiple sizes, allowing users to control the height of the widget. 我们正致力于使我们提供的大多数小组件可调整大小,可在此处查看详细信息。We’re working on making most of the widgets we ship resizable, so look for more here.

新工作项小组件现在允许选择默认工作项类型,而不是强制你选择要从下拉列表中反复创建的最常见类型。The New Work Item widget now allows you to select the default work item type, instead of forcing you to select the most common type you’re creating over and over from the drop-down list.

我们让 WIT 图表小组件可调整大小。We've made the WIT chart widgets resizable. 这使用户能够在仪表板上看到任何 WIT 图表的扩展视图(无论其原始大小如何)。This allows users to see an expanded view of any WIT chart on the dashboard regardless of its original size.

更新了团队成员小组件,使得可以更轻松地将某人添加到团队*(图 18)*。The Team Members widget has been updated to make it easier to add somebody to your team (Figure 18).

Widget Update
(图 18)小组件更新(Figure 18) Widget Update

现在,团队可以配置仪表板的查询结果小组件的大小,从而使其显示更多结果。Teams can now configure the size of the dashboard's Query Results widget, allowing it to display more results.

已重新设计了“冲刺(sprint)概述”小组件,使团队能够更轻松地查看他们是否步入正轨。The Sprint Overview widget has been redesigned making it easier for teams to see if they're on track.

“已指派给我”小组件帮助用户管理分配给他们的工作,而无需离开仪表板上下文(图 19)。The Assigned to Me widget helps users manage the work assigned to them without leaving the dashboard context (Figure 19). 通过提供专为此目的而设计的小组件,团队管理员只需不到 16 次单击,即可将此功能添加到其仪表板中,且无需上下文切换和键入。By providing a widget dedicated to this purpose, team admins can add this functionality to their dashboards with 16 fewer clicks, no context switches and no typing required. 用户现在可以在小组件上下文中对分配给自己的工作进行查看、排序、筛选和管理等操作。Users can now view, sort, filter, and manage the work assigned to them within the widget context.

Assigned to me
(图 19)分配到我(Figure 19) Assigned to me

仪表板 REST APIDashboards REST APIs

现在可以使用 REST API 以编程方式添加、删除和获取仪表板上的信息。You can now use REST APIs to programmatically add, delete, and get information on a dashboard. API 还允许你添加、删除、更新、替换和获取某个小组件上的信息或仪表板上的小组件列表。The APIs also let you add, remove, update, replace, and get information on a widget or a list of widgets on a dashboard. 文档在 Visual Studio 联机文档提供。The documentation is available on Visual Studio online docs.

可允许的仪表板Permissible dashboards

非管理员用户现在可以创建并管理团队仪表板。Non-admin users can now create and manage team dashboards. 团队管理员可通过仪表板管理器限制非管理权限。Team admins can restrict non-admin permissions through the dashboard manager.

有关详细信息,请参阅仪表板For more information, see Dashboards.

Git 改进 Git Improvements

在 Team Foundation Server 2017 的 Git 中进行了一些重大更改。Some major changes have been made in Git for Team Foundation Server 2017. 包含有分支页的重新设计和“挤压合并”的新选项。Included are a redesign of the Branches page and a new option to “squash merge”.

经过重新设计的分支页Redesigned Branches page

已彻底重新设计了分支页。The Branches page has been completely redesigned. 它具有“mine”透视,显示已创建、推送到或收藏的分支(图 20)。It has a "mine" pivot that shows the branches you created, pushed to, or favorited (Figure 20). 每个分支显示其生成和拉取请求状态,以及删除之类的其他命令。Each branch shows its build and pull requests status, as well as other commands like Delete. 如果分支名称中存在斜线,如“features/jeremy/fix-bug”,它将显示为一个树,因此浏览大型分支列表很容易。If there is a slash in a branch name, like "features/jeremy/fix-bug", it's shown as a tree, so it's easy to browse through a large list of branches. 如果你知道你的分支的名称,则可以快速搜索找到所需分支。If you know the name of your branch, you can search to find the one you want quickly.

Redesigned branches page
(图 20)已经过重新设计的“分支”页面(Figure 20) Redesigned branches page

有关分支的详细信息,请参阅管理分支For more details on branches, see Manage branches.

新拉取请求体验New pull request experience

本版本中的拉取请求体验有一些重大更新,引入了一些真正强大的差异功能、新的注释体验和全新的 UI。The pull request experience has some major updates this release, bringing some really powerful diff capabilities, a new commenting experience, and an entirely refreshed UI.

有关详细信息,请参阅使用拉取请求查看代码For more details, see Review code with Pull Requests.

重新设计的 UIRedesigned UI

打开拉取请求时,新的外观即呈现在眼前(图 21)。When opening a pull request, the new look and feel is evident immediately (Figure 21). 我们重新组织了标头,将所有关键状态和操作汇总,以便可从体验中的各视图访问它们。We've reorganized the header to summarize all the critical state and actions, making them accessible from every view in the experience.

Pull request header
(图 21)拉取请求头(Figure 21) Pull request header

概述现在会突出显示 PR 说明,提供反馈变得前所未有的轻松(图 22)。The Overview now highlights the PR Description and makes it easier than ever to give feedback (Figure 22). 事件和注释的显示方式为最新项在上,从而帮助审阅者查看位于显眼位置的最新更改和注释。Events and comments are shown with the newest items on top to help reviewers see the latest changes and comments front and center. 提供了策略、工作项和审阅者的详细信息并对其进行了重新组织,以便更加简明扼要。Policies, work items, and reviewers are all provided in detail and reorganized to be more clear and concise.

Pull request overview
(图 22)拉取请求概述(Figure 22) Pull request overview

本版本中最大的新功能是能够查看之前对拉取请求进行的更新(图 23)。The biggest new feature in this release is the ability to see past updates made to a pull request (Figure 23). 在之前的预览版中,我们发布了正确跟踪注释的功能(因为更新拉取请求时对其进行了更改)。In previous previews, we released the ability to properly track comments as a PR is updated with changes. 但,要查看两次更新之间的更改并不容易。However, it's not always easy to see what's between updates. 现在可在“文件”视图中确切地看到每次将新代码推送到拉取请求中时,对哪些内容进行了更改。In the Files view, you can now see exactly what changed each time new code is pushed to your PR. 如果你获得了有关一些代码的反馈,并且想在审阅时(独立于所有其他更改)查看其具体更改,这将非常有用。This is very useful if you've given feedback on some code and want to see exactly how it changed, isolated from all the other changes in the review.

Pull request files
(图 23)拉取请求文件(Figure 23) Pull request files

新的“更新”视图用于显示 PR 怎样随时间变化(图 24)。The new Updates view is used to show how the PR is changing over time (Figure 24). “文件”视图显示文件怎样随时间改变,而“更新”视图显示每次更新所增加的提交。Where the Files view shows how the files have changed over time, the Updates view shows the commits added in each update. 如果曾发生强制推送,由于曾经进行过更新,“更新”视图将继续显示这些过去的更新。If a force push ever happens, the Updates view will continue to show the past updates as they occurred in history.

Pull request updates
(图 24)拉取请求更新(Figure 24) Pull request updates
现可使用标记和表情符号进行注释Comments, now with markdown and emoji

在所有讨论中运用全部标记功能,包括格式设置、突出显示语法的代码、链接、图像和表情符号(图 25)。Use the full power of markdown in all your discussions, including formatting, code with syntax highlighting, links, images, and emoji (Figure 25). 注释控件也具有更加友好的用户编辑体验,允许一次编辑(然后保存)多个注释。The commenting controls also have a more user friendly editing experience allowing multiple comments to be edited (and then saved) at one time.

Pull request comments
(图 25)拉取请求注释(Figure 25) Pull request comments
添加和删除拉取请求中的审阅者Add and remove reviewers in pull requests

现在可以更轻松地添加和删除拉取请求中的审阅者。It's now easier to add and remove reviewers from your pull requests. 若要将审阅者或组添加到你的拉取请求,只需在审阅者部分中的搜索框中输入其(姓名)名称。To add a reviewer or group to your pull request, simply enter their name into the search box in the Reviewers section. 若要删除审阅者,在审阅者部分将鼠标悬停在其磁贴上,单击 X 即可删除*(图 26)*。To remove a reviewer, hover over their tile in the Reviewers section and click the X to remove them (Figure 26).

Add reviewers in pull requests
(图 26)在拉取请求中添加审阅者(Figure 26) Add reviewers in pull requests
改进的生成和拉取请求可跟踪性Improved build and pull request traceability

生成和拉取请求之间的可跟踪性得到改进,使在 PR 和生成之间来回导航变得轻松。The traceability between builds and pull requests has improved, making it easy to navigate from a PR to a build and back. 在由拉取请求触发的生成的生成详细信息视图中,源现在将显示指向排队生成的拉取请求的链接。In the build details view for a build triggered by a pull request, the source will now show a link to the pull request that queued the build. 在生成定义视图中,任何由拉取请求触发的生成将在“触发者”列中提供到拉取请求的链接。In the Build Definitions view, any build triggered by a pull request will provide a link to the pull request in the "Triggered By" column. 最后,生成资源管理器视图将在源列中列出拉取请求。Finally, the Build Explorer view will list pull requests in the source column.

拉取请求的注释跟踪Comment tracking for pull requests

改进了 VSTS 中的拉取请求,以显示正确行上的文件中剩余的注释,即使这些文件从注释被添加后已被更改。Pull requests in VSTS have been improved to show comments left in files on the proper line, even if those files have been changed since the comments were added. 以前,即使文件内容已更改,注释始终显示在它们最初被添加时所在的文件的行上,换而言之,第 10 行上的注释将始终显示在第 10 行上。Previously, comments were always shown on the line of the file where they were originally added, even if the file contents changed—in other words, a comment on line 10 would always be shown on line 10. 随着最新的改进,注释跟随代码以显示用户预期的位置(如果在第 10 行添加了注释,且有两个新行随后添加到了文件开头,则注释将显示在第 12 行)。With the latest improvements, the comments follow the code to show what the user expects—if a comment was added on line 10, and two new lines were subsequently added to the beginning of the file, the comment will be shown on line 12.

以下是第 13 行上注释的示例更改*(图 27)*:Here's an example change with a comment on line 13 (Figure 27):

Comment tracking
(图 27)注释跟踪(Figure 27) Comment tracking

甚至在代码已更改为将具有原始注释的行从第 13 行移位至第 14 行后,注释将会显示在预期位置(第 14 行)(图 28)Even after the code has changed to shift the line with the original comment from 13 to 14, the comment is appearing in the expected place on line 14 (Figure 28).

Comment tracking with change
(图 28)注释跟踪(代码已更改)(Figure 28) Comment tracking with change
自动完成拉取请求等待策略Auto-complete pull requests waiting on policies

使用分支策略 来保护分支的团队将需要签出自动完成操作。Teams that are using branch policies to protect their branches will want to check out the auto-complete action. 许多时候,拉取请求的作者准备合并其拉取请求,但需要等待完成生成,然后才可单击“完成”。Many times, the author of a pull request will be ready to merge their PR, but they're waiting on a build to finish before they can click Complete. 其他时候,虽然生成已通过,但有一个审阅者尚未给予最终批准。Other times, the build is passing, but there is one reviewer that hasn't given the final approval. 在这两种情况下,自动完成操作让作者将 PR 设置为在策略得到全部批准后立即自动完成*(图 29)*。In these cases, the auto-complete action lets the author set the PR to automatically complete as soon as the policies are all approved (Figure 29).

(图 29)自动完成(Figure 29) Auto-complete

正如手动完成操作一样,作者有机会对合并提交消息进行自定义并选择适当的合并选项*(图 30)*。Just like the manual complete action, the author has a chance to customize the message of the merge commit and select the appropriate merge options (Figure 30).

(图 30)自动完成对话框(Figure 30) Autodialog

设置自动完成后,PR 将显示一个横幅,确认自动完成已设置且正在等待策略完成*(图 31)*。Once auto-complete has been set, the PR will display a banner that confirms that the auto-complete is set and waiting for policies to complete (Figure 31).

Auto-complete confirmation
(图 31)自动完成确认(Figure 31) Auto-complete confirmation

满足所有策略后(例如,生成已完成或已授予最终批准),将使用指定选项和注释合并拉取请求。When all the policies have been met (e.g., the build completes, or that final approval is granted), the PR will be merged using the options and comments specified. 如预期那样,如果存在生成失败或审阅者未批准的情况,拉取请求将保持活动状态,直到策略通过。As expected, if there is a build failure or the reviewer doesn't approve, the PR will remain active until the policies are passing.

挤压合并拉取请求Squash merge pull requests

完成拉取请求后,现在可以选择挤压合并(图 32)。When completing a pull request, you now have the option to squash merge (Figure 32). 此新选项将生成单个提交,它包含将应用于目标分支的主题分支中的更改。This new option will produce a single commit containing the changes from the topic branch that will be applied to the target branch. 常规合并和挤压合并之间最明显的区别是,挤压合并提交只有一个父提交。The most notable difference between a regular merge and a squash merge is that the squash merge commit will only have one parent commit. 这意味着历史记录图表将更简单,因为对主题分支所做的任何中间提交在生成的提交图中将不可访问。This will mean a simpler history graph, as any intermediate commits made to the topic branch will not be reachable in the resulting commit graph.

Squash merge pull request
(图 32)使用 Squash 选项合并拉取请求(Figure 32) Squash merge pull request

可在挤压合并拉取请求中查找更多详细信息。You can find more information at Squash merge pull requests.

提交可跟踪性Commit traceability

生成状态(成功或失败)现已清楚地显示在代码资源管理器和提交详细信息视图中(图 33)。Build status (success or failure) is now clearly visible in the Code Explorer and Commit Details views (Figure 33). 只需一次单击即可了解更多详细信息,因此你将始终知悉提交中的更改是否通过了生成。More details are just a click away, so you’ll always know if the changes in the commit passed the build or not. 还可以在生成定义的存储库选项中自定义哪些生成发布状态。You can also customize which builds post status in the repository options for the build definition. 此外,提交详细信息视图的最新更改将提供有关所做更改的更深入的见解。Additionally, the latest changes to the Commit Details view provide deeper insights about your changes. 如果你使用拉取请求合并更改,将看到将更改引入主分支(或在合并提交的情况下,创建它的 PR)的拉取请求的链接。If you’re using pull requests to merge your changes, you’ll see the link to the pull request that introduced the changes into the master branch (or in the case of a merge commit, the PR that created it). 当更改到达主分支后,将显示分支链接以确认已包含所做更改。When your changes have reached master, the branch link will appear to confirm that the changes have been included.

Commit Traceability
(图 33)提交可跟踪性(Figure 33) Commit Traceability

在 Web 中查看 Git LFS 文件View Git LFS files in the Web

如果你已经在 Git 中处理大文件(音频、视频、数据集等),就会了解 Git 大型文件存储 (LFS) 使用 Git 内的指针替换这些文件,同时将文件内容存储在远程服务器上。If you’re already working with large files in Git (audio, video, datasets, etc.), then you know that Git Large File Storage (LFS) replaces these files with pointers inside Git, while storing the file contents in a remote server. 此项更改使查看这些大文件的全部内容成为可能(只需单击你的存储库中的文件)。This makes it possible to view the full contents of these large files by simply clicking the file in your repo.

有关详细信息,请参阅使用 Git 管理大文件For more information, see Manage large files with Git.

通过代码链接轻松地共享代码引用(图 34)。Share code references easily with code links (Figure 34). 只需在文件中选择文本,然后单击链接图标。Just select text in a file and click the Link icon. 它将复制到所选代码的链接。It will copy a link to the selected code. 当某个用户查看该链接时,你突出显示的代码将具有金色背景。When someone views that link, the code you highlighted will have a gold background. 它甚至适用于部分行的选择。It even works for partial line selections.

Send links to code
(图 34)发送代码链接(Figure 34) Send links to code

状态 APIStatus API

生成的(成功或失败)现已清楚地显示在代码资源管理器和提交详细信息视图中(图 35)。Success or failure of the build is now clearly visible in the code explorer and commit details views (Figure 35). 只需一次单击即可了解更多详细信息,因此你将始终知悉提交中的更改是否通过了生成。More details are just a click away, so you'll always know if the changes in the commit passed the build or not. 还可以在生成定义的存储库选项中自定义哪些生成发布生成状态。You can also customize which builds post build status in the repository options for the build definition.

Status API
(图 35)状态 API(Figure 35) Status API

文件类型图标File type icons

将看到新文件图标与资源管理器、拉取请求、提交详细信息、搁置集、变更集或显示文件列表的任何其他视图中的文件扩展名相匹配*(图 36)*。You will see new file icons matching the extension of the file in the explorer, pull requests, commit details, shelveset, changeset or any other view that shows a list of files (Figure 36).

File type example
(图 36)文件类型示例(Figure 36) File type examples

在存储库创建过程中添加自述文件Add a ReadMe during repo creation

通过为用户提供添加自述文件的功能改进了新的 Git 存储库创建(图 37)。The new Git repository creation has been improved by providing users the ability to add a ReadMe file (Figure 37). 向存储库添加自述文件不仅可以帮助其他用户了解基本代码的用途,还可以允许你立即克隆存储库。Adding a ReadMe to the repository not only helps others understand the purpose of the codebase, but also allows you to immediately clone the repository.

Add a ReadMe file
(图 37)添加自述文件(Figure 37) Add a ReadMe file

生成改进 Build Improvements

在此版本中,我们增加了日志大小、添加了 Java 生成模板,以及改进了用于命名数个更改的 Xamarin 支持。In this release, we’ve increased the size of the logs, added Java build templates, and improvements to our Xamarin support to name a few changes.

重新设计了生成队列选项卡Redesigned build queue tab

我们已为显示较长“排队的生成”和“正在运行的生成”列表的“排队生成”页面采用了新的设计,使其更加直观*(图 38)*。We've implemented a new design for the Queued builds page that shows a longer list of queued and running builds, and in a more intuitive fashion (Figure 38).

Build queue tab
(图 38)生成队列选项卡(Figure 38) Build queue tab

有关详细信息,请参阅管理生成系统For more information, see Administer your build system.

启用生成结果扩展,以指定顺序和列Enable build result extensions to specify order and column

生成结果部分扩展现在可以指定显示的列以及显示它们的顺序(图 39)。Build result section extensions can now specify which column and the order in which they appear (Figure 39). 结果视图有两个列,且所有扩展将默认位于第一列中。The result view has two columns, and all extensions will be in the first column by default. 注意:所有第三方扩展将出现在我们包含的生成结果部分之后。Note: All third-party extensions will appear after the build result sections we include.

Build order and column
(图 39)生成顺序和列(Figure 39) Build order and column

生成行号Build to line number

现在可以从生成错误跳转到导致该错误的代码行。Now you can jump from a build error to the line of code that caused it. 查看我们内部用作拉取请求策略的主生成上的最新错误时,可以看到*(图 40)*:Looking at the latest error on the primary build we use as a pull request policy internally, you see this (Figure 40):

Build to line number
(图 40)生成到行号(Figure 40) Build to line number

生成日志视图支持更大的日志Build log view supports much larger logs

以前的日志视图最多只支持 10,000 行。The previous log view only supported logs up to 10,000 lines. 新的查看器基于 VS Code 中使用的 Monaco 编辑器,并将最多支持 150,000 行。The new viewer is based on the Monaco editor used in VS Code and will support logs up to 150,000 lines.

Java 生成模板Java build templates

我们已通过对 Ant、Maven 和 Gradle 添加生成模板,使 Java 开发人员可以更轻松地入门生成*(图 41)*。We’ve made it even easier for Java developers to get started with build by adding build templates for Ant, Maven, and Gradle (Figure 41).

Java build templates
(图 41)Java 生成模板(Figure 41) Java build templates

有关模板的详细信息,请参阅生成步骤For more information on templates, see Build steps.

Xamarin 生成任务Xamarin build tasks

我们对 Xamarin 支持进行了一些重要改进:We made some significant improvements to our Xamarin support:

Xamarin 许可证步骤不再是必需的步骤,已从生成模板中将其删除。The Xamarin License step is no longer necessary and has been removed from the build templates. 作为此项操作的一部分,我们也将弃用此任务。As part of this effort we will also deprecate the task. 应将使用此任务的所有生成定义更新为删除此任务,以防止在最终删除此任务时发生任何中断。All build definitions that use this task should be updated to remove it in order to prevent any disruption when the task is finally removed.

最后,增强了 Xamarin 生成定义模板以使用这些新任务。Finally, the Xamarin build definition templates were enhanced to use these new tasks. 构建 Xamarin 应用Build your Xamarin app.

适用于生成和发布管理的 Docker 集成Docker integration for build and release management

利用生成功能来生成 Docker 映像并将其上传到 Docker 中心,作为持续集成流的一部分(图 42)。Take advantage of the build capabilities to build your Docker images and upload them to the Docker Hub as part of your continuous integration flow (Figure 42). 然后,将这些图像部署到大量 Docker 主机,作为 Release Management 的一部分。Then, deploy those images to a number of Docker hosts as part of Release Management. Marketplace 扩展 添加使用 Docker 所必需的所有服务终结点类型和任务。The Marketplace extension adds all the service endpoint types and tasks necessary for you to work with Docker.

Docker images
(图 42)Docker 映像(Figure 42) Docker images

拉取请求视图中的 SonarQube 结果SonarQube results in pull request view

如果运行以合并拉取请求的生成包含 SonarQube MSBuild 任务,将看到新代码分析问题作为讨论注释在拉取请求中出现(图 43)。If the build run to merge a pull request contains SonarQube MSBuild tasks, you will now see new code analysis issues as discussion comments in the pull request (Figure 43). 这种体验适用于为其在 SonarQube 服务器上安装了插件的任何语言。This experience works for any language for which a plug-in is installed on the SonarQube server. 有关详细信息,请参阅 SonarQube 代码分析问题集成到拉取请求博客文章。For more information, see the SonarQube Code Analysis issues integration into Pull Requests blog post.

SonarQube pull requests
(图 43)SonarQube 拉取请求(Figure 43) SonarQube pull requests

为生成定义配置状态 API 报告Configure status API reporting for a build definition

你现在可以选择哪些生成定义将其状态报告回 Git 状态 API。You can now choose which build definitions report their status back to the Git status API. 如果你有许多生成给定存储库或分支的定义,但只有一个代表实际运行状况的定义时,这特别有用。This is particularly useful if you have many definitions that build a given repository or branch, but only have one that represents the real health.

有关详细信息,请参阅生成 REST API 参考For more information, see the Build REST API reference.

在团队聊天室生成 vNext 支持Build vNext support in team rooms

始终可以在团队聊天室中添加 XAML 生成的通知。It has been always possible to add notifications of XAML builds in the team room. 用户通过此冲刺 (sprint) 还可以接收来自生成 vNext 完成的通知。With this sprint, users can also receive notifications from Build vNext completions.

启用 Git CI 触发器的路径筛选器Enable path filters for Git CI triggers

托管的 Git 存储库的 CI 触发器可以包括或排除某些路径。CI triggers for hosted Git repositories can include or exclude certain paths. 这使得能够将生成定义配置为仅在特定路径中的文件更改后运行*(图 44)*。This enables you to configure a build definition to run only when files in specific paths have changed (Figure 44).

Git CI Triggers
(图 44)Git CI 触发器(Figure 44) Git CI Triggers

Release Management 改进 Release Management Improvements

自 Team Foundation Server 2015 中引入了基于集成式 Web 的 Release Management 以来,我们在此版本中进行了几处功能增强。Since the introduction of integrated web-based Release management in Team Foundation Server 2015, we have made several enhancements in this version.

克隆、导出和导入发布定义Clone, export, and import release definitions

我们结合了发布中心内克隆、导出和导入发布定义的功能,无需安装扩展*(图 45)*。We have incorporated the ability to clone, export, and import release definitions within Release hub, without requiring installation of an extension (Figure 45).

Clone and export commands on release summary page
(图 45)发布摘要页上的克隆和导出命令(Figure 45) Clone and export commands on release summary page

有关详细信息,请参阅克隆、导出和导入发布定义文档。For more details, see Clone, export, and import a release definition documentation.

“发布摘要”中显示的测试结果Test results displayed in the release summary

在“发布摘要”页中,我们为外部服务启用了贡献点以显示特定于环境的信息。In the release summary page, we have enabled a contribution point for an external service to show environment-specific information.

在 Team Services 中,此功能用于显示测试作为发布环境的一部分运行时的测试结果摘要*(图 46)*。In Team Services, this functionality is used to display a summary of test results when tests are run as part of a release environment (Figure 46).

Test results displayed in the release summary
(图 46)发布摘要中显示的测试结果(Figure 46) Test results displayed in the release summary

有关详细信息,请参阅了解发布的摘要视图文档。For more details, see Understand the summary view of a release documentation.

向脚本传递 OAuth 令牌Pass OAuth tokens to scripts

如果需要运行在 Team Services 上调用 REST API 的自定义 PowerShell 脚本以创建工作项或查询生成的信息,则需要在脚本中传递 OAuth 令牌。If you need to run a custom PowerShell script that invokes the REST APIs on Team Services, perhaps to create a work item or query a build for information, you need to pass the OAuth token in the script.

配置环境时的新选项允许脚本在环境中作为任务运行以访问当前 OAuth 令牌*(图 47)*。A new option when you configure an environment allows scripts to run as tasks in the environment to access the current OAuth token (Figure 47).

Pass OAuth tokens to scripts
(图 47)向脚本传递 OAuth 令牌(Figure 47) Pass OAuth tokens to scripts

有关详细信息,请参阅环境的常规选项文档。For more details, see Environment general options documentation.

这是一个显示如何获取生成定义的简单示例*(图 48)*:This is a simple example showing how to get a build definition (Figure 48):

Example script using passed oAuth token
(图 48)使用传递的 oAuth 令牌的示例脚本(Figure 48) Example script using passed oAuth token

部分成功部署上的触发器Trigger on partially successful deployments

生成和发布任务在“控制选项”参数中对每个任务均有“出错时继续”的选项。Build and release tasks have an option to Continue on error in the Control Options parameters for each task.

在生成定义中,这会导致“生成已部分成功”结果(若设置此选项的任务应失败)。In a build definition, this results in a Build partially succeeded result if a task with this option set should fail.

现在,发布定义中提供同一行为。The same behavior is now available in release definitions. 如果任务失败,则整个发布结果将显示为“发布已部分成功”(图 49)If a task fails, the overall release result will show as "Release partially succeeded" (Figure 49).

Release summary shows partially successful releases in orange color
(图 49)发布摘要用橙色表明发布部分成功(Figure 49) Release summary shows partially successful releases in orange color

默认情况下,部分成功的发布将不会自动触发发布到后续环境,即使在环境部署选项中指定了此行为也不会触发。By default, a partially successful release will not automatically trigger a release to a subsequent environment, even if this behavior is specified in the environment deployment options.

但是,可以在每个发布环境中设置新选项(当上一发布已部分成功时,指示 Release Management 触发发布到后续环境)(图 50)However, a new option can be set in each release environment that instructs Release Management to trigger a release to a subsequent environment when the previous release is partially successful (Figure 50).

Setting the option to trigger from a partially successful release
(图 50)设置发布部分成功触发选项(Figure 50) Setting the option to trigger from a partially successful release

有关详细信息,请参阅环境部署触发器文档。For more details, see Environment deployment triggers documentation.

使用直接存储在 GitHub 中的项目Consume artifacts stored in GitHub directly

有时你可能想要直接使用存储在版本控制系统中的项目,而无需通过生成过程传递它们,如本主题所述。Sometimes you may want to consume artifacts stored in a version control system directly, without passing them through a build process, as described in this topic.

如果代码存储在 GitHub 存储库中,那么现在可以执行同一操作*(图 51)*。You can now do the same if your code is stored in a GitHub repository (Figure 51).

Linking code in a GutHub repository to a release definition
(图 51)将 GutHub 存储库中的代码链接到发布定义(Figure 51) Linking code in a GutHub repository to a release definition

有关详细信息,请参阅 TFVC、Git 和 GitHub 源文档。For more details, see TFVC, Git, and GitHub sources documentation.

使用 ARM 的 Web 应用部署Web App Deployment using ARM

有新版本的 Azure Web 应用部署任务,称为 AzureRM Web 应用部署A new version of the Azure Web App Deployment task is available, called AzureRM Web App Deployment.

它使用 MSDeploy 和 Azure 资源管理器服务终结点连接。It uses MSDeploy and an Azure Resource Manager service endpoint connection. 除了基于 ASP.NET 4、Node 和 Python 的 Web 应用之外,使用此任务还可以部署 Azure Web 作业和 Azure API 应用。Use this task to deploy Azure Web Jobs and Azure API apps, in addition to ASP.NET 4, Node, and Python based web apps.

此任务还支持常见发布选项,例如保留应用数据、使应用脱机和删除目标处的其他文件等功能。The task also supports common publishing options such as the ability to retain app data, take an app off-line, and remove additional files at the destination.

更多功能(如配置转换)可能会在即将推出的版本中出现*(图 52)*。More features, such as configuration transformations, may appear in forthcoming versions (Figure 52).

Web app deployment using ARM
(图 52)使用 ARM 的 Web 应用程序部署(Figure 52) Web app deployment using ARM

任务组Task groups

通过“任务组”可将已在生成或发布定义中定义的一系列任务封装到可添加到生成或发布定义的单个可重用任务中,如同任何其他任务一样(图 53)。A task group lets you encapsulate a sequence of tasks already defined in a build or a release definition into a single reusable task that can be added to a build or release definition just like any other task (Figure 53).

可选择从封装任务提取参数作为配置变量,并提取任务信息的剩余部分。You can choose to extract the parameters from the encapsulated tasks as configuration variables, and abstract the rest of the task information.

新任务组将自动添加到任务目录,并准备好添加到其他发布和生成定义中。The new task group is automatically added to the task catalogue, ready to add to other release and build definitions.

Linking code in a GutHub repository to a release definition
(图 53)将 GutHub 存储库中的代码链接到发布定义(Figure 53) Linking code in a GutHub repository to a release definition

有关详细信息,请参阅任务组文档。For more details, see Task Groups documentation.

发布的软删除Soft delete of releases

删除发布或保留策略自动将其删除时,该发布会从概述和详细信息列表中删除。When you delete a release, or it is automatically deleted by a retention policy, the release is removed from the overview and details lists.

但是,在它被永久删除之前将会在发布定义中保留一段时间(通常为 14 天)。However, it is retained with the release definition for a period (typically 14 days) before it is permanently deleted.

在此期间,该发布将显示在概述和详细信息列表的“已删除”选项卡上。During this period, it is shown in the Deleted tab of the overview and details lists.

可通过打开快捷键菜单并选择“撤消删除”来还原这些发布*(图 54)*。You can restore any of these releases by opening the shortcut menu and choosing Undelete (Figure 54).

Undelete releases
(图 54)撤消删除发布(Figure 54) Undelete releases

有关详细信息,请参阅还原删除的发布文档。For more details, see Restore deleted releases documentation.

为每个环境保留发布和生成Retain releases and builds for each environment

发布定义的发布保留策略确定链接到它的发布和生成的保留时间。The release retention policy for a release definition determines how long a release and the build linked to it are retained.

默认情况下,发布将保留 60 天 - 将自动删除在此期间尚未部署或修改的发布。By default, a release is retained for 60 days - releases that have not been deployed or modified during that time will automatically be deleted.

但是,你可能想要保留更多已部署到特定环境的发布(如你的生产环境),或让其保留的时间长于刚部署到其他环境中的发布(如测试、暂存和 QA)。However, you may want to retain more releases that have been deployed to specific environments, such as your production environment, or retain them longer than those that were just deployed to other environments such as test, staging, and QA.

如果需要重新部署该发布,还可将链接到发布的生成保留与发布同样的时间,以确保项目可用*(图 55)*。You can also retain the build linked to a release for the same period as the release to ensure that the artifacts are available if you need to redeploy that release (Figure 55).

Retain releases
(图 55)保留发布(Figure 55) Retain releases

有关详细信息,请参阅发布和生成保留文档。For more details, see Release and build retention documentation.

链接的项目改进Linked artifact improvements

两个新功能使得能够更轻松地处理项目和项目源:Two new features make it easier to work with artifacts and artifact sources:

  • 可将多个项目源链接到一个发布定义(图 56)。You can link multiple artifact sources to a release definition (Figure 56). 每个项目都将下载到名为源别名的代理上的文件夹中。Each of the artifacts is downloaded into a folder on the agent called the source alias. 现在可以编辑链接项目的源别名。You can now edit the source alias of a linked artifact. 例如,更改生成定义的名称时,可编辑源别名来反映生成定义的名称。For example, when you change the name of the build definition, you can edit the source alias to reflect the name of the build definition.
Linked artifact improvements
(图 56)链接项目改进(Figure 56) Linked artifact improvements
For more details, see [Artifact source alias]( documentation.
  • 公开了许多 Build.* 格式(如 Build.BuildId 和 Build.BuildNumber)的变量以用于任务参数。A number of variables of the format Build.* (such as Build.BuildId and Build.BuildNumber) are exposed for use in task parameters. 当多个源与一个发布相关联时,现在将使用你指定为主源的项目源中的值来填充这些变量。When multiple sources are associated with a release, these variables are now populated with values from the artifact source you specify as the primary source. 有关详细信息,请参阅项目变量文档。For more details, see Artifact variables documentation.

部署 - 手动干预任务Deployment - Manual Intervention task

现在,可以在部署到环境的过程中暂停执行。You can now pause execution during deployment to an environment.

在环境中包括手动干预任务让你能够暂时停止部署、执行手动步骤,然后继续进一步的自动步骤。Including a Manual Intervention task in an environment enables you to temporarily halt a deployment, perform manual steps, and then resume further automated steps.

手动干预后,还可拒绝部署和阻止进一步执行步骤*(图 57)*。You can also reject the deployment and prevent further steps from executing after a manual intervention (Figure 57).

Manual intervention task
(图 57)手动干预任务(Figure 57) Manual intervention task

有关详细信息,请参阅手动干预文档。For more details, see Manual intervention documentation.

SQL 数据库部署任务脚本SQL Database deployment task scripts

增强了 Azure SQL 数据库部署(图 58)任务以针对 Azure SQL 数据库运行 SQL 脚本。The Azure SQL Database Deployment (Figure 58) task has been enhanced to run SQL scripts against an Azure SQL Database. 这些脚本可作为文件或任务中的内联提供。The scripts can be provided as a file, or inline within the task.

SQL database deployment task scripts
(图 58)SQL 数据库部署任务脚本(Figure 58) SQL database deployment task scripts

发布定义摘要 - 仪表板小组件Release definition summary - dashboard widget

将发布定义固定到仪表板 - 制作对你的所有团队可见的发布摘要的一个简易方法。Pin a release definition to the dashboard - an easy way to make a summary of releases for that definition visible to all your team.

有关详细信息,请参阅 将发布信息添加到仪表板文档。For more details, see Add release information to the dashboard documentation.

在某个特定时间将发布提升到某个环境Promote releases to an environment at a specific time

希望你的全部生产部署在午夜进行?Want all your production deployments to happen at midnight? 可以对从其他环境选择了成功部署(或最新部署)的环境配置一个条件,并可在特定时间对其部署*(图 59)*。You can configure a condition on an environment that selects a successful deployment (or just the latest one) from another environment, and deploys it at the specified time (Figure 59).

Schedule release to an environment
(图 59)计划发布到环境(Figure 59) Schedule release to an environment

基于多个环境中的条件部署Deploy based on conditions in multiple environments

直到上一版本前,你可以进行并行部署(_分叉_部署),但是不能根据多个环境的状态开始部署到环境(_联接_部署)。Until the previous version, you could do parallel deployments (forkdeployments), but you could not start a deployment to an environment based on the status of multiple environments (join deployments). 你现在可以实现此操作。Now you can.

有关详细信息,请参阅 并行分叉和联接部署文档。For more details, see Parallel forked and joined deployments documentation.

适用于 Release Management 的 REST APIREST APIs for release management

你可以使用 Release Management 的 REST API 服务来创建发布定义和发布,并管理部署发布的多个方面。You can use the REST APIs for the Release Management service to create release definitions and releases, and manage many aspects of deploying a release.

有关详细信息,请参阅 API 参考文档For more information, see the API reference documentation. 你将在本博客文章使用 ReleaseManagement REST API 中找到使用 API 的一些基本示例。You'll find some basic examples that use the APIs in this blog post, Using ReleaseManagement REST API’s.

服务挂钩集成Service hooks integration

在创建新发布、启动或完成部署或审批处于挂起或完成状态时发送发布通知。Send release notifications when new releases are created, deployments are started or completed, or when approvals are pending or completed. 与第三方工具(如 Slack)集成以接收此类通知。Integrate with third party tools such as Slack to receive such notifications.

部署到国内 Azure 云Deployment to national Azure clouds

在 Azure 经典服务终结点使用新的环境设置,将特定 Azure 云设为目标,包括预定义的国内云(如 Azure China 云、Azure US Government 云和 Azure German 云)(图 60)Use the new Environment setting in an Azure Classic service endpoint to target a specific Azure cloud, including pre-defined national clouds such as Azure China cloud, Azure US Government cloud, and Azure German cloud (Figure 60).

Deployment to national Azure clouds
(图 60)部署到区域 Azure 云(Figure 60) Deployment to national Azure clouds

有关详细信息,请参阅 Azure 经典服务终结点文档。For more details, see Azure Classic service endpoint documentation.

测试改进 Test Improvements

在 Team Foundation Server 2017 中添加了关键测试改进。Key test improvements have been added in Team Foundation Server 2017.

更新后的测试结果存储架构Updated test result storage schema

在此版本中,我们会将测试结果项目迁移到新的紧凑且高效的存储架构中。In this release, we are migrating the test result artifacts to a new compact and efficient storage schema. 考虑到测试结果是最耗 TFS 数据库中存储空间的内容之一,我们希望转换此功能,降低其在 TFS 数据库的存储占用。Since test results are one of the top consumers of storage space in TFS databases, we expect this feature to translate into reduced storage footprint for TFS databases. 对于从早期版本的 TFS 升级的客户,测试结果将会在 TFS 升级期间迁移到新架构。For customers who are upgrading from earlier versions of TFS, test results will be migrated to the new schema during TFS upgrade. 此升级可能会导致升级时间较长,具体取决于你的数据库中存在多少测试结果数据。This upgrade may result in long upgrade times depending on how much test result data exists in your databases. 建议配置测试保留策略,并等待策略生效,降低测试结果使用的存储空间,这样 TFS 升级会更快。It’s advisable to configure the test retention policy and wait for the policy to kick in and reduce the storage used by test results so that the TFS upgrade will be faster. 在安装 TFS 后,但在升级 TFS 实例前,你可以使用 TFSConfig.exe 工具 来清理测试结果。After installing TFS, but before upgrading the TFS instance, you can use the TFSConfig.exe tool to clean up test results. 有关详细信息,请参阅 TFSConfig.exe 帮助。See TFSConfig.exe help for more details. 如果你不能灵活地配置测试保留或在升级前清理测试结果,请确保对升级窗口进行相应的计划。If you don’t have the flexibility to configure test retention or clean up test results before upgrade, make sure you plan accordingly for the upgrade window. 有关配置测试保留策略的更多示例,请参阅 Team Foundation Server 2015 的测试结果数据保留See Test result data retention with Team Foundation Server 2015 for more examples about configuring test retention policy.

测试中心改进Test Hub improvements

测试中心的测试配置管理Test configuration management in Test Hub

通过在测试中心内添加新的“配置”选项卡,将测试配置管理引入了 Web UI(图 61)。We’ve brought test configuration management to the web UI by adding a new Configurations tab within the Test Hub (Figure 61). 现在,你可以从测试中心内创建和管理测试配置及测试配置变量。Now you can create and manage test configurations and test configuration variables from within the Test hub.

Configurations hub
(图 61)配置中心(Figure 61) Configurations hub

有关详细信息,请参阅创建配置和配置变量For more information, see Create configurations and configuration variables.

将配置分配给测试计划、测试套件和测试用例Assigning configurations to test plans, test suites, and test cases

分配配置变得更轻松 - 可以直接从测试中心内将测试配置分配给测试计划、测试套件或测试用例(图 62)。Assigning configurations just got easier - you can assign test configurations to a test plan, test suite, or test case(s) directly from within the Test hub (Figure 62). 右键单击某个项目,选择“将配置分配到…”,即已完成并开始运行。Right-click an item, select Assign configurations to …, and you’re off and running. 还可以在测试中心内按配置进行筛选*(图 63)*。You can also filter by Configurations in the Test hub (Figure 63).

Assign Configurations
(图 62)分配配置(Figure 62) Assign Configurations
Configurations Filter
(图 63)配置筛选器(Figure 63) Configurations Filter

有关详细信息,请参阅将配置分配到测试计划和测试套件For more information, see Assign configurations to Test plans and Test suites.

查看“测试结果”窗格中的测试计划/测试套件列View test plan/test suite columns in test results pane

我们已向“测试结果”窗格添加了新列,向你显示将根据其执行测试结果的测试计划和测试套件。We’ve added new columns to the Test results pane that show you the test plan and test suite under which the test results were executed in. 当深化了解测试结果时,这些列提供急需的上下文*(图 64)*。These columns provide much-needed context when drilling into results for your tests (Figure 64).

Test Results Pane
(图 64)测试结果窗格(Figure 64) Test results pane
测试中心内和卡片上的测试顺序Ordering of tests in Test Hub & on cards

现在可以从测试中心内对手动测试进行排序(图 65),不考虑包含它们的套件类型:静态、基于要求的或基于查询的套件。You can now order manual tests from within the Test Hub (Figure 65), irrespective of the type of suite in which they’re included: static, requirement-based, or query-based suites. 你可以简单地拖放一个或多个测试或使用上下文菜单来对测试进行重新排序。You can simply drag and drop one or more tests or use the context menu to reorder tests. 完成排序后,可以按“顺序”字段对测试进行排序,然后从 Web 运行程序以该顺序运行它们。Once the ordering is completed, you can sort your tests by the Order field and then run them in that order from the Web runner. 也可以直接在看板上的“用户情景”卡上对测试进行排序(图 66)。You can also order the tests directly on a user story card on the Kanban board (Figure 66). 这将完成手动测试下其中一个长时间挂起的 User Voice 项(具有 495 票)。This completes one of the long-pending user voice items (with 495 votes) under manual testing.

Order tests
(图 65)对测试进行排序(Figure 65) Order tests
Order tests on card
(图 66)在卡上对测试进行排序(Figure 66) Order tests on card
在测试中心内对测试套件进行排序Order test suites in Test Hub

测试团队现在可以根据他们的需要对测试套件进行排序,而在推出此功能以前,套件只能按字母顺序排序。Test teams can now order the test suites as per their needs – prior to this capability, the suites were only ordered alphabetically. 现在,通过使用测试中心的拖/放功能,套件可以在对等套件间重新排序或移动到层次结构中的另一套件(图 67)。Now, using the drag/drop capability in Test hub, suites can be re-ordered among the peer suites or moved to another suite in the hierarchy (Figure 67). 这解决了手动测试/测试用例管理下的 user voice 项。This addresses the following user voice item under manual testing/test case management.

Order Test suites
(图 67)对测试套件进行排序(Figure 67) Order Test suites
作为分配测试人员的一部分的搜索用户功能Search for users as part of assigning testers

作为跨不同中心的新标识选取器控件推出的一部分,在测试中心中,我们也启用了在向测试人员分配一个或多个测试时搜索用户的选项(图 68)。As part of the rollout of new identity picker controls across the different hubs, in Test hub, we have also enabled the option to search for users when assigning testers to one or more tests (Figure 68). 对于拥有较大的团队成员数量,但上下文菜单仅显示有限的条目集的方案来说,此功能非常有用*(图 69)。This is extremely useful in scenarios where the number of team members is large, but the context menu only shows a limited set of entries *(Figure 69).

Search users
(图 68)搜索用户(Figure 68) Search users
Assign Users
(图 69)分配用户(Figure 69) Assign Users
选取要进行测试的生成Pick a build to test with

现在,可以选取想要进行测试的“生成”,然后使用测试中心的“使用选项运行”来启动 Web 运行程序(图 70)。You can now pick the “build” you want to test with and then launch the Web runner, using ‘Run with options’ in Test hub (Figure 70). 运行过程中报告的任何 bug 将自动与所选的生成关联。Any bug filed during the run will automatically be associated with the build selected. 此外,针对该特定生成发布测试结果。In addition, the test outcome is published against that specific build.

Pick a build
(图 70)选取一个生成(Figure 70) Pick a build
使用数据收集器从测试中心启动 Microsoft 测试运行程序客户端Launch Microsoft Test Runner client from Test Hub with data collectors

现可选择数据收集器和数据生成来与测试运行相关联(图 71),并从测试中心以高性能方式启动 Microsoft 测试运行程序 2017(客户端),而无需在 Microsoft 测试管理器客户端中对其配置。You can now choose your data collectors & build to associate with the test run (Figure 71), and launch the Microsoft Test Runner 2017 (client) in a performant way from Test hub, without having to configure them in Microsoft Test Manager client. Microsoft 测试运行程序将在不打开整个 Microsoft 测试管理器 shell 的情况下启动,并在测试执行完成后关闭。The Microsoft Test Runner will be launched without opening the entire Microsoft Test Manager shell and will shut-down on completion of the test execution.

Run with options
(图 71)使用选项运行(Figure 71) Run with options

有关详细信息,请参阅为桌面应用运行测试For more information, see Run tests for desktop apps.

从测试中心选择数据收集器和启动探索运行程序客户端Choose data collectors and launch Exploratory Runner client from Test hub

现在,你可以从测试中心高效地选择你的数据收集器并启动探索运行程序 2017(客户端),而无需在 Microsoft 测试管理器客户端中对其配置。You can now choose your data collectors and launch the Exploratory Runner 2017 (client) in a performant way from Test hub, without having to configure them in Microsoft Test Manager client. 为基于要求的套件调用上下文菜单(图 72)中的“使用选项运行”,并选择需要的探索运行程序和数据收集器。Invoke 'Run with options' from the context menu (Figure 72) for a Requirement based suite and choose Exploratory runner and the data collectors you need. 将采用与上面所述的启动 Microsoft 测试运行程序类似的方法启动探索运行程序。The Exploratory runner will be launched similar to Microsoft Test Runner as described above.

Run with Options - XT
(图 72)使用选项运行 - XT(Figure 72) Run with Options - XT
为跨不同测试套件的测试配置测试结果Configure test outcomes for tests across different test suites

我们现在已增加了为在同一测试计划下的不同测试套件之间共享的测试配置测试结果行为的功能(图 73)。We have now added the ability to configure the behavior of test outcomes for tests shared across different test suites under the same test plan (Figure 73). 如果选择了此选项并设置了某个测试的结果(从测试中心、Web 运行程序、Microsoft 测试运行程序或从看板上的卡中将其标记为通过/失败/已阻止),则该结果将传播给位于同一测试计划下不同测试套件中的所有其他测试,且配置相同。If this option is selected, and you set the outcome for a test (mark it as Pass/Fail/Blocked either from the Test hub, Web runner, Microsoft Test Runner, or from cards on Kanban board), that outcome will propagate to all the other tests present across different test suites under the same test plan, with the same configuration. 用户可以从测试中心测试的测试计划上下文菜单或从看板的测试页面,在通用设置配置对话框中,为特定测试计划设置“配置测试结果”选项。Users can set the “Configure test outcomes” option for a particular test plan either from the Test hub test plan context menu or from the Kanban board test page in the common settings configuration dialog. 此选项默认关闭,需要显式启用它,才能使之生效。This option is turned off by default and you will have to explicitly enable it to take effect.

Configure test outcomes
(图 73)配置测试结果(Figure 73) Configure test outcomes
验证工作项的 bugVerify bugs from work item

现在可通过重新运行识别 bug 的测试来验证 bug(图 74)。You can now verify a bug by re-running the tests which identified the bug (Figure 74). 可从 bug 工作项窗体上下文菜单调用“验证”选项在 Web 运行程序中启动相关测试用例。You can invoke the Verify option from the bug work item form context menu to launch the relevant test case in the web runner. 使用 Web 运行程序执行验证,并直接在 Web 运行程序中更新 bug 工作项。Perform your validation using the web runner and update the bug work item directly within the web runner.

Verify bugs
(图 74)验证 bug(Figure 74) Verify bugs
适用于测试计划/测试套件克隆的 REST APIREST APIs for test plan / test suite clone

我们已添加了用于测试计划克隆和测试套件克隆的 REST API。We've added REST APIs for cloning of test plans and test suites. 你可以在我们的 Team Services 集成网站上的测试管理部分下找到它们。You can find them under the Test Management section on our Team Services Integrate site.

看板卡中的测试进度Test progress from your Kanban cards

现在可以直接从看板上的情景添加、查看测试用例并与其进行交互。You can now add, view, and interact with test cases directly from your stories on the Kanban board. 使用新的“添加测试”菜单选项创建链接测试用例,然后在操作进行时直接从卡片监视状态*(图 75)*。Use the new Add Test menu option to create a linked Test case, and then monitor status directly from the card as things progress (Figure 75).

Inline tests
(图 75)内联测试(Figure 75) Inline tests

使用这项新功能,现在可以直接从看板上的卡片执行以下操作:With this new capability, you can now perform the following actions directly from a card on your board:

  • 添加测试。Add tests.
  • 打开测试。Open tests.
  • 通过从一个用户情景拖/放到另一个来重新设置测试的父级。Reparent a test by dragging/dropping from one user story to another.
  • 使用 CTRL+ 拖/放将同一测试复制到另一个用户情景(适用于同一测试用例测试多个用户情景的方案)。Copy the same test to another user story using CTRL+Drag/Drop (for scenarios where the same test case tests more than one user story).
  • 通过快速将其标记为通过/失败/等更新测试状态。Update the test status by quickly marking it Pass/Fail/etc.
  • 通过在 Web 测试运行程序中启动该测试来运行它,从中你可以使各个步骤通过或失败、归档 bug 等。Run the test by launching it in the Web Test Runner, from which you can pass or fail individual steps, file bugs, etc.
  • 查看汇总状态摘要,该状态指示已通过的测试数量和该情景剩余的测试数量。View a summary of the roll-up status indicating how many tests have passed and how many remain for that story.

如果需要高级测试管理功能(比如分配测试程序、分配配置、集中的参数、导出测试结果等),你可以切换到测试中心,开始使用已自动为你创建的默认测试计划/基于要求的套件。If you need advanced test management capabilities (like assign testers, assign configurations, centralized parameters, exporting test results, etc.), you can then switch over to Test Hub and start using the default test plan/requirement-based suites that have been auto-created for you. 有关详细信息,请参阅添加、运行和更新内联测试For more information, see Add, run, and update inline tests.

从卡片遍历至测试计划/测试套件Traverse to a test plan/test suite from the card

你现在可以在测试创建的位置,直接从看板上的卡片轻松地遍历至基础测试计划/测试套件。You can now easily traverse to the underlying test plan/test suite under which the tests are created, directly from a card on the Kanban board. 单击此链接*(图 76)*会转到测试中心,打开正确的测试计划,然后选择控制这些内联测试的特定套件。Clicking on this link (Figure 76) will take you to the Test hub, open the right test plan, and then select the specific suite that controls those inline tests.

Traverse to plan/suite
(图 76)遍历到计划/套件(Figure 76) Traverse to plan/suite
看板的通用设置配置中的测试页Test page in common settings configuration of Kanban board

使用看板的常用设置配置对话框中的新测试页,在内联测试创建的位置控制测试计划(图 77)。Use the new Tests page in common settings configuration dialog on Kanban board to control the test plan where the inline tests are created (Figure 77). 以前,卡片上创建的任何测试会被自动添加到新创建的测试计划(如果不存在与卡片的区域和迭代路径相匹配的测试计划)。Previously, any tests created on a card would automatically be added to a newly created test plan, provided no test plans existed that matched the area & iteration paths of the card. 现在,你可以通过对你所选的现有测试计划进行配置来替代此行为(然后,所有测试将被添加到之后所选的测试计划)。Now, you can override this behavior by configuring an existing test plan of your choice – all the tests will then be added to the selected test plan going forward. 请注意,仅当测试批注打开时才启用此功能。Note that this functionality is only enabled if the Test annotation is turned on.

Common settings
(图 77)常用设置(Figure 77) Common settings

Web 运行程序增强功能Web runner enhancements

在手动测试过程中添加测试步骤附件Add test step attachments during manual testing

我们已增强了 Web 测试运行程序,可在手动测试过程中添加测试步骤附件(图 78)。We’ve enhanced the Web test runner to give you the ability to add test step attachments during manual testing (Figure 78). 这些步骤结果附件会自动显示在你在会话中归档的任意 Bug 内,并随后显示在“测试结果”窗格中。These step result attachments automatically show up in any bugs you file in the session and subsequently in the Test results pane.

Test Step attachments
(图 78)测试步骤附件(Figure 78) Test Step attachments
Web 运行程序中的屏幕截图、屏幕录制、图像操作日志和系统信息支持(使用 Chrome 浏览器)Screenshot, screen recording, image action log and system info support in Web runner (using Chrome browser)

在 Chrome 中使用 Web 运行程序时,现可截取屏幕截图并对其进行内联批注(图 79)。You can now take screenshots and annotate them inline when you use Web runner in Chrome (Figure 79). 还可以捕获不只 Web 应用,还有桌面应用的点播屏幕录制。You can also capture on-demand screen recordings of not just the web apps, but also your desktop apps. 会自动将这些屏幕截图和屏幕录制添加到当前测试步骤。These screenshots and screen recordings are automatically added to the current Test step. 除了屏幕截图和屏幕录制以外,现在还可以从你的 Web 应用捕获点播图像操作日志。In addition to screenshots & screen recordings, you can also capture on-demand image action log from your web apps. 需要在浏览器窗口上指定捕获操作的位置 - 该窗口(该窗口中打开的任何现有或新选项卡)上的所有操作或你启动的任何新的子浏览器窗口将自动被捕获,并与在 Web 运行程序中测试的测试步骤相关。You need to specify the browser window on which to capture your actions – all actions on that window (any existing or new tabs you open in that window) or any new child browser windows you launch, will automatically be captured and correlated against the test steps being tested in the Web runner. 这些屏幕截图、屏幕录制和图像操作日志将随后被添加到运行期间归档的任何 bug,并被附加到当前测试结果。These screenshots, screen recordings and image action logs are then added to any bugs you file during the run and attached to the current test result. 同样,系统信息数据将作为从 Web 运行程序归档的所有 bug 的一部分自动进行捕获和包含。Similarly, the system information data is automatically captured and included as part of any bugs you file from the Web runner. 所有这些都利用了基于 Chrome 的测试和反馈扩展中的功能。All these leverage the capability from the Chrome-based Test & Feedback extension.

Web runner using Chrome browser
(图 79)使用 Chrome 浏览器的 Web 运行程序(Figure 79) Web runner using Chrome browser

有关详细信息,请参阅在测试过程中收集诊断数据For more information, see Collect diagnostic data during tests.

作为子级归档的 bug - Web 运行程序/测试和反馈扩展Bugs filed as children – Web runner/test & feedback extension

在 Web 运行程序中运行测试时,无论是从板上的卡片启动还是从测试中心内基于要求的套件启动,任何归档的新 Bug 现在都将被自动创建为该用户情景的子级。When running tests in Web runner, launched either from a card on the board or from a requirement-based suite in Test hub, any new bugs filed will now be automatically created as a child to that user story. 同样,如果要从探索测试扩展浏览用户情景,任何归档的新 Bug 也将被创建为该用户情景的子级。Similarly, if you are exploring a user story from the exploratory testing extension, any new bugs you file will also be created as a child to that user story. 这一新行为使情景和 Bug 中的可跟踪性更简单。This new behavior allows for simpler traceability across stories and bugs. 只有在将“常见设置配置”页中的“处理 bug”设置设为“Bug 不出现在积压工作或板上”或“Bug 出现在带有任务的积压工作和板上”时,才适用。This is applicable only if the “Working with bugs” settings in the Common Settings Configuration page is set to “Bugs do not appear on backlogs or board” or "Bugs appear on the backlogs and boards with tasks". 对于“处理 bug”选项的所有其他设置和在某些其他情况下(例如添加到已有定义的父级的现有 bug),将改为创建相关链接。For all other settings for “Working with bugs” option and in certain other scenarios, such as adding to an existing bug that already has a parent defined, a Related link will be created instead.

从 Web 运行程序更新现有 bugUpdate existing bugs from Web runner

除了从 Web 运行程序创建新 bug,现在还可以更新现有 bug(图 80)。In addition to creating new bugs from the Web runner, now you can also update an existing bug (Figure 80). 收集所有诊断数据后,重现步骤和现有会话中的可跟踪性链接将自动添加到现有 bug。All the diagnostic data collected, repro steps, and links for traceability from the current session are automatically added to the existing bug.

Add to existing bug
(图 80)添加到现有 bug(Figure 80) Add to existing bug

测试和反馈扩展 - 增强Test & feedback extension - enhancements

可从 Visual Studio Marketplace 安装基于浏览器的测试和反馈扩展The browser-based Test & Feedback extension can be installed from the Visual Studio Marketplace. 它支持 Visual Studio Team Services 和 Team Foundation Server(2015 或更高版本)。It supports both Visual Studio Team Services and Team Foundation Server (2015 or later).

探索工作项Explore work items

现在,可以对特定的工作项进行探索测试(图 81)。You can now do exploratory testing for a specific work item (Figure 81). 可将选定的工作项与正在进行的测试会话相关联,并从扩展内部查看验收条件和说明。This lets you associate the selected work item with your ongoing testing session, and view the acceptance criteria and description, from within the extension. 还可在存档于所选工作项上的 bug 或任务之间实现端到端可跟踪性。It also creates end-to-end traceability between bugs or tasks that you file on the selected work item. 可直接从工作项或从扩展内部探索工作项:You can explore the work item either directly from a work item, or from within the extension:

• 直接从工作项(图 81):使用上下文菜单中的“执行探索测试”选项,从产品内直接启动特定工作项的探索测试会话。• Directly from a work item (Figure 81): Launch exploratory testing session for a specific work item directly from within the product using the “Do exploratory testing” option in the context menu. 我们已在所有卡片、网格上和测试中心内添加了入口点。We’ve added entry points on all cards, grids, and in the Test hub.

• 在扩展中*(图 82)*:从 XT 会话内搜索工作项,然后将其与正在进行的会话相关联。• Within the extension (Figure 82): Search for a work item from within the XT session and then associate it with the ongoing session.

XT from card
(图 81)工作项中的 XT(Figure 81) XT from work item
Explore work item
(图 82)扩展中的 XT(Figure 82) XT from extension

有关详细信息,请参阅使用测试和反馈扩展探索工作项For more information, see Explore work items with the Test & Feedback extension.

使用测试和反馈捕获图像操作日志、屏幕录制和网页加载数据Capture image action log, screen recordings and web page load data using test & feedback

图像操作日志:扩展还提供了新选项,只需单击一下即可自动添加引导至 bug 的步骤。Image Action Log: The extension gives you a new option to add the steps that lead you to the bug automatically with just one click. 选择“包括图像操作日志”选项(图 83)来捕获鼠标、键盘和触控操作,并将相应的文本和图像直接添加到 bug 或任务中。Select the “Include image action log” option (Figure 83) to capture the mouse, keyboard, and touch actions, and add the corresponding text and images directly into the bug or task.

屏幕录制(即视频):还可以使用扩展捕获点播屏幕录制。Screen recording as video: You can also capture on-demand screen recordings using the extension. 这些屏幕录制不仅可以从 Web 应用捕获,还可以从你的桌面应用捕获。These screen recordings can be captured not just from the web apps, but also your desktop apps. 可使用扩展的“选项”页将扩展配置为自动停止屏幕录制并将其附加到正在归档的 bug。You can configure the extension to automatically stop screen recordings and attach them to a bug being filed using the extension’s “Options” page.

网页加载数据:我们已向扩展添加了新的背景捕获功能 - “网页加载”数据的捕获。Page Load Data: We have added a new background capture capability to the extension – capturing of “web page load” data. “图像操作日志”在背景中以图像形式捕获你在探索 Web 应用时执行的操作,“页面加载”功能自动捕获网页的详细信息以完成加载操作。Just like the “image action log” captured your actions performed on a web app being explored, in the form of images in the background, the “page load” functionality automatically captures details for a web page to complete the load operation. 你现在可以客观地量化 bug 中的慢速,而无需以依赖网页加载的主观/感知慢速。Instead of relying on subjective/perceived slowness of web page load, you can objectively quantify the slowness in the bug now. 报告 bug 后,除平铺视图外,一份详细的报表也会附加到 bug,可以帮助开发人员进行调查的初始设置。Once the bug is filed, in addition to the tile view, a detailed report is also attached to the bug, which can help the developer with their initial set of investigations.

XT Image Action Log
(图 83)XT 图像操作日志(Figure 83) XT Image Action Log
基于图像操作日志数据创建测试用例Create test cases based on image action log data

在探索会话期间创建测试用例时,包含图像的测试步骤会自动填充(图 84)。When you create test cases during your exploratory session, the test steps with images are automatically filled in for you (Figure 84). 同步测试设计和测试执行是真正探索测试的基础,而这项新功能使之成为现实。Simultaneous test design and test execution is the basis of true exploratory testing, and this new capability makes this a reality. 可以编辑捕获的文本、添加所需的结果、取消选中不相关的行并将其保存用于即将到来的测试轮次/运行。You can edit the text captured, add the expected result, uncheck rows not relevant, and save it for upcoming test passes/runs.

XT Create Test Cases
(图 84)XT 创建测试用例(Figure 84) XT Create Test Cases

有关详细信息,请参阅创建基于图像操作日志数据的测试用例For more information, see Create test cases based in image action log data.

探索测试会话见解Exploratory testing session insights

现在可以查看给定时间段内使用测试和反馈扩展创建的已完成探索测试会话(在团队或个人级别)。You can now view the completed exploratory testing sessions, either at a team or individual level, for a given time period created using the Test & Feedback extension. 通过单击 Web 访问中测试中心组内的运行中心中的“最近使用的探索会话”链接可以转到此见解页面。You can get to this insights page by clicking the “Recent exploratory sessions” link in the Runs hub within the Test Hub group in web access. 此新视图可帮助你获得有意义的见解,包括:This new view helps you derive meaningful insights, including:

  • 显示所浏览工作项的分解、创建的工作项、会话所有者,以及在这些会话上所花费的总时间的摘要视图(图 85)。The summary view that shows a breakdown of the work items explored, the work items created, and the session owners, along with the total time spent on these sessions (Figure 85).
  • 可通过浏览的工作项、会话或会话所有者透视或者通过三者均不可透视的分组依据视图。The group-by view that can be pivoted by either explored work-items, sessions, session owners, or none. 对于任何透视,可以查看创建的所有工作项(Bug、任务、测试用例)的列表或将列表的范围缩小到特定工作项类型。For any pivot, you can either view the list of all work items (bugs, tasks, test cases) created or scope the list down to a specific work item type.
  • 根据分组依据视图中所选内容显示信息的详细信息窗格视图。The details pane view that displays information based on selection in the group-by view. 对于选定的透视行(假设浏览的工作项),你可以在详细信息窗格中查看其摘要信息,如总会话数、在这些会话上所花费的总时间、浏览它的会话所有者、针对其创建的 Bug/任务/测试用例,以及它们的状态和优先级。For a selected pivot row (say explored work items), you can view its summary information in the details pane, such as the total number of sessions, the total time spent across these sessions, the session owners who explored it, and the bugs/tasks/test cases created against it, along with their state and priority. 对于选定的工作项行,可以查看其工作项窗体内联并视情况进行相应更改。For a selected work item row, you can view its work item form inline and make changes as appropriate.
XT Session insights
(图 85)XT 会话见解(Figure 85) XT Session insights

有关详细信息,请参阅获取跨探索测试会话的见解For more information, see Get insights across your exploratory testing sessions.

探索测试会话:查看未探索的工作项Exploratory testing sessions: View unexplored work items

除了在“最近探索会话”视图中查看所有探索的工作项的详细信息(按给定的数据范围的所有/我的会话筛选),我们现在还在同一视图中添加了查看所有未探索的工作项的列表(图 86)。In addition to seeing the details of all the explored work items in the “recent exploratory sessions” view, filtered by all/my sessions for a given date range, we have now added the ability to also see a list of all work items that have NOT been explored, in the same view (Figure 86). 通过为你感兴趣的工作项指定共享查询开始,会话页显示来自查询的所有工作项的列表,并对摘要部分中的已探索和未探索项进行了细分。You start by specifying a shared query for work items that you are interested in and the sessions page shows a list of all the work items from the query, with a breakdown of both explored and unexplored items in the summary section. 此外,使用数据透视的“未探索工作项”组可以查看尚未探索的项目列表。In addition, using the “Unexplored Work Item” group by pivot, you can see the list of items that have not been explored yet. 对于跟踪尚未探索或尚未进行 bug 大扫除的情景数量,此功能非常有用。This is extremely useful to track down how many stories have not been explored or gone through a bug-bash yet.

View unexplored WIT
(图 86)查看未探索的 WIT(Figure 86) View unexplored WIT
端到端利益干系人反馈流End to end stakeholder feedback flow
请求反馈Request feedback

具有基本访问级别的用户现在可以使用工作项菜单中的“请求反馈”选项直接从利益干系人针对正在进行或已完成的功能/情景请求反馈(图 87)。Users with basic access level can now request feedback from stakeholders directly for ongoing or completed features/stories using the Request Feedback option in the work item menu (Figure 87). 这将打开请求反馈窗体,可在其中选择要获得其反馈的利益干系人并提供(可选)一组简单的说明,提示希望输入的产品区域。This opens the Request feedback form where you can choose the stakeholders you want feedback from and optionally provide a simple set of instructions prompting for the areas of the product you’d like input. 这会将个人邮件和提供的说明(如有)一起发送给所选利益干系人。This will send off individual mails to the selected stakeholders along with the instructions provided, if any.

XT Feedback Flow
(图 87)XT 反馈流(Figure 87) XT Feedback Flow

有关详细信息,请参阅使用测试和反馈扩展请求利益干系人反馈For more information, see Request stakeholder feedback using the Test & Feedback extension.

提供反馈Provide feedback

利益干系人可通过单击所接收邮件中的“提供反馈”链接来回应反馈请求,其将自动使用所选反馈请求(如果尚未安装,将提示安装扩展)配置测试和反馈扩展(以前称为探索测试扩展)。Stakeholders can respond to the feedback request by clicking the Provide feedback link in the mail they received, which automatically configures the Test & Feedback extension (formerly Exploratory Testing extension) with the selected feedback request (it will prompt to install the extension, if not already installed). 然后,利益干系人可以使用该扩展的完整捕获功能来捕获其发现和以反馈响应/bug/任务工作项的形式来提交反馈意见。Stakeholders can then use the full capture capabilities of the extension to capture their findings and submit their feedback in the form of feedback response/bug/task work items. 此外,利益干系人可以导航到“反馈请求”页在一个位置查看接收到的所有反馈请求。Additionally, stakeholders can navigate to the “Feedback requests” page to view in one place all feedback requests received by them. 从列表中,可选择想要对其提供反馈的反馈请求、通过将其标记为完成或拒绝它们来管理“挂起反馈请求”(图 88),还可通过单击所需单选按钮在不同类型的反馈请求之间切换*(图 89)*。From the list, they can select the feedback request they want to provide feedback on, manage their “Pending feedback requests” (Figure 88) by marking them as complete or by declining them and can switch between different types of feedback requests by clicking on the desired radio button (Figure 89).

Provide feedback link
(图 88)提供反馈链接(Figure 88) Provide feedback link
XT Feedback Flow
(图 89)XT 反馈流(Figure 89) XT Feedback Flow

有关详细信息,请参阅使用测试和反馈扩展提供反馈For more information, see Provide feedback using the Test & Feedback extension.

自发反馈Voluntary feedback

除了上述经请求的流之外,利益干系人还可使用扩展来提供自发反馈(图 90)。In addition to the solicited flow mentioned above, stakeholders can also use the extension to provide voluntary feedback (Figure 90). 他们可以打开扩展、在“连接设置”页中选择“已连接”模式并连接到帐户和他们希望提供反馈的项目/团队。They can open the extension, select the “Connected” mode in the Connection settings page, and connect to the account and Project/Team to whom they wish to provide feedback. 然后,他们可以使用该扩展来捕获其发现和以反馈响应/bug/任务工作项的形式来提交反馈意见。They can then use the extension to capture their findings and submit their feedback in the form of feedback response/bug/task work items.

Voluntary Feedback
(图 90)自发反馈(Figure 90) Voluntary Feedback

有关详细信息,请参阅使用测试和反馈扩展提供自发反馈For more information, see Provide voluntary feedback using the Test & Feedback extension.

自动测试改进Automated testing improvements

生成/发布摘要中“测试”选项卡中的控制台日志和测试持续时间Console logs and test duration in tests tab in build/release summary

将提取在 .trx 文件中捕获的测试结果控制台日志,并将其作为测试结果附件发布(图 91)。Test result console logs that are captured in .trx files are extracted and published as test result attachments (Figure 91). 可选择在“测试”选项卡中预览它们,且无需下载 trx 文件来查看日志。You have an option to preview them in Tests tab, and don't need to download the trx file to view logs anymore.

Console logs and duration
(图 91)控制台日志和持续时间(Figure 91) Console logs and duration
生成的测试趋势小组件Test trend widget for builds

我们向小组件库中添加了新的“测试结果趋势”小组件(图 92)。We have added a new 'Test result trend' widget to the Widget Gallery (Figure 92). 使用此小组件可将生成定义的最多 30 个最新生成的测试结果趋势图表添加到仪表板。Use this widget to add a test result trend chart of up to 30 most recent builds for a build definition to the dashboard. 小组件配置选项可帮助你自定义图表以包含透视(如已通过测试数、未通过测试数、总测试数、通过百分比和测试持续时间)。Widget configuration options can help you customize the chart to include pivots like passed test count, failed test count, total test count, pass percentage, and test duration.

'Test result trend' widget
(图 92)“测试结果趋势”小组件(Figure 92) 'Test result trend' widget
发布环境的测试状态摘要Test status with Release Environment summary

我们建议你使用发布环境来部署应用程序并对其运行测试。It’s a recommended practice to use Release Environments to deploy applications and run tests against them. 在此版本中,我们在“发布”摘要页的“环境”部分集成了发布环境的测试通过率(图 93)。With this release, we have integrated test pass rate of Release Environments in the Environments section of the Release summary page (Figure 93). 如屏幕截图中所示,若某个环境失败,你可以通过查看测试列迅速推断该故障是否由失败的测试导致。As shown in the screenshot, if an Environment has failed, you can quickly infer if the failure is because of failing tests by looking at the Tests column. 你可以在通过率上单击以导航到“测试”选项卡并调查该环境的失败测试。You can click on the pass rate to navigate to the Tests tab and investigate the failing tests for that Environment.

Test status with Release Environment summary
(图 93)发布环境的测试状态摘要(Figure 93) Test status with Release Environment summary
分支和发布环境的自动测试历史记录Automated test history for branches and release environments

它是单个测试在多个分支、环境和配置上运行的通用方案。It’s a common scenario for an individual test to run on multiple branches, environments, and configurations. 当此类测试失败时,识别此次失败是否被包含到开发分支(如主分支)或是否也影响部署到生产环境的发布分支,这一点很重要。When such a test fails, it is important to identify if the failure is contained to development branches like the master branch or if failures are also impacting release branches that deploy to production environments. 现在可以通过查看“结果摘要”页面中的“历史记录”选项卡来显示正在测试的各个分支的测试历史记录(图 94)。You can now visualize the history of a test across various branches that it is testing by looking at the History tab in Result summary page (Figure 94). 同样,通过环境透视进行分组以对其在不同发布环境中运行的测试历史记录可视化。Similarly, you group by the Environment pivot to visualize the history of a test across different Release Environments in which its run.

Test status with Release Environment summary
(图 94)发布环境的测试状态摘要(Figure 94) Test status with Release Environment summary
持续测试的可跟踪性Traceability with continuous testing

用户现在可以直接在仪表板上跟踪其要求的质量(图 95)。Users can now track the quality of their Requirements right on their Dashboard (Figure 95). 针对我们计划的测试用户,我们已有要求质量的解决方案,并且我们将其带给我们遵循持续测试的用户。We already have a solution for Requirements quality for our Planned testing users and we are bringing it to our users who follow Continuous Testing. 用户能够直接链接到自动测试,然后使用仪表板小组件跟踪你想要跟踪的要求质量,并从生成或发布提取质量数据。Users will be able to link automated tests directly to Requirements and then use Dashboard widgets to track the quality of Requirements you are interested in tracking, pulling the Quality data from Build or Release.

Requirement Quality Widget
(图 95)“要求质量”小组件(Figure 95) Requirement Quality Widget
远程测试 - 基于计算机数量分布测试Remote testing – distribute tests based on number of machines

我们让程序集内的测试能够分布给使用运行功能测试任务的远程计算机(图 96)。We have enabled tests from within an assembly to be distributed to remote machines using the Run Functional Tests task (Figure 96). 在 TFS 2015 中,你仅能在程序集级别分布测试。In TFS 2015, you could distribute tests only at the assembly level. 可使用以下任务中的复选框来启用此功能。This can be enabled using the check box in the task as below.

Task Setting
(图 96)任务设置(Figure 96) Task Setting
对 SCVMM 和 VMWare 的自动测试Automated testing for SCVMM and VMWare

用户可以使用 Azure 在云中或使用 SCVMM 或 VMWare 在本地动态设置测试计算机,并使用这些计算机以分布式方式运行自己的测试。Users can dynamically set up test machines in the cloud with Azure, or on premises using SCVMM or VMWare, and use these machines to run their tests in a distributed manner. 用户可以使用其中一种计算机设置任务(Azure、SCVMM 或 VMWare)后接“运行功能测试”任务来运行测试。Users can use one of the machine provisioning tasks— Azure, SCVMM, or VMWare—followed by the Run Functional Tests task to run tests.

Maven 和 Gradle 任务中的 SonarQube 分析SonarQube analysis in Maven and Gradle tasks

现可通过检查“运行 SonarQube 分析”,并提供终结点、SonarQube 项目名称、项目密钥和版本来触发 Maven 和 Gradle 生成任务中的 SonarQube 分析*(图 97)*。You can now trigger a SonarQube analysis in the Maven and Gradle build task by checking 'Run SonarQube Analysis', and providing the endpoint, the SonarQube project name, the project key, and the version (Figure 97).

Run SonarQube Analysis
(图 97)运行 SonarQube 分析(Figure 97) Run SonarQube Analysis

现在还将获得 SonarQube 项目上的链接*(图 98)*。You will also now get a link on the SonarQube project (Figure 98). 可以请求完整的分析,以查看质量要求详细信息;如果不符合这些要求,则可以选择中断生成。You can request a full analysis to see the quality gates details, and choose to break the build if they are not met.

Run SonarQube Analysis
(图 98)运行 SonarQube 分析(Figure 98) Run SonarQube Analysis

有关详细信息,请参阅 Gradle 生成任务现在支持 SonarQube 分析For more information, please see The Gradle build task now supports SonarQube analysis.

Marketplace 改进 Marketplace Improvements

现在,项目集合管理员可以从 Team Foundation Server 浏览到 Visual Studio Marketplace,并在团队项目集合中安装免费扩展。Project collection administrators can now browse to the Visual Studio Marketplace from a Team Foundation Server and install free extensions in a team project collection. 扩展会自动从 Visual Studio Marketplace 下载,上传到 Team Foundation Server,并在所选的团队项目集合中安装*(图 99)*。The extensions are automatically downloaded from the Visual Studio Marketplace, uploaded to the Team Foundation Server, and installed in the selected team project collection (Figure 99).

Install Free Extension
(图 99)安装免费扩展(Figure 99) Install Free Extension

购买并安装付费扩展Purchase and install paid extensions

现在,项目集合管理员可以从 Team Foundation Server 浏览到 Visual Studio Marketplace,购买付费扩展,并在选定的团队项目集合中安装扩展(图 100)。Project collection administrators can now browse to the Visual Studio Marketplace from a Team Foundation Server, buy paid extensions, and install them in a selected team project collection (Figure 100). 管理员可以通过 Azure 订阅为扩展付费,并选择要分配给这些扩展的用户数。The administrator can pay for extensions with an Azure subscription and select the number of users to assign these extensions. 这些扩展会自动从 Visual Studio Marketplace 下载,上载到 Team Foundation Server,并在所选的团队项目集合中安装。These extensions are automatically downloaded from the Visual Studio Marketplace, uploaded to the Team Foundation Server, and installed in the selected team project collection.

Purchase Paid Extension
(图 100)购买付费扩展(Figure 100) Purchase Paid Extension

有关详细信息,请参阅获取用于 Team Foundation Server 的扩展文档。For more details, see Get extensions for Team Foundation Server documentation.

管理改进 Administration Improvements

Windows 身份验证Windows Authentication

在早期发布中,配置已加入域的 TFS 部署时,需要为 Windows 身份验证选择 NTLM 或 Negotiate 安全支持提供程序。In previous releases, you needed to decide between NTLM and Negotiate security support providers for Windows Authentication when configuring a domain-joined TFS deployment. 在 2017 中,我们从配置体验中删除了此设置。In 2017, we removed this setting from the configuration experience. 如果想在 2017 中继续使用 NTLM 身份验证,无需采取任何措施。If you want to continue using NTLM authentication in 2017, you do not need to take any action. 如果一直都在使用 Kerberos 身份验证,并想在 2017 中继续使用,无需采取任何措施。If you had been using Kerberos authentication and want to continue doing so in 2017, you do not need to take any action. TFS 2017 现在始终按此顺序配置 Negotiate 和 NTLM 安全支持提供程序。TFS 2017 now always configures both the Negotiate and NTLM security support providers, in that order. 采用此配置后,会尽可能使用 Kerberos 身份验证,以提高安全性。With this configuration, Kerberos authentication will be used where possible, providing enhanced security. 无法使用 Kerberos 时,将使用 NTLM 身份验证。When Kerberos cannot be used, NTLM authentication will be used. 我们进行了广泛测试,确保使用 NTLM 身份验证时不会因这种改变而对现有 TFS 部署产生任何影响。We did extensive testing to ensure that there would not be any impact on existing TFS deployments using NTLM authentication due to this change.

新式导航体验A Modern navigation experience

在此版本中,我们启用了新的和改进的顶部导航栏。In this release, we are enabling a new and improved top navigation bar. 对新的导航栏有两个核心目标:There are two core goals for the new nav:

  • 通过一次单击,快速允许你访问任何中心,从而提高了跨产品区域的导航效率。Increase navigation efficiency across product areas by quickly allowing you access any of the hubs with one click.
  • 为产品带来现代视觉审美和用户体验。Bring a modern visual aesthetics and user experience to the product.

因为对用户来说,这是一项较大的更改,且该功能仍在迭代中,所以我们决定将新的导航 UX 在默认情况下设为关闭状态。Since this is a big change for our users, and the feature is still being iterated on, we decided to have the new navigation UX off by default. 如果你想要尝试新的导航,可以通过转至 Team Foundation Server 管理区域控制面板并选择“打开新的导航”来启用它。If you want to play with it, you can enable it by going to the Team Foundation Server admin area Control Panel and choosing to “Turn on new navigation”. 请注意,这将对服务器中的所有用户启用。Please note that will enable it for all users in the server.

团队项目重命名权限Team project rename permission

控制哪些用户可以重命名团队项目的权限已更改。The permission controlling which users can rename a team project has changed. 以前,具有团队项目的编辑项目级信息权限的用户可以对其重命名。Previously, users with Edit project-level information permission for a team project could rename it. 现在通过新的重命名团队项目权限,可以授予或拒绝用户重命名团队项目的能力。Now users can be granted or denied the ability to rename a team project through the new Rename team project permission.

管理设置工作中心Admin settings Work hub

我们在管理设置页中引入了新的“工作”中心,将常规设置(图 101)、迭代和区域合并在单个选项卡内。进行此更改后,用户将看到项目级别设置和团队设置之间的明显区别。We've introduced a new "Work" hub in the Admin settings page that combines general settings (Figure 101), Iterations, and Areas in a single tab. With this change, users will see clear differences between project-level settings and team settings. 对于团队设置,用户将只看到与其团队相关的区域和迭代。For team settings, users will only see areas and iterations that are relevant to their team. 在项目级别中,设置页将使管理员能够管理整个项目的区域和迭代。At a project level, the settings page will enable admins to manage areas and iterations for the entire project. 此外,对于项目区域路径,已增添了一个名为“团队”的新列,便于管理员轻松快速明确哪些团队选择了特定区域路径。Additionally, for project area paths, a new column called "Teams" has been added to make it convenient for admins to tell quickly and easily which teams have selected a specific area path.

Admin work hub
(图 101)管理工作中心(Figure 101) Admin work hub

进程配置 REST APIProcess configuration REST APIs

此公共 API 使用户能够获得给定项目的进程配置。This public API allows users to get the process configuration of a given project. 进程配置包含以下设置:The process configuration contains the following settings:

  • __TypeFields:__在敏捷工具中使用的可自定义字段的抽象概念。TypeFields: abstractions of customizable fields that are used in the agile tooling. 例如,“情景点”字段的类型为“Effort”。For example, the type of the "Story points" field is "Effort".
  • __积压工作定义:__定义位于每个积压工作上的工作项类型。Backlog definitions: define what work item types are on each of the backlogs. 这是从客户生成扩展经常请求的 API。This is a frequently requested API from customers building extensions. 借助此数据,扩展可以知道如何利用特定于进程的字段在敏捷工具中启用常见方案(如更改工作项的活动或工作量、了解给定积压工作级别中包括的工作项或确定按区域路径还是自定义字段标识团队)。With this data, an extension can know how to leverage process-specific fields to enable common scenarios in the agile tools (such as changing the activity or effort of a work item, knowing what work items are included at a given backlog level, or determining whether teams are identified by area path or a custom field). 有关详细信息,请参阅 工作概述Please refer to Work Overview for more information.

Team Foundation Server 2017 引入了管理组和组成员资格的新体验。Team Foundation Server 2017 introduces a new experience to manage groups and group membership. 你可以使用用户/组名称的基于前缀的搜索条件在 Active Directory 或本地计算机用户/组中搜索。You can search in active directory or local machine users/groups using prefix based search criteria on user/group name(s). 例如,“John D”和 samaccountname(例如“businessdomain\johbdnd”并查看用户/组的联系人卡片。For example, 'John D' as well as samaccountname (e.g. 'businessdomain\johbdnd') and see the contact card of a user/group.

用户安全性设置User security settings

可以在新的“我的安全”体验中管理个人访问令牌和 SSH(图 102)。You can manage your personal access tokens and SSH in the new "My Security" experience (Figure 102). 使用“我的配置文件”管理 SSH 的用户,现在需要在用户安全性设置中管理 SSH 公钥*(图 103)*。Users who were using "My Profile" to manage SSH will now need to manage their SSH public keys in the user security settings (Figure 103).

My security
(图 102)我的安全性(Figure 102) My security
My profile
(图 103)我的配置文件(Figure 103) My profile

统一配置向导Unified configuration wizard

在早期的版本中,你会根据想要尝试的操作为你的 TFS 部署选取多个配置向导之一 - 基本和完整向导可用于配置新部署;更新部署可用于生产和预生产升级;应用层专用向导可用于各种方案,包括扩展现有部署、将应用层替换为新硬件等。In previous releases, you would pick one of multiple configuration wizards for your TFS deployment depending on what you were trying to do – the Basic and Full wizards could be used to configure a new deployment; the Upgrade wizard could be used for production and pre-production upgrades; and the Application-Tier Only wizard could be used for a variety of scenarios, including scaling out an existing deployment, replacing an application tier with new hardware, and so forth. TFS 2017 中,所有这些方案被统一为单个服务器配置向导,通过要求你作出简单的选择来指导你完成每个方案。In TFS 2017, all of these scenarios have been unified into a single Server Configuration Wizard, which guides you toward and then through each of these scenarios by asking you to make simple choices. 此外,高级配置(如预生产升级和克隆现有部署)现在自动化操作(过去通过 tfsconfig.exe 完成),包括更改服务器 ID、重新映射数据库连接字符串以及删除对外部依赖项的引用(过去通过 tfsconfig.exe PrepareClone 完成)。Additionally, advanced configurations like pre-production upgrades and clone existing deployment now automate actions which used to be done via tfsconfig.exe, including changing server IDs, remapping database connection strings, and removing references to external dependencies (which used to be done with tfsconfig.exe PrepareClone).

新的访问级别New access level

新 Visual Studio Enterprise 组添加到 Team Foundation Server 的“访问级别”管理门户后,可以快速确定拥有 Visual Studio Enterprise 订阅的用户。With the new Visual Studio Enterprise group added to the Access Level admin portal in Team Foundation Servers, you can now quickly identify who has a Visual Studio Enterprise subscription. 确定后,对于从 Visual Studio Marketplace 安装的所有第一方 TFS 扩展,这些用户将获得完全访问权,无需支付额外费用。Once identified, these users will gain full access to all first party TFS extensions installed from the Visual Studio Marketplace at no additional charge.

个人访问令牌 Personal Access Tokens

除了 SSH 外,现在可以使用个人访问令牌连接到任何 Team Foundation Server(图 104)。You can now connect to any Team Foundation Server using a personal access token in addition to SSH (Figure 104). 如果你在 Linux 或 Mac 上进行开发并希望在任何自动化工具和 GIT 中使用,此功能非常有用。This is helpful if you develop on Linux or Mac and would like to use in any automation tools and GIT. 你可以在用户安全性设置页面管理你的个人访问令牌。You can manage your personal access tokens from the user security settings page.

Personal Access Tokens
(图 104)个人访问令牌(Figure 104) Personal Access Tokens

已知问题 Known Issues

这是此发布中已知问题的完整列表。This is a complete list of known issues in this release.

没有适用于 Team Foundation Server 2017 的 Power ToolsThere are no Power Tools for Team Foundation Server 2017

  • 问题:Issue:

    未发布适用于 TFS 2017 的 Power Tools。No Power Tools have been released for TFS 2017.

  • 解决方法:Workaround:

    非常高兴通知你,已将大多数之前的 Power Tools 集成到 TFS 2017。We are excited to let you know that most of the previous Power Tools have been integrated into TFS 2017. 未集成过程模板编辑器,但可以在 Visual Studio Marketplace 中获取该编辑器。The Process Template Editor is one that has not been integrated, but you can get it in the Visual Studio Marketplace.

更新自定义控件扩展Updating custom control extensions

导入工作项类型定义时出错Error when importing work item type definition

  • 问题:Issue:

    导出工作项类型定义,然后导入该定义的安装了工作项页面扩展的客户将看到错误“未声明 ‘LayoutMode’ 属性”。Customers with a work item page extension installed, who export a work item type definition then import that definition, will see an error, “The ‘LayoutMode’ attribute is not declared”.

  • 解决方法:Workaround:

    每次导出工作项类型定义时,都会在 PageContribution 元素上出现额外的 LayoutMode 属性。There is an extra LayoutMode attribute on the PageContribution element each time you export a work item type definition. 导入定义前,搜索 PageContribution 模式并删除 LayoutMode 属性。Before importing the definition, search for the PageContribution mode and remove the LayoutMode attribute. 例如,删除 LayoutMode="FirstColumnWide"。For example, remove LayoutMode="FirstColumnWide".

客户应更新到 Git LFS 1.3.1 版或更高版本Customers should update to Git LFS version 1.3.1 or higher

  • 问题:Issue:

    未来版本中将不再支持早于 1.3.1 的 Git LFS 版本。Git LFS versions before 1.3.1 will not be supported in future releases.

  • 解决方法:Workaround:

    强烈建议使用 Git LFS 的客户更新到 Git LFS 1.3.1 版或更高版本。Customers using Git LFS are strongly encouraged to update to Git LFS version 1.3.1 or higher. LFS 客户端的早期版本与此版 TFS 中的身份验证更改不兼容。Older versions of the LFS client are not compatible with authentication changes in this version of TFS. 为了给客户提供时间进行迁移,我们为 RTW 实施了短期解决方法。In order to give customers time to migrate, we implemented a short-term workaround for RTW. 将会在 Update 1 中删除该解决方法,届时低于 1.3.1 版的 Git LFS 客户端将不再起作用。The workaround will be removed in Update 1, at which point Git LFS clients below 1.3.1 will no longer work.

NuGet 还原未找到存在于 中的包NuGet Restore is not finding packages that exist in

  • 问题:Issue:

    使用 NuGet 3.4.3 或更高版本时,NuGet 还原任务不会还原 中的包,除非它是 NuGet.Config 中的显式源。When using NuGet 3.4.3 or greater, the NuGet Restore task will not restore packages from unless it is an explicit source in the NuGet.Config.

  • 解决方法:Workaround:

    确保 位于 NuGet.Config 中。Ensure is in NuGet.Config.

NuGet 生成和发布任务不进行身份验证NuGet build and release tasks do not authenticate

  • 问题:Issue:

    使用 Team Foundation Server/包管理时,如果代理作为“网络服务”用户运行,则 NuGet 生成和发布任务不会对源进行身份验证,这是生成代理作为服务运行时的默认状态。When using Team Foundation Server / Package Management, NuGet build and release tasks will not authenticate to feeds if the agent is running as a NETWORK SERVICE user, which is the default when the build agent is run as a service. 这是因为 3.5 以前的 NuGet 版本使用用户帐户的凭据(而不是生成任务提供的凭据)运行生成代理。This happens because versions of NuGet before 3.5 use the credentials of the user account running the build agent, not the credentials provided by the build task.

  • 解决方法:Workaround:

    若要借助作为“网络服务”运行的代理,将 NuGet 生成/发布任务与 TFS 源结合使用,必须使用 NuGet 3.5 及更高版本。To use NuGet build/release tasks with TFS feeds using an agent that is running as a NETWORK SERVICE, you must use NuGet 3.5 or higher.

NuGet 生成和发布任务使用代理的凭据NuGet build and release tasks use agent’s credentials

  • 问题:Issue:

    3.5 以前的 NuGet 版本使用用户帐户的凭据(而不是生成任务提供的凭据)运行生成代理。Versions of NuGet before 3.5 use the credentials of the user account running the build agent, not the credentials provided by the build task. 这可能会导致意外访问源或缺乏对源的访问权。This may result in unexpected access or lack of access to feeds.

  • 解决方法:Workaround:

    对 TFS 生成代理使用 NuGet 3.5 或更高版本。Use NuGet 3.5 or higher on TFS build agents.

外部扩展不会在升级 TFS 时自动升级External extensions do not automatically upgrade when upgrading TFS

  • 问题:Issue:

    如果从 Visual Studio Marketplace 下载扩展,则将其发布到 TFS 2015 安装,然后升级到 TFS 2017,该扩展将不会在新版本的扩展发布到 Marketplace 时自动更新。If you downloaded an extension from the Visual Studio Marketplace, published it to your TFS 2015 installation, and then upgraded to TFS 2017, the extension will not be automatically updated when new versions of the extension are published to the Marketplace.

  • 解决方法:Workaround:

    升级到 TFS 2017 后,卸载已在 TFS 2015 中安装的扩展。After upgrading to TFS 2017, uninstall the extensions you had installed in TFS 2015. 然后重新安装最新的扩展。Then reinstall the latest extensions. 在 TFS 2017 中,我们添加了一项功能,用于每天自动检查一次已更新的外部扩展并将其升级。In TFS 2017 we added a feature to automatically check for updated external extensions once a day and upgrade them.

无法在发布定义中运行 Jenkins 队列作业任务The Jenkins Queue Job task cannot be run in release definitions

  • 问题:Issue:

    在发布定义中运行 Jenkins 队列作业任务时,客户会收到 500 服务器错误。When running the Jenkins Queue Job task in a release definition, customers get a 500 server error.

  • 解决方法:Workaround:

    目前,Jenkins 队列作业任务可作为 TFS 生成定义的一部分运行,但对发布定义不适用。Currently, the Jenkins Queue Job task can be run as part of TFS build definitions, but not release definitions. 将在未来版本中添加此功能。This ability will be added in a future release.

需要针对 TFS 2017 DLL 重新生成自定义 TFS 服务器插件Custom TFS server plugins need to be rebuilt against TFS 2017 DLLs

  • 问题:Issue:

    自定义 TFS 服务器插件在升级到 TFS 2017 后无法工作。Custom TFS server plugins do not work after upgrading to TFS 2017.

  • 解决方法:Workaround:

    针对 TFS 2017 程序集重新生成自定义服务器插件。Rebuild your custom server plugins against the TFS 2017 assemblies.

自 TFS 2015 RTM 开始,自定义 TFS 服务器插件的服务器对象模型已更改The Server Object Model for Custom TFS server plugins has changed since TFS 2015 RTM

  • 问题:Issue:

    自定义 TFS 服务器插件无法编译。Custom TFS server plugins do not compile.

  • 解决方法:Workaround:

    按照本篇博客文章中所述修复源代码。Fix up source code as described in this blog post.

使用管理员操作时,将引发异常When using administrator actions, an exception is thrown

  • 问题:Issue:

    在“警报管理”页中,当团队管理员使用“查找特定用户的警报”搜索来查找团队的订阅时,可能会收到异常。In the Alerts Administration page, when Team Administrators use the Find Alerts for a specific user search to find subscriptions for a team, they might get an exception.

  • 解决方法:Workaround:

    • __选项 1:__单击“全部警报”节点,然后将“所有我的团队警报”筛选器设置为显示。Option 1: Click on the All Alerts node and set the All My Teams Alerts filter to show. 这将显示用户有权访问的所有组的全部警报。This will show all alerts for all groups that the user has access to.

    • __选项 2:__如果该组是一个团队,请勿按团队名称进行搜索,而是导航到该团队的“警报管理”页来管理订阅。Option 2: In case the group is a team, instead of searching by team name, navigate to this team’s Alerts Administration page to manage subscriptions.

在 Team Build / Release Management 中使用任务运行功能测试时出现问题Issue using tasks for running functional tests in Team Build / Release Management

  • 问题:Issue:

    在 Team Build / Release Management 中使用任务目录中的“Visual Studio Test Agent Deployment”和“Run Functional Tests”任务运行功能测试 - 该操作当前使用 Agents for Visual Studio 2015 Update 3,且只能用于运行通过 Visual Studio 2013 和 Visual Studio 2015 生成的测试。Running functional tests in Team Build / Release Management using ‘Visual Studio Test Agent Deployment’ and ‘Run Functional Tests’ tasks from the task catalog currently uses Agents for Visual Studio 2015 Update 3 and can only be used to run tests built using Visual Studio 2013 and Visual Studio 2015. 这些任务不能用于运行使用 Visual Studio 2017 RC 生成的测试。These tasks cannot be used for running tests built using Visual Studio 2017 RC. 有关详细信息,请参阅此博客文章For more details, please refer to this blog post.

  • 解决方法:Workaround:

    无解决方法。There is no workaround. 将在 TFS 2017 Update 1 时间范围内添加对以下内容的支持:使用 Test Agent 2017 以及运行通过 Visual Studio 2017 生成的测试。Support for using Test Agent 2017 and running tests built using Visual Studio 2017 will be added in the TFS 2017 Update 1 timeframe.

扩展未自动更新Extensions are not being auto-updated

  • 问题:Issue:

    如果将以前版本的 TFS 升级到 TFS 2017,并在连接模式下运行 TFS 2017,那么扩展将不会按正常情况自动更新。If you upgrade a prior version of TFS to reach TFS 2017 and are running TFS 2017 in connected mode then your extensions will not be auto-updated as they should be.

  • 解决方法:Workaround:

    目前没有解决方法。There is no workaround at this time. 该问题已解决,自动更新行为将通过 TFS 2017 Update 2 实现。We have fixed the issue and the auto update behavior will reach you through TFS 2017 Update 2. 如果由于某种原因等不到 Update 2,请通过支持渠道与我们联系,我们会提前共享该修复程序。If for any reason you cannot wait for Update 2 then reach us through the Support channel and we shall share the fix earlier.

如果遇到阻止你在生产环境 (Go-Live) 中部署的问题,请联系 Microsoft 产品支持If you encounter issues that are preventing you from deploying in a production environment (Go-Live), please contact Microsoft product support. (仅英语)仅限美国营业时间(太平洋标准时间,周一至周五,每天早上 6 点至下午 6 点),1 个工作日内答复。(English only) U.S. business hours only (M-F 6a-6p PST), 1 business day response.

Top of Page