I85PREP
⌘ K
DevNet Professional study materials
DevNet Professional study resources

DevNet Professional: Automation development and CI/CD pipelines

DevNet Professional · Work through your exam, one topic at a time.

All guide sections

Automation development and CI/CD pipelines

What the domain tests

Automation development and CI/CD pipelines covers Python automation, Git workflows, infrastructure as code, testing, and pipeline design for network changes. The exam focuses on repeatable, reviewable changes with automated verification, not on writing a single script.

Core rules

  • Version control: every template, playbook, Terraform module, and test belongs in Git. Feature branches, pull requests, and protected main; commits are the audit trail.
  • Pipeline stages: lint, unit test, integration/lab test, plan/dry run, approval, deploy, verify, rollback. Fail fast: a lint failure should stop before a device is touched.
  • Testing: unit tests mock API calls (responses, unittest.mock); integration tests hit a lab; pyATS/Genie validates operational state; pytest is the common runner.
  • IaC: Ansible is procedural and idempotent per module; Terraform is declarative with state and plan. Neither guarantees idempotency if you use raw CLI commands or command modules carelessly.
  • Secrets: inject from CI secret stores or a vault; never commit credentials or tokens. Use short-lived credentials and least privilege.
  • Artifacts: build once, promote the same artifact; pin container image tags and dependency versions.

Worked example

A pull request changes an interface description template. The pipeline runs yamllint and ansible-lint, then pytest with a mocked RESTCONF client to check the rendered JSON contains the module-qualified interface and description. A --check Ansible run against the lab produces a diff. After review approval, the deploy stage applies the playbook; a pyATS job runs show interfaces and asserts the description and operational state. If verification fails, the pipeline runs the previous template revision. Reasoning: each gate catches a different class of error, and the same tested artifact moves forward.

Traps

Putting credentials in group_vars; testing only after production deployment; using state: latest or unpinned images; treating --check as a full integration test; skipping rollback; and writing scripts that append configuration instead of enforcing desired state.