The scariest command in networking is no longer 'reload' — it's 'git push' when a pipeline you wrote is about to touch 100 devices. Here's how to build that pipeline so it's safer than any human at a keyboard.
The Repository Layout
Structure the repo around intent, not devices: a host inventory (YAML), per-role templates (Jinja2), and variables split by site and role. Every config change becomes a pull request with a diff a colleague can review.
Stage 1: Validate
The first pipeline stage costs nothing and catches most mistakes: YAML linting, Jinja2 render checks, and schema validation of variables. If an engineer typos a VLAN ID as a string, the pipeline fails in twelve seconds — not on the switch.
Stage 2: Test Against a Lab
Spin up a containerlab or CML topology that mirrors a slice of production. Render the configs, push them to the lab devices, then run automated assertions with pyATS or Nornir: are the BGP sessions established? Is the OSPF neighbor count right? This is where confidence comes from.
Stage 3: Dry Run in Production
Use NAPALM's commit-confirm or vendor dry-run mechanisms to generate real diffs against production devices without applying them. Post the diff back to the merge request. A human approves the exact lines that will change.
Stage 4: Deploy in Waves
Never deploy everywhere at once. Wave 1: one canary device per role. Automated health checks run — interface errors, routing table deltas, syslog anomalies. Only when the canary passes does the pipeline proceed to the next wave, with an automatic rollback path armed at every step.
What This Gets You
Change windows shrink from evenings to minutes, every change is reviewed and reversible, and the network stops depending on which engineer happens to be awake. That's the job in 2026.