A green pipeline proves that a technical sequence finished. It does not prove that users can complete the flow, that data is correct or that the team can detect degradation. Confusing deployment with delivery moves risk into production.
A serious release defines before it begins what must be verified, who observes the change and which signal requires stopping or reversing it.
Acceptance criteria tied to the flow
Tests should describe behavior, not only components. "The endpoint responds" is insufficient when the result depends on permissions, data, queues or an external integration. A useful criterion follows the path that creates value and the failures that would cause the most damage.
Data changes need their own checks: migration applied, coherent counts, valid constraints and critical queries within the expected time.
Deployment does not mean exposing everything
Separating deployment from activation reduces pressure. Feature flags, canaries or group-based activation support observation before expansion. The cut size should be proportional to the capacity to detect and respond.
A canary without metrics or comparison only delays risk; it does not control it.
Observe technical and product signals
Errors, latency and resources are necessary, but business outcomes matter too: completed operations, abandonment, rejections, amounts or inconsistent states. A baseline must exist before the change to determine whether variation is real.
- Service and dependency health.
- Errors by version, route and client.
- Latency of critical flows.
- Asynchronous processing and pending queues.
- Outcome and data-quality metrics.
- Support and internal-user feedback.
Rollback that includes data and configuration
Returning to the previous container does not always reverse a release. Migrations, emitted events, configuration and external actions may have changed state. The plan should state what is reversible, what needs compensation and how long the team has to decide.
Rollback is tested before it is needed. If it depends on improvising commands during an incident, it is an intention rather than a capability.
Close with ownership
Delivery ends when acceptance evidence exists, observation covers an agreed window, the change is documented and somebody owns subsequent behavior. Non-blocking findings become explicit work; they do not disappear when the card closes.
Frequently asked questions
Does every release need a canary?
No. The mechanism should match risk. A small reversible change may use direct validation; a critical one needs limited exposure and stop criteria.
How long should a release be observed?
It depends on the flow cycle. The window should cover when relevant effects appear rather than a fixed number of minutes.
What if a migration cannot be reversed?
Use backward compatibility, expand-and-contract or a compensating action. That limitation must be known before activation.