Azure 0s downtime with deployment slots & App service
I am currently maintaining a Umbraco project (7.3.8) with Azure for a client of mine. I have app services & Azure devops (vsts) as source control (git).
I have a pretty standard architecture (development-test-staging-production). Every instance is linked to a git branch and it gets automatically deployed with vsts and the deployment center.
The production instance is the only instance that is public. The other instances are protected by ip restriction.
I created a deployment slot with a separate branch (live-clone) and pushed the code to this branch, load the website, swap with the live instance before merging the code with the master branch.
While I can still swap instances, I can never merge my code with the master branch as it forces the live website to restart regardless of deployment slots.
In short:
I create a deployment slot called 'live-clone' and bind it to a branch called 'live-clone'
I push updates to the live-clone branch. The website restarts and rebuilds the index. - the live website is still working fine.
I swap the main production instance with live-clone.
The changes I pushed are now live
I merge the master branch with the live-clone branch
The live website restarts, causing a downtime.
Is it a normal behavior ? How do you manage to reach 0s downtime with app services in Azure ?
We are going through the same process. We have decided to link master branch to the "live-clone" slot, or "warm-up" slot in our case. We do not have any release pipeline targeting the production slot and never deploy to it. We only deploy from master to "live-clone" then swap into production... Done.
Would this approach not meet your needs for some reason?
Thank you for taking the time to explain, we figured out the way Azure wants us to use deployment slots a bit ago but I am glad you are using the same workflow than us.
Azure 0s downtime with deployment slots & App service
I am currently maintaining a Umbraco project (7.3.8) with Azure for a client of mine. I have app services & Azure devops (vsts) as source control (git).
I have a pretty standard architecture (development-test-staging-production). Every instance is linked to a git branch and it gets automatically deployed with vsts and the deployment center.
The production instance is the only instance that is public. The other instances are protected by ip restriction.
I have issues when I push to production as it forces the website to restarts, giving me about 2-5 min of downtime. I have followed the best practices for this kind of environment (https://our.umbraco.com/documentation/getting-started/setup/server-setup/azure-web-apps) but I am looking for a solution to reach 0s downtime.
I created a deployment slot with a separate branch (live-clone) and pushed the code to this branch, load the website, swap with the live instance before merging the code with the master branch.
While I can still swap instances, I can never merge my code with the master branch as it forces the live website to restart regardless of deployment slots.
In short:
Is it a normal behavior ? How do you manage to reach 0s downtime with app services in Azure ?
A similar question was asked on stackoverflow: https://stackoverflow.com/questions/40773941/how-to-achieve-zero-downtime-deployment-to-azure-web-app-with-database-updates
We are going through the same process. We have decided to link master branch to the "live-clone" slot, or "warm-up" slot in our case. We do not have any release pipeline targeting the production slot and never deploy to it. We only deploy from master to "live-clone" then swap into production... Done.
Would this approach not meet your needs for some reason?
Hi Bryan,
Thank you for taking the time to explain, we figured out the way Azure wants us to use deployment slots a bit ago but I am glad you are using the same workflow than us.
Best,
One thing we noticed after swapping is the Examine index getting out of date. So after swapping we rebuild the index.
is working on a reply...