Delivery Platform
Before tracing a single change, it helps to see the systems it will touch and where the ownership boundaries sit. Almost every “why is my deploy stuck” question resolves to a handoff between two of these boxes.
The main path
Read it left to right. Your branch enters at the far left; running production code is on the right.
- GitHub holds trunk and your pull request. The PR is the unit of review, not the commit.
- GitHub Actions builds and tests. Its output is not a green tick — it is an artifact: a container image with a content digest.
- Image Registry stores that artifact immutably. Nothing downstream rebuilds it. Staging and production run the byte-identical image.
- Deploy Controller promotes a digest from one environment to the next and paces the rollout. It is the only component that decides when traffic moves.
- Runtime Cluster runs the workloads and serves traffic.
The two boxes above and below the rail are the ones people forget until they matter.
Supply-chain policy
CI signs the image and publishes provenance (an SBOM and an attestation). The cluster’s admission controller verifies that signature before any pod starts.
This is a genuine gate, not a formality. A locally built image, an image from an unexpected pipeline, or an image whose attestation does not match the source commit will be rejected at admission — after the deploy controller has already accepted the request. If a rollout dies with no application logs at all, admission is the first place to look.
The feedback loop
Two arrows point backwards, and they are the reason this is a platform rather than a pipeline:
- Observability → Deploy Controller. Health signals do not merely populate a dashboard for a human to notice. The controller consumes them and can halt or reverse a rollout on its own.
- Feature Flags → Runtime Cluster. Exposure is controlled at runtime, independent of the delivery plane. Turning a feature off does not require a build, a deploy, or an approval — which is why it is almost always the fastest mitigation available.
Ownership, and why it matters at 3am
| Layer | Typically owns | You escalate here when |
|---|---|---|
| Delivery plane | Build reproducibility, artifact signing, promotion, rollout pacing | The image never appears, or promotion refuses a digest |
| Runtime plane | Cluster capacity, admission policy, networking | Pods are rejected, pending, or crash-looping before your code runs |
| Your service | Application behaviour, its tests, its flags, its telemetry | Everything above is green and the behaviour is still wrong |
What to check when a change is not moving
- No artifact in the registry. The build failed, or it succeeded on a different commit than you think. Check which SHA the run used.
- Artifact exists, promotion refuses it. Usually the digest is not signed, or the attestation does not match the source commit.
- Promotion accepted, nothing running. Admission rejected the workload, or the cluster has no capacity to schedule it.
- Running, but nobody sees the feature. The delivery plane did its job. This is a flag question — see Feature Rollout.