Team Foundation Server 2017 Update 2 Release Notes

Article
11/27/2023

Note

This is not the latest version of Team Foundation Server. To download the latest release, please visit the current release notes for Team Foundation Server 2018 Update 3. You can change the language of this page by clicking the globe icon in the page footer and selecting your desired language.

In this article, you will find information regarding Team Foundation Server 2017 Update 2. Click the button to download.

To learn more about Team Foundation Server 2017, see the Team Foundation Server Requirements and Compatibility page.

Please see the TFS Install page for more information.

Release Date: July 24, 2017

Summary of What's New in Team Foundation Server 2017 Update 2

We have added a lot of new value to Team Foundation Server 2017 Update 2. Some of the highlights include:

Work items now have icons associated with each work item type.
We have introduced Delivery Plans.
You can search for work items using Work Item Search.
There is a new branch policies configuration experience.
There have been many pull request improvements.
There are now Git graphs to visualize your Git history.
You can now add and view Git tags.
We have a new Package Management experience.
There is a new build definition editor experience.
Various updates when deploying to Azure Web Apps.
Many improvements when deploying containers.
We have introduced conditional build tasks.
There are now out-of-the-box notifications.

You can see the details of all the new features by viewing the improvements by feature area:

Work item tracking
Version control
Pull requests
Package Management
Build and release
Testing
Warehouse
Administration
Microsoft Teams integration

Details of What's New in TFS 2017 Update 2

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 types 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.

Color bars conveying type on the backlog and queries grids have been replaced with colored icons (Figure 1).

Wit icons in query — *(Figure 1) Colored icons in query*

Cards on the board now include a type icon (Figure 2).

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. 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.

For users with a TFS instance that is disconnected from the Internet, Delivery Plans are 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.

To enable this feature, toggle the setting under Options in your build definition (Figure 3).

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. 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. Read more about our plans on the Microsoft Application Lifecycle Management page.

Work Item Search

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.

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:

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.
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. 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.

Version Control Improvements

New branch policies configuration experience

We have 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.

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).

If you are using the build policy, you can now configure multiple builds for a single branch. 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 are configuring multiple builds.

Once you have 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).

For required reviewer policies (Figure 9), we added the ability for administrators to specify a note that can be appended to the pull request timeline when the policy applies (Figure 10).

New policy for no active comments

Ensure that all comments in your pull requests are addressed with the new Comments policy. With this policy enabled, active comments will block completion of the PR, forcing all comments to be resolved. Reviewers that leave comments for the PR author but optimistically approve the pull request can be sure that an author that is eager to merge won't miss any comments.

Files hub improvements

We have made several updates to the Files hub to improve the viewing and editing experiences.

For viewing, we have 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.

For editing, you can now preview your changes, easily add a comment, commit to a new branch, and link work items (Figure 13).

Visualize your Git repository

You can now see a graph while showing commit history for repositories or files. 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.

The key elements of Git graph include (Figure 15):

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.
Merge commits are represented by grey dots connected to their first parent and second parent.
Normal commits are represented by blue dots.
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.

View git tags on commits

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. You are able view tags (Figure 16) for a specific commit in the commit list view and the details page.

Add tags to commits

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.

The commit list view also supports a context menu (Figure 18). No need to go to the commit details page to create tags and create new branches (Figure 19).

Updated changeset and shelveset pages

We have modernized the changeset and shelveset pages in TFVC. Both pages are more accessible for those of you who use assistive technologies. 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).

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.

Improved commit filtering

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).

Import repositories from TFVC to Git

You can migrate code from your TFVC repositories to Git repositories in the same account. To start migration, select import repository from the repository selector drop-down (Figure 23).

*(Figure 23) Repository selector drop-down*

Individual folders or branches can be imported to the Git repository, or the entire TFVC repository can be imported (minus the branches) (Figure 24). You can also import up to 180 days of history.

Git LFS file locking

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, and that lock 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. Please upgrade to Git LFS 2.1 or higher to use this feature.

Git commit comments use the new discussion control

We have updated lightweight comments left on Git commits to use the new discussion control. 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

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 have 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.

Pull Request Improvements

Improved 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 is ready to complete? 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.

When policies are configured, but have not passed, the Complete button (Figure 26) now encourages the use of the Auto-complete feature. It is not likely that you can complete the PR successfully if policies are blocking, so we offer an option that completes the PR when those policies eventually pass.

For reviewers, it is more likely that you will want to approve a PR than complete it, so reviewers will see the Approve button (Figure 27) highlighted as the main CTA if you have not approved yet.

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

In a PR with more than a few comments, it can be hard to keep track of all of the conversations. To help in comment management, we have simplified the process of resolving items that have been addressed with a number of enhancements:

In the header for every PR, you will now see a count of the comments that have been resolved (Figure 28).

When a comment has been addressed, you can resolve it with a single click (Figure 29).

If you have comments to add while you are resolving, you can reply and resolve in a single gesture (Figure 30).

As comments are resolved, you will see the count go up until everything has been addressed (Figure 31).

*(Figure 31) Comment count address rate*

We have improved the filter in the Overview to enable filtering by various comment states and to show the count of comments for each filter option (Figure 32).

Updates view shows rebase and force push

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). These two features are extremely useful if you rebase changes in your topic branches before completing your PRs. Reviewers will now have enough info to know exactly what is happened.

Pull request filtering by people

It is now easier to find pull requests! We have added new filtering options to allow you to find PRs created by a specific author or assigned to a specific reviewer (Figure 34). Simply select a user from the author or reviewer filter, and the list will update to show only the PRs that match the filter.

Reason required when bypassing pull request policies

When you are bypassing a pull request policies, you are required to specify a reason. In the Complete pull request dialog, you will see a new Reason field, if they choose to bypass (Figure 35).

After entering the reason and completing the pull request, the message displays in the Overview (Figure 36).

The Share Pull Request action is a handy way to notify reviewers (Figure 37). In this release, we have added support for teams and groups, so you can notify everyone involved the pull request in a single step.

Pull request improvements for teams

If you are 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). This makes the My Pull Requests view the one stop you need to visit to see all the PRs on your plate.

In a future release, we will 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

Stay up to date with the conversations happening in your PRs with the new comment notifications (Figure 39). 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. 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.

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

We have 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 adds npm READMEs and download button

You can now see the README of any npm package that includes a README.md in the package (Figure 41). READMEs can help your team document and share knowledge about your packages.

You can also download any npm package using the Download button in the command bar.

*(Figure 41) Package Management npm README*

NuGet Restore and NuGet Command build tasks

We have made major updates to the NuGet Installer (now called NuGet Restore) task, and added a new NuGet task: NuGet Command. Most notably, the NuGet Command and NuGet Restore tasks now use nuget.exe 4.0.0 by default.

NuGet Restore is now optimized for the most common scenario of restoring packages before a Visual Studio Build step. 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.

For more complex NuGet operations, the NuGet Command task provides the flexibility to specify any command and set of arguments (Figure 42).

Build and Release Improvements

New build definition editor

We have redesigned our build definition editor to provide a more intuitive experience, fix some pain points, and add new capabilities. We hope that you will find it easier to use templates, add tasks, and change settings. Additionally, you can now 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

Search for the template you want and then apply it, or start with an empty process (Figure 43).

Quickly find and add a task right where you want it

Search for the task you want to use, and then after you have 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).

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

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.

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.

For a walkthrough of creating your first build definition using the new editor, see CI/CD for newbies.

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, enabling them to ship patches for each major version they have in production.

See Reference for creating custom build tasks within extensions.

Conditional build tasks

If you are 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 are now offering four built-in choices for you to control a running task (Figure 46).

If you are looking for more flexibility, such as a task to run on specific 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

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: Build, push, or run Docker images, or run a Docker command. This task can be used with Docker or Azure Container registry. You can now use our built-in service principal authentication with ACR to make it even easier to use.
Docker-Compose: Build, push, or run multi-container Docker applications. This task can be used with Docker or Azure Container registry.
Kubernetes: Deploy, configure, or update your Kubernetes cluster in Azure Container Service by running kubectl commands.
Service Fabric: Deploy containers to a Service Fabric Cluster. Service Fabric is the best choice today for running Windows Containers in the cloud.

Azure Web App deployment updates

We have made many enhancements for Azure Web Applications:

Azure App Service deployment task supports deployment of Java WAR files, Node.js, Python, and PHP applications.
Azure App Service deployment task supports deploying to Azure Web App for Linux using containers.
Azure portal Continuous Delivery is expanded to support Node applications.
Azure App Service manage task is added to Start, Stop, Restart or Slot swap for an Azure App Service. It also supports installing site extensions to enable installation of the required PHP or Python version or installing IIS Manager or Application Insights.

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 https://myaccount.visualstudio.com/myproject/_git/myrepo --cd-provider vsts --cd-app-type AspNetCore

.NET Core tasks support project files

With the current update, we are enhancing .NET core tasks to support *.csproj files in addition to project.json. You can now use Visual Studio 2017 on your build agents to build .NET core applications using csproj files.

SSH deployment improvements

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 causes the build/release to fail when no files are found to copy.

The SSH build/release task now supports running scripts with Windows line endings on remote Linux or macOS machines.

Install an SSH key during a build or release

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. 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. This feature will improved in the future to support passphrases and other capabilities.

Tasks fail if Visual Studio 2017 is specified but not present on agent

The Visual Studio Build and MSBuild tasks enable you to select a specific version of Visual Studio. Until now, if the Visual Studio 2017 version was not available, these tasks would automatically pick the next available version.

We are changing this behavior. 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:

Newer app types such as .NET Core do not compile with older build tools. They explicitly require Visual Studio 2017 or newer.
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.

Tip

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

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.

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 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 enhancements

The Apple App Store extension now supports two-step verification (two-factor authentication) and releasing builds to external testers (Figure 48).

*(Figure 48) Apple App Store connection*

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.

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, and Xamarin.iOS build tasks now support building with the Visual Studio for Mac tool set.

Java code coverage enhancements

The Publish Code Coverage Results build task reports Cobertura or JaCoCo code coverage as part of a build. 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 and SonarQube improvements

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.

Improved Jenkins integration

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). Pipeline results are published to the Team Services build summary.

Azure virtual machine scale set deployment

A common pattern 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. 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. This image can then be used for Azure virtual machine scale set deployments that work well with this type of immutable image deployment.

Override template parameters in Azure resource group deployments

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. This experience is now enhanced so the template parameters are rendered in a grid that allows them to be edited and overridden (Figure 50). 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). This feature requires that you enable CORS rules at the source. If template and parameter .json files are in Azure storage blob, refer to the Azure Storage Services documentation to enable CORS.

Multiple release triggers with branch and tag filters

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

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.

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

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 (that have the same approvers) can be done at one go if you choose to not approve every deployment.

In the case where 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. If the policy on Test is set as shown below, during deployment time it is sufficient for userA and userB to approve only Dev. Deployment to Test will get auto-approved. If the deployment to Test is triggered manually, approvals are required before deployment to ensure correct approvals.

Deploy to Azure Government Cloud

Customers with Azure subscriptions in Government Clouds can now configure Azure Resource Manager service endpoint to target national clouds.

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).

Set maximum number of parallel deployments

This feature gives you control on how multiple pending releases are deployed into a given environment (Figure 54). 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 is 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.

Timeout enhancements for the Manual Intervention task

The Manual Intervention task can now be automatically rejected or resumed after pending for the specified timeout or 60 days, whichever is earlier. You can specify the timeout value in the control options section of the task.

Release Management parallel execution

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.

*(Figure 55) Parallel execution support*

Multi-configuration: Select this option to run the phase for each multi-configuration value. 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.

Web app deployment history in Azure portal

Release management now updates the deployment logs of Azure App Service when a deployment is completed by using the App Service deployment task. 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

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:

You can leverage an agent pool for your testing needs.
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.

*(Figure 56) Run tests using Agent Phases*

For more information, refer to this Microsoft Application Lifecycle Management post.

On-demand triggering of automated tests

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.

*(Figure 57) On-demand automated tests trigger*

Warehouse Improvements

Performance improvements in Analysis Services cube processing

We have made performance improvements to the vDimWorkItemTreeOverlay view, that is used to create Work Item Tree Hierarchy dimension based on the links. 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 that 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 through email when there is activity in the account directly relevant to them, such as when:

a work item is assigned to a user.
a user or team is added as a reviewer to a pull request.
a user or team is a reviewer on a pull request that is updated.
another user responds to a pull request comment.
a build requested by a user completes.
an extension is installed or requested (administrators 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 administrator 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

An administrator 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.

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:

*(Figure 58) Extension management permissions*

Getting notified when extensions are installed, require attention, and more

Administrators, 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.

Administrators can also define custom subscriptions for extension-related events. For example, an administrator can get notified whenever any extension is updated.

Users can also now turn off automatic notifications about their extension requests.

Allowing TFS admins to add subscribers to the advanced access level

The Advanced access level will be removed from future versions of Team Foundation Server. However, until that happens, TFS admins have the ability to add MSDN Platform and Visual Studio Test Professional subscribers to the Advanced access level with Update 2.

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 Integration

Organizations using Microsoft Teams to collaborate can now see activity from their TFS projects within their team's channels. 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

Work item forms do not render correctly in the web

Issue:

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. It is necessary to add a web layout that does not contain the missing control element. You can find the latest multi-value control for TFS 2017 Update on the Custom Controls for TFS Work Item Tracking page. For more information on the layout, see All FORM XML elements reference (TFS 2015) page.

TFS version is RC2 instead of the final release

Issue:

After downloading TFS 2017 Update 2 before August 1, 2017, and installing, you have an RC2 version.
Workaround:

This was due to an intermittent issue in the installation links fixed on August 1, 2017. Please redownload TFS 2017 Update 2 and install this final release.

See customer-reported issues reported for Team Foundation Server 2017.

Feedback & Suggestions

We would love to hear from you! You can report a problem and track it through Developer Community and get advice on Stack Overflow.

Top of Page