In Conventional web hosting, we deploy or publish an application to hosting and soon after publishing, user can access the application via an endpoint or a domain (say myapplication.com). Consider a scenario of releasing next version of same application, we again need to release the solution into another staging environment which need to have environment settings which is a manual and time-consuming job. In other words, another staging environment need to prepare with same setting manually and release the application. Once the new release passes the testing then again, we need to deploy this into production hosting manually. There are several others background tasks are involved during the release management like taking backup and setting environments likewise.
Another hassle is rollback. If our latest release is having any issues, then we will again need to rollback to previous version manually which is time consuming and error prompt task. Again, reverting settings, environments and all are painful job as well. The major issue is user impact, which means during the release, update and rollback, there will be downtime and end user cannot use the application.
Azure App service gives another remarkable feature to overcome the above mentioned problems which is deployment slots.
Deployment slot, one of the incredible features is probably the most underrated and many people do not know about it.
In this article we will explore about deployment slots, one of the remarkable features of Azure App service which is quite useful for developers and DevOps engineers to over the problems of managing releases and rollback. I will cover following topics in this article.
- Azure App service introduction
- What is deployment slot in azure app service?
- Some facts about deployment slots
- Swapping in Deployment slots
- Rollback
- Setting that are/are not swapped
Let us begin.
Azure App service
Azure app service is one of the services of azure for hosting websites, and APIs. It is a cloud-based platform created and managed by Microsoft. Azure App service is PaaS, platform as a Service where we can quickly build, deploy, and scale web apps and APIs based on your requirements. It works perfectly with .NET, .NET core, Node.js, java, Python or PHP, and other programming languages.
Azure App services are much flexible to developers or DevOps engineer. It has several useful features like scaling or auto scaling in a click, easy authentication and secured with standard security compliance, offline sync (Mobile Apps), hybrid connections, easy sharing, monitoring, and insights, many more configuration and extensive features. It is highly scalable, secured, trusted, and fully managed platform.
You can find many articles in Microsoft docs and c-sharpcorner itself.
Deployment slots in azure app service
This is also called as slotting in azure app service which is one of the amazing features. Let me elaborate with one example.
Suppose we have one azure app service with endpoint production.azurewebsites.net where we have deployed an application and is in production. With the deployment slots feature, we can add another slot which is a full-fledged app service with different end point URL like production-stg.azurewebsites.net. Now, we can copy the configurations and settings of production environments into the newly added slot (called as deployment slot) and can deploy the new release of the application. The new release into this deployment slot will not do any impact on production environments. Therefore, user will continue to access our live application and same time we can deploy next version where we can carry-out full testing and verification.
Swapping is another advantageous feature about deployment slots. Instead of deploying again new release of application into production environment, we can simply swap staging slot (newly added deployment slot) with our production within same app service. The magic of deployment slots: we can do swapping with zero downtime which means, end users will notice nothing and experience no downtime.
Yes, users will experience no downtime.
Therefore, this is one of the awesome features of Azure app services.
Some important points about deployment slots
- Slots are different environments exposed via a publicly available endpoint. (can accessible via another URL)
- Default app instance is always mapped to the production slot.
- Can copy the configuration (app settings and connection strings)
- Swap option: we can swap between slots
- Use same app service plan therefore, scaling (up or down) will be applied to every slots.
- Deployment slots are free to use.
- Comes with standard pricing tier or higher
- If you have installed any site extensions, you need to do that again in a deployment slot, as it is a new App Service instance
Swapping
We can do swapping between slots without any downtime within same app service.
- Traffic redirection is seamless; no requests are dropped because of a swap.
- If a function is running during a swap, execution continues, and the next triggers are routed to the swapped app instance.
- Yes,users will experience no downtime
- What is a swap does?
- Warmed-up source slots by firing couple of requests into root slots. (Custom warm-up rules)
- Swaps virtual IP address between source and destination, thereby swapping the URLs of those slots
Continuous deployments and Authentication settings, if enabled
Rollback
Another advantageous feature with deployment slots is rollback.
In case, if we are unhappy with latest release in production or having issues then we can easily rollback to reverse the effect with deployment slots without any downtime or user impact. In order to do reverse back, again we can do swap with the deployment slot.
Swapping Options
There are following options for swapping
- Manual swapping
- Auto swap
- Swap with preview
- Swap and VSTS
Manual swap
By name, it is clear that we can do swapping from azure portal manually. We can choose source and destination slots and swap it.
Auto Swap
You can choose to swap automatically to a slot when there is a new version of your app in a deployment slot – this is called Auto Swap.
Swap with Preview
- It performs the swap in stages.
- It applies the configuration elements of the destination slot to the source slot, so you can test if everything works as expected before the actual swap happens.
- If you complete the swap, it does the same as in a manual swap, warm-up the slot and performs the swap.
Swap and VSTS
We can take advantage of deployment slots and swapping with Visual studio team services. You can deploy a new version of your app to a deployment slot and then swap it using steps in a release definition.
Setting that are/are not swapped
Settings that are swapped,
- All the General settings, like framework version, 32/64-bit, web sockets, OS (window or Linux)
- App settings based on demand
- Connection strings based on demand
- Service endpoints *
- Handler mappings
- Azure Content Delivery Network *
- Public certificates
- WebJobs content
- Hybrid connections *
Settings that are not swapped,
- URL or Publishing endpoints
- Custom domain names
- Scale settings
- WebJobs schedulers
- IP restrictions
- Non-public certificates and TLS/SSL settings
- Cross-origin resource sharing (CORS)
- Virtual network integration
- Always On
- Diagnostic settings
Conclusion
In this article we have learned about deployment slots, one of the remarkable features of Azure App Service to overcome the issues related releasing new version of an application and rollback based on demand. In next article, I will demonstrate on how to create deployment slots and do swapping and rollback in azure app service from Azure portal.