Azure Website Deployment Slots
When you deploy your web app, web app on Linux, mobile back end, or API app to Azure App Service, you can use a separate deployment slot instead of the default production slot when you're running in the Standard, Premium, or Isolated App Service plan tier. Deployment slots.
A version of this article appeared on ruslany.net
Azure Resource Manager (ARM) templates are used to automate deployment and configuration of Azure resources. With the templates you can define the infrastructure to be deployed via a JSON file and then use that file to repeatedly deploy new resources or update existing ones. ARM templates are widely used to release new versions of the Azure web apps and function apps. During a release the new version of an app is deployed to a staging slot and then it is swapped into production. This blog post explains how to automate the App Service deployment slot swap operation with an ARM template.
Let’s assume you have a web app with production and staging deployment slots. When you release a new version of that web app you first would deploy it to the staging slot and then swap it into production slot. To define the swap operation via ARM template you’ll need to use two properties on the “Microsoft.Web/sites” and “Microsoft.Web/sites/slots” resources:
buildVersion– this is a string property which can be set to any arbitrary value that would represent the current version of the app deployed in the slot. For example: “v1“, “1.0.0.1“, “2019-09-20T11:53:25.2887393-07:00“.targetBuildVersion– this is a string property that is used to specify what version of the app the current slot should have. If the targetBuildVersion is different from the buildVersion then this will trigger the swap operation by finding a slot that has the expected build version and then swapping the site from that slot into the current slot.
- During the swap operation the site in the staging slot is warmed up by making an HTTP request to its root directory. More detailed explanation of that process is available at How to warm up Azure Web App during deployment slots swap. By default the swap will proceed as long as the site responds with any status code.
- Create a deployment slot If you have a Standard service plan or higher, you can use deployment slots. To create a new deployment slot, you should use the New-AzWebAppSlot cmdlet as shown below. $StagingSlotName = 'Staging' New-AzWebAppSlot -Name $webApp.Name ` -ResourceGroupName $resourceGroupName ` -Slot $StagingSlotName.
- After the slot is created, if you click on the slot, you will be taken to another Web App. So what happens behind the scenes is Azure does create another Web App with some more sugar on top of it so that it can be classified as a deployment slot. You can use this slot to push code to this the same way you have pushed to the original Web App.
With that the process of deploying a new version of an app can be done as follows:
- Deploy a new version of an app into a staging slot
- Execute ARM template to update the buildVersion of the app in staging slot
- Execute ARM template to set the targetBuildVersion on the production slot
- Here is an example ARM template that demonstrates how to perform steps #2 and #3:
This ARM template is idempotent, meaning that it can be executed repeatedly and produce the same state of the slots. In other words if you re-run the same template with the same parameters after the swap has been performed and targetBuildVersion on production slot matches the buildVersion then it will not trigger another swap.
Helpful links
I should start this post by apologizing for getting terminology wrong. Microsoft just renamed a bunch of stuff around Azure WebSites/Web Apps so I’ll likely mix up terms from the old ontology with the new ontology (check it, I used “ontology” in a sentence, twice!). I will try to favour the new terminology.
Azure Website Deployment Slots Software
On my Web App I have a WebJob that does some background processing of some random tasks. I also use scheduler to drop messages onto a queue to do periodic tasks such as nightly reporting. Recently I added a deployment slot to the Web App to provide a more seamless experience to my users when I deploy to production, which I do a few times a day. The relationship between WebJobs and deployment slots is super confusing in my mind. I played with it for an hour today and I think I understand how it works. This post is an attempt to explain.
If you have a deployment slot with a webjob and a live site with a webjob are both running?
Yes, both of these two jobs will be running at the same time. When you deploy to the deployment slot the webjob there is updated and restarted to take advantage of any new functionality that might have been deployed.
My job uses a queue, does this mean that there are competing consumers any time I have a webjob?
If you have used the typical way of getting messages from a queue in a webjob, that is to say using the QueueTrigger annotation on a parameter:
then yes. Both of your webjobs will attempt to read this message. Which ones gets it? Who knows!
Doesn’t that kind of break your functionality if you’re deploying different functionality for the same queue giving you a mix of old and new functionality?
Yep! Messages might even be processed by both. That can happen in normal operation on multiple nodes anyway which is why your jobs should be idempotent. You can either turn off the webjob for your slot or use differently named queues for production and your slot. This can then be configured using the new slot app settings. To do this you need to set up a QueueNameResolver, you can read about that here
What about the webjobs dashboard, will that help me distinguish what was run?
Kind of. As far as I can tell the output part of this page shows output from the single instance of the webjob running on the current slot.
Azure Website Deployment Slots No Deposit
However the functions invoked list shows all invocations across any instance. So the log messages might tell you one thing and the function list another. Be warned that whey you swap a slot the output flips from one site to another. So if I did a swap on this dashboard and then refreshed the output would be different but the functions invoked list would be the same.
