12 ms·
> If you deploy a broken build, a rollback to an earlier version should never, ever, require a rollback on your source control. Why not? In some cases in light
by rileymat2 5y ago
> If you deploy a broken build, a rollback to an earlier version should never, ever, require a rollback on your source control.
Why not? In some cases in lighter weight systems, you might have a release branch that gets pushed to production. Like dokku.
- pdpi 5y agoKey word there is "require". Having that automation set up is super convenient and a pretty important factor in making things more productive, not contesting that. The other side of the equation is that if I break something, I want to make the smallest change possible that fixes it, so as to avoid confounding variables if it doesn't work. Off the top of my head: * I don't want to make things worse by messing up the rollback due to stress * I don't want to trigger a build and wait for CI to run and build * I don't want to depend on my build not being perfectly reproducible (e.g. because the problem comes from a bad dependency upgrade and the rollback rebuilds with the bad dependency) What I do want is a really simple way to just tell my system "You know that thing you were running 5 minutes ago? Please go back to running that again".