this post was submitted on 23 Jun 2023
3 points (100.0% liked)

Experienced Devs

3961 readers
1 users here now

A community for discussion amongst professional software developers.

Posts should be relevant to those well into their careers.

For those looking to break into the industry, are hustling for their first job, or have just started their career and are looking for advice, check out:

founded 1 year ago
MODERATORS
 

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.

you are viewing a single comment's thread
view the rest of the comments
[โ€“] funbike@programming.dev 0 points 1 year ago (1 children)

Zero downtime deployments can get very complex for heavy usage apps, such as blue-green deployment.

We decided to avoid the complexity with some practical workarounds.

  • Most deployments happen at 4am. "develop" branch merges deploy at 4am, and "master" branch merges deploy immediately.
  • We force browser refresh if the front end detects the back end has had breaking changes. We attempt to re-populate form field values.
  • During database migrations, we send 503 with Retry-After header in response to POSTs. Our client code knows to wait for that time and try again. If the time is too long, the user gets a friendly message that it will try again in X seconds. GETs are handled by an available read-replica, if possible.
[โ€“] hascat@programming.dev 1 points 1 year ago

We force browser refresh if the front end detects the back end has had breaking changes. We attempt to re-populate form field values.

Do users not find this disruptive?