LEARN. PRACTICE. GROW.What is actually being promoted
Start by identifying the unit of decision. In a fictional release, API 41 works with configuration 7 and batch 12. A ticket merely saying API ready leaves two dependencies unidentified. Build a record containing target, artifact, configuration, relevant dependencies, validation evidence, and owner. Then compare that record with what the job will execute. If configuration changed to 8, binary identity can remain correct while behavioral evidence stops covering the combination. In APS, this detail determines whether a team receives a predictable service or a combination never exercised. The record supports both the current decision and subsequent investigation by keeping differences visible.
A tag does not fix the bytes
Run the first laboratory group. A local dictionary associates candidate with bytes A; we store the expected digest and then associate the same tag with bytes B. Comparison rejects substitution while retained bytes A still match. This models a mutable reference without a real registry. Make a prediction before running the code: must the name change for the content to change? No. A digest supports identity comparison, but depends on a trusted reference and does not establish who approved or produced the package. To apply the idea at work, connect the identified artifact to relevant evidence and protect the reference path through promotion.
Running one at a time does not define order
The second group starts at 40 and performs two sequential writes: 42 and then 41. The unconditional result is 41 despite never having simultaneous executors. The next variant applies the condition that seq must be lower than the incoming intent. Write 42 changes one row; write 41 changes zero; the target retains 42. Zero requires explicit handling because a SQL statement can finish without error while promoting nothing. This is a local monotonic-decision model, not a safety proof for a distributed controller. In GitLab, resource_group and processing mode have distinct responsibilities; also check the policy against outdated deployments.
Recovery can be a new decision
A freshness rule should not force selection of bytes with an ever higher version number. In the third group, intent 43 points to artifact-40. The counter increases because there is a new decision even though selected content is older. Discuss what is missing before transferring this idea to production: authority, state compatibility, effects already produced, validation, and execution procedure. The laboratory only demonstrates the conditional record update. It does not demonstrate application recovery. Avoid silently renumbering an old job to bypass the rule; the new intent must represent an actual traceable decision about observed state. Artifact version and decision sequence serve different purposes.
Authorizations have scope
The sixth group compares staging approval for configuration 7 with a production request for configuration 8. The digest matches, but environment and configuration differ. The result lists those fields without querying any authorization service. Use comparison to prepare concrete questions: who can decide for this target, which evidence was reviewed, and which changes require reassessment? In GitHub Actions, environment rules cover jobs referencing that environment; the visible name production does not replace that connection. Available features depend on context and plan. Do not conclude that approval was enforced from an isolated ticket comment or a local field-comparison test. Verify the real execution path separately.
Workshop: review the promotion decision
Prepare three fictional cards: current state 42, pending job 41, and recovery request 43 for artifact 40. For each card, write the expected effect, identity evidence, authorization scope, and stopping condition. Run the laboratory and compare predictions with records. Then change only the target from staging to production and explain why matching digest does not automatically preserve authorization. The expected workshop output is a justified decision including what remains unproven. There is no real pipeline in this exercise. Summarize learning by distinguishing content, intent, and permission; connect it to change management, CI/CD, and support responsibility after the release. A facilitator can review the reasoning separately.
python3 content/labs/release-evidence/run.py
# Sequential intents: 42, then 41
# Unconditional final sequence: 41
# Conditional update final sequence: 42; affected rows: [1, 0]
# New recovery intent: sequence 43, artifact-40
# Local SQLite model, not a vendor pipeline. In a fictional funds team, two jobs approved at different times reach the same environment outside the intended order.
Common pitfalls
Trusting a mutable tag, equating hash with authorization, confusing locks with order, and reusing approval outside its scope.
Related topics: Change Management · CI/CD · Production Support L3
A promotion needs identified content, current intent, and controls covering the actual execution path.
Reference: Release engineering · Release management practices 2026-09; scoped GitLab GitHub CodeDeploy and EF Core documentation