Tutorials · DevOps & Containers

How to Build a Safe Change Process for Networks and Edge Apps (CI/CD)

Most outages start with a change. Use a simple pipeline: change in Git, automatic checks, peer review, staged rollout, monitoring and a one-command rollback.

Advanced15 min6 steps

Before you start

  • Configurations and compose files in Git
  • A CI service (GitLab CI, GitHub Actions or similar)
  • A lab or pilot site

Step by step

  1. Change on a branch

    Every change is a commit with a clear message and a ticket number.

  2. Automatic checks

    The pipeline validates syntax and policy before anyone reviews it.

    # .gitlab-ci.yml (example)
    validate:
      image: docker:27
      script:
        - docker compose -f site1/edge/compose.yaml config --quiet
        - ansible-playbook edge.yml --syntax-check
    
  3. Peer review

    A second engineer reviews the diff and the rollback plan. No one approves their own change.

  4. Staged rollout

    Deploy to the lab or a pilot site first, wait and watch, then roll out to the rest in waves.

  5. Watch the metrics

    Compare alarms, latency and error rates before and after. Stop the rollout at the first unexpected alarm.

  6. Roll back fast

    Revert the commit and redeploy. Practise the rollback before you need it.

    git revert <commit> && git push
    # the pipeline redeploys the previous version
    

Commands are generic, industry-standard examples. Exact syntax and menu names vary by model and firmware; check your device's manual on the Documentation page.

Pro tips

  • Schedule risky changes in a maintenance window, but do not let windows replace testing.
  • Record every change in NavCloud's audit log or your ticket system.