Curious to know how many people do zero-downtime deployment of backend code and how many people regularly take their service down, even if very briefly, to roll out new code.
Zero-downtime deployment is valuable in some applications and a complete waste of effort in others, of course, but that doesn’t mean people do it when they should and skip it when it’s not useful.
Whenever possible, I’ve run projects to have zero downtime deployments. Multiple stateless instances behind a load balancer. Deploy one instance at a time, run a health check and move traffic to the fresh instances. Most cloud providers often have these out of the box. Database migrations are run well in advance. New functionality is hidden behind feature flags.
Zero downtime is nice, but the real benefit is that you force the teams to really think about deployments as migrations to accomplish this policy.
Your instrumentation and alerting need to be top-shelf you need to automate deployments fully, which means you can fully automate rollbacks.
The downside is that you have to build everything twice, deployments are slower and there is a significant descaffolding.
But that’s a small price to pay not to be on call outside of business hours to deploy.