Introduction#
Rollback is the safety net for production incidents, but many rollbacks fail because they are incompatible with data or rely on manual steps. Effective rollback design is planned during development, not during outages.
Immutable Artifacts and Promotion#
Rollback works best when the original artifact still exists and can be re-promoted. Store artifacts in a registry with immutable tags and promotion metadata.
Backward-Compatible Changes#
Schema and API changes should remain compatible for at least one release. This ensures that rolling back the application does not break against the new schema.
Blue-Green and Traffic Switching#
Blue-green deployments enable instant rollback by switching traffic back to the old version. The key is ensuring both environments share the same dependencies and configuration.
Fast Rollback Endpoints#
Expose a controlled endpoint that reveals the running version so you can validate a rollback quickly.
1
2
3
4
5
6
7
8
9
10
11
@RestController
@RequestMapping("/internal")
public class VersionController {
@Value("${app.version}")
private String version;
@GetMapping("/version")
public Map<String, String> version() {
return Map.of("version", version);
}
}
Database Rollbacks#
Avoid rolling back schema changes unless absolutely necessary. Prefer forward fixes and ensure data migrations are reversible only when required.
Summary#
Rollback strategies work when artifacts are immutable, schemas are compatible, and traffic switching is automated. Plan for rollback early, and test it regularly in staging.