A successful build, an accepted manifest and a working user journey answer three different questions. A deployment pipeline should make those differences visible.
Consider an example release: the container image builds, the registry accepts it, and the deployment command exits successfully. The pipeline turns green. Meanwhile, the application cannot complete its main request because a dependency is unreachable.
The pipeline reported what it checked. The missing piece was the definition of success.
Define four release checks
| Check | Question |
|---|---|
| Artifact identity | Are we deploying the intended build? |
| Workload rollout | Did the workload converge to the intended state? |
| Application behavior | Does a representative request produce the expected result? |
| Operational observation | Are errors and latency acceptable after release? |
These checks complement one another. None proves the entire release is correct.
1. Connect the running release to its build
Record the source revision, image digest, target environment and deployment identifier together. If you use mutable image tags, a tag name alone may not identify the artifact you intended to release.
Choose a way to identify the running application version. A version endpoint, build metadata or a deployment annotation can help, but decide what it proves. An annotation records an intention; a response from the application can provide different evidence.
Keep credentials and sensitive configuration out of release reports.
2. Wait for the rollout, with a deadline
For a Kubernetes Deployment named web in namespace demo, a rollout check can look like:
kubectl rollout status deployment/web -n demo --timeout=180s Replace the example resource names and choose a timeout appropriate to your workload. The command's success describes the rollout conditions Kubernetes evaluates; it is not an end-to-end business test.
Ensure a failed check actually fails the pipeline. A command placed in a script that ignores its exit status is not an effective gate.
If another system reconciles deployment state, such as a GitOps controller, wait for the intended revision through that system as well. Avoid assuming that a successful repository update means the cluster is already running it.
3. Test through the intended application path
A representative check should exercise the behavior users depend on. For a read-only HTTP check, a starting point is:
curl --fail --silent --show-error \ --connect-timeout 5 --max-time 15 \ https://app.example.com/health The URL and timeouts are placeholders. curl's --fail makes HTTP responses of 400 or higher fail in ordinary cases; a successful exit does not validate response content or prove business correctness.
A shallow health endpoint may not exercise a database, an authorization rule or a downstream API. Add explicit assertions appropriate to a safe test request. Check the status, expected fields and result, not just whether any response arrived.
For operations that write data, use an approved synthetic test design with clear ownership and cleanup. Do not retry a business transaction blindly.
4. Observe after the initial check
A single request is a small sample. Define an observation window and the signals that matter: request failures, latency, dependency errors and relevant application outcomes.
Decide who receives an alert and who can stop or reverse a release. A rollback command is only part of recovery; configuration changes and database migrations may require a different approach.
Do not treat an automatic rollback as proof that every effect of the release has been reversed.
Make the pipeline result explainable
Prefer a release summary that says which checks passed, which revision they evaluated and when they ran.
For example:
- Artifact identity recorded.
- Intended workload rollout completed.
- Representative request assertions passed.
- Observation window completed within agreed thresholds.
These are proposed report fields, not results from a real deployment. They make it easier for an operator to distinguish “deployment accepted” from “release behavior verified.”
The useful question is not whether the pipeline is green. It is what evidence made it green.
