Reproducibility means using the same configuration to recreate an environment or infrastructure resources. It replaces manual reconstruction with a repeatable source of truth. section 1.3.1 section 1.6
A manual console change breaks reproducibility when version-controlled configuration still describes the old state. Update the configuration first, then apply the automation, so teammates and newly created environments receive the same change. section 1.3.1 section 2.4
Apply reproducibility through these infrastructure practices:
- Keep infrastructure configuration in version control and use commit messages to record why a change was made and how it affects other resources. section 2.3.1
- Parametrize names, environments, and dependencies so one configuration can produce appropriately varied environments without being rewritten. section 2.4
- Prefer immutable changes that replace a resource rather than accumulating localized mutable changes that must later be reconciled. section 2.4
- Separate resource automation into create, read, update, and delete operations, and use reusable modules for standard infrastructure components. section 2.4 section 3.6
- Assess reproducibility alongside idempotency, composability, and evolvability before adopting an infrastructure tool or configuration. section 1.3.5
On-demand testing environments
A QA team copies the production configuration, changes its variables and parameters, runs performance tests, and deletes the environment afterward. Reproduction keeps testing aligned with the latest production configuration while avoiding an environment that runs unused for most of the year. section 12.3.1 section 12.3
Figure 1.6 Manual changes introduce drift between version control and actual state and affect reproducibility, so you instead update changes in version control.
Use the figure to trace how manual changes create drift between version control and actual infrastructure, then restore reproducibility through configuration. section 1.3.1
