Azure Slots / Staging Environment – Making Deployments Easier
How happy would you be if you got a chance to test your app in the same platform/environment as your production?
Azure slots do that for you. To be more precise you get to test it in your production environment.
Azure App Services is one of the extremely useful services consisting of web apps, API Apps, web jobs etc. They provide a host of amazing features like scaling, backups, SSL support, custom domains to name a few. But Azure deployment slot is one such feature which is often underrated & mostly underused.
Common Deployment issues
1. Testing the new version of the app
Consider you have a web app running on your app service & your app’s URL is something like Prodapp.azurewebsites.net & is already live. Now, you have updated your web app and you want to deploy the new version to your production URL. Before that, you need to test your app for correctness. One obvious way and the common practice prevailing is to create a new app service & deploy the new web app, port the configurations & test it over there.
2. Deploy/Rollback
Now you have tested your app and you are ready to deploy the app to your production URL. Now you will be publishing the app, which in turn would require a downtime for deployment, test & depending on the architecture of your app you may need to pay a cold start penalty too. And what if you want to rollback your deployment in case of an issue?
3. Deployment Slots to the RESCUE
Azure deployment slots help you overcome all these issues. Consider deployment slots as different boxes inside your App Service. Each slot will have its own publishing profile, its own configurations & app settings. The default slot (even if you don’t create one) as soon as you do a deployment to your app service is your production slot. You can create new slots to deploy a new version of your app.
Deployment slots to rescue
Here, if you want to test a new version of your app, create a new slot, get the publishing profile & deploy your new version over there. You now have a production ready version of your app, in the same environment as like production but with different URL, configurations & app settings. Depicted below is how your apps would have been deployed.
How your apps would of been deployed
Deployed app to production no downtime
You have deployed your app to production with no downtime. Azure also warms up the slots before the swap & hence you don’t run in to cold start issues. In case you need a rollback, you do a swap again and that’s it!!
Considerations
Below are few points you need to consider before starting with deployment slots,
I) Deployment slots are supported only in the Standard or Premium App Service plan mode
II) When your app has multiple slots, you cannot change the mode
III) Scaling is not available for non-production slots
IV) Each App Service plan mode supports a different number of deployment slots
V) Each slot shares the same pool of resources as your live/production slot. So load test is not suggested here
VI) Deployment slots have a different URL than the original App Service. This URL is based on the name you give the deployment slot
VII) When you scale a deployment slot, you also scale all other slots of your App Service. This is because all slots share the same App Service Plan
Reference:
Jayabalan, C (2018) . Available at: https://blog.hubfly.com/azure/azure-slots-staging-environment-making-deployments-easier (Accessed 20 June 2018)
