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. This sprint has our Build 2017 conference deliverables in it, so it’s a big one, especially in the CI/CD space. Here’s a recap with all of our conference presentations.

One of our goals is to keep lowering the barrier to entry for automating your application deployment. The ease with which teams can deploy and validate their application is a huge part of how quickly they are able to ship. While our CI/CD system is completely open, by doing deep integrations with Azure we can make setting up deployments extremely simple. It also unlocks many opportunities for richer workflows that span both development and operations. To that end, we are continuing to strive to make VSTS + Azure the best end-to-end DevOps experience.

This month brings a bunch of new capabilities toward realizing that goal. We have significantly expanded the breadth of app type we support:

• We now support using the automation agent on the VMs to which you deploy and using it to drive your application deployment. This has easily been our most requested feature for Release Management and we’re excited for it go live.
• We continue to give more and more focus to containers. This sprint, we introduce native support for Kubernetes and Service Fabric, the latter being a great option for Windows containers.
• We already have great support for deploying to Azure Web Apps, but we’ve expanded the app types we support with our native task to include Node, PHP, and Linux Web Apps with containers. We’ve also expanded the entry point for setting up CI/CD with more options in the Azure portal configuration UI and introduced the ability to set up CI/CD for Azure Web Apps from the AZ CLI.

Let’s dive in!

VM Deployment (Public Preview)

Release Management now supports robust out-of-the-box multi-machine deployment. You can now orchestrate deployments across multiple machines and perform rolling updates while ensuring high availability of the application throughout.

Agent-based deployment capability relies on the same build and deployment agents. However, unlike the current approach where you install the build and deployment agents on a set of proxy servers in an agent pool and drive deployments to remote target servers, you install the agent on each of your target servers directly and drive rolling deployment to those servers. You can use the full task catalog on your target machines.

A deployment group is a logical group of targets (machines) with agents installed on each of them. Deployment groups represent your physical environments, such as single-box Dev, multi-machine QA, and a farm of machines for UAT/Prod. They also specify the security context for your physical environments.

You can use this against any VM that you register our agent with. We’ve also made it very easy to register with Azure with support for a Azure VM extension that auto-installs the agent when the VM spins up. We will automatically inherit the tags on the Azure VM when it’s registered in VSTS.

Once you have a deployment group, you simply configure what you want us to execute on that deployment group. You can control what gets run on which machines using tags and control how fast or slow the rollout happens.

When the deployment is run, the logs show the progression across the entire group of machines you are targeting.

This feature is now an integrated part of Release Management. There are no additional licenses required to use it.

While we’re on the topic of deploying to different environments, check out our post on configuring your release pipelines for safe deployments.

Azure virtual machine scale set deployment

Another common pattern being use 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 that uses Packer to generate a machine image after deploying applications and all the required prerequisites. The tasks takes either deployment script or packer configuration template to create the machine image and stores it in an Azure Storage account. This image can than be used for Azure Virtual Machine Scale Set deployments that work well for this type of immutable image deployment. You can learn more in our post on deploying applications to VM scale sets.

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. In fact, this is where more and more of VSTS itself is running each sprint.

Azure Web App deployment updates

We have made many enhancements for Azure Web Applications:

• Azure App Service deployment task supports Node.js, Python 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 to now support Node applications.

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

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. Read more about this in our on setting up continuous delivery to Microsoft Azure Government.

Automatic linking from work items to builds

With this new setting in the build definition, users can track the builds that have incorporated their 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.

Note: The feature is only available for definitions building Team Services Git or TFVC repos, and only through the new build definition editor.

Using Jenkins for Continuous Integration with Team Services

Jenkins is a popular continuous integration build server, and there are multiple ways to use Jenkins as a CI server with Team Services. Jenkins’ built-in Git Plugin or Team Foundation Server Plugin can poll a Team Services repository every few minutes and queue a job when changes are detected. For those who need tighter integration, Team Services provides two additional ways to achieve it: 1) the Jenkins Service Hook, and 2) Jenkins build and release tasks.

Team Services adds capabilities over the Jenkins Service Hook by including connectors that allow its build and release systems to integrate with Jenkins. These connectors can be chosen from the list of tasks to execute as steps in a Team Services build or release definition.

A Team Services build or release will queue a Jenkins job and download resulting artifacts. Since these tasks execute in a light-weight, long-polling agent that can be installed in your data center, there is no need to modify inbound firewall rules for Team Services to access your Jenkins server from the cloud.

You can learn more in our blog post on integrating with Jenkins.

Maven for Package Management (Public Preview)

Java developers share components by packaging up their code in Maven artifacts, the Java equivalent of a NuGet package. Team Services customers needing a place to host Maven artifacts used to have to use third-party services, like Nexus or Artifactory, to meet their needs. We’re proud to announce that Team Services Package Management now supports hosting Maven artifacts! Check out our getting started guide.

You’ll also want to check out our recent blog post on the extensive support for Java development with Team Services.

New Git branch policies configuration experience

Branch policies are a great way to ensure quality in your branches by requiring code reviews, automatically running a build and tests for each PR, and more. We’ve redesigned the branch policies configuration experience and added some great new capabilities. 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.

If you’re using the build policy, you can now configure multiple builds for a single branch. There are also new options to specify the type of trigger, automatic or manual. 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.

Share Git pull requests with teams

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

Visualize your Git repository

Team Services now supports showing a graph while showing commit history for repositories or files. Now you can easily create a mental model of all your branches and commits for your git repositories using git graph. The graph shows all your commits in topological order.

The key elements of the git graph include:

1. The git graph is right-aligned, so commits associated with the default branch or the selected branch appear on the right while the rest of the graph grows on the left.
2. Merge commits are represented by grey dots connected to their first parent and second parent.
3. Normal commits are represented by blue dots.
4. 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.

You can read more in our post on the Git graph and advanced filters.

Delivery Plans general availability

We are excited to announce that Delivery Plans is out of preview and is now included in the basic access level of VSTS. Delivery Plans is an organizational tool that helps users drive cross-team visibility and alignment by tracking work status on an iteration-based calendar. Users can tailor their plan to include any team or backlog level from across projects in the account. Furthermore, Field Criteria on Plans enables users to further customize their view, while Markers highlight important dates.

Delivery Plans is currently only available for VSTS; however, it will be included in the upcoming TFS 2017 Update 2 release.

Check out the marketplace page for Delivery Plans to learn more and install the extension.

Delivery timeline markers

Have you been looking for a way to highlight key dates on your Delivery Plan? Now you can with plan markers. Plan markers let you visualize key dates for teams directly on your deliver plan. Markers have an associated color and label. The label shows up when you click the marker dot.

Work item search general availability

Thank you all for installing and using the Work Item Search preview from the marketplace. It has been one of our most highly rated extensions. With this release, we are making it easier for you to use work item search by making it a built-in feature of VSTS.

You can get started with work item search using the search box:

Updated process customization experience

We have modernized our pages when customizing your process. The page now includes a breadcrumb in the top to clearly show the context you are in when editing the process or the work item types inside the process.

Also, it’s much easier to start customizing your work item form. When you select Customize from the context menu in a work item, we automatically create an inherited process for you, if you are not already using one, and bring you into the layout editor.

Insight into your projects with Analytics

Our new Analytics service brings you and your team new insights into the health and status of your work. Analytics is currently in preview, and at this early stage includes three new dashboard widgets, Lead Time, Cycle Time, and Cumulative Flow Diagram (CFD). You can install Analytics from the VS Team Services Marketplace.

We released a long list of new features the last couple of sprints. Be sure to read the release notes for May 11th and April 19th for a full list.

Happy coding!