Skip to content

rollback

A rollback is the act of returning a running system to a previous, known-good version after a deploy goes wrong, undoing the change as if it had never shipped. It is the fastest way to end an incident caused by a bad release. Instead of debugging under pressure, the team puts the last working version back in front of users and investigates later, choosing one of two paths depending on what shipped:

A teal "New version failing" box feeds a decision diamond branching to a green "Last known good restored" box and a coral "Roll forward, ship hotfix" box, with a dotted arrow to "Fix on a branch".
A code change reverts to the last known good version, but a data migration forces you to roll forward instead.

Say a fresh deploy starts throwing errors. Rather than hunt for the cause live, you revert to the release that was healthy minutes ago:

Language: Shell 
$ deploy history web
  v2.4.0   12:30   current, failing
  v2.3.1   09:15   last known good

$ deploy rollback web --to v2.3.1
rolling back web: v2.4.0 -> v2.3.1
done in 18s, v2.3.1 now serving all traffic

The new version is gone from production in seconds, and the broken code goes back to a branch to be fixed properly.

How It Shows Up in Practice

A Python developer triggers a rollback from the same place they deploy, often a single command or one button in GitHub Actions, Argo CD, or a cloud console. It works because the previous build is kept around as a ready-to-serve artifact, so going back is a matter of pointing traffic at it again.

Some release strategies make rollback close to instant. A blue-green deployment keeps the old version running and flips traffic back in one step, and a canary release limits the damage by sending only a sliver of traffic to the new version in the first place. Flipping a feature flag off is a rollback of a single feature without redeploying anything.

When You Can’t Roll Back

Code rolls back cleanly, but data often does not. A database migration that dropped a column cannot be undone by redeploying the old version, because the data it needs is already gone.

For changes like that, teams roll forward instead. They leave the system on the new version and ship a hotfix that corrects the problem. A common safeguard is to keep schema migrations backward compatible, so the old code still runs against the new database and a clean rollback stays on the table for as long as possible.

Continuous Integration and Deployment for Python With GitHub Actions

Tutorial

Continuous Integration and Deployment for Python With GitHub Actions

With most software following agile methodologies, it's essential to have robust DevOps systems in place to manage, maintain, and automate common tasks with a continually changing codebase. By using GitHub Actions, you can automate your workflows efficiently, especially for Python projects.

advanced devops

For additional information on related topics, take a look at the following resources:

By Martin Breuss • Updated June 22, 2026
Software Engineering Glossary Share Feedback