CI/CD Pipeline Components

Mental model

Cisco objective 4.4 says “Describe components for a CI/CD pipeline in application deployments”. Also 5.4 says the same for infrastructure automation. Same pipeline, different payload.

A pipeline is an ordered chain of stages. Every commit flows through. If any stage fails, the pipeline stops (no bad code reaches prod).

[Developer pushes] ─▶ Source ─▶ Build ─▶ Test ─▶ Deploy ─▶ Verify
                        │        │       │        │          │
                     checkout   image  pytest   ansible    curl /
                     code       build  unit     push       health
                                       tests    config

The five stages

1. Source

• Pipeline starts when something changes in the repo (push, merge, cron, manual trigger).
• Pipeline runner (GitHub Actions, GitLab CI, Jenkins, Cisco pxGrid for custom) clones the repo.

2. Build

• Compile, package, bundle, or build container image.
• For a Python script project: install deps with pip install -r requirements.txt.
• For a Docker-based app: docker build -t app:$SHA ..
• Produces an artifact (binary, container image, zip of code).

3. Test

• Unit tests (pytest, go test, mocha).
• Lint (black, flake8, yamllint, eslint).
• Static analysis (bandit for Python security, semgrep).
• For network IaC: ansible-lint, yamllint, dry-run against a lab inventory.
• Fast feedback: 2 to 5 minutes typically.

4. Deploy

• Push the artifact to its target.
• For an app: push container image to registry, roll out to Kubernetes.
• For network automation: ansible-playbook push.yml -i prod, or RESTCONF PATCH.
• Common safety: deploy to staging first; promote to prod on approval.

5. Verify

• Smoke test the deployment (curl the health endpoint, SSH and run show version).
• Compare against pre-deploy state (did OSPF stay converged?).
• If verify fails, auto-rollback (deploy previous artifact) and page someone.

CI vs CD

• CI (Continuous Integration): every commit is built and tested automatically. Catches regressions in minutes.
• CD (Continuous Delivery): every passing build is ready to deploy. A human decides when.
• CD (Continuous Deployment): every passing build is actually deployed. No human in the loop.

Most teams start at CI and the first version of CD, then graduate to full continuous deployment for well-tested services.

A tiny GitHub Actions pipeline

Workflow file at .github/workflows/ci.yml:

name: ci

on:
  push:
    branches: [ main ]
  pull_request:

jobs:
  build-and-test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - uses: actions/setup-python@v5
        with:
          python-version: '3.11'

      - name: Install deps
        run: pip install -r requirements.txt

      - name: Lint
        run: |
          pip install flake8
          flake8 .

      - name: Unit tests
        run: pytest -q

      - name: Build container image
        run: docker build -t myapp:${{ github.sha }} .

Every push to main (or PR against main) runs: checkout → setup Python → install deps → lint → test → build. Any failure stops the chain.

Common pipeline tools

Where network engineers hook in

• Add a lint step for YAML / Jinja templates.
• Add a dry-run step: ansible-playbook --check runs the playbook without changing anything.
• Add an approval gate before Deploy to prod.
• Add a verify step: SSH + show ip interface brief | include up to confirm interfaces came back up.
• Rollback: keep the last-known-good config in Git, re-run deploy with it.

FAQ

What is the difference between CI/CD and GitOps? GitOps is CD with the twist that Git is the single source of truth for desired state. A controller (ArgoCD, Flux) continuously reconciles the live state to match Git. Config drift gets corrected automatically.

Can I use CI/CD for network changes? Yes, and should. Store configs/playbooks in Git; let the pipeline lint + dry-run; deploy to lab, then prod. The 2000s model (SSH + manual change) does not scale.

Does Cisco publish a CI/CD tool? Cisco uses standard tools (GitHub Actions, GitLab CI, Jenkins) rather than publishing its own. NSO has a built-in commit flow with rollback that complements a CI/CD pipeline for network services.