Is the release problem the same as the deployment problem?

No. Deployment is usually about putting an artifact onto infrastructure. Release is broader: it includes which users receive it, which configuration is active, whether the database is compatible, whether old clients still work, how traffic moves, and whether rollback is safe. A deployment can succeed while the release fails.

Why can a passing CI pipeline still lead to a bad release?

CI normally tests a controlled approximation of the system. Production adds live traffic, real credentials, production-only configuration, existing data, caches, queues, and partial-version states. If the new code depends on assumptions that are false in production, the build can be correct in isolation and still unsafe to release.

What makes rollback unsafe?

Rollback is unsafe when the new version has changed shared state in a way the old version cannot understand. For example, a new writer may store data in a format the old reader rejects, or a migration may remove something the old code still needs. Rollback depends on backward compatibility, not just redeploying the previous artifact.

Release Problem

The release problem is the coordination problem of changing software that is already serving users. A release is safe only when the new artifact, configuration, database shape, traffic routing, observability, rollback path, and user-facing behaviour remain compatible while old and new states overlap.

Releasing is hard because production is not just a place where a build runs. It is a live system with real data, real traffic, cached clients, queues, permissions, feature flags, and people depending on stable behaviour. A build can pass CI and still fail in production because CI did not exercise the production database, IAM roles, traffic volume, CDN state, or a configuration value that only exists outside staging.

Mechanically, a release combines several moving parts: an artifact version, configuration, database state, traffic placement, and a plan for retreat. During a rolling or staged rollout, old and new versions often run at the same time. That means both versions may read and write the same tables, consume the same queues, and serve the same users. Compatibility across that mixed state is the core of release safety.

The main trade-off is speed versus reversibility. Application code may be easy to roll back, while a destructive migration or changed message format may not be. Feature flags help only if the flag is separated from irreversible changes. Safer releases usually mean more steps: expand-and-contract migrations, staged exposure, extra monitoring, and explicit rollback design. The cost is operational complexity, but the benefit is a smaller blast radius.

Engineers meet the release problem in Kubernetes rolling updates, weighted Lambda aliases, database migrations, CDN or edge rollouts, mobile clients, and long-lived WebSocket sessions. It also appears in release timing: deploying when responders are unavailable increases recovery risk. A common misunderstanding is that deployment tooling solves the problem. It helps execute a plan, but the plan must preserve compatibility and make failure visible.

Go deeper

DeploymentThe Release ProblemState what makes releasing hard independently of the tool doing it.Open the lesson

Common questions

Is the release problem the same as the deployment problem?: No. Deployment is usually about putting an artifact onto infrastructure. Release is broader: it includes which users receive it, which configuration is active, whether the database is compatible, whether old clients still work, how traffic moves, and whether rollback is safe. A deployment can succeed while the release fails.
Why can a passing CI pipeline still lead to a bad release?: CI normally tests a controlled approximation of the system. Production adds live traffic, real credentials, production-only configuration, existing data, caches, queues, and partial-version states. If the new code depends on assumptions that are false in production, the build can be correct in isolation and still unsafe to release.
What makes rollback unsafe?: Rollback is unsafe when the new version has changed shared state in a way the old version cannot understand. For example, a new writer may store data in a format the old reader rejects, or a migration may remove something the old code still needs. Rollback depends on backward compatibility, not just redeploying the previous artifact.

Every term