Delivery without a leap of faith
Build a repeatable release path and plan for code and data to change at different speeds.
BY THE END, YOU CAN
- Distinguish continuous integration, delivery, and deployment
- Design a reversible staged rollout
- Plan a compatible database migration
Diagram description: Build → Staging; Staging → Canary 5%; Canary 5% → Everyone (healthy); Canary 5% → Staging (roll back); Expand schema → Contract schema (old and new code both work)
Build once, promote deliberately
Continuous integration gives frequent automated feedback when changes are combined.
Continuous delivery keeps changes ready for release; continuous deployment automatically releases changes that satisfy the chosen checks. A pipeline should produce a traceable artifact with known dependencies and run checks appropriate to the change. Promote the same built artifact through environments instead of rebuilding from an ambiguous state each time.
Record which version is running and how to inspect its health. A passing pipeline reduces uncertainty, but it does not remove the need to observe real behavior.
Expose a little before exposing everyone
A staged rollout limits the initial population affected by a change.
A canary can receive a small share of traffic while you compare relevant signals with a baseline. Choose stop conditions in advance: elevated failures, latency, queue age, or a violated invariant. Feature flags can separate deployment from feature exposure, but add states that need testing and cleanup.
Rollback is useful only when the old version remains compatible with the data and external effects produced by the new one.
Data outlives a deployment
For a schema change, use an expand-and-contract sequence: add compatible structure, deploy code that can coexist, migrate data, switch use, then remove the obsolete structure after old readers and writers are gone.
Long-running Relay jobs and old workers may remain active during a rollout. Account for them explicitly. Large backfills need rate limits, resumability, and progress visibility.
A destructive migration cannot be reversed merely by redeploying old code, so verify backups and recovery procedures before depending on them.
COMMON FAILURE MODE
Calling a release reversible because the code can roll back ignores schema changes, external side effects, and queued payloads.
TRY IT YOURSELF
Plan a rollout that adds a required tenant_id to existing jobs without breaking old workers. Identify compatible stages and when the old field assumptions can be removed.
Make the call in the laboratory.
The two-question checkpoint, your notes, and your saved progress are in the laboratory. Free, with no account.
Open in the laboratory ↗CONNECT IT TO RELAY
Create a Relay release checklist with a traceable artifact, staged rollout signals, and a migration-specific recovery plan.