Team Foundation Server 2017 Update 2 发行说明 Team Foundation Server 2017 Update 2 Release Notes


如果正在从一个非英语的语言版本访问此页,并想要查看最新内容,请访问此“发行说明”页(英文版)。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 Update 2 的最新版本的相关信息。In this article, you will find information regarding the newest release for Team Foundation Server 2017 Update 2. 单击此按钮下载。Click the button to download.

Download the latest version of Team Foundation Server

有关其他格式或语言,请参阅下载站点For other formats or languages, please see the download site.

有关 Team Foundation Server 2017 的详细信息,请参阅 Team Foundation Server 要求和兼容性 页。To learn more about Team Foundation Server 2017, see the Team Foundation Server Requirements and Compatibility page.


我们期待你的宝贵意见和建议!We’d love to hear from you! 你可以报告问题并通过开发人员社区门户进行跟踪。You can report a problem and track it through the Developer Community portal. 通过 Visual Studio Team Services 产品更新站点向我们发送建议。Send us your suggestions through the Visual Studio Team Services Product Updates site.

发布日期:2017 年 7 月 24 日Release Date: July 24, 2017

TFS 2017 Update 2 的更新摘要Summary of Updates in TFS 2017 Update 2

我们在 Team Foundation Server 2017 Update 2 中增加了许多新值。We've added a lot of new value to Team Foundation Server 2017 Update 2. 其中一些要点包括:Some of the highlights include:

通过按功能区域查看改进,可以查看所有新功能的详细信息:You can see the details of all the new features by viewing the improvements by feature area:

此版本中的新增功能What's New in this Release

工作项跟踪改进 Work Item Tracking Improvements

工作项类型图标 Work item type icons

我们做出了一个面向全球的承诺,确保客户可以完全访问我们的产品。We have made a global commitment to make our products fully accessible to our customers. 作为该承诺的一部分,我们一直致力于查找和解决存在于从键盘模式到可视化设计和布局等任何位置的许多辅助功能问题。As part of that commitment, we have been working to find and address many accessibility issues – anywhere from keyboard patterns to visual design and layout.

在许多情况下,工作项跟踪仅依赖颜色来传达工作项类型。Work item tracking has relied solely on color in many experiences to convey work item type. 但是,这会对我们的色盲或弱视用户造成困扰,由于颜色的相似性,他们可能无法区分这些工作项。However, this is problematic for our color blind or low vision users who may not be able to distinguish between items due to similarities in color. 为了提高所有客户对工作项类型的可视性,我们在工作项类型视觉对象语言中引入了图标。To increase the scanability of work item type for all our customers, we have introduced icons to the visual language of work item type. 可以通过选择我们的图标库来自定义工作项类型You can customize your work item types by choosing from a selection of our icon library.

表示有关积压工作 (backlog) 和查询网格类型的颜色条已经替换为彩色图标*(图 1)*。Color bars conveying type on the backlog and queries grids have been replaced with colored icons (Figure 1).

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

看板上的卡片现在包含一个类型图标*(图 2)*。Cards on the board now include a type icon (Figure 2).

Board with icon type
(图 2)具有图标类型的板(Figure 2) Board with icon type

交付计划 Delivery Plans

交付计划是一种组织工具,它可以通过在基于迭代的日历上跟踪工作状态来帮助推动跨团队的可见性和一致性。Delivery Plans is an organizational tool that helps you drive cross-team visibility and alignment by tracking work status on an iteration-based calendar. 可以定制计划,将跨项目的任何团队或积压工作 (backlog) 级别包含在帐户中。You can tailor your plan to include any team or backlog level from across projects in the account. 此外,计划上的“字段条件”允许你进一步自定义视图,同时“标记”突出显示重要日期。Furthermore, Field Criteria on Plans enables you to further customize your view, while Markers highlight important dates.

查看交付计划的商城页,以了解详细信息并安装扩展。Check out the marketplace page for Delivery Plans to learn more and install the extension.

如果用户的 TFS 实例 与 Internet 断开连接,可直接通过 Web 访问中的“管理扩展”选项提供交付计划,而无需导航到 VSTS Marketplace。For users with a TFS instance that is disconnected from the Internet, Delivery Plans will be available directly from the Manage extensions option in web access, without navigating to the VSTS Marketplace. 从“管理扩展”,单击“浏览本地扩展”,然后选择“交付计划”并单击“安装”。From Manage extensions, click on Browse local extensions, then select Delivery Plans and click Install. 有关详细信息,请参阅预安装扩展一文。See the documentation on pre installed extensions for more information.

从工作项自动链接到生成Automatic linking from work items to builds

通过在生成定义中使用此新设置,可以跟踪已合并工作的生成,而无需手动搜索大量生成。With this new setting in the build definition, you can track the builds that have incorporated your work without having to search through a large set of builds manually. 与工作项关联的每个成功生成将自动在工作项窗体的开发部分中显示。Each successful build associated with the work item automatically appears in the development section of the work item form.

若要启用此功能,请在生成定义中切换__“选项”__下方的设置*(图 3)*。To enable this feature, toggle the setting under Options in your build definition (Figure 3).

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

弃用旧的工作项窗体Deprecation of old work item form

对新工作项窗体的总体反馈是积极的,并且现在已在我们的托管帐户上完全采用。Overall feedback for the new work item form has been positive and we now have 100% adoption on our hosted accounts. 我们希望本地客户能够利用使我们的 VSTS 用户感到满意的相同功能,因此我们已经决定弃用旧的工作项窗体和旧的扩展性模型。We want on-premises customers to tap into the same value that has delighted our VSTS users and so we have made the decision to deprecate the old work item form and old extensibility model. 请参阅 Microsoft 应用程序生命周期管理页上有关我们计划的详细信息。Read more about our plans on the Microsoft Application Lifecycle Management page.

工作项搜索可跨集合中所有项目提供对所有工作项的快速灵活搜索(图 4)。Work Item Search provides fast and flexible search across all your work items over all projects in a collection (Figure 4). 工作项搜索全文搜索引擎可用于在所有工作项字段中轻松搜索术语,并有效地查找相关工作项。You can use the Work Item Search full text search engine to easily search for terms across all work item fields and efficiently locate relevant work items. 在任何工作项字段上使用嵌入式搜索筛选器,以快速将范围缩小到工作项列表。Use in-line search filters, on any work item field, to quickly narrow down to a list of work items.

在 TFS 中配置搜索服务之后,可以进行搜索而无需安装任何其他程序。Once the Search service is configured in TFS, you can get searching without the need to install anything else. 通过使用工作项搜索,可以执行以下操作:By using Work Item Search you can:

  • 搜索所有项目:在你自己和合作伙伴团队的积压工作 (backlog) 中进行搜索。Search over all your projects: Search in your own and your partner teams' backlog. 在所有工作项中使用跨项目搜索,以在组织的整个工作项中进行搜索。Use cross-project searches over all the work items to search across your organization's entire work items. 通过使用项目和区域路径筛选器来缩小搜索范围。Narrow your search by using project and area path filters.
  • 跨所有工作项字段进行搜索:通过跨所有工作项字段(包括 ere 字段)进行搜索来快速轻松地查找相关工作项。Search across all work item fields: Quickly and easily find relevant work items by searching across all work item fields (including ere fields). 在所有字段中使用全文搜索以有效地查找相关工作项。Use a full text search across all fields to efficiently locate relevant work items. 片段视图将指示找到匹配项的位置。The snippet view indicates where matches were found.
  • 在特定字段中进行搜索:在任何工作项字段上使用快速嵌入式搜索筛选器,在几秒钟内将搜索范围缩小至工作项列表。Search in specific fields: Use the quick in-line search filters, on any work item field, to narrow down to a list of work items in seconds. 建议的下拉列表有助于更快地完成搜索。The dropdown list of suggestions helps complete your search faster. 例如,执行 AssignedTo:Chris WorkItemType:Bug State:Active 搜索将查找分配给名为 Chris 的用户的所有活动 Bug。For example, a search such as AssignedTo:Chris WorkItemType:Bug State:Active finds all active bugs assigned to a user named Chris.
  • 利用与工作项跟踪的集成:工作项搜索接口可与工作中心中的熟悉控件集成,以便用户进行查看、编辑、注释、共享等其他操作。Take advantage of integration with work item tracking: The Work Item Search interface integrates with familiar controls in the Work hub, letting you view, edit, comment, share, and much more.
Workitem search
(图 4)工作项搜索(Figure 4) Workitem search

版本控制改进 Version Control Improvements

新的分支策略配置体验 New branch policies configuration experience

我们已经重新设计了分支策略配置体验并添加了一些出色的新功能(图 5)。We’ve redesigned the branch policies configuration experience and added some great new capabilities (Figure 5). 其中最强大的功能之一是能够为分支文件夹配置策略。One of the most powerful features is the ability to configure policies for branch folders. 可以在“分支”视图中通过选择一个分支文件夹,然后从上下文菜单选择“分支策略”来执行此操作。You can do this from the Branches view by selecting a branch folder and choosing Branch policies from the context menu.

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

这将打开新的策略配置 UX,可在其中配置适用于分支文件夹中所有分支的策略*(图 6)*。This will open the new policies configuration UX, where you can configure policies that apply to all of the branches in the branch folder (Figure 6).

Policies page
(图 6)策略页(Figure 6) Policies page

如果使用的是生成策略,那么现在可以为一个分支配置多个生成。If you’re using the build policy, you can now configure multiple builds for a single branch. 此外,还有新的选项可用来指定自动或手动触发器(图 7)。There are also new options to specify an automatic or manual trigger (Figure 7). 手动触发器对于类似自动测试运行这样可能需要很长时间才能运行的操作非常有用,而且只需要在完成拉取请求之前运行一次。Manual triggers are useful for things like automated test runs that might take a long time to run, and you only really need to run once before completing the pull request. 生成策略还有一个显示名称,如果配置多个生成,该名称将非常有用。The build policy also has a display name that is useful if you’re configuring multiple builds.

Manual build
(图 7)手动生成(Figure 7) Manual build

配置手动触发策略后,可以通过选择__“策略”部分中的“队列生成”__选项运行它来获取拉取请求*(图 8)*。Once you’ve configured a manually triggered policy, you can run it by selecting the Queue build option in the Policies section for the pull request (Figure 8).

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

对于必需的审阅者策略*(图 9),我们为管理员添加了指定注解的功能,以便在应用策略时将该注解追加到拉取请求时间线(图 10)*。For required reviewer policies (Figure 9), we added the ability for administrators to specify a note that will be appended to the pull request timeline when the policy applies (Figure 10).

Required reviewer dialog
(图 9)必需的审阅者对话框(Figure 9) Required reviewer dialog
Required reviewer note
(图 10)必需的审阅者注释(Figure 10) Required reviewer note

适用于非活动注释的新策略New policy for no active comments

确保使用新的注释策略来处理拉取请求中的所有注释。Ensure that all comments in your pull requests are being addressed with the new Comments policy. 启用此策略后,活动注释将阻止 PR 的完成,以强制解决所有注释。With this policy enabled, active comments will block completion of the PR, forcing all comments to be resolved. 那些给 PR 作者留下注释但乐观地批准拉取请求的审阅者可以确信,渴望合并的作者不会错过任何注释。Reviewers that leave comments for the PR author but optimistically approve the pull request can be sure that an author that’s eager to merge won’t miss any comments.

文件中心改进Files hub improvements

我们已经对文件中心进行了一些更新,以改善查看和编辑体验。We’ve made several updates to the Files hub to improve the viewing and editing experiences.

对于查看,我们添加了透视,以便用户可以查看当前文件夹中的“README”(图 11),预览 Markdown 文件,将文件与此前的版本进行比较*(图 12)*,并查看指责。For viewing, we’ve added pivots that let you view the README in the current folder (Figure 11), preview Markdown files, compare a file to a previous version (Figure 12), and view blame.

Files viewing
(图 11)文件查看(Figure 11) Files viewing
Git graph
(图 12)Git 图(Figure 12) Git graph

对于编辑,用户现在可以预览更改,轻松地添加注释,提交到新分支,并链接工作项*(图 13)*。For editing, you can now preview your changes, easily add a comment, commit to a new branch, and link work items (Figure 13).

Files editing
(图 13)文件编辑(Figure 13) Files editing

可视化 Git 存储库 Visualize your git repository

现在可以查看一个图,同时显示存储库或文件的提交历史记录。You can now see a graph while showing commit history for repositories or files. 这使用户可以使用 Git 图为 Git 存储库创建所有分支和提交的心理模型(图 14)。This allows you to easily create a mental model of all your branches and commits for your git repositories using git graph (Figure 14). 此图以拓扑顺序显示所有提交。The graph shows all your commits in topological order.

Git graph
(图 14)Git 图(Figure 14) Git graph

Git 图的关键元素包括*(图 15)*:The key elements of the git graph include (Figure 15):

  1. Git 图为右对齐,因此与默认分支或所选分支关联的提交在右侧显示,而图的其他部分则在左侧显示。the git graph is right-aligned, so commits associated with the default branch or the selected branch appear on the right while the rest of the graph grows on the left.
  2. 合并提交由连接到它们的第一个父级和第二个父级的灰色点表示。merge commits are represented by grey dots connected to their first parent and second parent.
  3. 正常提交由蓝色点表示。normal commits are represented by blue dots.
  4. 如果在接下来的 50 个提交的视图端口中看不到某个提交的父提交,那么我们将删除该提交连接。if the parent commit of a commit is not visible in the view port on the next 50 commits, then we excise the commit connection. 单击箭头之后,该提交就会连接到它的父提交。Once you click the arrow, the commit is connected to its parent commit.
Git graph elements
(图 15)Git 图元素(Figure 15) Git graph elements

在提交上查看 Git 标记 View git tags on commits

如果团队一直使用 Git 标记来标记存储库历史记录中的特定点,那么提交现在将显示已创建的标记。If your team has been using Git tags to mark a specific point in the history of your repository, then your commits will now show the tags that you have created. 用户将可以查看__“提交列表”视图和“详细信息”__页中特定提交的标记*(图 16)*。You will be able view tags (Figure 16) for a specific commit in the commit list view and the details page.

Show tags
(图 16)显示标记(Figure 16) Show tags

将标记添加到提交Add tags to commits

无需从命令行创建标记并将标记推送到存储库,现在只需转到提交然后添加一个标记(图 17)。Instead of creating tags from the command line and pushing the tags to the repository, you can now simply go to a commit and add a tag (Figure 17). 通过标记创建对话框还可以标记存储库上的任何其他引用。The tag creation dialog will also let you tag any other ref on the repo.

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

提交列表视图还支持上下文菜单*(图 18)The commit list view also supports a context menu (Figure 18). 无需转到__“提交详细信息”__页来创建标记,然后创建新分支(图 19)*。No need to go to the commit details page to create tags and create new branches (Figure 19).

Create tag history
(图 18)创建标记历史记录(Figure 18) Create tag history
Tag branch
(图 19)标记分支(Figure 19) Tag branch

更新的变更集页和搁置集页Updated changeset and shelveset pages

我们改进了 TFVC 中的变更集页和搁置集页。We have modernized the changeset and shelveset pages in TFVC. 对于使用辅助技术的用户而言可以更方便地访问这两个页面。Both pages are made more accessible for those of you who use assistive technologies. 这些新页还具有包含变更集标题以及有关变更集的相关信息的新标头,例如作者的详细信息*(图 20)*。The new pages also have a new header that contains the changeset title and associated information about the changeset, such as author details (Figure 20).

Changeset page
(图 20)变更集页(Figure 20) Changeset page

变更集页和搁置集页还托管新的 Markdown 讨论控件(图 21),以便在 markdown、@mention 用户中键入注释,使用 # 关联工作项,并轻松地附加文件和图像。Both changeset and shelveset pages also host the a new markdown discussion control (Figure 21) that will allow to type comments in markdown, @mention users, associate work items using #, and easily attach files and images.

Changeset discussion
(图 21)变更集讨论(Figure 21) Changeset discussion

改进的提交筛选Improved commit filtering

现在可以通过高级筛选选项来筛选提交历史记录结果(图 22)。You can now filter the commit history results (Figure 22) by advanced filtering options. 可以通过以下方式筛选提交:You can filter commits by:

  • 完整历史记录。full history.
  • 使用简化合并的完整历史记录。full history with simplified merges.
  • 第一个父级。first parent.
  • 简单的历史记录(这是默认筛选器设置)。simple history (this is the default filter setting).
Changeset discussion
(图 22)改进的提交筛选(Figure 22) Improved commit filtering

将存储库从 TFVC 导入到 GitImport repositories from TFVC to Git

可以将代码从 TFVC 存储库迁移到同一个帐户中的 Git 存储库。You can migrate code from your TFVC repositories to Git repositories in the same account. 若要开始迁移,请选择存储库选择器下拉列表中的__“导入存储库”__(图 23)To start migration, select import repository from the repository selector drop-down (Figure 23).

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

单独的文件夹或分支可以导入到 Git 存储库,或者可以导入整个 TFVC 存储库(减去分支)(图 24)Individual folders or branches can be imported to the Git repository, or the entire TFVC repository can be imported (minus the branches) (Figure 24). 还可以导入最多 180 天的历史记录。You can also import up to 180 days of history.

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

Git LFS 文件锁定Git LFS file locking

我们已添加 Git LFS 文件锁定功能。We have added the Git LFS file locking feature. 这样,团队就可以使用无法区分的大型文件,以避免在两个或多个用户尝试同时编辑同一个文件时丢失工作。This allows teams working with large, undiffable files to avoid losing work when two or more people attempt to edit the same file at once. 在任何人开始编辑文件之前,他们会使用锁定,这会通知服务器。Before anyone can begin editing the file, they take a lock, which notifies the server. 当其他人尝试采用锁定时,服务器将拒绝该请求,以便让第二位用户知道已经有人在使用该文件。When anyone else attempts to take a lock, the server rejects the request, letting the second person know that someone else is already working on that file. 使用此功能前,请升级到 Git LFS 2.1 或更高版本。Please upgrade to Git LFS 2.1 or higher to use this feature.

Git 提交注释使用新的讨论控件Git commit comments use the new discussion control

已更新 Git 提交上的轻型注释,以便使用新的讨论控件。Lightweight comments left on Git commits has been updated to use the new discussion control. 这在注释中为 Markdown 提供支持,并为 Git 和 TFVC 在 Web 中提供所有代码注释功能,以便使用最新体验。This brings support for Markdown in those comments, and rounds out all of the code-commenting features in the web for both Git and TFVC to use the latest experience.

新的树视图控件New tree view control

拉取请求文件视图、Git 提交详细信息、Git 推送详细信息、TFVC 搁置集详细信息、TFVC 变更集详细信息、TFVC 变更集中心和 Git 历史记录中心已更新,并提供新的树视图控件(图 25)。The Pull Request Files view, Git commit details, Git push details, TFVC Shelveset details, TFVC Changeset details, TFVC Changesets hub and Git history hub have been updated with a new tree view control (Figure 25). 稍微改进了树视图的可用性。The tree view has a few usability improvements. 首先,我们已更改视图以显示自动折叠空文件夹节点的简要树视图,以最大化视图中的文件数。First, we’ve changed the view to show a condensed tree view that automatically collapses empty folder nodes, maximizing the number of files that are in view.

此外,树还可以更紧凑的方式显示注释。The tree also shows comments in a more compact way. 带有注释的文件显示每个注释线程的子项,其中的虚拟形象指示创建该线程的用户。Files with comments show a child item for each comment thread, with the avatar indicating the user that created the thread. 新的注释线程和带有回复的线程由蓝色点表示,并且回复计数通过计数来汇总。New comment threads and those with replies are indicated by the blue dot, and the count of replies is summarized with a count.

New tree view
(图 25)新的树视图(Figure 25) New tree view

拉取请求的改进 Pull Request Improvements

适用于 PR 作者和审阅者的改进的 CTAImproved CTAs for PR author and reviewers

对于使用分支策略的团队来说,在查看拉取请求时,有时很难确切地知道需要执行什么操作。For teams using branch policies, it can sometimes be hard to know exactly what action is required when you view a pull request. 如果对操作的主要调用是“完成”按钮,这是否意味着该请求已经准备好执行完成操作了?If the main call to action is the Complete button, does that mean it’s ready to complete? 使用有关查看配置分支策略的页面和状态的用户信息,PR 视图现在将显示对该用户最有意义的操作的调用。Using information about the person viewing the page and the state of configured branch policies, the PR view will now present the call to action that makes the most sense for that user.

配置策略时(但尚未通过),“完成”按钮(图 26)现在将推荐使用“自动完成”功能。When policies are configured, but aren’t yet passing, the Complete button (Figure 26) will now encourage the use of the Auto-complete feature. 如果策略受阻,则不可能成功地完成 PR,因此我们提供了一个选项,当这些策略最终通过时,它将完成 PR。It’s not likely that you’ll be able to complete the PR successfully if policies are blocking, so we offer an option that will complete the PR when those policies eventually pass.

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

对于审阅者来说,更可能是想要批准一个 PR 而不是去完成它,因此,如果尚未批准,审阅者将会看到__“批准”__按钮*(图27)*突出显示为主 CTA。For reviewers, it’s more likely that you’ll want to approve a PR than complete it, so reviewers will see the Approve button (Figure 27) highlighted as the main CTA if you haven’t approved yet.

CTA approve
(图 27)CTA 批准(Figure 27) CTA approve

获得批准后,在审阅者同时还是完成 PR 的人员的情况下,审阅者将看到“完成”(或“自动完成”)按钮突出显示为 CTA。Once approved, reviewers will see the Complete (or Auto-complete) button highlighted as the CTA for those cases where a reviewer is also the person completing the PR.

可操作注释Actionable comments

在具有多个注释的 PR 中,很难跟踪所有对话。In a PR with more than a few comments, it can be hard to keep track of all of the conversations. 为了帮助用户更好地管理注释,我们简化了解决项目的过程,这些项目已经通过若干增强功能进行处理:To help you better manage comments, we’ve simplified the process of resolving items that have been addressed with a number of enhancements:

  • 在每个 PR 的标头处,现在将看到已解决的注释计数*(图 28)*。In the header for every PR, you’ll now see a count of the comments that have been resolved (Figure 28).
PR header
(图 28)PR 标头(Figure 28) PR header
  • 处理注释后,可以通过单击进行解决*(图 29)*。When a comment has been addressed, you can resolve it with a single click (Figure 29).
Resolve button
(图 29)解决按钮(Figure 29) Resolve button
  • 在解决过程中,如果要添加注释,则可以一次性进行回复并解决*(图 30)*。If you have comments to add while you’re resolving, you can reply and resolve in a single gesture (Figure 30).
Reply and resolve
(图 30)回复并解决(Figure 30) Reply and resolve
  • 解决注释时,将看到计数上升直到处理完所有注释*(图 31)*。As comments are resolved, you’ll see the count go up until everything has been addressed (Figure 31).
Comment count address rate
(图 31)注释计数处理率(Figure 31) Comment count address rate
  • 已改进概述中的筛选器,以通过各种注释状态进行筛选,并显示每个筛选器选项的注释计数。(图 32)The filter in the Overview has been improved to enable filtering by various comment states and to show the count of comments for each filter option (Figure 32).
Filter improvements
(图 32)筛选器改进(Figure 32) Filter improvements

更新视图显示变基和强制推送Updates view shows rebase and force push

在“拉取请求详细信息”视图中,已改进“更新”选项卡来显示何时发生了强制推送以及基提交是否发生了更改(图 33)。In the Pull Request details view, the Updates tab has been improved to show when a force push has occurred and if the base commit has changed (Figure 33). 如果在完成 PR 之前主题分支中的变基发生更改,那么这两个功能将非常有用。These two features are really useful if you rebase changes in your topic branches before completing your PRs. 现在,审阅者将有足够的信息来了解到底发生了什么。Reviewers will now have enough info to know exactly what’s happened.

Updates views
(图 33)更新视图(Figure 33) Updates views

按人员筛选拉取请求Pull request filtering by people

现在更容易查找拉取请求!It’s now easier to find pull requests! 我们添加了新的筛选选项,以便可以找到由特定作者创建或分配给特定的审阅者的 PR(图 34)。We’ve added new filtering options to allow you to find PRs created by a specific author or assigned to a specific reviewer (Figure 34). 只需从作者或审阅者筛选器中选择一个用户,列表将进行更新以显示仅与该筛选器匹配的 PR。Simply select a user from the author or reviewer filter, and the list will be updated to show only the PRs that match the filter.

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

绕过拉取请求策略时所需的理由Reason required when bypassing pull request policies

绕过拉取请求策略时,需要指定原因。When you are bypassing a pull request policies, you are required to specify a reason. 在__“完成拉取请求”对话框中,如果他们选择绕过,则将看到新的“原因”__字段*(图 35)*。In the Complete pull request dialog, you will see a new Reason field, if they choose to bypass (Figure 35).

Bypass dialog
(图 35)绕过对话框(Figure 35) Bypass dialog

输入原因并完成拉取请求后,该消息将在__“概述”__中显示*(图 36)*。After entering the reason and completing the pull request, the message will be displayed in the Overview (Figure 36).

Bypass message
(图 36)绕过消息(Figure 36) Bypass message

与团队共享拉取请求Share pull requests with teams

“共享拉取请求”操作是通知审阅者的一种便捷途径(图 37)。The Share Pull Request action is a handy way to notify reviewers (Figure 37). 在此版本中,我们添加了对团队和组的支持,因此,可以在单个步骤中通知拉取请求中所涉及的每个参与者。In this release, we’ve added support for teams and groups, so you can notify everyone involved the pull request in a single step.

Share PR with teams
(图 37)与团队共享拉取请求(Figure 37) Share PR with teams

团队的拉取请求改进Pull request improvements for teams

如果你是多个团队的成员,则将看到分配给在“我的拉取请求”视图中列出的那些团队的所有 PR(图 38)。If you’re a member of multiple teams, you will now see all of the PRs assigned to those teams listed in the My Pull Requests view (Figure 38). 这使得必须访问“我的拉取请求”才能查看板上的所有 PR。This makes the My Pull Requests view the one stop you need to visit to see all the PRs on your plate.

PR improvements for teams
(图 38)团队的拉取请求改进(Figure 38) PR improvements for teams

在未来版本中,我们会将团队添加到“代码”下的“拉取请求”中心,以便可以更轻松地查看单个项目的所有 PR。In a future release, we’ll add teams to the Pull Requests hub under Code to make it easier to see all of your PRs for a single project.

拉取请求注释的默认通知Default notifications for pull request comments

通过新的注释通知随时掌握 PR 中发生的对话(图 39)。Stay up to date with the conversations happening in your PRs with the new comment notifications (Figure 39). 对于已经创建的 PR,在用户添加新的注释线程或回复现有线程时,都会向创建者自动发送通知。For PRs that you've created, you will automatically be notified any time a user adds a new comment thread or replies to an existing thread. 当你对其他用户的 PR 添加注释后,你将收到关于你创建或回复的注释线程的任何未来回复的通知。When you comment on another user's PR, you'll be notified about any future replies to comment threads that you create or reply to.

Default PR notifications
(图 39)默认拉取请求通知(Figure 39) Default PR notifications

这些通知可作为现有订阅的一部分提供,并可在“通知”设置页上进行配置。These notifications are available as part of the out of the box subscriptions, and are configurable on the Notifications settings page.

包管理改进 Package Management Improvements

更新的包管理体验 Updated Package Management experience

我们更新了包管理用户体验,以便更快地解决用户报告的常见问题,并为即将推出的包生命周期功能留出空间(图 40)。We've updated the Package Management user experience to make it faster, address common user-reported issues, and make room for upcoming package lifecycle features (Figure 40). 请在更新体验页上了解有关更新的详细信息。Learn more about the update on the Updated experience page.

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

包管理将添加 npm README 和下载按钮Package Management adds npm READMEs and download button

现在,可以在包中看到包含 的任何 npm 包的 README(图 41)。You can now see the README of any npm package that includes a in the package (Figure 41). README 可以帮助团队记录并共享有关包的知识。READMEs can help your team document and share knowledge about your packages.

也可以使用命令栏中的“下载”按钮来下载任何 npm 包。You can also download any npm package using the Download button in the command bar.

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

NuGet 还原和 NuGet 命令生成任务NuGet Restore and NuGet Command build tasks

我们主要更新了 NuGet 安装程序(现在称为 NuGet 还原)任务,并添加了新的 NuGet 任务:NuGet 命令。We’ve made major updates to the NuGet Installer (now called NuGet Restore) task, and added a new NuGet task: NuGet Command. 最值得注意的是, NuGet 命令和 NuGet 还原任务现在默认使用 nuget.exe 4.0.0。Most notably, the NuGet Command and NuGet Restore tasks now use nuget.exe 4.0.0 by default.

现在,NuGet 还原在 Visual Studio 生成步骤之前针对还原包最常见的方案进行了优化。NuGet Restore is now optimized for the most common scenario of restoring packages before a Visual Studio Build step. 它还对共享单个 NuGet 源的小项目提供更好的支持:现在可以选取一个Team Services 源,并将其添加到自动生成的 NuGet.Config 中。It also has better support for small projects that share a single NuGet feed: you can now pick a Team Services feed and have it added to an auto-generated NuGet.Config.

对于更复杂的 NuGet 操作, __NuGet 命令__任务提供了指定任何命令和参数集的灵活性*(图 42)*。For more complex NuGet operations, the NuGet Command task provides the flexibility to specify any command and set of arguments (Figure 42).

NuGet command
(图 42)NuGet 命令(Figure 42) NuGet command

生成和发布改进 Build and Release Improvements

新的生成定义编辑器 New build definition editor

我们已重新设计生成定义编辑器,以提供更直观的体验,修复某些难题,并添加新的功能。We’ve redesigned our build definition editor to provide a more intuitive experience, fix some pain points, and add new capabilities. 我们希望用户可以更轻松地使用模板、添加任务和更改设置。We hope that you’ll find it easier to use templates, add tasks, and change settings. 现在,可以使用过程参数来轻松地指定最重要的数据位,而不必深入探索任务。And now you can use process parameters to make it easier to specify the most important bits of data without having to go deep into your tasks.

搜索模板Search for a templates

搜索想要的模板然后应用它,或者从一个空的过程开始*(图 43)*。Search for the template you want and then apply it, or start with an empty process (Figure 43).

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

快速查找并在所需位置添加任务权限Quickly find and add a task right where you want it

搜索想要使用的任务,然后在找到它之后,可以在左侧当前选择的任务之后添加它,或者将它拖放到想要的位置*(图 44)*。Search for the task you want to use, and then after you’ve found it, you can add it after the currently selected task on the left side, or drag and drop it where you want it to go (Figure 44).

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

还可以拖放一个任务来移动它,或者在拖放的同时按住 Ctrl 键来复制任务。You can also drag and drop a task to move it, or drag and drop while holding the Ctrl key to copy the task.

使用过程参数将密钥自变量传递给任务Use process parameters to pass key arguments to your tasks

现在,可以使用过程参数*(图 45)*以便使用生成定义或模板的用户能够轻松地指定最重要的数据位,而无需深入探索任务。You can now use process parameters (Figure 45 to make it easier for those who use your build definition or template to specify the most important bits of data without having to go deep into your tasks.

Process parameters
(图 45)过程参数(Figure 45) Process parameters

如果从某些内置模板创建新的生成(例如 Visual Studio 和 Maven),则会看到说明工作原理的示例。If you create a new build from some of the built-in templates (for example Visual Studio and Maven) you can see examples of how these work.

新编辑器还包含几个其他增强功能,例如可以使用户更快地访问源设置。The new editor includes a few other enhancements, such as giving you quicker access to your sources settings.

有关使用新编辑器创建第一个生成定义的演练,请参阅适用于新手的 CI/CDFor a walkthrough of creating your first build definition using the new editor, see CI/CD for newbies.

请在 2017 用户体验页上了解详细信息。Learn more on the 2017 user experience page.

扩展任务的多个版本Multiple versions of Extension tasks

现在,扩展创建者可创建具有多个版本的给定任务的扩展,使他们能够为生产中的每个主版本交付修补程序。Extension authors can now create extensions with multiple versions of a given task, which enables them to ship patches for each major version they have in production.

请参阅 Reference for creating custom build tasks within extensions(在扩展中创建自定义生成任务的引用)。See Reference for creating custom build tasks within extensions.

条件生成任务 Conditional build tasks

如果想要更好地控制生成任务(例如在出现问题的时候执行清理或发送消息的任务),我们现在提供了四个内置选项,以便用户在任务运行时进行控制*(图 46)*。If you’re looking for more control over your build tasks, such as a task to clean things up or send a message when something goes wrong, we’re now offering four built-in choices for you to control when a task is run (Figure 46).

Conditional build tasks
(图 46)条件生成任务(Figure 46) Conditional build tasks

如果希望具备更多的灵活性,例如在某些情况下仅针对具有某些触发器的特定分支运行的任务,则可以表明自己的自定义条件:If you are looking for more flexibility, such as a task to run only for certain branches, with certain triggers, under certain conditions, you can express your own custom conditions:

and(failed(), eq(variables['Build.Reason'], 'PullRequest'))

请参阅指定运行任务的条件页。See Specify conditions for running a task page.

用于生成和部署基于容器的应用程序的内置任务Built-in tasks for building and deploying container based applications

通过这个版本,我们默认已经将 Docker 扩展中的大部分任务都拉取到产品中,进行了改进,并引入了一组新的任务和模板,从而可以更轻松地生成一组容器方案。With this release we have pulled most of the tasks in our Docker extension into the product by default, improved them, and introduced a set of new tasks and templates for making a set of container scenarios easier.

  • Docker:生成、推送或运行 Docker 映像或运行 Docker 命令。Docker: Build, push, or run Docker images, or run a Docker command. 此任务可与 Docker 或 Azure 容器注册表一起使用。This task can be used with Docker or Azure Container registry. 现在,可以结合使用内置的服务主体身份验证和 ACR,使之更易于使用。You can now use our built-in service principal authentication with ACR to make it even easier to use.
  • Docker-Compose:生成、推送或运行多容器 Docker 应用程序。Docker-Compose: Build, push, or run multi-container Docker applications. 此任务可与 Docker 或 Azure 容器注册表一起使用。This task can be used with Docker or Azure Container registry.
  • Kubernetes:通过运行 kubectl 命令来部署、配置或更新 Azure 容器服务中的 Kubernetes 群集。Kubernetes: Deploy, configure, or update your Kubernetes cluster in Azure Container Service by running kubectl commands.
  • Service Fabric:将容器部署到 Service Fabric 群集。Service Fabric: Deploy containers to a Service Fabric Cluster. 目前,Service Fabric 是在云中运行 Windows 容器的最佳选择。Service Fabric is the best choice today for running Windows Containers in the cloud.

Azure Web 应用部署更新Azure Web App deployment updates

我们已经对 Azure Web 应用程序做了很多改进:We have made many enhancements for Azure Web Applications:

  • Azure App Service 部署任务支持要部署的 Java WAR 文件、Node.js、Python 和 PHP 应用程序。Azure App Service deployment task supports Java WAR files, Node.js, Python, and PHP applications to be deployed.
  • Azure App Service 部署任务支持使用容器部署到适用于 Linux 的 Azure Web 应用。Azure App Service deployment task supports deploying to Azure Web App for Linux using containers.
  • 经扩展的 Azure 门户持续交付现支持 Node 应用程序。Azure portal Continuous Delivery is expanded now support Node applications.
  • 将 Azure App Service 管理任务添加到 Azure App Service 的启动、停止、重启或槽交换中。Azure App Service manage task is added to Start, Stop, Restart or Slot swap for an Azure App Service. 它还支持安装站点扩展,以启用所需的 PHP 或 Python 版本的安装或安装 IIS Manager 或 Application Insights。It also supports installing site extensions to enable installation of the required PHP or Python version or installing IIS Manager or Application Insights.

我们还为最新版本的 Azure CLI 引入了 CI/CD 支持,以配置 CI/CD。We have also introduced CI/CD support into the latest version of the Azure CLI for configuring CI/CD. 下面是一个示例:Here is an example:

az appservice web source-control config --name mywebapp --resource-group mywebapp_rg --repo-url --cd-provider vsts --cd-app-type AspNetCore

.NET Core 任务支持项目文件.NET Core tasks support project files

借助当前的更新,我们正在改进 .NET Core 任务,以支持除了 project.json 之外的 *.csproj 文件。With the current update, we are enhancing .NET core tasks to support *.csproj files in addition to project.json. 现在可以使用生成代理上的 Visual Studio 2017 来生成使用 csproj 文件的 .NET Core 应用程序。You can now use Visual Studio 2017 on your build agents to build .NET core applications using csproj files.

SSH 部署改进SSH deployment improvements

通过 SSH 复制文件生成/发布任务现支持目标路径中的波形符 (),以简化将文件复制到远程用户的主目录的过程。The Copy Files Over SSH build/release task now supports tildes() in the destination path to simplify copying files to a remote user’s home directory. 此外,利用新选项,可以在找不到要复制的文件时允许造成生成/发布失败。Also, a new option allows causing the build/release to fail when no files are found to copy.

SSH 生成/发布任务现支持在远程 Linux 或 macOS 计算机上使用 Windows 行尾运行脚本。The SSH build/release task now supports running scripts with Windows line endings on remote Linux or macOS machines.

在生成或发布过程中安装 SSH 密钥Install an SSH key during a build or release

一个新的预览版任务,安装 SSH 密钥(预览),在生成或发布之前安装 SSH 密钥,并在生成或发布完成时将其从代理中删除。A new preview task, Install SSH Key (Preview), installs an SSH key prior to a build or release and removes it from the agent when the build or release completes. 已安装的密钥可用于从 Git 存储库或子模块提取代码、运行部署脚本或需要 SSH 身份验证的其他活动。The installed key can be used for fetching code from a Git repository or submodules, running deployment scripts, or other activities that require SSH authentication. 该任务将在以后得到改进,以支持密码和其他功能。It will be improved in the future to support passphrases and other capabilities.

如果已指定 Visual Studio 2017 但在代理上不存在,则任务失败Tasks fail if Visual Studio 2017 is specified but not present on agent

借助 Visual Studio 生成MSBuild 任务,用户可以选择特定版本的 Visual Studio。The Visual Studio Build and MSBuild tasks enable you to select a specific version of Visual Studio. 到目前为止,如果 Visual Studio 2017 版本不可用,这些任务将自动选择下一个可用的版本。Until now, if the Visual Studio 2017 version was not available, these tasks would automatically pick the next available version.

我们将更改此行为。We’re changing this behavior. 现在,如果你选择 Visual Studio 2017 但在代理上不存在,则生成将失败。Now the build will fail if you select Visual Studio 2017 but it is not present on the agent.

我们做了这一更改,原因如下:We made this change for the following reasons:

  • 较新的应用类型,如 .NET Core 不使用较旧的生成工具进行编译。Newer app types such as .NET Core do not compile with older build tools. 它们明确要求使用 Visual Studio 2017 或更高版本。They explicitly require Visual Studio 2017 or newer.

  • 在使用完全相同的 Visual Studio 版本时,将会获得更一致且可预测的结果。You get more consistent and predictable results when you use the same exact version of Visual Studio.

  • 每当生成任务回退时,可能会收到难以理解的编译错误。Whenever build tasks fall back, you may get compilation errors that are difficult to understand.


请确保使用一个与池相连的队列,该池具有使用 Visual Studio 2017 的代理,并且不具有仅使用 Visual Studio 早期版本的代理。Make sure to use a queue connected with a pool that has agents with Visual Studio 2017, and no agents that have only earlier versions of Visual Studio.

专用代理自动工作区清理Private agent automatic workspace cleanup

现在可以配置代理池以定期清理过时的工作目录和存储库(图 47)。You can now configure an agent pool to periodically clean up stale working directories and repositories (Figure 47). 例如,池将删除由已删除的生成和发布定义留下的工作区。For example, the pool will delete workspaces left behind by deleted build and release definitions.

Agent maintenance
(图 47)代理维护(Figure 47) Agent maintenance

使用此选项应尽量避免专用生成和发布代理耗尽磁盘空间的可能性。Using this option should reduce the potential for your private build and release agents to run out of disk space. 维护是由每个代理(而不是每台计算机)完成的,因此,如果一台计算机上有多个代理,仍然会遇到磁盘空间的问题。The maintenance is done per agent (not per machine), so if you have multiple agents on a single machine you could still run into disk space issues.

生成代理升级状态Build agent upgrade status

升级代理时,它现在将指示队列和池管理门户中的升级状态。When an agent is being upgraded, it now indicates the status of the upgrade in the queue and pool management portal.

选择未使用计算机上的专用代理Selection of private agents on machines not in use

在将生成或发布分配给专用代理时,系统现在使用计算机名作为一个因素。The system now uses machine name as a factor when allocating a build or a release to a private agent. 因此,当系统分配作业时,它会选择空闲计算机上的代理,而不是忙碌计算机上的代理。As a result, the system will prefer an agent on an idle machine over an agent on a busy machine when it allocates the job.

管道队列Pipelines queue

现在,我们已从基于代理的定价模型转移到了基于管道的定价模型We have now moved from the agent-based pricing model to pipeline-based pricing model. 在此新模型中,用户可以并行运行数量与其帐户中配置的管道数量一样多的生成或发布。In this new model, users can run as many builds or releases concurrently as the number of pipelines configured in their account. 超过此限制的额外生成和发布将排入队列,并等待早期的生成和发布完成。Additional builds and releases beyond this limit are queued and wait for earlier builds and releases to complete. “管道队列”功能为用户提供对版本或发布位置的更多可见性。The Pipelines queue feature provides users with more visibility into where their builds or releases are.

启动“管道队列”时,可以看到以下信息:On launching the Pipelines queue, you can see the following information:

  1. 等待管道执行的生成和发布以及它们在等待队列中的位置。Builds and releases waiting for a pipeline to execute and their position in the waiting queue.
  2. 当前正在使用可用管道运行的生成和发布。Builds and releases currently running using available pipelines.

当生成/发布正在等待管道时,也可以直接从生成/发布日志页面内启动此视图,并在管道队列和其他详细信息中查找其当前位置。While your build/release is waiting for a pipeline, you can also directly launch this view from inside the build/release logs page and find its current position in the pipeline queue and other details.

“生成”摘要中的“发布”操作Release action in Build summary

我们现在支持“生成”摘要操作栏中提供的“发布”操作,使你能够轻松为生成创建发布。We are now supporting a Release action, available in the Build summary action bar, so it is easy for you to create a release for a build.

变量组的安全性Security for variable groups

现在,可以通过“创建者”和“管理员”等一组角色管理变量组的安全性。Security for variable groups is now governed through a set of roles such as Creator and Administrator.

默认情况下,将分配以下角色。By default, the below roles are assigned.

  • 参与者的创建者角色Creator role to Contributors
  • 项目集合管理员、项目管理员、生成管理员和发布管理员的管理员角色Administrator role to Project Collection Administrators, Project Administrators, Build Administrators, and Release Administrators
  • 有效项目用户的读取者角色Reader role to Valid Project Users

可以替代所有变量组或特定变量组的默认设置。The defaults can be overridden for all variable groups or for a specific one.

iOS DevOps 增强功能iOS DevOps enhancements

Apple App Store 扩展现支持双重验证(双因素身份验证),并支持将生成发布给外部测试人员*(图 48)*。The Apple App Store extension now supports two-step verification (two-factor authentication) and releasing builds to external testers (Figure 48).

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

安装 Apple 证书(预览)是一项新的生成任务,它在代理上安装 P12 签名证书,以便后续的 Xcode 或 Xamarin.iOS 生成使用。Install Apple Certificate (Preview) is a new build task that installs a P12 signing certificate on the agent for use by a subsequent Xcode or Xamarin.iOS build.

安装 Apple 配置文件(预览)是一项新的生成任务,它在代理上安装预配配置文件,以便后续的 Xcode 或 Xamarin.iOS 生成使用。Install Apple Profile (Preview) is a new build task for installing provisioning profiles on the agent for use by a subsequent Xcode or Xamarin.iOS build.

MSBuild、Xamarin.Android 和 Xamarin.iOS 生成任务现支持使用 Visual Studio for Mac 工具集执行生成。MSBuild, Xamarin.Android, and Xamarin.iOS build tasks now support building with the Visual Studio for Mac tool set.

Java 代码覆盖率增强功能Java code coverage enhancements

发布代码覆盖率结果生成任务报告 Cobertura 或 JaCoCo 代码覆盖率作为生成的一部分。The Publish Code Coverage Results build task reports Cobertura or JaCoCo code coverage as part of a build. 它现在支持在“摘要文件”和“报表目录”字段中指定通配符和 minimatch 模式,允许在每个生成基础上对在生成之间进行更改的路径的文件和目录进行解析。It now supports specifying wildcards and minimatch patterns in Summary File and Report Directory fields, allowing the files and directories to be resolved on a per-build basis for paths that change between builds.

Maven 和 SonarQube 改进Maven and SonarQube improvements

Maven 生成任务现在允许在不同于 Maven pom.xml 文件中指定内容的情况下指定用于分析结果的 SonarQube 项目。The Maven build task now allows specifying a SonarQube project for analysis results in cases where it differs from what is specified in the Maven pom.xml file.

改进的 Jenkins 集成Improved Jenkins integration

Jenkins 队列作业生成/发布任务现在支持运行 Jenkins 多分支管道作业,同时在 Team Services 中显示 Jenkins 控制台输出(图 49)。The Jenkins Queue Job build/release task now supports running Jenkins multibranch pipeline jobs while displaying the Jenkins console output in Team Services (Figure 49). 管道结果会发布到 Team Services 生成摘要中。Pipeline results are published to the Team Services build summary.

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

Azure 虚拟机规模集部署Azure virtual machine scale set deployment

用于部署的一个常见模式是要为应用程序的每个版本创建一个完整的虚拟机映像,然后部署该映像。A common pattern being used for deployment is to create a full machine image for each version of the application and then deploy that. 为了方便起见,我们新建了一项生成不可变虚拟机映像任务。To make that easier we have a new Build immutable machine image task. 此任务在部署应用程序和所有需要的先决条件后使用打包程序来生成虚拟机映像。This task uses Packer to generate a machine image after deploying applications and all the required prerequisites. 任务采用部署脚本或打包程序配置模板来创建虚拟机映像,并将其存储在 Azure 存储帐户中。The task takes either the deployment script or the packer configuration template to create the machine image and stores it in an Azure Storage account. 然后,可以将此映像用于 Azure 虚拟机规模集部署,这种部署可以很好地处理此类型的不可变映像部署。This image can then be used for Azure virtual machine scale set deployments that work well with this type of immutable image deployment.

替代 Azure 资源组部署中的模板参数Override template parameters in Azure resource group deployments

当前在 Azure 资源组部署任务中,用户选择 template.json 和 parameters.json 并在文本框中按照特定的语法提供替代参数值。Currently in Azure resource group deployment tasks, users select the template.json and the parameters.json and provide the override parameter values in a text box, following a specific syntax. 这种体验现在已经得到改进,以便在可以编辑和替代模板参数的网格中呈现这些参数(图 50)。This experience is now enhanced so the template parameters are rendered in a grid which allows them to be edited and overridden (Figure 50). 可以通过单击替代参数字段旁边的...来访问此功能,这会打开一个带有模板参数及其默认值和允许值的对话框(已在模板和参数 .json 文件中定义的前提下)。You can access this feature by clicking the ... next to the override parameters field, which opens a dialog with the template parameters along with their default values and allowed values (if defined in the template and parameter .json files). 此功能需要在源中启用 CORS 规则。This feature requires that CORS rules are enabled at the source. 如果模板和参数 json 文件位于 Azure 存储 blob 中,请参阅 Azure 存储服务文档来启用 CORS。If template and parameter json files are in Azure storage blob, refer to the Azure Storage Services documentation to enable CORS.

Azure RG parameters
(图 50)Azure RG 参数(Figure 50) Azure RG parameters

带有分支和标记筛选器的多个发布触发器Multiple release triggers with branch and tag filters

发布管理现支持在“生成”类型的多个项目源上设置 CD 触发器。Release management now supports setting up CD triggers on multiple artifact sources of type “Build”. 添加后,当一个新的项目版本可用于任何指定的项目源时,就会自动创建一个新的发布。When added, a new release is created automatically when a new artifact version is available for any of the specified artifact sources. 还可以指定源分支,新的生成应来源于该分支,以触发一个发布。You can also specify the source branch that the new build should be from to trigger a release. 此外,可以设置标记筛选器来进一步筛选应触发发布的生成。Additionally, Tag filters can be set to further filter the builds that should trigger a release.

在发布中设置项目源的默认值Set defaults for artifact sources in a release

在定义中链接项目源时,用户可以定义要在发布中部署的默认项目版本(图 51)。Users can define the default artifact version to deploy in a release when linking an artifact source in a definition (Figure 51). 自动创建发布后,将部署所有项目源的默认版本。When a release is created automatically, the default version for all the artifact sources would be deployed.

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

部署请求者和审批者的职责分离Separation of duties for deployment requester and approvers

以前,环境所有者可以限制发布创建者批准到环境的发布部署。Previously, environment owners could restrict release creators from approving deployments of the release to an environment. 但是可以手动启动由其他用户创建的发布的部署,然后自行批准。You could, however, manually start deployment of a release created by another user, and approve it yourself.

我们现在已经通过将部署创建者作为部署的独立用户角色来填补这一空白。We have now filled this gap by considering the deployment creator as a separate user role for deployments. 可以限制发布创建者或部署创建者批准部署。Either the release creator or deployment creator can be restricted from approving the deployments.

发布级别批准Release level approvals

现在可以选择自动批准在成功部署到另一个环境后自动触发的部署(图 52)。You can now choose to automatically approve deployments that were automatically triggered after successful deployment to another environment (Figure 52). 如果选择不批准每一个部署,那么可以一次完成批准一个部署链(拥有相同的审批者)。Approving a chain of deployments (which have the same approvers) can be done at one go if you choose to not approve every deployment.

假设有两种环境,即开发和测试环境,预部署审批者设置为“userA”和”userB”,两者都需要批准部署。Let’s say you have two environments Dev and Test, with the predeployment approvers set to “userA” and “userB,” with both of them required to approve the deployment. 如果测试环境上的策略设置如下所示,则在部署期间它足以让 userA 和 userB 仅批准开发。If the policy on Test is set as shown below, during deployment time it will be sufficient for userA and userB to approve only Dev. 对测试的部署将获得自动批准。Deployment to Test will get auto-approved. 如果手动触发对测试的部署,则在部署之前需要批准,以确保正确批准。If the deployment to Test is triggered manually, the approvals will be required before deployment to ensure correct approvals.

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

部署到 Azure 政府云Deploy to Azure Government Cloud

在政府云中拥有 Azure 订阅的客户现在可以配置 Azure 资源管理器服务终结点来针对各国云端。Customers with Azure subscriptions in Government Clouds can now configure Azure Resource Manager service endpoint to target national clouds.

借助此功能,现在可以通过相同的部署任务使用 Release Management 将任何应用程序部署到在政府云中托管的 Azure 资源*(图 53)*。With this, you can now use Release Management to deploy any application to Azure resources hosted in government clouds, using the same deployment tasks (Figure 53).

Government cloud
(图 53)政府云(Figure 53) Government cloud

设置最大并行部署数Set maximum number of parallel deployments

使用此功能可以控制如何将多个挂起发布部署到给定环境中(图 54)。This feature gives you control on how multiple pending releases are deployed into a given environment (Figure 54). 例如,如果发布管道在 QA 环境中执行生成验证,并且生成的生成速度比部署的完成速度更快,则可以配置多个代理和任意多个生成以进行并行验证。For example, if your release pipeline performs validation of builds in a QA environment and the rate of generation of builds is faster than the rate of completion of the deployments, you may configure multiple agents and as many builds to get validated in parallel. 这意味着所生成的每个生成都得到了验证,并且等待时间取决于可用的代理数。That means each of the builds generated gets validated, and the wait time is dependent in the number of available agents. 利用此功能,可以通过在最近使用的生成中并行执行验证,并取消较旧的部署请求来优化验证。With this feature, we let you optimize validations by enabling you to perform validation on the n most recent builds in parallel and cancel the older deployment requests.

Parallel deployments
(图 54)并行部署(Figure 54) Parallel deployments

手动干预任务的超时增强功能Timeout enhancements for the Manual Intervention task

在挂起指定超时或 60 天之后(以首先达到的文件为准),现在可以自动拒绝或恢复手动干预任务。The Manual Intervention task can now be automatically rejected or resumed after it is pending for the specified timeout or 60 days, whichever is earlier. 可以在任务的控制选项部分指定超时值。The timeout value can be specified in the control options section of the task.

Release Management 并行执行Release Management parallel execution

Release Management 现在支持阶段的并行执行选项(图 55)。Release Management now supports a parallel execution option for a phase (Figure 55). 选择此选项可以通过使用多配置或多代理作为一个阶段乘数选项来扇出一个阶段。Select this option to fan out a phase by using either Multi-configuration or Multi-agent as a phase multiplier option.

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

多配置:选择此选项可以运行每个多配置值的阶段。Multi-configuration: Select this option to run the phase for each multi-configuration value. 例如,如果想要同时部署到两个不同的地区,则使用“变量”选项卡上定义的变量 ReleasePlatform,其值为并行运行该阶段的“east-US, west-US”,其中一个值为“east-US”,另一个为“west-US”。For example, if you wanted to deploy to two different geos at the same time, using a variable ReleasePlatform defined on the Variables tab with values "east-US, west-US" would run the phase in parallel, one with a value of "east-US" and the other "west-US”. 多代理:选择此选项以在并行的多个代理上运行具有一个或多个任务的阶段。Multi-agent: Select this option to run the phase with one or more tasks on multiple agents in parallel.

Azure 门户中的 Web 应用部署历史记录Web app deployment history in Azure portal

当部署通过使用应用程序服务部署任务完成后,发布管理现在可以更新 Azure App Service 的部署日志。Release management now updates the deployment logs of Azure App Service when a deployment is done by using the App Service deployment task. 可以通过选择“应用服务”边栏选项卡中的“持续交付”选项来在 Azure 门户中查看部署历史记录。You can view deployment history in the Azure portal by selecting the Continuous delivery option in the App Service blade.

测试改进 Testing Improvements

使用代理阶段运行测试Run tests using agent phases

使用 Visual Studio 测试任务,现在可以使用代理阶段运行自动测试(图 56)。Using the Visual Studio Test task, you can now run automated tests using agent phases (Figure 56).

现在我们具有跨生成、发布和测试的一个统一的自动化代理。We now have a unified automation agent across build, release and test. 它带来了如下优点:This brings in the following benefits:

  1. 可以针对测试需求来利用代理池。You can leverage an agent pool for your testing needs.
  2. 在不同模式下使用相同的 Visual Studio 测试任务运行测试,根据需要—基于单个代理的运行、基于多个代理的分布式测试运行或者多配置运行,来在不同浏览器上运行测试。Run tests in different modes using the same Visual Studio Test task, based on your needs—single agent–based run, multi-agent–based distributed test run or a multi-configuration run to run tests on, say, different browsers.
Run tests using Agent Phases
(图 56)使用代理阶段运行测试(Figure 56) Run tests using Agent Phases

有关详细信息,请参阅此 Microsoft 应用程序生命周期管理文章。For more information, refer to this Microsoft Application Lifecycle Management post.

自动测试的按需触发On-demand triggering of automated tests

“测试”中心现支持从测试计划和测试套件中触发自动测试用例(图 57)。The Test hub now supports triggering automated test cases from test plans and test suites (Figure 57). 从“测试”中心运行自动化测试需要进行一个设置,该设置类似于在发布环境中以计划方式运行测试。Running automated tests from the Test hub will need a setup similar to the way you run tests in a scheduled fashion in release environments. 需要使用“从测试计划运行自动测试”模板在发布定义中设置一个环境,并关联测试计划以运行自动测试。You will need to setup an environment in the release definition using the Run automated tests from test plans template and associate the test plan to run the automated tests. 有关如何设置环境和从“测试”中心运行自动测试的分步指南,请参阅文档See the documentation for the step by step guidance on how to setup environments and run automated tests from the Test hub.

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

仓库改进 Warehouse Improvements

Analysis Services 多维数据集处理的性能改进Performance improvements in Analysis Services cube processing

我们对“vDimWorkItemTreeOverlay”视图进行了性能改进,该视图用于基于链接创建“工作项树层次结构”维度。We’ve made performance improvements to the vDimWorkItemTreeOverlay view, which is used to create Work Item Tree Hierarchy dimension based on the links. 虽然它依赖于 System.LinkTypes.Hierarchy 链接,但我们观察到处理持续时间也会受到其他链接(例如 System.LinkTypes.Related)的影响。Although it depends on System.LinkTypes.Hierarchy links, we observed that the processing duration was affected by other links as well (e.g. System.LinkTypes.Related). 我们优化了视图,跳过了添加会限制读取数据量的链接类型的步骤。We optimized the view to skip addition link types which limits the amount of data read. 此更改可以明显减少某些仓库的处理时间。This change significantly decreases processing time for certain warehouses.

不区分大小写的架构协调Case-insensitive schema reconciliation

仓库数据库的架构是在架构协调过程中,由合并字段基于所有附加的集合数据库创建的。The schema of the warehouse database is created by merging fields from all the attached collection databases in the schema reconciliation process. 以前,所有的比较都是区分大小写的,管理员必须确保字段引用名称精确匹配。Previously, all comparisons were case-sensitive and administrators had to make sure there is an exact match on field reference names. 这会导致在大小写方面存在细微差异的问题。This led to problems where there were subtle differences in casing. 在此版本中,我们提高了该过程对此类差异的容忍度。With this release we make the process more tolerant to such discrepancies.

管理改进 Administration Improvements

合并电子邮件收件人来接收通知Combined email recipients for notifications

收到相同电子邮件通知的收件人现在一起包含在“收件人:”行上,并向他们发送一封电子邮件。Recipients for the same email notification are now included together on the to: line and sent a single email. 以前,会向每个收件人单独发送电子邮件。Previously, individual emails were sent to each recipient. 这使得用户难以知道还有谁也收到了通知,并且难以通过电子邮件讨论相关事件。This made it difficult to know who else received the notification and to have a conversation about the event over email. 该功能适用于现成可用以及能够针对多个收件人的团队订阅。This feature applies to out-of-the-box as well as team subscriptions that are capable of targeting multiple recipients. 例如,当对拉取请求进行更改时,会向该拉取请求的所有审阅者发送一封电子邮件。For example, all reviewers of a pull request are now sent a single email when a change is made to the pull request.

了解有关合并电子邮件收件人的详细信息。Learn more about combining email recipients.

现成可用的通知Out-of-the-box notifications

当帐户中的活动与用户及团队直接相关时,他们会通过电子邮件自动收到通知,例如:Users and teams are now automatically notified via email when there is activity in the account directly relevant to them, such as:

  • 在向某个用户分配了工作项时。when a work item is assigned to a user.
  • 在将某个用户或团队添加为拉取请求的审阅者时。when a user or team is added as a reviewer to a pull request.
  • 在某个用户或团队成为更新的拉取请求的审阅者时。when a user or team is a reviewer on a pull request that is updated.
  • 在另一个用户响应拉取请求注释时。when another user responds to a pull request comment.
  • 在用户请求的生成操作完成时。when a build requested by a user completes.
  • 在安装或请求扩展时(仅适用于管理员)。when an extension is installed or requested (admins only).

用户可以通过转到用户配置文件菜单下的“通知”设置,然后关闭相应的切换来取消订阅任何这些订阅。Users can unsubscribe from any of these subscriptions by going to Notification settings under the user profile menu and then switching off the appropriate toggle(s).

帐户管理员可以通过导航到“设置”齿轮下的集合级别“通知”中心来禁用一个或多个自动订阅。An account admin can disable one or more of these automatic subscriptions by navigating to the collection-level Notifications hub under the settings gear. 任何这些订阅都可以通过单击“...””操作下的“禁用”来禁用。Any of these subscriptions can be disabled by clicking Disable under the "..." action. 禁用订阅后,它将不再出现在用户的个人通知设置页中。Once a subscription is disabled, it will no longer appear for users in their personal notification settings page.

了解有关现成可用通知的详细信息。Learn more about out-of-the-box notifications.

扩展管理权限Extension management permissions

管理员现在可以授予其他用户和组权限来管理集合扩展(图 58)。An admin can now grant other users and groups permission to manage extensions for the collection (Figure 58). 以前只有集合管理员(即项目集合管理员组的成员)可以查看扩展请求、安装、禁用或卸载扩展。Previously only collection administrators (i.e. members of the Project Collection Administrators group) could review extension requests, install, disable, or uninstall extensions.

为了授予此权限,管理员可以通过打开“Marketplace”菜单、选择“管理”扩展,然后单击“安全性”按钮来导航到“扩展管理”中心:To grant this permission, an administrator can navigate to the Extensions admin hub by opening the Marketplace menu, selecting Manage extensions, and then click the Security button:

Extension management permissions
(图 58)扩展管理权限(Figure 58) Extension management permissions

在扩展安装、请求注意等操作时获得通知Getting notified when extensions are installed, require attention, and more

管理员或拥有管理扩展功能的管理员在扩展安装、卸载、启用、禁用或请求注意时会自动收到通知。Admins, or those with the ability to manage extensions, are now automatically notified when an extension is installed, uninstalled, enabled, disabled, or requires attention. 这在更大的部署中特别有用,在这种情况下,多个人员都有责任来管理扩展。This is especially useful in larger deployments where multiple people have the responsibility of managing extensions. 管理员可以通过导航到“配置文件”菜单下的“通知”设置并关闭扩展切换来关闭这些通知。Admins can turn off these notifications by navigating to Notification settings under the profile menu and switching off the extensions toggle.

管理员还可以为扩展相关的事件定义自定义订阅。Admins can also define custom subscriptions for extension-related events. 例如,管理员可以在更新扩展时收到通知。For example, an admin can get notified whenever any extension is updated.

用户现在还可以关闭关于扩展请求的自动通知。Users can also now turn off automatic notifications about their extension requests.

允许 TFS 管理员将订阅者添加到高级访问级别Allowing TFS admins to add subscribers to the advanced access level

在 Team Foundation Server 的未来版本中,将会删除高级访问级别。The Advanced access level will be removed from future versions of Team Foundation Server. 然而,在此之前,TFS 管理员可以将 MSDN Platform 和 Visual Studio Test Professional 订阅者添加到具有 Update 2 的高级访问级别。However, until that happens, TFS admins will have the ability to add MSDN Platform and Visual Studio Test Professional subscribers to the Advanced access level with Update 2.

应将 Visual Studio Enterprise 订阅者添加到 Visual Studio Enterprise 访问级别,而不是添加到高级访问级别。Visual Studio Enterprise subscribers should be added to the Visual Studio Enterprise access level instead of Advanced. 如果已经购买了测试管理器扩展,请继续在购买的团队项目中的“用户”中心管理它。If you have purchased the Test Manager extension, please continue to manage this in the Users hub within the Team Project that you made the purchase.

Microsoft Teams 集成 Microsoft Teams Integration

使用 Microsoft Teams 进行协作的组织现在可在其团队频道内看到其 TFS 项目中的活动。Organizations using Microsoft Teams to collaborate can now see activity from their TFS projects within their team’s channels. 这样,团队在 Microsoft Teams 中工作时就可随时了解相关工作项更改、拉取请求、生成和版本等的最新信息。This allows teams to stay informed about relevant work item changes, pull requests, builds, and releases and more as they are working in Microsoft Teams. 有关详细信息,请参阅文档For more information see our documentation.

已知问题Known Issues

工作项窗体在 Web 中无法正确呈现Work item forms do not render correctly in the web

  • 问题:Issue:

    如果已安装了适用于 Visual Studio 客户端而非 Web 客户端的自定义控件(如多值控件),则 Web 中的工作项窗体将无法呈现。If you have a custom control, such as the multi-value control, installed for the Visual Studio client but not the web client, work item forms in the web fail to render.

  • 解决方法:Workaround:

    需要更新到控件的最新版本。You will need to update to the latest version of your control. 需要添加不包含缺失控件元素的 Web 布局。It is necessary to add a web layout that doesn’t contain the missing control element. 可以在 TFS 工作项跟踪的自定义控件页上找到 TFS 2017 Update 的最新多值控件。You can find the latest multi-value control for TFS 2017 Update on the Custom Controls for TFS Work Item Tracking page. 有关布局的详细信息,请参阅所有 FORM XML 元素引用 (TFS 2015)页。For more information on the layout, see All FORM XML elements reference (TFS 2015) page.

TFS 版本是 RC2,而不是最终版本TFS version is RC2 instead of the final release

  • 问题:Issue:

    下载 TFS 2017 Update 2 后但在 2017 年 8 月 1 日之前,安装的都是 RC2 版本。After downloading TFS 2017 Update 2 before August 1, 2017, and installing, you have an RC2 version.

  • 解决方法:Workaround:

    这是由于安装链接中存在间歇性问题导致的,该问题已于 2017 年 8 月 1 日修复。This was due to an intermittent issue in the installation links that was fixed on August 1, 2017. 请重新下载 TFS 2017 Update 2,然后安装此最终版本。Please redownload TFS 2017 Update 2 and install this final release.

The Developer Community Portal 请参阅客户报告的有关 Team Foundation Server 2017 的问题。 See customer-reported issues reported for Team Foundation Server 2017.

Top of Page