A Revision History for the Building Itself

Opening Scene

A building whose blueprints are kept in a well-organized archive, with every revision dated and attributed, lets anyone later understand exactly what changed, when, and why. A building whose plans exist only as scattered, informal notes offers no such clarity. Version-controlling infrastructure definitions gives cloud infrastructure this exact same durable, reviewable revision history.

In Plain English

Because infrastructure as code definitions are just text files, they can be stored in the same version control systems — most commonly Git — that have long tracked application code changes. This gives infrastructure the same durable benefits: a complete history of every change, clear attribution of who made it and why, and the ability to review a proposed change before it’s actually applied.

The Old Way

Before infrastructure definitions were commonly stored in version control, this durable history simply didn’t exist for most infrastructure:

Infrastructure changes made manually through a web console left no durable, reviewable record of exactly what changed or why.
There wasn’t yet a well-established practice of applying the same version control discipline to infrastructure that had long been standard for application code.
Understanding why a piece of infrastructure was configured a certain way often required asking around, rather than simply checking a change history.

Infrastructure changes without a durable, reviewable version history is what version-controlled infrastructure as code directly addresses.

What’s Changing (and Why AI Is the Reason)

Organizations increasingly store infrastructure definitions in the same version control systems as application code, applying identical review and history practices to both.
This connects directly to the peer review practice covered in Article 12, which depends entirely on infrastructure changes existing as reviewable, version-controlled proposals before being applied.
As AI-generated infrastructure code becomes more common, a durable version history has become especially valuable for understanding exactly what an AI tool proposed, why, and how it differs from the previous state.

The Metaphor, Fully Extended

The Brick Mold	Infrastructure as Code Concept
A well-organized archive of dated, attributed blueprint revisions	Version control tracking every infrastructure definition change
Scattered, informal notes offering no clarity	Manual configuration leaving no durable, reviewable record
Understanding exactly what changed, when, and why	Understanding exactly what changed, when, and why through commit history
The same durable discipline long applied to other records	The same version control discipline long applied to application code

For Beginners: What to Actually Do

Practice checking whether infrastructure definitions you have access to are stored in a version control system like Git.
Learn to read a commit history for infrastructure changes, noticing who made a change and what the accompanying explanation was.
Get comfortable with the idea that infrastructure deserves the same review discipline application code has long received.

For Practitioners and Leaders: The Deeper Layer

Store all infrastructure definitions in version control, applying the same review and history practices used for application code.
Build peer review into infrastructure change workflows, connecting directly to the practice covered in Article 12.
Maintain especially careful version history for AI-generated infrastructure proposals, given the value of understanding exactly what changed and why.

Quick Recap

Infrastructure as code definitions can be stored in version control, just like application code.
This provides a complete history of every change, with clear attribution and the ability to review before applying.
This durable history didn’t exist for manually configured infrastructure.
AI-generated infrastructure proposals make this version history especially valuable for understanding exactly what changed.

Where This Fits in the Series

Article 4 covered giving infrastructure a durable, reviewable revision history. Article 5 turns to a related property well-designed IaC tools should have: running the mold twice, getting the same brick.