CI/CD Pipelines and Version Control for Network Automation
Treat network configuration like software: versioned, reviewed, tested, and deployed through a pipeline. Know Git fundamentals: repository, commit, branch, merge, pull request, tag, and remote. Understand branching strategies (feature branches, main/trunk) and why peer review via pull request is a control point. Know that .gitignore keeps secrets/artifacts out, and that committing credentials is a serious security failure.
Understand the CI/CD pipeline stages: commit → lint/syntax check → unit tests → render/template validation → dry-run/check against devices or a lab → approval gate → deploy → post-deploy verification → rollback on failure. Know the difference between continuous integration (build/test on every commit) and continuous delivery/deployment (automated release; delivery keeps a manual gate). Understand artifacts, pipeline-as-code, and environment promotion (dev → staging → prod).
Traps: assuming CI/CD means fully automatic production changes (delivery often includes approval gates); confusing testing the template with testing the device outcome; and forgetting rollback and idempotency in the pipeline design. Expect questions on secrets management (vaults, env vars, never in Git), audit trails (commits and pipeline logs), and immutable/reproducible builds. Also know that pipeline failures should halt promotion, not be bypassed.
Rule of thumb: nothing reaches production that has not passed automated validation and human review; every deployment must have a tested rollback path.
Worked example: A pull request changes a Jinja2 template; CI renders it, runs commit check in a lab, posts results to the PR, and only after approval does the deploy stage apply a confirmed commit to production with automatic rollback on failure.