Learning bite
Dev, QA, preprod, and production gates
Define promotion evidence while keeping four environment labels distinct from four running clusters.
On this page
Promotion moves a known artifact
An artifact is a built result, such as a container image. Promotion selects the same tested result for another environment. Rebuilding source for each environment can produce different bytes, so a passing QA run may no longer describe the image sent to production. An image digest identifies content; a tag is a name that may be moved.
Promote an artifact, preserve its identity
A release moves forward when the target declaration references an artifact already evaluated by the preceding gate. Rebuilding the same source for each environment can produce different images. A source SHA tag is useful evidence, but a mutable tag alone does not establish immutable identity. Record registry digests when publishing; for local-only exercises, retain image IDs and record that registry promotion has not been tested.
On this host, model four stages in Git and run one local workload profile. Do not claim these stages provide production isolation. Real environments need their own identities, secrets, state, data policy, and operational boundaries.
Design gates around MicroBank
| Stage | Evidence to request |
|---|---|
| Dev | Build and unit checks, rendered manifests, policy evaluation |
| QA | Compatible API contract and a real local transaction result |
| Preprod | Recovery of the same case; candidate check limitations recorded |
| Production | Approved change, compatible data plan, target readiness, rollback owner |
The local transaction, scheduled synthetic check, and fault drill remain local. A cloud promotion does not inherit their CronJob. Live cloud acceptance needs a separately defined, bounded operational verification plan; it is not the periodic simulation from this course.
Review a release as a sequence of decisions
Use two symbolic artifact names in this exercise: image-A is the currently accepted image, and image-B is a candidate. They are labels for reasoning, not runnable registry references.
| Stage | Candidate | Required observation | If absent |
|---|---|---|---|
| Build | B | Source revision, architecture and resulting digest recorded | Do not publish it as an approved release |
| QA | B | Tests ran against B with known configuration | Investigate; A remains the accepted candidate |
| Pre-production | B | Recovery and data compatibility reviewed | Hold promotion |
| Production decision | B | Required review refers to B and its configuration | Do not substitute a newly rebuilt image |
Suppose QA passes B, but the release job rebuilds the same commit and produces C. Can B's result approve C? No: source identity alone does not establish identical output. Dependency downloads, build inputs and architecture can differ. Either retain B or explicitly test and approve C.
On your host, inspect an existing release record from the previous path and find source revision, image identity, architecture and test result. Mark missing fields as unknown. This is a record-review task; it does not create four running environments on your 16 GB machine.
Try it
Create a promotion record with artifact identity, source revision, environment, check results, evidence locations, approver role, and rollback identity. Use not run for missing checks. Keep promotion blocked until the required checks have run and their results are available.
GitHub environment approval protects jobs that reference that environment. It does not automatically block Argo CD from syncing a Git commit. Protect the desired-state repository and its merge path as well; confirm which controls your account and repository support.
Checkpoint and revision
Trace the same artifact through all four declarations. Explain who can change desired state and what prevents a direct push from bypassing the intended gate.
Compare your reasoning
A gate is an enforced decision point, not a heading in a README. Identify what prevents a rejected candidate from reaching the watched Git revision. An approval on a pipeline that Argo CD does not depend on is not that control.
Sources
GitHub deployment environments↗, GitHub rulesets↗, Docker image digests↗.
Your notes and evidence
Record observations, questions, or links to your work. Keep credentials out of your notes.
Back up or restore this path
Progress and notes stay in this browser. A backup contains only this learning path.