Microsoft released a clever feature for Azure web apps called “Deployment Slots.” This feature has capabilities that can improve availability of your web app by reducing downtime due to deployments, and reducing time to recover from failure. It can be useful in some scenarios, but there are limitations.
A deployment slot is separate configuration for a web app, and represents another target location to which you can deploy the web app.
Why would you want this? From the documentation for deployment slots, we learn that you can
- validate web app changes in a staging deployment slot before swapping it with the production slot
- deploy first to a slot, warm up the app, then make a hot swap with production
- easily swap back to revert the changes if the new software does not work well
These are the capabilities that improve availability. However, there are some limitations of this technology, as well as alternate ways to reduce downtime from deployments and deployment failures.
Some of the limitations stated in the documentation include
- When your web app has multiple slots, you cannot change the mode.
- Scaling is not available for non-production slots.
- Linked resource management is not supported for non-production slots.
These do not seem like serious limitations to me since there are workarounds for most of them. If deployment slots are used merely to help reduce deployment downtime and aid in rapid recovery, then I am interested. But there have been some people suggesting these slots are an easy way to create a full stack of environments (dev, devTest, QA, Staging, Prod) through which you can deploy changes to the web app. I would not pursue that myself. One reason is a limitation not mentioned in the documentation on deployment slots. As others have noted, the limitation is related to Azure diagnostic logs. You configure those per web app, NOT per slot. So if you were to be clever and setup a dev, QA, and staging slot, you would find that error messages from those slots would appear in the Azure diagnostic logs, alongside the production messages. This would be highly disruptive to logging. Each environments logs should be isolated from one another.
So, if we use deployment slots to merely create a staging environment, and that is used solely to warm up and run some basic smoke tests, then it may make sense to use them. But I would be reluctant to use deployment slots for development environments, because I would pollute my production logs with test data, and confuse testing with production messages.
The other reason that may limit the use of deployment slots is that real-life, complex systems may involve elaborate automation to properly deploy multiple components. If you already have developed a sophisticated automated deployment framework, then the incremental advantages of deployment slots may be modest.
Still, there may be many customers who have primarily one web app, and do not use sophisticated deployment automation. Deployment slots would be a great staging tool in these cases.