Continuous Integration and Continuous Delivery
Continuous Integration and Continuous Delivery
This domain tests pipeline design, automated validation, deployment strategies, and rollback. Network pipelines must validate configuration before it reaches production devices.
Core rules
- CI merges code frequently and runs automated build and test on every change. CD keeps the main branch deployable; continuous deployment goes further and releases automatically.
- A network CI pipeline typically lints YAML and Jinja2, renders configs, validates syntax with
commit_checkin a lab, runs unit tests on parsing logic, and publishes artifacts. - Test pyramid: fast unit tests for templates and data; integration tests against virtual Junos or lab devices; a small set of end-to-end checks.
- Deployment patterns include canary (small subset first), blue-green (parallel environments, switch traffic), and rolling upgrades. Every pattern needs a tested rollback.
- GitOps uses Git as the deployment trigger: a merge to an environment branch causes an agent to reconcile the device to the declared state.
Worked example
A pipeline job renders a Junos config and deploys it to two canary routers:
yamllintand Jinja2 render steps fail fast on bad data.commit_checkon a lab vJunos device validates hierarchy and syntax.- The job deploys to canary routers with
commit confirmed 10. - Post-change checks for BGP neighbor state and interface status pass; the job confirms the commit.
- On failure, the job does nothing and the confirmed commit auto-rolls back.
Reasoning: validation happens before production, blast radius is limited to canaries, and the confirmed commit provides an automatic safety net if post-checks fail.
Traps
- Treating a successful
git pushas a successful deployment. - Running integration tests only after production deployment.
- Conflating continuous delivery with continuous deployment.
- Having no rollback path or an untested rollback.
- Pinning no tool versions, so pipelines break unpredictably.