Infrastructure as code for network configs: a gentle start with Git
"Infrastructure as code" sounds like it requires a CI/CD pipeline, automated testing, and a platform team before it's worth doing. It doesn't. The first and highest-leverage step is embarrassingly simple: put your device configs in a Git repository and stop editing them live as the source of truth.
Why a diff beats a memory
The real value of version control isn't automation — it's the diff. When a config change goes into Git as a pull request, the reviewer sees exactly which lines changed, not a wall of running-config to eyeball for what's different from last week. Most "we didn't mean to change that" incidents are caught right here, before anything touches a device.
A workflow that doesn't require new tooling
- Export running configs into a repo, one file per device (or use a templating tool later — text files work fine to start).
- Any planned change is a commit, with a message describing why, not just what.
- A second engineer reviews the diff before it's applied — same as reviewing code.
- The applied config and the repo stay in sync; drift between them is itself a signal something happened outside the process.
The payoff compounds
None of this requires templating engines or a pipeline to start paying off. Six months
in, you have a searchable history of every intentional change to every device, with a
reason attached to each one — something almost no network team has today, and something
that turns "why is this configured this way" from an oral-history question into a git blame.