I was showing someone my blog the other day and they asked when my last post was. I confidently said, “About a month or so ago..” and then I saw it…

Where did all those months go? Maybe I blacked out out or something…

In order to ease into my “blogging resurgence”, I thought I would start with a quick one regarding how I use VSTS and an interesting issue I encountered last night. Since this problem owes me a few hours, I hope it shortcuts somebody else’s pain.

I love how VSTS gives teams the flexibility to work in whatever way they like but a framework still exists to put some guard rails in place. More important than governance though is the ability to share proven DevOps patterns so team members can focus on the unique aspects of the solution rather than common activities like deployment.

Scenario

1. A series of environments in a DTAP (Dev, Testing, Acceptance, Prod) pipeline.
2. Each environment is a single web app that we wish to run as PaaS.
3. We would like to use deployment slots to perform a blue/green deployment when releasing a build.
4. Some kind of unit testing or load testing wouldn’t hurt… 🙂

Approach

1. Create a single environment.
2. Create a web app on Azure as a deployment target.
3. Add the required tasks for a blue/green deployment to the environment . i.e. Deploy to a Slot, Quick Performance test, Slot Swap.

4. Since these tasks are pretty consistent to all of the different environments, select all of the tasks, right click and then select Create task group from the context menu.

5. Name the task group and save it.
6. Specify the required properties you need to pass in as parameters using variables.  These will be the App Service Name, the Resource Group Name and the Azure Subscription.

The only property that doesn’t love this strategy is the Azure Subscription. In a normal build or release it is not possible to use a variable to specify the Azure Subscription normally but at some stage the VSTS team added the ability to use a variable for specifying the Azure Subscription in a task group. The issue I discovered last night is that there is some sensitivity however when it comes to the name of this variable.

IMPORTANT!!! If you try to use a variable name for the Azure Subscription with a hyphen in it like $(Subscription-Name), VSTS will attempt to verify the subscription and report a validation error. This will prevent you from saving the task group.

This took me a couple of hours to realise so as a result I was pretty motivated to share this for the common good of all. I removed the hyphen and the world was fair again. Save the task group and return to the release pipeline.

7. When back in the release definition, go to the tasks for the Dev environment and configure your task group. It should have a number of required parameters which we are going to specify using a Variable Group.

The subscription is the only one we can’t use a variable for, so go ahead and manually select the desired Azure subscription.

8. For all of the other properties lets create a variable group. For this example we need the ResourceGroup and the AppServiceName.

9. We can then link the variable group and scope it to the Dev environment. This means when variables with the names above are used in the release to Dev they will use these linked values.

10. From here we can clone the environment three times to create the entire DTAP pipeline. We also need to create the matching App Services on Azure that we will use for deployment targets.

11. We can then duplicate the variable group three times and create one for each environment. Unfortunately there isn’t a clone function so you have to do it manually. I do have a PowerShell script that can automate the process by hitting the REST API and I’ll throw that in another post before the end of the long weekend.
12. Finally we link all of the other new variable groups to the remaining environments and specify the scope so their values are used exclusively in that environment. We additionally have to ensure we have remembered to select the desired Azure subscription in all of the environments using the task group.

That’s it. We now have a DTAP pipeline where all of the environments are deploying to App Services on Azure. We are also using blue/green deployments that allows us to perform a quick performance test before we activate the new site.

We have a task group with our “recommended” way to perform web deployments which anyone in the organisation can use, regardless of the VSTS project. They can either manually specify the required parameters or as shown above, create a variable group for each environment with its specific properties. The next time a member of the team needs to add a new environment, they will simply clone it or add the task group, create the variable group and link it.

Isn’t consistency fun?