A release you can trace

Video transcript

1. 0:00–0:06

   Name the candidate • Track the exact revision and build inputs. • Exact revision • Build inputs • Environment • Release evidence • Pinned candidate · R17 • Moving branch · R17 • Moving branch · R18 • Illustrative IDs · record exact references, not branch alone

   The exact illustrative candidate stays pinned at R17 while the development branch moves from R17 to R18. The approved figure links exact revision, build inputs and environment to a release-evidence record. Keep repository/revision, package identity, check results, configuration version, data compatibility, release decision and live verification references, without copying secrets. A branch alone can move and is not the full release identity.

2. 0:06–0:12

   Check the risky journey • Test permission, failure and retry behaviour. • Authorised booking • Expected: permitted booking • Unauthorised request • Expected: rejection • Retry same request • Expected: no second booking • Proposed booking tests · record actual results and redacted diagnostics

   Three proposed cases for the article’s hypothetical booking application connect each input to its expected result: authorised booking to permitted booking, unauthorised request to rejection, and a retry of the same request to no second booking. These are expectations to test, not claims of passing tests. Use appropriate fixtures and supported test integrations; retain candidate-linked actual results and redacted diagnostics, distinguishing a broken check from an application defect.

3. 0:12–0:18

   Record the environment • Build-time settings can change the artifact. • R17 · staging inputs • R17 · production inputs • Build A · configuration S • Build B · configuration P • Different embedded inputs? Check the actual production candidate

   R17 remains the source revision on both sides while different embedded staging and production settings feed illustrative Build A and Build B. Their identities are not asserted equal. Document the separate build inputs and run the required checks on the actual production candidate. Promote a checked artifact where the platform allows it; keep environment configuration separate where supported. Environment names alone do not create isolated accounts, databases or networks, and production credentials stay outside ordinary test jobs.

4. 0:18–0:24

   Control promotion • Delivery can retain a production decision. • Check fails • Stop promotion • R17 · awaiting decision • Authorised person or agreed rule • Delivery readiness does not require automatic production deployment

   The first approved failure lane shows a failed required check stopping promotion. Separately, an illustrative candidate awaiting decision approaches but does not pass its agreed production boundary. An authorised person or explicit rule owns the decision; continuous delivery need not deploy every change automatically. Verify available repository/platform controls, access boundaries and concurrency handling rather than promising unavailable approval features or treating cancellation as recovery.

5. 0:24–0:30

   Verify and hand over • A passing build does not prove the live journey. • Journey fails • Recovery decision • F17 · live-flow evidence • Named recovery owner • Code rollback does not undo data writes or external actions • Second maintainer rehearses · alerts need a named responder

   The second failure lane routes a failed live journey to a recovery decision with version/data compatibility. F17 is an illustrative flow-evidence reference delivered to the named owner, not an automatic rollback instruction. A successful build or page response does not prove the booking or background workflow. Code rollback does not undo writes or completed external actions. Recovery can include restoring a compatible version, disabling a feature, repairing forward, or a separately rehearsed data process. A second authorised maintainer rehearses operation and recovery; alerts need actual named observation coverage, not an assumed staffed response.