The point of describing infrastructure in code is not elegance. It is that you can destroy an environment on Friday and have an identical one on Monday, which changes how freely a team can experiment.
What you gain
- Environments that are identical by construction rather than by discipline.
- A review process for infrastructure changes, in the same place as code review.
- A record of why something exists, in the commit history.
- The confidence to delete things, because recreating them is a command.
- Onboarding that means reading a repository rather than interviewing a colleague.
Structure it for reuse
- Write one module per logical component: network, database, service.
- Keep environment differences in variable files, not in duplicated code.
- Store state remotely, with locking, so two people cannot apply at once.
- Tag every resource with environment, owner and an expiry where relevant.
- Make destroy a first-class, tested operation, not a theoretical one.
The last point is the one teams skip. An environment that has never been destroyed and recreated is an environment you do not know you can rebuild.
Ephemeral environments per change
Once destroy works reliably, a pipeline can create an environment for each pull request, run the tests against it, and tear it down when the branch merges. Reviewers get a real URL instead of a description, and nothing accumulates.
| Technique | Effect |
|---|---|
| Small instance sizes for review environments | Cost proportional to purpose. |
| Shared managed database with per-branch schemas | Avoids provisioning a database each time. |
| Automatic teardown on merge or after N days | Nothing outlives its usefulness. |
| Seeded, anonymised fixture data | Realistic without exposing real records. |
| A separate account for review environments | Blast radius and billing both contained. |
Start smaller than you think
You do not need to codify an existing estate before benefiting. Write the next new thing in code, then the one after. Importing legacy resources can happen gradually or never; the value arrives with the first environment you can confidently destroy.
Summary
Code the infrastructure, store the state properly, test destruction, and let the pipeline create environments on demand. The goal is not automation for its own sake; it is the freedom to throw things away.
