Plan rollback strategies before the first failed deployment.
A rollback is a prepared return to a tested artifact with compatible data, not just an improvised reaction to a failure.
For developers and technical project managers, the "Last Good State" and "Decision Boundary" are crucial when planning a rollback before a failure. An "Untested Revert Path" serves as a cross-check.
Published: 3 min read · Author: Sebastian Geier
What needs to be in place for a rollback before the first failed deployment?
An immutable last good state, a documented rollover path, and a decision-making role must be available. Data changes remain backward compatible or have their own recovery plan.
Last Good State
Last Good State – Code, artifact, and necessary configuration are clearly identified and available.
Decision Boundary – Failure impact and response time determine in advance when a rollback occurs.
Data Compatibility – The legacy application can safely read the current data state, or it is restored in a controlled manner.
Decision Boundary
Provide the last good state, configuration, and dependencies immutably.
Define error classes, thresholds, decision-makers, and communication channels.
Test rollback and restart with representative data and real-world permissions.
Data Compatibility
Control signal
Signal 1
Time from reaching a rollback criterion to a stable previous state.
Control signal
Signal 2
Failed rollback attempts by cause and missing prerequisite.
Control case: "Untested rollback path"
A new version generates errors in the central query path. The defined threshold triggers the switch to the saved previous artifact; a previously extended database column remains compatible and does not need to be reverted under time pressure.
Untested Rollback
Untested Rollback – The incident lacks permissions, commands, or a working artifact because the rollback path was never tested under realistic conditions.
Schema Trap – Old code starts but corrupts already migrated data or expects schema elements that have since been removed.
Delayed Decision – Without a threshold, damage accumulates during a lengthy diagnostic process before a rollback decision is even made.
Related questions and next steps
Release Notes for Technical and Business Changes answers the next practical question: What information makes release notes useful for both business and technical stakeholders?
Delivering Static Assets with Long Runtimes and Version Parameters continues this line of thought with another question: How do you combine long cache runtimes with immediately visible changes to static assets?
If you want to practically implement "Planning a Rollback Before the Failure Occurs," you can refer to Robust Website Systems . This focuses on "Release, Artifact, and Recovery" and "Last Good State."
Conclusion: Plan a Rollback Before a Failure
A rollback is a pre-defined operational procedure. Artifact, data, and authorization must function together and be tested under realistic conditions.
Sources and Further Information
The primary sources define the technical framework for "planning a rollback before a failure."
SLSA Specification 1.1The primary specification defines proof of origin and requirements for trustworthy, traceable build artifacts.
Deployments and environments – GitHub DocsThe vendor documentation specifies environmental permissions, protection rules, and controlled deployment states.
Content
Key Thesis
The immutable predecessor version, the transition path, responsible parties, and decision thresholds are defined in advance. Data changes require backward-compatible steps or a separate recovery plan.
What This Is Not About
A backup alone is not a rollback as long as the transition path, data state, and decision are unclear.
What it's about
The predecessor version, trigger criteria, responsible parties, and data compatibility are defined and tested before the incident.
Git, deployment, and quality assurance
Secure database changes together with code changes.
"Planning a rollback before a failure occurs" includes, as a separate check, the question: How can database migrations be rolled out without risky coupling to a code change?
Git, deployment, and quality assurance
Manage environment variables between development and production
"Planning a rollback before a failure occurs" is supplemented by a separate decision: How can environmental variables between development, staging, and production be kept manageable?
Insights Overview
All VELUNO Insights at a Glance
Further analyses on Website Systems, digital visibility, and robust working models.
Data compatibility: a specific checkpoint
A planned test run with the latest release reveals missing permissions and data assumptions. The result is documented as a short, executable fallback path.