Rollback

A rollback returns a system to the last version known to work after a release causes problems.

A rollback is the planned answer to a bad release. The team stops debugging in production, restores the previous version and analyzes the problem afterward without pressure. How fast that can happen is one of the most useful measures of a delivery process.

For a frontend there are several levels:

• Turning off a feature flag, which hides the new code path.
• Pointing the CDN or the server back to the previous build.
• In a micro-frontend platform, pointing the manifest back to the previous version of one remote.
• Reverting the commit and running the pipeline again, which is the slowest option.

Example

On Friday a new version of the invoices remote ships, and error tracking shows a spike on the payment screen. The on-call engineer changes one line in the manifest so that invoices points to the previous version. New sessions receive the old remote shortly after. The host and the other remotes were never involved.

Common misunderstanding

Teams often assume that a rollback is always available. It has to be prepared. The previous build must still exist in storage, which means artifacts are versioned and kept, and never overwritten in place. The team must have practiced the procedure. And the change must be reversible in the first place.

That last point is the common trap. If the new frontend needs a new API field, or a database migration ran with the release, restoring the old frontend alone may leave it talking to a backend it does not understand. Releasing backward-compatible API changes first, and the frontend afterward, keeps the way back open. The migration guide builds this into every step.

Related terms

• Blue-green deployment
• Canary release
• Feature flag
• Remote entry and manifest