Module 7.6 20 minAdvanced

Source of truth and change pipelines

Automation is only as good as the data it pushes. This chapter covers where a network's intended state lives (the source of truth), the Git workflow engineers use to change it, the pipeline that reviews, tests, deploys, verifies and rolls back every change, and how drift between the source of truth and the running devices is found and handled.

Course plan — preview

What you'll learn

  • Explain what a source of truth is, and why it holds the intended state rather than the configuration running on the devices.
  • Use the Git vocabulary of a network change: commit, branch, pull request, review, history and revert.
  • Put the stages of a change pipeline in order and say what each one catches: peer review, CI checks, an approved deploy, post-change verification and rollback.
  • Explain how a template and its variables render device configuration, so that the data is what gets reviewed.
  • Detect configuration drift by comparing rendered intended configuration with running configuration, and choose what to do with each difference.

Where the intended state lives

Every network has two versions of itself. The intended state is what the network is supposed to be: which VLANs exist, which address each interface gets, where logs go. The actual state is what the devices are running right now. A source of truth is the one place the intended state is written down, and every tool reads it from there.

In practice the source of truth is a few systems with clear jobs. A Git repository holds the configuration data and templates, an IP address management (IPAM) tool owns subnets and addresses, and an inventory lists every device with its role and site. The rule that makes it work: each fact has exactly one owner.

The running configuration is evidence, not authority. It tells you what a device is doing, which may or may not be what anyone intended. When the two disagree, the difference is called drift, and the source of truth decides which side is wrong.

Nightly configuration backups are not a source of truth. A backup records what the devices were running, mistakes included; it cannot tell you what the configuration should have been.

Why automation needs a source of truth first

The chapter on why we automate introduced idempotency and drift: a declarative tool compares the desired state with the actual state and changes only the difference. Desired according to what? Without a source of truth, it is whatever the person running the job had in mind, or whatever the last device they copied looked like.

Automation without a source of truth just automates mistakes faster. A script that copies one 'golden' switch to two hundred others copies its typos and forgotten test VLANs to all of them, in seconds, with no review, no history and no way back. The tools in the configuration-as-code chapter are only as good as the data they are handed.

Decide where each fact lives first, then automate the push. Automating first gives you fast, consistent configuration that nobody reviewed, consistent in its mistakes too.

8 more sections in this chapter, plus a 4-question quiz.

Course plan

Modules 2–8 are part of the Course & Lab Pass and All-Access Max — start with a free account

You can see the title, summary, learning objectives and the opening sections. The rest of this chapter, like all of modules 2–8, comes with the Course & Lab Pass and All-Access Max. A free account opens Module 1: How Networks Work end-to-end and saves your labs — start there, no card required.

  • Read every chapter in Module 1 — How Networks Work
  • Save labs of up to 5 devices
  • Save up to 3 topologies
  • See the full course syllabus + chapter titles

Free account · no card required · compare plans any time