Before automating a network, you need to know what you actually run in production. Everyone wants to skip that step, and that is exactly where NetDevOps projects go off the rails: you write playbooks before you have a reliable source of truth, and you end up automating the spread of your own mistakes.
NetDevOps brings software-development habits to network operations. The order in which you lay the building blocks matters as much as the blocks themselves: a Source of Truth, then Git, then pipelines. Get it backwards and you version noise and ship wrong configs faster than before.
Source of Truth first
Without a central database, your inventory drifts within weeks. A VLAN renamed by hand during an on-call, an interface added and never documented, a prefix parked in a corner of a spreadsheet. After a quarter, nobody knows which document is authoritative, and the first automation script inherits that fog.
A Source of Truth fixes the problem at the root: you model intent once (sites, devices, IPAM, roles, VRFs) in a database that holds authority, and everything else generates its config from there. No more copy-pasting between a spreadsheet, a variables file and the on-call engineer’s memory: one dataset, readable by humans and pipelines alike.
Two tools share the field. NetBox founded the category and remains the reference for describing a network cleanly; it describes, it does not act. Nautobot starts from the same model and brings automation next to the data, with Python Jobs running inside the SoT itself. For a first clean inventory, NetBox is enough. When you already know you will push automation far, Nautobot saves you a detour. I compared both, plus Infrahub, on the same small lab, all the way to migrating the infra from one to the other (article coming soon). Those deep dives (NetBox, Nautobot) are in French for now.
Git, to version intent
With the SoT in place, Git becomes the record of what you want, not of what is wired. Config templates, variables, schema definitions: everything lives in a repository, with history and a review before merge. Git makes a network change as readable as code: who touched what, why, and what it might break. A VRF change or a new prefix gets discussed in a pull request, calmly, before it reaches a single device. The day a deployment goes wrong, the history tells you which commit introduced the regression, and a revert undoes it cleanly.
Pipelines, to close the loop
What remains is turning intent into config, and config into deployment. On every change pushed, the pipeline runs a few steps: it validates the data (does the schema hold, do the references exist?), renders the configs from the SoT, tests them, then deploys. Pre-deployment tests, the NRFU checks, catch the error before production, not the next morning at standup.
The full chain makes sense there: the SoT states the desired state, Git arbitrates it, the pipeline materializes it.
The classic trap
The temptation, when you discover Ansible or Python, is to write the script that configures the devices right away. It works on three devices in a demo, and it collapses at scale because the data has no home. The reflex that pays is the opposite one: model first, script second. The code then becomes a plain translator between the SoT and the device, instead of the place where the truth lives.
Takeaways
Three building blocks, in an order that is not up for debate. The Source of Truth first, otherwise everything else automates a blur. Git, to treat the network like code. Pipelines, to connect intent to the device. Before the first line of a script, you decide where your network’s truth lives.
Going further
- RFC 9315, the Intent-Based Networking reference: what “declaring intent” formally means.
- The NetBox documentation, to see what a Source of Truth looks like in practice.