Production deployments are one of the most hated software rituals. There are so many overwhelming customs to take care of – pre and post deployment.
Managers have to seek permission, and notify stake holders of downtimes. To minimize impact, deployments are scheduled late nights or odd hours leading to additional inconvenience.
Lots of questions linger in our minds during deployments.
- What will happen if deployment fail?
- How long will it take to detect the cause?
- How long will it take to fix the problem?
- Should we rollback?
- Should be fix it immediately?
- What is the business impact ?
With Agile – frequent deployments becomes even worse with above problems.
Azure deployment slots can help us deploy fearlessly to production without worrying. We do not have to seek permissions, notifying users, and cause any downtimes.
Deployment slots lets us test our newer code changes in parallel to production by copying configurations. So you can have 2 websites, one with older code and another newer – both pointing to same prod database.
When we create a new deployment slot, we are adding an additional website to app service virtual machine. Like creating another IIS website. All the static content, and most configurations are copied over to this new website.
Say if we have v1 code right now in production, and we create slot for v2 code; then v1 and v2 share the configuration, storage, and dependencies.
We can test v2 without bring down v1. After verification is complete – we can just swap v1 and v2 slots. That’s it – our v2 is now deployed to production without a downtime.
This way, we can test our newer code changes with same production configuration.
Swapping slots after verification is the biggest advantage of deployment slot.
Swapping deployments can be used in following use case scenarios.
Staged deployment: Staging is useful for websites where users are currently logged-in. You can create a staging slot, deploy new code here, and verify. On completion, just swap it with production slot. New code is deployed to production without any downtime.
Incremental deployment: Sometimes post-deployment we have to modify database tables or add master data. In such cases, we can create a separate slot, deploy code, and do these changes. After verification is complete, we can swap the new slot with production.
- Rollback deployment: Swapping back production slot to rollback to older version is easy. Issues found post deployment can be handled quickly this way.
Since deployment slots share the production virtual machine – performance testing on slots can affect the production.
Stateful applications are not easy to manage with deployment slots. We will have to do some guess work, and it spoils the fun of deployment slots.
Also, swapping will not port below configurations because
- Custom domains names: Domain names exposed to customers will not change on swapping, hence users window urls remains the same.
- SSL certificates: We do not have to bother with porting SSL certificates between slots. Production SSL settings are intact.
- Repository source: Master branch will point to production even though we are swapping.
- Scale settings: Obviously, we do not want to be scaling and incurring bill for staged environments. Only production will scale the way.
Deployment slots are of advantage to both software teams, and businesses. Also, they save you bunch of money if you are currently using separate apps for each of dev, stage, and prod.