03 / Delivery
A path to production
Give teams a repeatable release process and a clear view of what happened.
A delivery pipeline connects decisions made by several people: what counts as ready, which artifact is deployed, who can promote it, and what happens when it fails. Automating commands is only part of the work.
A useful path lets a developer answer four questions: what is running, what changed, did it work, and how do we recover?
Keep the release identifiable
Record the source revision, artifact, and relevant configuration for each deployment. Where practical, promote the tested artifact instead of rebuilding it for each environment. Keep environment-specific configuration explicit so differences can be investigated.
The record need not become another tool. It can live beside the deployment history, provided the next person can find it.
Plan for versions to overlap
Rolling deployments mean old and new application instances may run together. A database change must account for that overlap.
For a field migration, one approach is to add the new representation, deploy compatible code, backfill and verify existing data, switch reads, and remove the old representation after the compatibility window closes. Define how writes remain consistent during the transition.
This adds temporary complexity. For a small application that permits downtime, a planned maintenance window may be a better fit. The choice follows the service requirement.
Verify beyond the deployment controller
| Stage | Question |
|---|---|
| Build | Can this revision produce the intended artifact? |
| Check | Does it satisfy the behavior and compatibility we depend on? |
| Deploy | Are the expected instances ready? |
| Observe | Can a user complete a representative operation through the real entry point? |
The final check can expose a hostname, routing, authentication, or downstream failure that process health alone cannot see. Use a bounded observation window where infrastructure needs time to converge. Persistent failures require investigation.
Make recovery part of the change
Replacing code does not undo emails, payments, or deleted records. Identify irreversible effects before releasing and document any repair procedure separately from rollback.
When the checks pass and the user journey works, the release is complete. Leave the artifact and outcome recorded, so the next change starts from a known state.