Continuous Integration and Continuous Delivery
What this domain covers
CI/CD tests pipeline design for network change: source control, automated validation, artefact promotion, safe deployment patterns and rollback.
Core rules and concepts
- Everything in Git. Config templates, YAML data, tests and pipeline definitions live in version control; the pipeline itself is code (Jenkinsfile,
.gitlab-ci.yml). - Continuous delivery vs continuous deployment. Delivery stops at a manual button; deployment ships automatically on green tests. Both are legitimate; hand-configuring a device is neither.
- Build once, promote the artefact. Test the exact artefact that ships; do not rebuild per environment.
- Validation ladder - syntax and lint, YANG or schema validation, template render plus unit tests, lab integration on virtual Junos (vMX, vQFX, cRPD), then production with
commit confirmed. - Deployment patterns: canary (one device or region first), blue-green (parallel path, cut over), and automated rollback via
commit confirmedor a config archive. - Post-change verification is part of the pipeline: assert BGP peers Established, interfaces up, reachability intact. A pipeline that cannot fail on verification is not testing anything.
Worked example
A pull request edits a firewall filter template. The pipeline: (1) yamllint the data file; (2) render the Jinja2 template and diff against current device config; (3) load it into a containerised vMX and run commit check; (4) run assertions - the management-plane session must survive the filter; (5) deploy to production with commit confirmed 5 and confirm only after the assertion job passes. Failure at any stage stops promotion; the artefact never reaches production.
Traps
- Calling a scheduled script that logs into devices "CI/CD" - there is no test gate.
- Testing a rendered config in one environment and deploying a different render.
- Having no rollback path and no verification step.
- Confusing continuous delivery with continuous deployment.