Build Reproducibility
Pinned inputs and hermetic builds, so one commit cannot produce two different artifacts.
5 to work through
-
intermediate
A build produced a different artefact from the same commit two weeks apart. Why does that matter, and what makes builds reproducible?
2 min answer -
intermediate
A team proposes making every build hermetic - pinned toolchains and dependencies, no network access during the build, byte-identical output from the same commit. What does that buy and what does it cost?
3 min answer -
intermediate Multiple choice
A team wants the same commit to produce a bit-identical container image on any machine, any day. Which single change contributes most?
3 min answer -
intermediate
Your pipeline builds a container image from a tagged commit. Rebuilding the same tag two weeks later produces a different digest. The application behaves identically. Where does the difference come from, and which parts should you fix?
3 min answer -
advanced
Why do reproducible builds matter beyond supply-chain security, and what makes them hard?
2 min answer
3 terms in this topic
Build Reproducibility
The same source input produces a bit-for-bit identical artifact, on any machine, at any time.
practiceDependency Reproducibility
Guaranteeing that a given commit pulls the same dependencies every time - the practical subset of build reproducibility that delivers most of its val…
practiceHermetic Build
A build whose output is a function only of its declared inputs, so the same commit cannot produce two different artifacts.
Neighbouring topics
Delivery & Release Engineering
General material on getting a change from commit to production safely and often.
Pipeline Architecture
Stages, fan-out, caching, and the difference between a pipeline and a long script.
Artifact Management
Immutable versioned outputs, promotion between repositories, and retention policy.
Environment Strategy
How many environments earn their cost, what each proves, and what none of them prove.
Branching Models
GitFlow, trunk and release branches as delivery constraints rather than Git preferences.
Continuous Integration Discipline
Integrating to the mainline daily, and the test speed and review culture that requires.
Deployment Strategies
Rolling, blue-green, canary and shadow, and the traffic and state each one assumes.
Progressive Delivery
Separating deploy from release, and exposing a change to users in controlled increments.
Rollback & Forward Fix
When reversing is genuinely possible, and designing so that it usually is.
Database Migration Under CD
Expand-contract, backwards-compatible schema change, and migrations that cannot roll back.
GitOps
Declared desired state in version control, with a reconciler closing the gap continuously.
IaC Modules & Drift
Reusable infrastructure modules, state ownership, and detecting what changed out of band.
Policy as Code
Encoding standards as automated admission and plan-time checks instead of review comments.
Pipeline Secrets
Short-lived credentials, workload identity, and why the CI system is a prime target.
Supply-Chain Provenance
SBOMs, signed artifacts, attestation, and knowing what actually went into a build.
Deployment Gates
Automated verification between stages, and the difference between a gate and a delay.
Flow Metrics
Work in progress, flow time and flow efficiency — where a change waits rather than moves.
Change Management vs CD
Reconciling CAB-era controls with continuous delivery without pretending either away.
Multi-Region Rollout
Ordering regions, bake time, and stopping a bad change before it becomes global.