I used hot deploys extensively at my prior job. I wrote up my thoughts on it a while back (Why Hot Deploys are Cool | Greg Vaughn’s Musings). The landscape has changed in the past couple of years with distillery no longer being the primary tool to build releases though.

Voted “No”. I don’t care about the hot-upgrade thing and I pray I never need it.

But even if you end up needing it, IMO just having blue-green deployments with a load balancer is good enough.

No, but I am interested. I have an app that have internal state that taking many network loads and significant time to recover.

I am not experienced in hot upgrades but I’ve heard same thing you said repeated a number of other times and I admit this made me develop a remote (as in: not personally confirmed) bias to it.

IMO I think our current model of deploying apps is super outdated anyway e.g. if you need persistent WebSockets connections they absolutely must be managed by something else like a load balancer or a CDN-like service in front of your “real” app so as people never actually disconnect – and when you are redeploying your app the service on top should employ the blue-green deployment model and transparently hand-off the state and connections to the new app.

Same idea goes for DB connections and all other stateful components. Some cloud providers are doing this really well with attachable HDD / SDD volumes were you have literal zero downtime even if you issue a command like “please give me 50GB more”. Your app will never find out that it happened, it will just have access to the bigger storage medium right away.

…But that’s going in the territory of advanced computing R&D activities that nobody wants to champion, sadly.

Kubernetes deployments!!