CI-CD pipelines for networks (NetDevOps)

Share

Requirement / business driver

Deliver network changes through a pipeline - validated, tested, staged, and reversible - instead of ad-hoc CLI pushes.

Pipeline stages

On a commit to the source of truth (Infrastructure as Code - declarative, idempotent, source of truth), a CI/CD platform (Jenkins, GitLab CI, GitHub Actions) runs:

  1. Lint / validate - syntax and policy checks.
  2. Test - against a virtual/lab topology (and pre/post automated validation, e.g., pyATS/Batfish-style state checks).
  3. Stage - deploy to a canary/pilot.
  4. Deploy - roll out (often GitOps: merge triggers deploy).
  5. Verify + rollback - confirm intent; revert on failure.

The network-specific challenge

Unlike stateless app deploys, the network is live and stateful with real blast radius - you can't trivially "redeploy." So testing, canary, gating, and rollback (Reference models and migration considerations) matter even more.

Recommendation / justification

Run changes through a CI/CD pipeline with automated pre/post validation, canary, and rollback, triggered from Git (GitOps). Justify by change safety and auditability at scale; the pipeline is what turns IaC from "push once" into a repeatable, reversible process.

What would change this (mid-scenario twist)

  • High blast radius / critical core -> stronger gating + canary + automated verification.
  • Regulated environment -> pipeline-enforced review/approval and immutable audit.

Validation checks

  • Are there automated pre/post checks and a canary stage before full rollout?
  • Is rollback defined and tested (not just deploy)?

IPv6 / dual-stack note

Pipeline tests must validate v4 and v6 reachability/state - a v4-only test suite passes while v6 silently breaks.

Spaced repetition

List the core stages of a network CI/CD pipeline.

Lint/validate -> test (virtual/lab + pre/post checks) -> stage/canary -> deploy -> verify + rollback.

Why is CI/CD harder for networks than for stateless apps?

The network is live and stateful with real blast radius - you can't trivially redeploy, so testing, canary, and rollback are critical.

"GitOps" means [...].

"GitOps" means the Git repo is the trigger and source of truth: a merge drives the automated deploy.

Sources

  • Cisco Press, Network Programmability and Automation; CI/CD (GitLab/GitHub Actions) references.

domain: Core · blueprint-ref: Core 8.2.a CI/CD and automation platforms (Jenkins, GitLab, GitHub) · type: design-decision · status: complete · tags: [core, core/automation, tradeoff/operability, tradeoff/convergence]