liveBook · Manning

Rollback

As explained in Think Like a Software Engineering Manager

A rollback is the restoration of a software system or deployment to a previous known state after a change causes problems.

A rollback restores a production deployment to its previous known state when a change causes unwanted customer effects. It is a predefined response, not an improvised fix. section 12.2.4

A practical rollback procedure should:

  • Be written into the deployment checklist and remain accessible before deployment begins. section 12.2.4
  • Start when the deployment affects customers or threatens system stability. section 12.2.4
  • Specify concrete restoration actions rather than relying on manual improvisation. section 12.2.4

Duplicate customer records

If a deployment creates duplicate records in the customer table, the rollback procedure may direct operators to run database queries that identify and delete the duplicates, restoring system stability. section 12.2.4

How Think Like a Software Engineering Manager covers it

How deep it goes
Defines a prepared response and gives one database-remediation example, without detailing broader implementation mechanics.
Examples
Uses duplicate customer records and database queries as the concrete restoration example.
What it assumes
Assumes a production deployment and a deployment checklist, while emphasizing preparation before deployment begins.
What you can do after
Operate/configure it by preparing and executing a predefined procedure that restores a stable production state.
How it connects
Connects rollback with deployment checklists, quality gates, automated deployments, and continuous deployment.

Also explained in

Compare how 8 books explain rollback →

Related concepts

This explainer was generated by Manning's knowledge graph from the text of Think Like a Software Engineering Manager. The section links point to the parts of the book it draws on.