What Is a Release State Machine? Prepared vs Live

In a release state machine, prepared means the new version is fully built, configured, and staged in the target environment, but it is not yet serving production traffic. It is not live because the state machine deliberately holds the release in a ready-but-inactive state until explicit approval, automated checks pass, or a scheduled window opens, preventing premature exposure to users.

Why a State Machine for Releases?

Software releases are complex, multi-step processes that benefit from formal state modeling. A release state machine defines the distinct phases a release passes through, the allowed transitions between them, and the conditions that trigger each transition. This approach brings predictability and safety to deployments, especially in microservices, mobile apps, and infrastructure-as-code environments.

Without a state machine, releases often rely on ad-hoc scripts and manual checklists, which are prone to human error. A state machine enforces a strict order: you cannot jump from building to live without passing through prepared. It also provides a clear audit trail—each transition is logged, so you know exactly when and why a release moved from one state to another.

Common States in a Release State Machine

While implementations vary, most release state machines share these core states:

• Draft – The release is being defined; code may not be finalized.
• Building – Artifacts are being compiled, packaged, and tested in CI.
• Prepared – The release is deployed to a staging or canary environment, fully configured, and awaiting approval.
• Live – The release is actively serving production traffic to all or a subset of users.
• Rolled Back – The release was reverted to a previous version, often due to detected issues.
• Archived – The release is no longer active and is kept for audit or reproducibility.

Some state machines add deploying and verifying as transient states between prepared and live, but the essential distinction remains: prepared is a holding pattern, live is the point of no return (unless you have a rollback).

What Happens in the Prepared State?

When a release enters the prepared state, several things have typically already occurred:

1. The code has been merged and built into an immutable artifact (e.g., a Docker image or a compiled binary).
2. The artifact has been deployed to a staging environment or a canary cluster that mirrors production.
3. Database migrations have been run in a controlled manner, often with backward compatibility.
4. Configuration files, secrets, and feature flags are set to the intended values.
5. Automated smoke tests or integration tests have passed.

In the prepared state, the release is ready to go live but is not yet serving user traffic. It may be accessible via a private URL for final manual testing, but the public-facing load balancer still points to the previous version. This is the last checkpoint before exposing the release to real users.

Why Isn’t Prepared the Same as Live?

The most fundamental reason is risk management. If a prepared release were automatically live, you would lose the ability to catch issues after deployment but before user impact. The prepared state is a deliberate pause that allows:

• Human approval – A release manager or on-call engineer reviews the deployment and gives the go-ahead.
• Scheduled windows – The release can wait until off-peak hours to minimize disruption.
• External dependencies – You might be waiting for a third-party service to be ready or for a support team to be available.
• Canary analysis – In some setups, the prepared state is used to run a small percentage of traffic to the new version, monitoring metrics before scaling to 100%.

Additionally, the state machine treats prepared and live as distinct because the actions required to transition from prepared to live are often irreversible or costly. For example, once you switch a database schema to a new version that drops a column, rolling back may require restoring from a backup. The prepared state gives you a chance to abort without such consequences.

Transition from Prepared to Live

The transition from prepared to live is typically triggered by one of:

• Manual approval – A human clicks a button in a CI/CD dashboard.
• Automated policy – All required checks pass, and the system automatically promotes the release.
• Schedule – A cron job or time-based trigger executes the promotion at a predetermined time.

Once live, the release starts receiving production traffic. Depending on the deployment strategy, this could be:

• Blue-green – The new version is fully deployed alongside the old, and traffic is switched over instantly.
• Canary – A small percentage of traffic is routed to the new version, gradually increasing.
• Rolling – Instances are updated one by one, with health checks between each.

In all cases, the release state machine tracks the live state and can trigger a rollback if health checks fail or error rates spike.

Common Misconceptions and Pitfalls

One common misconception is that prepared means the release is already running and serving some users. In a strict state machine, that would be a canary or partial live state, not prepared. Prepared should be a pure holding state with no user-visible impact.

Another pitfall is treating the prepared state as a guarantee that the release will work in production. Staging environments are rarely identical to production—differences in data volume, network latency, and third-party integrations can cause failures that only appear after going live. The prepared state reduces risk but does not eliminate it.

Teams also sometimes forget to define a timeout for the prepared state. If a release sits in prepared for too long, it may become stale (e.g., a security patch was released in the meantime) and should be re-validated before promotion. A robust state machine includes an expiration or a re-verification step.

Frequently Asked Questions

Can a release go from prepared back to building?

Yes, in many state machines this is allowed. If a critical bug is found during the prepared phase, the release can be moved back to building or draft to incorporate a fix. This is safer than promoting a known-bad release.

Is prepared the same as ‘staging’?

Not exactly. Staging is an environment, while prepared is a state. A release can be deployed to a staging environment but still be in the building state if tests haven’t run. Conversely, a release could be prepared in a production-like environment that is not called staging, such as a canary cluster.

What happens if a prepared release is never promoted?

It remains in the prepared state indefinitely unless your system has an expiration policy. It’s good practice to automatically archive or expire prepared releases after a certain period to avoid confusion and resource waste.

Does prepared mean the code is already compiled?

Yes, typically a release cannot be prepared unless it has been successfully built into an artifact. The build step is a prerequisite for the prepared state, ensuring that the artifact is immutable and reproducible.

Can a rollback go directly from live to prepared?

In some state machines, a rollback returns the system to the previous live version, not to a prepared state. However, if you want to re-apply the same release later, you might move it back to prepared after rollback, so it can be re-promoted after fixes.

Why not just use a boolean flag for ‘isLive’?

A boolean flag cannot capture the rich set of states and transitions needed for safe releases. For example, you need to know if a release is in a failed state, if it’s waiting for approval, or if it’s been rolled back. A state machine provides a structured way to handle these scenarios and prevents invalid transitions.

Conclusion

The prepared state is a critical safety checkpoint in the release process. It ensures that a release is fully built and deployed to a non-production environment, but it is not yet exposed to users. This separation allows for human oversight, scheduled rollouts, and a final verification step, significantly reducing the risk of deploying broken code to production. Understanding this distinction is essential for anyone designing or operating a CI/CD pipeline.

Related

• Budget Headphones with Mic for Calls, Music & Gaming
• IT Blocks File Sync: What It Means & How to Fix It
• Apple Copy Paste Photos? How It Works