This post series provides the latest updates and news for Visual Studio Team Services and is a great way for Azure users to keep up-to-date with new features being released every three weeks. Visual Studio Team Services offers the best DevOps tooling to create an efficient continuous integration and release pipeline to Azure.

In this month’s update, we begin with an industry first by scaling Git beyond what anyone else thought possible. After discussing more improvements in Git, we’ve got a brand new built-in wiki now in public preview. We also have improvements in build, release, package management, and work item tracking. There’s a lot of new stuff, so let’s dive in.

World’s largest Git repo is on VSTS: 3.5M files and 300 GB!

As part of a big effort at Microsoft to modernize engineering systems, which we call One Engineering System (1ES), we set an audacious goal of moving the Windows code base into Git a few years ago. We tried a couple of different approaches, including submodules, before deciding that the best approach was to scale Git by virtualizing the repo. This spring we accomplished our goal when the Windows team moved the entire Windows code base into a single Git repo hosted on VS Team Services. With nearly 4,000 engineers working in a single Git repo called “OS,” Windows is in a single version control repository for the first time in decades. To achieve this, we created Git Virtual File System (GVFS) which we’ve also released as an open source project so that anyone can use it with VSTS.

The scale that Windows development operates at is really amazing. Let’s look at some numbers.

• There are over 250,000 reachable Git commits in the history for this repo, over the past 4 months.
• 8,421 pushes per day (on average)
• 2,500 pull requests, with 6,600 reviewers per work day (on average)
• 4,352 active topic branches
• 1,760 official builds per day

We’ve already significantly improved performance from the first release of GVFS. Along the way, we’ve also made performance and scale improvements in Git, and we are contributing those to the Git project. Any account on VSTS can use GVFS, so feel free to try it out.

Since we’re talking about Git, let’s take a look at the improvements we’ve made in the experience.

Collapsible pull request comments

Reviewing code is a critical part of the pull request experience, so we’ve added new features to make it easier for reviewers to focus on the code. Code reviewers can easily hide comments to get them out of the way when reviewing new code for the first time.

Hiding comments hides them from the tree view and collapses the comment threads in the file view:

When comments are collapsed, they can be expanded easily by clicking the icon in the margin, and then collapsed again with another click. Tooltips make it easy to peek at a comment without seeing the entire thread.

Improved workflow when approving pull requests with suggestions

Using the auto-complete option with pull requests is a great way to improve your productivity, but it shouldn’t cut short any active discussions with code reviewers. To better facilitate those discussions, the Approve with suggestions vote will now prompt when a pull request is set to complete automatically. The user will have the option to cancel the auto-complete so that their feedback can be read, or keep the auto-complete set and allow the pull request to be completed automatically when all policies are fulfilled.

Filter tree view in Code

Now you don’t need to scroll through all the files that a commit may have modified to just get to your files. The tree view on commit details, pull requests, shelveset details, and changeset details page now supports file and folder filtering. This is a smart filter that shows child files of a folder when you filter by folder name and shows a collapsed tree view of a file to show the file hierarchy when you filter by file name.

Find a file or folder filter on commit tree:

Git tags

Our Git tags experience in the VSTS web UI continues to evolve quickly. In addition to improvements to viewing, you can also delete, filter, and set security on tags.

View tags

You can view all the tags on your repository on the Tags page. If you manage all your tags as releases, then a user can visit the tags page to get a bird’s-eye view of all the product releases.

You can easily differentiate between a lightweight and an annotated tag here, as annotated tags show the tagger and the creation date alongside the associated commit, while lightweight tags only show the commit information.

Delete tags

Sometimes you need to delete a tag from your remote repo. It could be due to a typo in the tag name, or you you might have tagged the wrong commit. You can delete tags from the web UI by clicking the context menu of a tag on the Tags page and selecting Delete tag.

Filtering tags

The number of tags can grow significantly with time. Some repositories may have tags created in hierarchies, which can make finding tags difficult.

If you are unable to find the tag that you were looking for on the tag page, then you can simply search for the tag name using the filter on top of the Tags page.

Tags security

Now you can grant granular permissions to users of the repo to manage tags. You can give users the permission to delete tags or manage tags.

New Wiki experience in public preview

For quite a while we’ve wanted to have a built-in wiki. I’m happy to announce that each project now has its own wiki. Help your team members and other users understand, use, and contribute to your project. Learn more about it in our announcement blog post and check out the docs. Oh, and one more thing. It fully supports emoji, so have fun with it!

Building with the latest Visual Studio

We’re changing the model for handling different versions of Visual Studio. Due to architectural, storage, and performance limitations, we’re no longer going to offer multiple versions of Visual Studio on a single hosted build machine. For details on the history and rationale for these changes, see Visual Studio Team Services VS Hosted Pools.

In this release you’ll see the following changes:

• You must now explicitly select a queue when you create a build definition (no default).

• To make it easier, we’re moving the default queue to the Tasks tab, in the Process section.

• The Visual Studio Build and MSBuild tasks now default to the Latest setting for the version argument.

Coming soon you’ll see more changes. For example, the following hosted pools (and corresponding queues) will be:

• Hosted VS2017

• Hosted VS2015

• Hosted Deprecated (previously called “Hosted Pool”)

• Hosted Linux Preview

Chef: Infrastructure as code

Chef is now available in the Visual Studio Team Services Marketplace! If you’re not familiar with Chef, they offer an infrastructure automation platform with a slick custom development kit allowing you to “turn your infrastructure into code.” In their words, “Infrastructure described as code is flexible, versionable, human-readable, and testable.” The Chef team wrote their own extensive blog post about this release, and I encourage you to check that out as well.

The Chef extension adds six new Build & Release tasks for configuring Chef Automate.

The tasks in this extension automate the common activities you perform when interacting with the Chef Automate platform. For a detailed look at setup and configuration, check out the getting started guide on GitHub. The tasks included in the extension typically used as part of the build process are:

• Update cookbook version number: Allows you to take your current build number and set the version of a Chef cookbook with that version prior to uploading.
• Upload cookbook to Chef Server: Allows you to specify a path containing a cookbook from within your repo, and have it uploaded to your Chef Server, along with all prerequisites if you have specified them.

The tasks typically used as part of your Release process are:

• Add variables to Chef Environment: Using this task allows you to copy a set of VSTS Release Management variables for your Environment, over to a specified Chef environment.
• Release cookbook version to environment: This task allows you to specify a version ‘pin’ for a Chef cookbook in a particular environment. You can use this task in a Release Pipeline to ‘release’ cookbooks to that environment.
• Execute InSpec: Execute InSpec on machines in a Deployment Group.
• Execute Chef Client: Execute Chef Client on machines in a Deployment Group.

We are happy to have Chef join the Team Services extension ecosystem, so take your infrastructure to the next level and give them a shot.

Control releases to an environment based on the source branch

A release definition can be configured to trigger a deployment automatically when a new release is created, typically after a build of the source succeeds. However, you may want to deploy only builds from specific branches of the source, rather than when any build succeeds.

For example, you may want all builds to be deployed to Dev and Test environments, but only specific builds deployed to Production. Previously you were required to maintain two release pipelines for this purpose, one for the Dev and Test environments and another for the Production environment.

Release Management now supports the use of artifact filters for each environment. This means you can specify the releases that will be deployed to each environment when the deployment trigger conditions, such as a build succeeding and creating a new release, are met. In the Trigger section of the environment Deployment conditions dialog, select the artifact conditions such as the source branch and tags for builds that will trigger a new deployment to that environment.

In addition, the Release Summary page now contains a pop-up tip that indicates the reason for all “not started” deployments to be in that state, and suggests how or when the deployment will start.

Release Triggers for Git repositories as an artifact source

Release Management now supports configuring a continuous deployment trigger for Git repositories linked to a release definition in any of the team projects in the same account. This lets you trigger a release automatically when a new commit is made to the repository. You can also specify a branch in the Git repository for which commits will trigger a release. This also means that you can link GitHub and Team Foundation Git repositories as artifact sources to a release definition, and then trigger releases automatically for applications such as Node.js and PHP that are not generated from a build.

On-demand triggering of automated tests

The Test hub now supports triggering automated test cases from test plans and test suites. Running automated tests from the Test hub can be set up similarly 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 it with the test plan to run the automated tests. See the documentation for step by step guidance on how to set up environments and run automated tests from the Test hub.

Securely store files like Apple certificates

We’ve added a general-purpose secure files library to the Build and Release features. Use the secure files library to store files such as signing certificates, Apple Provisioning Profiles, Android Keystore files, and SSH keys on the server without having to commit them to your source repository.

The contents of secure files are encrypted and can only be used during build or release processes by referencing them from a task. Secure files are available across multiple build and release definitions in the team project based on security settings. Secure files follow the Library security model.

We’ve also added some Apple tasks that leverage this new feature:

• Utility: Install Apple Certificate

• Utility: Install Apple Provisioning Profile

Consume secrets from an Azure Key Vault as variables

We have also added first-class support for integrating with Azure Key Vault by linking variable groups to Key Vault secrets. This means you can manage secret values completely within Azure Key Vault without changing anything in VSTS (for example, rotate passwords or certificates in Azure Key Vault without affecting release).

To enable this feature in the Variable Groups page, use the toggle button Link secrets from an Azure key vault as variables. After configuring the vault details, choose +Add and select the specific secrets from your vault that are to be mapped to this variable group.

After you have created a variable group mapped to Azure Key Vault, you can link it to your release definitions, as documented in Variable groups.

Note that it’s just the secret names that are mapped to the variable group variables, not the values. The actual values (the latest version) of each secret will be used during the release.

Package build task updates

We’ve made comprehensive updates to the NuGet, npm, Maven, and dotnet build tasks, including fixes to most of the issues logged in the vsts-tasks repo on GitHub.

New unified NuGet task

We’ve combined the NuGet Restore, NuGet Packager, and NuGet Publisher task into a unified NuGet build task to align better with the rest of the build task library; the new task uses NuGet 4.0.0 by default. Accordingly, we’ve deprecated the old tasks, and we recommend moving to the new NuGet task as you have time. This change coincides with a wave of improvements outlined below that you’ll only be able to access by using the combined task.

As part of this work, we’ve also released a new NuGet Tool Installer task that controls the version of NuGet available on the PATH and used by the new NuGet task. So, to use a newer version of NuGet, just add a NuGet Tool Installer task at the beginning of your build.

npm build task updates

Whether you’re building your npm project on Windows, Linux, or Mac the new NPM build task will accommodate. We have also reorganized the task to make both npm install and npm publish easier. For install and publish, we have simplified credential acquisition so that credentials for registries listed in your project’s .npmrc file can be safely stored in a service endpoint. Alternatively, if you’re using a VSTS feed, we have a picker that will let you select a feed, and then we will generate a .npmrc with requisite credentials that are used by the build agent.

Working outside your account/collection

It’s now easier to work with feeds outside your VSTS account, whether they’re Package Management feeds in another VSTS account or TFS server, or non-Package Management feeds like NuGet.org/npmjs.com, Artifactory, or MyGet. Dedicated Service Endpoint types for NuGet and npm make it easy to enter the correct credentials and enable the build tasks to work seamlessly across package download and package push operations.

Maven and dotnet now support authenticated feeds

Unlike NuGet and npm, the Maven and dotnet build tasks did not previously work with authenticated feeds. We’ve added all the same goodness outlined above (feed picker, working outside your account improvements) to the dotnet task. Similarly, the Maven task now supports authenticated feeds within the same VSTS account or TFS collection as the current build. Just add a feed to your pom.xml and the Maven step will add credentials automatically (and clean them up when finished). These make it easy to work with VSTS/TFS and external feeds/repositories for all the package types supported by Package Management.

Mobile work item form general availability

The mobile experience for work items in Visual Studio Team Services is now out of preview! We have a full end-to-end experience that includes an optimized look and feel for work items and provides an easy way to interact with items that are assigned to you, that you’re following, or that you have visited or edited recently from your phone.

 

Extension of the month: Product Plan

Communicating the big picture helps align everyone to the team goals and empowers more people to notice when something may not be lining up. So I am happy to announce that our partners at ProductPlan have brought their roadmap solution to the VSTS Marketplace.

ProductPlan provides an easy way to plan and communicate your product strategy. Get started with a 30-day free trial.

• Easily drag and drop bars, milestones, containers, and lanes to build beautiful roadmaps in minutes.
• Update your plans on-the-fly.
• Securely share with individuals, your whole team, or the entire company – for free. Easily print and export to a PDF, image, or spreadsheet.
• Use the Planning Board to score your initiatives objectively.
• Capture future opportunities in a central location with the Parking Lot.
• Expand lanes and containers to tailor the amount of detail you share.
• View multiple roadmaps in a Master Plan to understand your entire product portfolio at a glance.

As always, there’s even more in our sprintly release announcements. Check out the June 1st and June 22nd announcements for the full list of features. Be sure to subscribe to the DevOps blog to keep up with the latest plans and developments for VSTS.

Happy coding!