When developing an application, we need to ensure that deployment to Production environment is rapid, with least or no downtime and most importantly ability to roll back previous version if new deployment fails or encounters any error.
In traditional world, this requires at least few hours of downtime due to redeployment of code, settings validation etc.
Azure WebApps provides a unique feature known as Deployment Slots. Microsoft official documentation can be found here.
Deployment slot is an option in the existing Azure WebApp instance with its own URL and configuration settings. Think of hosting multiple websites in a same IIS server. There is option to create multiple slots such as UAT, Staging etc. Let us say you have Web Application that runs version 1.0 of an application hosted on Azure Web Apps, the new version of same application “Version 2.0” is hosted on Staging slot. Once the testing is complete, you can then swap the slots to make Staging (Version 2.0) as Production now, and old Production (Version 1.0) becomes staging now.
If there are no errors or complaints then you could retain the environment as is else swap the slots again to make stable Version 1.0 Production again.
Though this sounds interesting, there are number of consideration to be taken here, one is that Database connection strings should not be swapped, if you don’t take care of this then Staging can start making changes to Production contents.
Let us see what settings are/can be swapped –
Settings that are swapped –
- General settings – such as framework version, 32/64-bit, Web sockets
- App settings (can be configured to stick to a slot)
- Connection strings (can be configured to stick to a slot)
- Handler mappings
- Monitoring and diagnostic settings
- WebJobs content
Settings that are not swapped –
- Publishing endpoints
- Custom Domain Names
- SSL certificates and bindings
- Scale settings
- WebJobs schedulers
Traditional Design – way of deployment on Azure WebApp
Explanation – In the design below, there is manual path to production from Staging environment to Production, and failover or fallback to previous version is not straight forward either.
Modern Design – way of deployment on Azure WebApp
Explanation – In this design, Production and Staging environments are part of same App Service Plan and are deployed on different slots. The database for each environment is slot fixed, which means connection strings of each slot is fixed. Using this method, path to production is just a click away and in the event of error, failover is quick and straight forward.
Benefits of using Azure WebApp deployment slots –
- Each slot has its own configuration settings as if they are different Azure WebApp environments.
- Each slot has its own publishing URL
- Staging slots can’t be auto-scaled
- You can have more than one slot
- Since Production and Staging slots are on same server (maintained by Microsoft, ofcourse), running performance testing tools on non-production slots can also impact the performance of Production slot.
- Auto-scaling on non-prod environment can’t be enabled.
Recommendation – is to use different Azure WebApp for Production, Development and UAT environments but for staging environment have it co-exist with the Production environment in different slot.
Hope this was helpful