Defining an IaC strategy
Define an IaC strategy
Infrastructure code is code. The strategy is mostly about applying the disciplines you already apply to application code.
| Discipline | Applied to infrastructure |
|---|---|
| Source control | Templates and modules in git, reviewed by pull request |
| Testing | Lint → validate → what-if / plan → deploy to a disposable environment |
| Promotion | Same template, different parameter files per environment |
| Release | Deployed by the pipeline, never by hand |
The parameterisation rule
One template, parameter files per environment. Environment-specific templates are the anti-pattern — they drift apart, and the thing you validated in test is no longer the thing you deploy to production. It is exactly build once, deploy many applied to infrastructure.
Preview before applying
ARM/Bicep what-if shows the changes a deployment would make before it makes them. Running it in the pipeline and surfacing the output turns an infrastructure review into a review of actual consequences rather than of template diffs — the difference between "this line changed" and "this will delete the database".
State and idempotency
Declarative templates converge to the described state, so re-running is safe. That is what allows the same deployment to run on every commit without a human deciding whether it is safe this time.
Primary sources