Staging environments in Azure: Why should you try App Services Slots?

App Services

Maybe you have heard about App Services, the Azure PaaS where you can host your API, web and mobile applications. This service is aimed to developers since its phylosofy is that you have to worry only about your code, Azure will handle everything else. You just pick your application development stack, upload your code and you will have your application smoothly running, having at your disposal some features like auto-scaling, backups, certificates management, virtual network integration, CDN, etc.

What you may not know, specially if you have never used this service before, is one of its more powerful key features: Deployment slots.

Deployment slots

This feature allows you to have multiple versions of your application code and even with multiple environment configurations, each one of them placed in a slot. It’s like if each slot was a different web site with its own web address, although at the same time it’s all placed in a single App Service, which also provides you with the option of swapping the production slot with secondary slots, thus it’s an awesome feature to implement staging environments, particularly if combined with CI/CD processes.

Features

These are some functionalities provided by Deployment slots:

• Blue-green deployments: allow you to swap a secondary slot with the production slot.
• Canary deployments: You can configure in which proportion traffic will be forwarded to production or other slots.
• Warm-up: When swapping an slot with the production one, this slot previously will be warmed-up by sending some requests. It’s possible to customize its parameters, for example, to send these requests to a particular path or paths.
• Two-step swapping: the configuration of the destination slot is copied to the source in order to test the code with the “final” configuration. Once tested you can decide to cancel the phase or continue to the second phase, in which case you will complete the exchange from the source to the destination. Regardless of whether you cancel or continue, the change of configuration at the source will be reversed at the end of the process.
• Rollbacks: after making a slot exchange the new code will be in the production slot and the old one in the staging slot, so you only need to make a new exchange to go back to the previous situation.

Some characteristics and considerations:

• Every App Service has at least the production slot.
• You can add multiple slots, limit depends on the App Service Plan that you are using for this App Service. They are free of charge, there is no additional cost in your billing.
• Every slot has its own URL, which is generated by Azure. You can customize this to use your own domain.

Use case

Just imagine that you have an application in App Services with the url www.site.com and you want to publish a new version, so you deploy the code in a slot with the url staging.site.com. Both url can be accessible at that moment, so after doing proper testing in the slot you consider that this version is ok to go to production, you swap this slot (which have been warmed-up previously) with the production slot and just like that you would have the new code application published in www.site.com

Later someone lets you know that some users are recently experiencing problems with some functionalities in your web app. In this case you can rollback the current version by swapping again the staging slot with the production one.

Conclusion

As you can see, Deployment slots are a powerful feature, and we think that they are worth if you want staging environments with no effort.

If you have any doubt about this subject or just need our services, just contact us!