In this article, you will find information regarding the newest release for Team Foundation Server 2017 Update 2 RC2. Click the button to download.
To learn more about Team Foundation Server 2017, see the Team Foundation Server Requirements and Compatibility page.
Release Date: June 26, 2017
What's new in RC2
- You can now integrate TFS with Microsoft Teams
Summary of Updates in TFS 2017 Update 2
We've added a lot of new value to Team Foundation Server 2017 Update 2 RC2. 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
- Microsoft Teams integration
What's New in this Release
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.
Color bars conveying type on the backlog and queries grids have been replaced with colored icons (Figure 1).
Cards on the board now include a type icon (Figure 2).
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.
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 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.
- 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.
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.
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’re 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’re configuring multiple builds.
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).
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).
New policy for no active comments
Ensure that all comments in your pull requests are being 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’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.
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.
For editing, you can now preview your changes, easily add a comment, commit to a new branch, and link work items (Figure 13).
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 the git graph include (Figure 15):
- 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.
- 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.
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 will be 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 made 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).
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, 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. Please upgrade to Git LFS 2.1 or higher to use this feature.
Git commit comments use the new discussion control
Lightweight comments left on Git commits has been updated 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’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.
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’s 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 aren’t yet passing, the Complete button (Figure 26) will now encourage the use of the Auto-complete feature. 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.
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.
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.
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:
- In the header for every PR, you’ll 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’re resolving, you can reply and resolve in a single gesture (Figure 30).
- As comments are resolved, you’ll see the count go up until everything has been addressed (Figure 31).
- 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).
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 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.
Pull request filtering by people
It’s now easier to find pull requests! 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). 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.
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 will be displayed in the Overview (Figure 36).
Share pull requests with teams
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.
Pull request improvements for teams
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). 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’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
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.
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 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.
NuGet Restore and NuGet Command build tasks
We’ve 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).
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
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’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).
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.
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).
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.
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.
We have made many enhancements for Azure Web Applications:
- Azure App Service deployment task supports Java WAR files, Node.js, Python, and PHP applications to be deployed.
- Azure App Service deployment task supports deploying to Azure Web App for Linux using containers.
- Azure portal Continuous Delivery is expanded now 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 allows causing 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. It will be 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’re 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.
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 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.
iOS DevOps enhancements
The Apple App Store extension now supports two-step verification (two-factor authentication) and releasing builds to external testers (Figure 48).
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.
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. 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 which 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 CORS rules are enabled 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 (which have the same approvers) can be done at one go if you choose to not approve every deployment.
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. 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.
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 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.
Timeout enhancements for the Manual Intervention task
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 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.
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 done 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.
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.
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.
Performance improvements in Analysis Services cube processing
We’ve made performance improvements to the vDimWorkItemTreeOverlay view, which 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 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.
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.
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
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.
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:
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.
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 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 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.
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.
TFS Database Import Service does not support RC releases
The TFS Database Import Service for Visual Studio Team Services doesn’t support imports from RC releases of TFS. If you’re planning on importing your collection database to Team Services using this service, it’s important that you don’t upgrade your production database to this RC release. If you do upgrade, then you will need to wait and upgrade to the RTW version of this release or restore a backup copy of your database from a previous TFS version to import.
Work item forms do not render correctly in the 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.
You will need to update to the latest version of your control. It is necessary to add a web layout that doesn’t 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.
There are some unlocalized strings in web access
If you upgraded from TFS 2017 Update 2 RC1 to RC2, you will see some menu items and other web access items in English. Upgrades from any previous version of TFS and new installs will not have this problem.
This will be fixed for TFS 2017 Update 2 RTW. There is no other workaround at this time.
Upgrade fails with “Microsoft.VisualStudio.Services.Npm.Server.Exceptions.GetDownloadUriFailedException” or “System.InvalidOperationException” while executing the “UpdateAllPackagesWithPackageManifest” step.
In some scenarios, an upgrade to Team Foundation Server 2017 Update 2 RC2 will fail with exception “Microsoft.VisualStudio.Services.Npm.Server.Exceptions.GetDownloadUriFailedException” or “System.InvalidOperationException” while executing the “UpdateAllPackagesWithPackageManifest” step.
If you observe that an upgrade has failed with a “Microsoft.VisualStudio.Services.Npm.Server.Exceptions.GetDownloadUriFailedException” or “System.InvalidOperationException” while executing the “UpdateAllPackagesWithPackageManifest” step, run the following SQL script against your Team Foundation Server configuration database.
DELETE FROM tbl_ServicingStep WHERE StepName = 'UpdateAllPackagesWithPackageManifest' GO EXEC prc_SetRegistryValue 1, '#\Configuration\Servicing\ResourceCookie\', 'SkipUpdateAllPackagesWithPackageManifestStep' GO DECLARE @jobSource UNIQUEIDENTIFIER DECLARE @jobs typ_JobQueueUpdateTable INSERT INTO @jobs SELECT JobId, 15 FROM tbl_ServicingJobDetail WHERE Result = 1 AND OperationClass = 'ApplyPatch' AND QueueTime > DATEADD(day, -2, GETUTCDATE()) AND (JobStatus = 4 OR Result = 4) SELECT @jobSource = HostId FROM tbl_ServiceHost WHERE Name = 'TEAM FOUNDATION' EXEC prc_QueueJobs @jobSource, @jobs, 1, 0