3 ms·
> 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 v
by pdhborges 7mo 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?
- jamiemallers 7mo ago[dead]
- DrewADesign 7mo agoHaving data model changes be a part of regular deployments would give me persistent heartburn.
- redman25 7mo agoIt's why you always have a rollback plan. Every `up` needs to a `down`.
- hedora 7mo agoIf 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.
- DrewADesign 7mo agoAircraft engineer: “That’s why you have parachutes.” They might be an appropriate safeguard for a prototyping shop, but not for Delta.
- Swizec 7mo ago> 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/ https://swizec.com/blog/why-software-only-moves-forward/
- pdhborges 7mo agoI 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.