Hacker News new | ask | show | jobs
by scott_karana 3413 days ago
`git revert` is perfectly suited for this, since it makes a new "inverse" commit of the changes.

Your production deploys continue monotonically into the future as usual, and you now have version-controlled documentation of the rollback, instead of needing to maintain a separate mapping of production <-> code state.
2 comments
byroot 3413 days ago
Having an actual rollback mechanism that brings you back to a known working version is usually way faster than pushing a new version, since it needs to go through CI / Build etc again.

At my company rolling back is a matter of a minute or 2, while pushing a revert is more in the 5 to 10 minutes. Your mileage can definitely vary though.

However it requires all the shipped changes to be rollback compatible, which isn't that hard with a bit of experience.

link
pavel_lishin 3413 days ago
Doesn't this assume you only ever deploy one commit at a time?
link
scott_karana 3413 days ago
Cherry picks and merges are single commits... and fit well for a lot of dev->staging->release branch workflows.
link