VSTS Release Management plans for 2016 H1

[Update as on April 15 2016: There is a newer version of this blog and an update to our plans: Release Management Planning Update 2016 H2. Please post your comments on that blog. This blog is now closed for comments.]

After opening the VSTS Release Management service for public preview at Connect(), we are now gearing up for rolling out the next set of features into the service. Here are a subset of improvements and features you can expect to see in the first half of 2016.

Better control over deployments

We are working on a set of features that are aimed at providing you with better control on how you manage your release processes. Here are some features that are lined up in this space.

Better control over order of environments in a release (Q1 2016)

Here are some common requests that we have seen – (1) Once a build is completed, you need to deploy and run automated tests in parallel on multiple environments/configurations, (2) Once the release is successfully deployed on Dev environment, you would like to deploy and test it on multiple QA environments in parallel, (3) You want to start with the deployments to production to be always manually triggered, etc. Currently, the Release Management service constrains you to define a linear pipeline of environments. You will no longer have to do that. On each environment in a release definition, you will have the flexibility to model a trigger/deployment condition. Using this approach, you can model all of the above examples and more using a single release definition. You will also be able to manually promote the deployment to a selected environment without having to go through all the dependent environments.

Better control over deployment of multiple releases into an environment (Q1 2016)

Your CI pipeline may produce builds faster than they can be deployed onto environments in a release management process. Or, multiple releases may be queued up on Prod waiting for an approval after they have passed QA, and it may be desirable to just deploy the last one. To have better control on how multiple pending releases get deployed into a given environment, we are introducing queuing policies for environments.

Better control over time of deployment into an environment (Q1 2016)

You may want to approve a release to be deployed to Prod environment now, but really want that deployment to happen at midnight. We are introducing the ability to defer the deployment at the time of approval.

Better control over approvals (Q1 2016)

You may want to configure multiple approvers for an environment, and in that case, you may want to control whether those approvers have to go one after the other or can approve in parallel. We are adding approval options to help you control this.

Better visibility into releases

We will continue to improve on traceability of ALM assets, and bring in the following features:

  • (Q1 2016) When deploying a release into an environment, you would want to know what exactly is being deployed – work items, commit list, build artifact versions, etc. We will compute this based on what was previously deployed into that particular environment.
  • Test Results in RM: Just like we shipped in-context test results experience in continuous integration, we will be adding in-context test results experience to Release management as well.
  • History of deployments on an environment.
  • Audit history of all operations, deployments, and changes made to a specific release.
  • Dashboard integration

Deployment and testing of your apps

We are aiming to make the following scenarios simpler in Release Management:

  • (Q1 2016) SCVMM integration: An SCVMM extension in the marketplace with the capabilities to create SCVMM endpoint, provision new VMs in SCVMM, and restore VMs to a clean snapshot.
  • (Q1 2016) VMware integration: A VMware extension in the marketplace with the capabilities to create VMware endpoint, provision new VMs in VMware, and restores VMs to a clean snapshot.
  • Azure IaaS integration: Creating SPN based service endpoints to Azure, provisioning VMs in Azure, running remote scripts on those VMs, and running tests on those VMs.
  • Azure PaaS integration: Deploying Azure web apps, SQL Azure databases, using deployment slots for zero downtime, and changing configurations in each environment.

APIs and extensibility

  • Publish REST APIs.
  • Publish Service hooks.
  • Publish Release hub UI contribution points.

Besides bringing all these new features to VSTS, we are also aiming to integrate RM service be part of on-premises TFS server by 2015 Update 2, so that you have a choice of using VSTS or TFS for all your release management needs.


Documentation for Release Management.

You can track all of the new features as and when they get deployed in the What’s new section.

Have a question? Follow us on Twitter (@vsreleasemgmt).