Delivery tracking

A pipeline run records a commit, branch, start and finish time, result and service. A deployment records a service, environment, version, deployment time, rollback reference and status. Together they let a release manager inspect what was built and what happened during delivery. The records answer different questions: a passed pipeline run reports a build result, while a healthy deployment reports an environment outcome.

The deployment workflow begins when a release change moves into implementation. It records a pending deployment for the delivery team to follow. The engineer then updates the deployment outcome as work proceeds. If the environment is unhealthy or the release is rolled back, the status should show that result. The release manager compares the deployment service and time with the change window, then checks the environment and version on the deployment before verifying the change.

• Run evidence. Pipeline runs retain the branch, commit and result for the service.
• Deployment evidence. Deployments track the version and outcome in an environment.
• Change handoff. The release change explains why the work was scheduled and who reviewed it.

Decide how source control and CI results will be entered or connected to pipeline run records. Agree how the service name is matched across the pipeline, change and deployment records. Define the environments used by the team and the version convention that will be meaningful during incident response. Record the actual deployment time when an environment changes, so the release timeline is legible.

A run marked Passed should point to the same service the deployment affects. If several commits are included in one version, the team must agree how to identify the relevant run evidence; check the run against the service and version before treating it as release evidence. A failure in a pipeline run should be visible before the release is treated as ready. The deployment status then tracks Pending, Approved, Deploying, Healthy, rolled back or Failed according to the observed work.

Use a service with an approved release change. Inspect its pipeline run result and confirm the commit and branch under review. Move the change into implementation and check that a pending deployment appears for the right service. Record the target environment and version. After the engineer records the outcome, the release manager should compare service, environment, version and time with the change before closing it.

If the result is a rollback, use the deployment’s rollback reference and the change’s rollback plan to explain the decision. A rollback check can hold the expected and actual result for a checkpoint. This gives the next on-call responder a concrete trail when an incident opens after the release.

• Deployment Outcomes — Service versions and their current environment outcomes.
• Pipeline Activity — Recent run states with branch, commit and timing.
• Change Schedule — The approved work that frames the delivery window.

Start with release change, then rehearse deployment outcome from pending record to final result.