What's changed: Initial version
5.2Testing, CI/CD, and automation tools
Covers the CI/CD pipeline (lint -> test -> deploy) for shipping network changes safely, Cisco Modeling Labs (CML) for trying changes in a virtual lab, pyATS for validating state, and the strengths of Ansible (agentless, idempotent), Terraform (declarative, state management), and Cisco NSO (multi-vendor, service model), framed as the judgment of "what does this pipeline stage protect" and "which tool for this requirement."
Automation also carries the danger of "distributing a wrong configuration faster and wider." That is exactly why you need a mechanism to verify changes mechanically before they reach production (tests and a pipeline). This section organizes what each CI/CD stage protects when shipping network changes safely, the roles of the virtual lab CML and the test framework pyATS, and choosing among Ansible, Terraform, and NSO by "what each is good at"—as a match against requirements, not rote tool comparison.
5.2.1Stages of a CI/CD pipeline
- CI (Continuous Integration) runs an automatic build, check, and test on every commit/Pull Request, catching broken changes early. For networks, a lint (syntax/format check) stage (e.g.,
yamllint) first mechanically confirms "is the syntax even valid?" If it fails here, the change stops before reaching production. - CD (Continuous Delivery/Deployment) is the stage that distributes passing changes to production automatically (or after approval). A typical order is
lint -> test in a virtual lab -> approval -> deploy to production -> post-verification. Each stage is a gate that lets only what passed the previous one through, and which stage failed becomes the clue for isolating the cause.
Continue reading — free sign-up
You're reading the free preview. Sign up free to read this section in full, plus every chapter (including 4+) and all questions.