In my last post I covered off how to set up a simple release process that deploys to an Azure Website in classic mode.

That process involved an explicit web deploy to each slot. What might be useful for some of you is to actually swap slots. There are some advantages to this, one of the principle reasons is that due to the way slot swaps work you can avoid a cold start of the website.

Setting up for this is reasonably straightforward, all this is involves is having a simple PowerShell script to do the swap for you in your code base which you ensure is in the output from your build and calling that from a task in your release process.

A lot of what I’ll cover here is based on the great documentation provided by the VSTS team,  https://www.visualstudio.com/en-us/docs/release/examples/azure/deployment-slots-webapps. However I’ll give you a few tips on how you can use variables in your release process and do it in the context of the process that I setup in my last post.

The script itself is trivial:

 
param (
   [string] $AzureWebsiteName,
   [string] $From,
   [string] $To
)
Switch-AzureWebsiteSlot -Name $AzureWebsiteName -Slot1 $From -Slot2 $To -Force -Verbose
 

I have this added to the root folder of my project in the example here.

Once you have this commited in source control you need to make a couple of adjustments to your build and release processes.

Open up the build process that you have defined in edit mode, I’ve gone back into the Simple WebDeploy build that I built in the last post, click on Add build step.

In the dialog select Utility and then Add a Copy files task.

Select the new task and configure it as shown here. Of course if you have your script in another folder you’ll want to set the Source Folder appropriately. I choose to use *.ps1 here so that as I add other PowerShell scripts that I want to use during release they’ll come along in future.

Then re-order the tasks by dragging and dropping so that the Copy files to task occurs before the Publish Artifact task:

Click on Save then OK in the pop-up dialog, add a comment if you like.  Then click Queue new build and accept the defaults in this dialog and click OK.

You should probably wait for this build to complete and then click on Releases in the second level navigation.

Click on the little down arrow next to the Release definition that you want to modify and select Edit:

Because we set up the old release process to treat each slot as a separate environment which the official docs from the VSTS team does not advise doing let’s bring this process in line with their recommendations. First let’s delete the “Production” environment.

Click OK in the dialog

Click on Add tasks, then Add the Azure PowerShell task and close the Task catalog.

Because we’re going to be using a few values in common between the two tasks that we have let’s configure some variables. Select the Deploy step and copy the value in the Web App Name input, replace this with a variable name $(webapp.Name)

We have a couple of options as to the scope that we can configure variables at, either for the entire release definition, which is available in the set of pivots just under the release definition name, or for a single environment. In this case as the value of the variable here would  change per target environment let’s create a variable for the target environment. Click on the ellipsis in the environment and then Configure variables

Click Add variable and enter the new variable and value. Strangely when I opened this I found some variables that I’d not setup. so I assume that they were created when I initially created the environment, feel free to delete any existing variables that are not being used in your definition. Then click OK to save your new variable.

Click on the Azure PowerShell script task, select the Azure subscription, the script path and enter the Script Arguments as below:

-AzureWebsiteName $(webapp.Name) -From dev -To production

At this point you could save the release definition and have a successful deployment, but let’s look at some more of the power that we have as we use variables.

We can set up our slot names as variables if we were so inclined, actually we can configure pretty much anything as a variable and if you have a definition scoped variable it can use one defined at the environment level. So let’s set up the script path and the script Arguments as variables.

Copy the value of the script path and enter $(script.swap.path) then click on the Variables link just under the release definition name. Click on Add Variable and enter the corresponding name and value. Repeat this process for the Script Arguments value using a variable named $(script.swap.args).

The variables pane should now look like this:

And the script task should look like this:

Time to test our the process. Save the definition and add a new release. If you navigate into the release and go to the logs pivot you can watch the deployment progress, or if it;s done by the time you get to the logs click on the Azure PowerShell step in the list and see that the nested variables have successfully been expanded and your swap slot script executed as expected

If you needed to add a new environment now all that would be necessary, once the target site and slots are created, would be to clone the exiting environment in the release definition and change the value of the webapp.Name variable in the new environment.

As you can see setting up swap slots is straight forward to set up and by using variables it becomes trivial to add new environments or change deployment targets.