Automating Releases to Separate Azure Resource Groups using both TFS and VSTS

Developer Support

This post is written collaboratively by Premier Developer Consultants Ilias Jennane and Daisy Chaussee along with App Dev Manager Wyn Lewis-Bevan. Read on to learn how to build a solution in TFS, release it in VSTS, and automate the deployments to separate Azure Resource Groups.

Business Case:

One of our customers recently challenged us with a use case that is not very common. They wanted to keep using TFS 2015 for work item management, git source control, and build management. However, they also wanted to use VSTS for release management into Azure. In addition, their deployment process is quite advanced. They deploy the same application to hundreds of customers in separate resource groups, but they do not wish nor want to have to create hundreds of release definitions, and above all they want close to zero manual intervention steps.

You may ask, why? And we did too. Their (decently large) team is currently heads down focused on delivering the product they are building and cannot afford any migration time to VSTS. They also had some upcoming tight deadlines. Hence, they didn’t want any disruption to their teams, but they did want to accelerate their deployment process using built-in capabilities in VSTS release management.


Azure to the rescue: The solution is extremely simple and relies heavily on existing features in Microsoft Azure.

1- Bridging TFS and VSTS:

The team continues doing what it has been doing without having to change anything. They push their commits to a source control repository in TFS 2015, and they have a continuous build definition that builds their application. What we added to that build definition is an additional step that uploads the build drops to an Azure file storage location. For simplicity we used Azure Files as the drop destination. We named the folders using the name definition.

2- Automating deployments to separate resource groups:

We chose to build a VSTS extension that encapsulates the whole deployment process. A release manager selects a customer name from a drop down. This triggers a release for that customer’s environment.

For each customer that will be managed using this utility, we store all of their target deployment information in an Azure Key Vault. Once that customer name is picked from the drop down, we connect to the vault, get the information we need, and trigger a release definition to deploy the application.

3- Working around (current) known limitations:

Currently VSTS release definitions do not allow overriding variable values at run time. So, when we pick a customer from the drop down we can’t really pass that customer name to the release definition. This created another challenge, since we needed to change this information on the fly. The solution is simple as well, we used a build definition in VSTS, since they allow overriding variable values at queue time. This build, which doesn’t do any code building, simply takes a variable as an input (the customer name), downloads the TFS 2015 build artifacts from the Azure storage, then publishes them as artifacts to be used in the release definition. For simplicity, the customer name is written into a text file and added to the build artifacts as well; simply the customer name and nothing else, because we don’t want secure information to be copied to text files or artifacts. From there everything is handled via a normal VSTS release definition.

What it looks like:

Let’s look at the TFS 2015 build definition. It builds a simple web application, zips it and then uploads it to Azure files.



The PowerShell script connects to the Azure files and uploads the zip file:


(This is a proof of concept, in a real-life scenario you may want to use much more advanced security practices for passing parameters to PowerShell files)

Once these files are uploaded they are labeled using the build number:


The extension that we build in VSTS fits into VSTS as follows:

– It sits right under the “Build and Release” VSTS Hub.


– It has an extremely simple user interface (this is just a sample):


The most important aspect of this extension is the release manager picks a build, a customer and then the rest is done by the extension. It gets the information for that customer from the Azure Key Vault, downloads the TFS 2015 build drops from the Azure Files and kicks off a release pipeline into several validation environments before going sending it to product. The release process itself is managed via the release definition:



While the scenario we’ve built may not be very common, the possibilities we were able to explore show that the most important aspect is to define your business goals clearly, then quickly experiment.


In addition to this posting, this blog post has been published here.


Discussion is closed.

Feedback usabilla icon