Version control as the single source of truth
Version control for code is settled practice. The leap: version control for everything — code, environments, configs, scripts, even the tools. Forsgren's DORA research finds this single practice is one of the strongest predictors of software delivery performance.
Version control records changes, lets you compare, merge, restore, and revert. For decades it has been the standard for source code. Module 04 extends it to the whole system — because delivering value requires code AND the environments it runs in, so both belong in the repo.
Source, deps, static assets — everything the app needs to compile and run.
Schema migrations, reference data, seeds. Forward + rollback.
Terraform, Puppet, Chef, Ansible, AMI templates — whatever builds the infra.
Dockerfiles, K8s manifests, Helm charts, Compose files.
Unit, integration, perf, security, smoke — and the manual test scripts too.
Anything that takes a commit and turns it into a running production artifact.
Also commit the build tooling itself (compilers, test runners, the build environments they depend on). Pinning the toolchain is what lets you reproduce a release from three years ago byte-for-byte.
Dr. Nicole Forsgren's 2014–2019 State of DevOps Reports found that version control for all production artifacts — not just code — was one of the strongest predictors of software delivery performance, which in turn predicted organizational performance.
Why does committing environments predict performance even more than committing code? Because environments are where drift hides. Code drift gets caught by failing tests; environment drift gets caught at 3 a.m. during an outage. Eliminating it removes a whole class of operational risk.
Version control is for everyone in the value stream — QA, Operations, Infosec, as well as developers. If a step in the stream can be expressed as text, it belongs in the repo.
A team has perfect code-only version control: every commit traceable, every diff reviewed. They keep environment configs in a separate shared drive. What does DORA research predict?
// pick one to verify
Argument from a senior engineer: "Putting Terraform configs in Git just creates more pull requests for the SRE team. The shared drive worked fine for 10 years." How do you respond?
// pick one to verify