Shipping & Running
$definerollback--plain-english
TLDRPutting the last good version back on stage.
The disaster is not the bad deploy. The disaster is standing there with no previous version to put back.
Rollback is the undo button for the live app. The new version is up. Judges are hitting it. The login is on fire. The panic move is to fix it live while they watch. The professional move is to put last hour's working version back on stage, then fix the broken one in private.
Platforms remember old builds on purpose. Vercel, Cloudflare, most hosts: previous deploy, one click. That memory is the product. Use it.
Workshop vs storefront
A git revert happens in your workshop. You walk the code back while you build. A rollback happens at the storefront. You flip what the public is hitting. Same instinct — every version is already saved — two different rooms. Don't confuse "I undid the commit" with "the judge sees the good URL again."
A rollback that needs a 40-minute database migration is not a rollback. It is a project. Keep deploys small so the fire exit still fits. Staging is how you avoid needing the exit. CI is how you stop shipping the obvious red.
At a hackathon, practice the click once before you need it. Know where "previous deploy" lives on your host. The builder picked a lobby; the lobby's undo is part of the pick. A clever Docker file you wrote during lunch is worth less than a platform that can rewind.
Feature flags are a finer tool: kill one feature, leave the rest. Rollback is the whole house.
What this unlocks
Deploying stops being a held breath the moment undo is one button. You are no longer promising the new version is flawless. You are promising that if it isn't, the audience sees the mess for a minute and then the good show is back. Shipping isn't brave because you're certain. It's brave because rollback turns a bad version into a short problem.