Releases and rollback

A release is more than generated source. It binds artifacts to the model revision, generator version, migration chain, configuration manifest, and validation evidence that produced them.

Immutable releases

Once built, a release does not change. A correction creates another release. This makes rollback, audit, and reproduction meaningful.

A release record identifies:

• model and parent revision;
• generator version and targets;
• artifact hashes;
• schema manifest and migrations;
• required configuration contract;
• build, test, health, readiness, and smoke evidence;
• destination and promotion result.

Blue-green delivery

Blue-green keeps the active release serving traffic while the candidate is built and verified separately.

                ┌─► Blue: current active release
Router ─────────┤
                └─► Green: isolated candidate

build → configure → migrate compatibly → ready → smoke → switch traffic

If green fails before the switch, blue remains untouched. Once green passes, routing changes atomically. The new release enters an observation window before it is marked stable.

Rollback is a compatibility decision

Traffic can return to blue only if blue remains compatible with the current database and runtime contract.

Change	Typical rollback posture
Application-only, no contract change	Traffic rollback normally safe
Additive nullable schema	Old release usually compatible
New write format old code cannot read	Requires dual compatibility or forward fix
Destructive column/table removal	Old release incompatible; do not traffic-rollback
External contract changed	Depends on adapter/config compatibility
Secret rotation	Old release must accept the current credential/config

The release planner should calculate and record the compatibility floor before promotion.

Candidate verification

Required gates normally include:

1. artifact integrity and dependency checks;
2. migration-plan approval;
3. candidate startup;
4. health and readiness;
5. migration checksum and schema verification;
6. central journey smoke tests;
7. traffic switch;
8. telemetry observation.

What rollback does not do

Traffic rollback does not automatically:

• reverse an applied data transformation;
• restore deleted rows;
• un-send notifications or external side effects;
• revoke a provider request already accepted;
• rotate configuration back safely;
• remove a partially completed async workflow.

Those outcomes require compensation, repair, restore, or a new forward release.

Failed deployment

If an error occurs during build, migration, readiness, or smoke verification, do not promote. Record the failure against the candidate and preserve the active release. Retry only when the failed operation is idempotent and its observed state is reconciled.

Continue with Managed deployment and Incidents.