Configuration Management Tools and Version Control with Git

Configuration Management Workflow

The operational loop is simple: define the desired state, store the change where it can be reviewed, deploy it through automation, and check that the running environment stays aligned.

Desired State and Configuration Drift

Desired state is the configuration an environment should have. It can describe a hostname, VLAN, interface policy, NTP source, access rule or service setting. The important shift is that the intended result becomes explicit and reusable instead of living only in a one-time CLI session.

A Network Change in Real Life

Imagine an operations team needs to add an NTP server and a management VLAN to 40 access switches. A manual approach might mean opening devices one at a time, pasting commands, and keeping notes in a spreadsheet. That process can work for one urgent fix, but it becomes difficult to prove what was changed, which devices were missed, and whether every switch received the same values.

With configuration management, the engineer describes the intended settings once and supplies the device-specific values as data. The tool can check connectivity, apply the change to a small pilot group, show the proposed difference, and then continue through the remaining switches after review. The engineer still decides the scope and approves the change; automation simply makes the approved process consistent.

This distinction matters. Configuration management is not an excuse to press a button against every device. It is a way to make the button operate inside a controlled workflow with an explicit target list, a visible change, and a verification step.

What Belongs in the Source of Truth?

A useful repository contains the information needed to reproduce an approved result. That often includes inventory data, templates, variables, automation tasks, validation checks and documentation. Keeping these pieces together helps another engineer understand both the desired setting and the method used to apply it.

The source of truth should not contain passwords, private keys or long-lived tokens in plain text. Secrets belong in a protected secret store or an approved CI/CD variable system, while the repository contains references to those secrets and the permissions needed to use them. A configuration file that is easy to read but unsafe to protect is not a good automation asset.

What Configuration Management Tools Provide

A configuration management tool gives the workflow an execution and verification layer. It reads variables and templates, connects to targets, applies only the necessary change, and reports what happened.

The best result is not always a long list of changes. A healthy run may report that most devices were already correct and required no action. That is useful information: it shows the workflow is idempotent, meaning repeated runs converge on the same intended state instead of adding another change every time.

How to Choose a Configuration Management Tool

Tool choice should follow the environment and the operating model, not popularity alone. Start with the targets: network operating systems, servers, cloud services and security appliances may expose different connection methods and data models. Then consider whether the team needs continuous enforcement, scheduled runs, event-driven jobs, or an operator-approved change pipeline.

Ansible is often approachable for network teams because it can use existing protocols and readable YAML tasks. Puppet and Chef use a stronger agent-oriented model in many deployments. The important lesson is to evaluate the workflow your organization can operate reliably, including inventory, credentials, logging and recovery.

Agent-Based and Agentless Approaches

Tools differ in how they reach managed systems. The choice affects installation, connectivity, scale, security boundaries and the kinds of environments they fit best.

Why Git Belongs Beside Automation

Git is the history and collaboration layer for configuration files, templates, variables and automation code. It does not replace a deployment tool. Instead, it gives the team a reviewable source of truth before a tool changes production.

1. Edit. Change a template, variable or task in a working branch.
2. Review. Compare the difference and ask whether the intended state is correct.
3. Commit. Record a focused change with a message that explains the operational reason.
4. Share. Push the branch to a remote repository and open a review.
5. Deploy. Run validation and the approved automation workflow.
6. Recover. Use history to understand what changed or restore a known-good version.

A good commit message answers a future question: what changed and why? “Update access switch template” is better than “fix stuff,” but a message such as “Add NTP source for branch switches” gives reviewers and incident responders much more context. Small commits also make it easier to identify the exact change associated with an outage or an unexpected device result.

git switch -c add-branch-ntp
git diff
git add inventory/branch-switches.yml templates/ntp.yml
git commit -m "Add NTP source for branch switches"
git push -u origin add-branch-ntp

These commands do not deploy anything by themselves. They prepare a change for review. Deployment should happen only after the repository checks, peer review and operational approvals that your environment requires.

A Safer Change Workflow

Use batches when the change affects a large fleet. A pilot group can reveal an unexpected platform difference before it becomes a fleet-wide incident. After the pilot, pause long enough to examine logs and device state, then continue with a deliberate batch size. The exact number depends on the risk of the change, the maintenance window and the quality of the rollback plan.

Verification should check more than a successful connection. A device can accept a command while the resulting service remains unavailable, a route is missing, or a policy has the wrong scope. Pair configuration checks with an operational test such as interface state, reachability, routing neighbors, telemetry or an application health probe.

When Automation Does Not Go as Planned

A mature workflow expects partial results. Some devices may be offline, some may already contain a conflicting manual change, and some platforms may reject a field that another platform accepts. Treating every non-success result as identical makes troubleshooting harder.

Rollback is not always a single command. A previous Git version may restore the intended file, but the deployment still needs to be run and verified. Some changes also have dependencies or irreversible effects. That is why backups, pre-change snapshots, staged rollout and a documented recovery decision are more valuable than assuming every change can be instantly undone.

How This Leads to Cisco DNA Center

You now have the operating pattern behind larger automation platforms: structured intent, versioned changes, an execution engine and post-change verification. The next lesson applies that pattern to Cisco DNA Center and its controller-based workflows.

Configuration Management Tools and Version Control with Git Frequently Asked Questions