H.11 Delivery
One commit can be a coherent source identity for many products without being one release or deployment. Delivery becomes tractable when source, artifact, release, promotion, runtime, and recovery states keep their own identities and explicit joins.
Follow Identity Into An Operated Product
H.11.1 Source Identity names the selected repository state and any external repositories, generated inputs, patches, or configuration needed to interpret it. H.11.2 Artifact Identity adds the configuration, tools, invocation, and provenance that produced immutable bytes. H.11.3 Release Identity gives those artifacts product or consumer meaning; SemVer is appropriate only when its compatibility promise is real.
H.11.4 Runtime Compatibility accounts for API, protocol, schema, configuration, data, client, worker, and toolchain skew among independently running revisions. Shared source removes neither rolling deployment nor external and stored-state boundaries. The supported source and dependency contract that enables this evolution remains in H.5.3 Compatibility Contracts.
Move And Recover State Deliberately
H.11.5 Promotion advances an identified artifact through environments or cohorts with eligibility, approval, health, soak, supersession, and repair rules without changing authoritative source state.1 H.11.6 Delivery Models chooses unified delivery, independent products, trains, supported lines, or hybrids from the real compatibility and coordination boundary.
Two cases expose the difference. A fleet of services may build once and promote independently through canary cohorts while preserving protocol skew. A public SDK may publish a versioned supported line and backport a security fix without advancing every product at repository head. Both share source; their release and recovery state machines differ.
H.11.7 Delivery Recovery distinguishes source revert, artifact rollback, deployment rollback, rollforward, configuration repair, and data recovery. Finally, H.11.8 Delivery Traceability tests the joins from running product through promotion, release, artifact, build evidence, review, and exact source, including declared retention and completeness limits. Security and compliance proof remains the separate contract of H.9.5 Security Audit.
Do not use “version” or “rollback” as a substitute for a state model. Identify source, bytes, release meaning, compatibility, promotion, delivery topology, recovery operation, and trace joins separately, then connect only the states a product actually operates.
Footnotes
-
Site Reliability Engineering — Ch. 8: Release Engineering — immutable artifacts, release identity, promotion, and traceability ↩
Sections in this chapter · 8
Use one repository revision as a coherent source identity without assuming one release, deployment, or supported line.
Identify immutable bytes through the source, configuration, tools, invocation, and provenance that produced them.
Choose internal release identifiers and external versions according to uniqueness, traceability, and consumer promises.
Preserve protocol, schema, configuration, data, and runtime compatibility across independently running revisions and environments.
Advance identified artifacts through environments, cohorts, health gates, approval, supersession, and destination repair.
Choose unified releases, independent product delivery, trains, supported lines, or hybrids from real coordination boundaries.
Choose source revert, artifact rollback, deployment rollback, rollforward, configuration repair, or data recovery as distinct operations.
Correlate source, review, invocation, evidence, artifacts, release, promotion, and runtime state with declared limits.
