Delivery pipeline feedback and artifact promotion

Trace a release across systems

CI creates and tests an artifact. GitOps reconciles an approved desired-state revision. A release record connects those activities to the observed workload and application check. A passing build does not prove the controller applied its output.

For MicroBank, keep source SHA, build platform, local image ID or published digest, desired-state commit, observed Pod image identity, and saved-case result together. If the Mac rebuilds an AMD64 CI artifact as ARM64, record it as a new artifact and verify it separately.

Name what moves between the stages

An artifact is an output retained for another step, such as a test report, package, or container image. A cache speeds retrieval or repeated work and may be discarded. A reusable workflow defines shared job logic. A deployment record connects a particular artifact and configuration with a target and result. A cache hit does not identify which artifact was deployed.

Suppose source commit C1 builds image digest D1, and deployment commit G1 changes a manifest to reference D1. A later promotion should select the same tested D1 if the intention is to promote that artifact. Rebuilding C1 with changed dependencies can create D2; the source commit alone cannot prove equivalence. A local ARM64 build also needs its own identity when CI built another architecture.

Use this invented timeline for a small calculation: queued 09:00, started 09:02, tests finished 09:05, image finished 09:09, deployment change approved 09:20, sync finished 09:22, journey verified 09:23. Queue time is 2 minutes, the measured build/test interval is 7, review wait is 11, and sync plus verification is 3. End-to-end elapsed time is 23 minutes. These are example timestamps, not a claimed MicroBank result.

Practice: if a dependency cache saves 2 minutes during the build, the same timeline becomes 21 minutes only if the other intervals stay unchanged. It does not remove the 11-minute review wait. If tests fail at 09:05, should G1 advance? No: the desired revision should advance only through the defined successful path. Preserve the failed attempt so the record does not count only easy successes.

Observe feedback without inventing speed gains

Measure queue time, dependency retrieval, build/test time, review wait, sync time, and verification time separately. Record failed and cancelled attempts. A warm cache can shorten a build while leaving a slow approval or unreliable dependency unchanged.

Stage fast checks before expensive ones when dependencies permit. A test matrix helps evaluate genuinely supported runtime combinations; each additional combination should cover a runtime you intend to support. Keep periodic synthetic journeys and fault injection local.

Try it

Use one existing build and local deployment attempt. Construct its timeline from actual timestamps and label missing observations. Identify the first point where a developer could know the change was invalid. Improve one feedback step, then repeat a comparable attempt and report the measured result.

Review a deliberately failed offline policy or unit test. Confirm the failure is visible in the release record and the desired-state revision does not advance automatically. Later Platform engineering can package this proven contract as a reusable workflow and a portal action.

Checkpoint and revision

Distinguish a reusable job, a build cache, a retained artifact, and a deployment record. Each has a different consumer and trust boundary. A dashboard of successful jobs alone cannot establish delivery reliability or user-visible correctness.

Checkpoint guide: inspect one real attempt using the same stage definitions, leave unavailable timestamps blank, and identify one delay you can actually change. The next lab connects a reviewed render and artifact to one observed sync; a speed claim can wait until comparable measurements exist.

Sources

GitHub workflow reuse↗, GitHub workflow artifacts↗, Argo CD tracking strategies↗.