08.02 · Concept
The Release Problem
State what makes releasing hard independently of the tool doing it.
No video curated for this lesson yet
This lesson is written, ordered and part of the path - the video slot is the only thing still open. We are working through Deployment lesson by lesson; 29 of 56 have their video so far.
The written notes below cover this idea in full - you lose nothing by reading instead of watching.
Releasing is hard because a live change is a coordination problem across code, configuration, database shape, traffic, rollback safety, observability, and user impact. A build can be correct yet still fail in production if old and new versions coexist badly, migrations cannot be reversed, or nobody can detect and contain the damage.
What this lesson answers
- why is releasing harder than deploying code
- what makes a software release risky
- why do rollbacks fail after database migrations
Notes
The Release Problem — The release problem exists because changing running software requires coordinating code, configuration, data, traffic, and user expectations; without that coordination, a correct build can still cause downtime, data loss, security regressions, or irreversible user-facing failures.
Key Concepts: - A release is not just a deploy: release artifact version config values database state traffic routing rollback plan. - Releasing is hard because different parts change at different speeds, e.g.
References
Common questions
- What is the difference between a deploy and a release?
- A deploy usually means putting an artefact into an environment. A release is the broader production change: the artefact, configuration, data model, traffic routing, operational checks, and rollback path all have to work together. The user-visible outcome depends on the whole system state, not just the binary or container that was shipped.
- Why can a passing CI build still be unsafe to release?
- CI proves a limited set of assumptions in a controlled environment. Production adds real configuration, credentials, data volume, traffic patterns, caches, queues, and user behaviour. A change can pass tests and still fail because production-only settings differ, old clients remain active, or the new version writes data the old version cannot understand.
- What makes rollback unreliable during a release?
- Rollback is only safe when the previous version can run against the state created by the new one. If a migration removes data, changes meaning, or writes a format the older code rejects, reverting the application does not restore compatibility. Safe releases usually require forward and backward compatible changes before removing old assumptions.
Short definition: what is Release Problem?