3 ms·

I don't want to have to stay up late to do it. I don't want to have to deal with a rollback. I, and the developer, want to be able to make changes when we feel

I don't want to have to stay up late to do it. I don't want to have to deal with a rollback. I, and the developer, want to be able to make changes when we feel like it, not based on a schedule. The developer does their work at their pace, I go about my work without thinking about their deployment. Apps with planned downtime are often poorly designed and have other problems, usually due to nobody taking the time to make them work better or fix tech debt. Downtime deployments can lead to huge changes which, if not completed successfully, can lead to much longer downtimes in the event of a rollback. And, yeah, I don't want my customer to see any downtime or errors. Call me fussy, but I want our product to work better than everyone else's. It's 2021. We may not have flying cars, but we do have zero downtime deployments, sometimes. Let's not go back to the dark ages please.

slver 5y ago
Unfortunately "it's CURRENT_YEAR" and "downtime means you're poorly designed" are very poor, circular arguments. The only thing you said back which I can trace back to an objective problem is that you don't want to stay late.
- 0xbadcafebee 5y ago
  Would you rather a change 1) depend on two people doing a series of precarious steps and recovery which could possibly lead to a large amount of downtime, or 2) depend on one person doing a series of predictable small steps through automation which won't lead to any downtime? I prefer #2. Also I don't want to stay late.
  - slver 5y ago
    Planned downtime means only one thing: you have an atomic update, that needs some downtime. It doesn't inform you that the steps are "precarious" vs. "predictable" or that you have have or don't have quick way of recovery, or how small or big the update is. You can just as easily screw up your application state without downtime. You gotta be careful thinking purely by association. It's natural and intuitive, but often causes you to group unrelated characteristics together. Maybe my update is as simple as adding a column to a table. If I have millions of rows, that won't be instant, it can take say half an hour. In InnoDB for example it'll do a full table copy to add a column. But it's not precarious or fragile, or dangerous. It's just what it says on the can. It'll either do the copy or it won't.

slver 5y ago

Unfortunately "it's CURRENT_YEAR" and "downtime means you're poorly designed" are very poor, circular arguments. The only thing you said back which I can trace back to an objective problem is that you don't want to stay late.

0xbadcafebee 5y ago
Would you rather a change 1) depend on two people doing a series of precarious steps and recovery which could possibly lead to a large amount of downtime, or 2) depend on one person doing a series of predictable small steps through automation which won't lead to any downtime? I prefer #2. Also I don't want to stay late.
- slver 5y ago
  Planned downtime means only one thing: you have an atomic update, that needs some downtime. It doesn't inform you that the steps are "precarious" vs. "predictable" or that you have have or don't have quick way of recovery, or how small or big the update is. You can just as easily screw up your application state without downtime. You gotta be careful thinking purely by association. It's natural and intuitive, but often causes you to group unrelated characteristics together. Maybe my update is as simple as adding a column to a table. If I have millions of rows, that won't be instant, it can take say half an hour. In InnoDB for example it'll do a full table copy to add a column. But it's not precarious or fragile, or dangerous. It's just what it says on the can. It'll either do the copy or it won't.