August 2015

We have been talking about the vNext version of Release Management Service in Visual Studio Online for the past few months. This service is currently in private preview and is expected to be available for all VSO users later this year. In this article, we will walk through some of the features that you can expect to be in this service.

Why RM vNext service?

The current version of Release Management service, which is based on a rich client, has been available as part of Visual Studio Online since November 2014. However, that solution had several limitations, including:

• No browser-based interface integrated into Visual Studio Online
• Deploy only to Microsoft Azure, and not to on-premises servers

The Release Management vNext service addresses these and other limitations, and offers many more improvements. It is not just a change of user interface from the old WPF client to the new web interface. Instead, it is based on a new architecture, and a new set of simplified concepts. You will find that this service:

• Is easy to use
• Works for all of your apps – Windows and Linux, Java and .Net
• Provides traceability between various ALM entities such as builds, environments, work items, etc

Let us look at some of the features that are coming soon. The screenshots shown below may change between now and when the service is made public.

Easy to use

Web interface 

You have been asking us to provide an easy-to-use web-based interface for RM. RM vNext has a familiar web based interface that is aligned with the rest of VSO. Getting started, authoring a release definition, and creating releases can all be done more easily in the web interface than in the current product. To simplify getting started, we have provided starter deployment templates. You can also create your own templates for your project.

It is easy to visualize what is happening with your releases using Overview and Releases pages. You have given us feedback to provide an overview describing which release is deployed in each environment. We have enabled that.

Simplified concepts

Team projects. The Release hub is integrated into Team projects.

Fewer concepts.“Release Paths” and “Release Templates” in the current version have been replaced by a single concept called Release Definitions. Using release definitions, you can define both the “path” (the series of environments and approvals that your applications needs to go through) as well as the “template” (the sequence of automation steps that should be executed in each environment). Furthermore, the concepts of “stages” and “environments” from the current version have been combined into a single concept named Environments. Within a single environment, you can now deploy to multiple resources or resource groups.

Distributed Tasks. The current version of RM was based on XAML workflows and tasks that were hard to extend and maintain. RM vNext is based on the same distributed task execution infrastructure as Build vNext. All the tasks in your Build and RM flows execute on a pool of agents. Build and RM share the same agent.

Security. The security infrastructure of RM vNext is different from the current version in that it does not manage its own groups and permissions. New permissions are introduced in VSO for RM vNext, such as “Create release definitions”, “Create releases”, and “Manage approvers”. Default values for these permissions are set for specific groups at various levels. These permissions can then be overridden for groups or individual users, for a specific release definition, or for a specific environment within a release definition.

Works for all your apps

Provisioning and Deploying to Azure resources

If you are developing Azure applications or if you are looking for cloud resources to host your Windows or Linux applications, then RM vNext has a great set of tasks that you can compose into your automation. You can deploy your releases to Azure websites, Azure cloud services, or Azure resource groups. All of these resources can be dynamically provisioned when you have a new release to deploy. We have tasks to easily copy your builds into Azure blobs or into Azure virtual machines. If these built-in tasks are not sufficient, you can always run an Azure Powershell script as part of your release automation.

Deploying to on-premise resources from VSO

With the new architecture, you can setup on-premise agents to run release automations locally. These agents will poll your VSO account periodically, pull down any pending automations that they have to run, and deploy builds to your on-premise servers. You do not have to open any firewall ports in your network or setup VPN connections.

You can store meta-data about your on-premise resources including their IP addresses or FQDNs as well as credentials securely, and then use them in your deployments. Deployments can be done by running Powershell scripts on these resources, or through IIS web deployment and SQL DACPAC deployment.

Linux deployments

To deploy to Linux servers, you have several options. To start with, we will support xplat agents for running your Shell scripts. You can also run maven or ant scripts to perform deployments. Alternatively, you can use DSC push to deploy to Linux servers. Finally, we also have integration with Chef.

Integration with Jenkins and on-premise TFS builds

You can use the RM vNext service even if you have not adopted VSO as your CI system. We have in-built support for deploying your on-premise TFS builds or even your Jenkins builds. To deploy on-premise TFS builds, you will need to setup an agent that has access to the builds.

Traceability and integration with other VSO services

Tracking work items, commits, and test results

For every release that you create, you will have information about what’s new in that release. RM vNext provides visibility into the new work items and commits that went into a release when compared to an earlier release. Every release also clearly shows the builds that it is made of and the branches those builds came from. If you run tests on an environment, then you can also see the summary of test runs within the release.

Continuous deployment

You can easily setup continuous deployment so that a new release is automatically created and deployed to multiple environments when a build completes.

Summary

To summarize, the vNext RM service provides a new set of release management and deployment capabilities in an intuitive web experience. It is more open and allows you to plugin your own tasks or deployment scripts to deploy to a cloud of your choice. Out-of-the-box, it has good support for deploying both Windows and Linux applications. Finally, it allows you to understand how your work items, changes, and builds are getting deployed to various environments.

FAQ

When will the RM vNext service be available in VSO?

Later this year. We are currently previewing this service to some customers. If you are interested in participating in the preview, send us an email to rm_customer_queries at microsoft dot com.

I am a current customer of RM service using the WPF client in VSO. What should I do to use the new features? Will my data be migrated?

You can either join our private preview program, or you can get these features when we go public later this year. The release templates and releases data that you see in WPF client will stay intact and will not be migrated to the new vNext service. The two services (current and Next RM services) will co-exist for some time. You will have to re-create your release definitions using the web interface.

When will these features be available in an on-premise version?

We do not have a firm date yet. Probably mid 2016. At that time, these RM features will be an integral part of your TFS server.

I am a current customer of on-premise RM server 2013 or 2015. Since the new features described above won’t be available until sometime in 2016, how should I use the current products so that my investments are carried forward?

We will ship the above features in a future update of TFS server. But, at the same time, we will continue to ship updates to RM server 2015. In other words, both the current RM server as well as the new RM features in TFS server will co-exist for a while. The data that you have  created in RM server will not be automatically migrated into TFS server. We are thinking about some guidance and tools to help you migrate the data partially when you decide to move to the vNext version of RM. To maximize the chances of carrying your investments forward, we recommend that you write PS scripts to drive your deployments with the current versions of RM server. You may choose to run these PS scripts either in agent-based release templates or in vNext release templates in RM server. In either case, when your deployments are largely driven by PS scripts, you will be able to leverage and run the same PS scripts in the new TFS integrated RM service.