Comment by pdhborges
13 hours ago
> The other side of this is building safety nets. Takes ~10min to revert a bad deploy.
Does it? Reverting a bad deploy is not only about running the previous version.
Did you mess up data? Did you take actions on third party services that that need to be reverted? Did it have legal reprecursions?
> Does it? Reverting a bad deploy is not only about running the previous version.
It does. We’ve tried. No it’s not as easy as running the previous version.
I have written about this: https://swizec.com/blog/why-software-only-moves-forward/
I read the article and to be honest I don't know where we disagree. I disagree with this quote,
> Takes ~10min to revert a bad deploy
A bad deploy can take way over that just in customer or partner management communication.
Having data model changes be a part of regular deployments would give me persistent heartburn.
It's why you always have a rollback plan. Every `up` needs to a `down`.
If you do that, it expands your test matrix quadratically.
So, it makes sense if you have infinite testing budgets.
Personally, I prefer exhaustively testing the upgrade path, and investing in reducing the time it takes to push out a hot fix. Chicken bits are also good.
I haven’t heard of any real world situations where supporting downgrades of persistent formats led to best of class product stability.
Would love to hear of an example.
[dead]