## Core Insight Hermetic builds are insensitive to the libraries and software installed on the build machine — they depend only on known versions of build tools and dependencies. This guarantees that two people building the same product at the same revision on different machines get identical results. Hermetic builds enable cherry picking (rebuilding older releases with specific fixes) and make releases repeatable rather than "unique snowflakes." ## How It Works at Google - Build tools (compilers, etc.) are themselves versioned per the project's source revision — a build from last month won't use this month's compiler - The build process is self-contained and must not rely on external services - Cherry picking: rebuild at the original revision, then include specific post-revision changes - Branch-and-cherry-pick model: branch from mainline at a specific revision, never merge back. Bug fixes go to mainline first, then cherry picked into the release branch ## The Hermetic Principle Applied to Config The same reproducibility principle extends to configuration management: binary configs are snapshotted and released alongside binaries using separate MPM packages. Build IDs allow reconstructing configuration at any point in time. ## Cross-Domain Applications - **Any CI/CD pipeline**: Docker containers and Nix achieve similar hermeticity through different mechanisms - **Debugging production issues**: reproducible builds mean you can always recreate the exact binary running in production - **Compliance**: audit trails become meaningful only when builds are deterministic ## Source - [[Site Reliability Engineering - Chapter 8 - Release Engineering|SRE Ch 8: Release Engineering]] by Dinah McNutt ## Related Concepts - [[Release Engineering Four Principles]] - [[Configuration Management as Stability Risk]] - [[Automation Value Hierarchy in SRE]]