Continuous integration and continuous delivery/deployment (CI/CD) is a set of modern software development practices used for delivering code changes more reliably and often. While CI/CD is widely adopted in the software world, it’s becoming more relevant for network engineers, particularly as networks become automated and software-driven.
In this post, I briefly introduce CI/CD and explain how network engineers can use these practices for network automation, particularly when using Cumulus Linux and simulating with the NVIDIA Air digital twin platform.
What’s a CI/CD pipeline?
A CI/CD pipeline automates the software delivery process. It ensures that code is tested, validated, and deployed across environments in a repeatable and scalable way. The pipeline integrates:
- Continuous integration (CI): Code is frequently merged and tested.
- Continuous delivery/deployment (CD): Code is packaged and deployed automatically across testing, staging, and production environments.
For network engineers, this translates to a more efficient, reliable process for deploying network configurations and automation scripts.
Why CI/CD for networks?
With a network operating system like Cumulus Linux, which natively supports automation and scripting thanks to its Linux roots, network automation can adopt the same principles used in software engineering.
Why is it important?
- Speed: Faster iterations and deployment of changes.
- Quality: Automated linting and validation reduce errors.
- Reliability: Consistent processes mean fewer surprises in production.
- Scalability: Easily support growing infrastructure and use cases.
CI/CD applied to network automation
Let’s look at how network engineers can apply CI/CD concepts in practice.
Code commit: treating configuration as code
If we treat network configurations as code, changes like automation scripts or topology configs go through version control (e.g., Git). This makes changes traceable, reviewable, and testable, like any software development workflow.
By accepting configuration changes as code changes, network teams integrate directly into DevOps workflows, improving visibility and governance.
Continuous integration (CI)
CI automatically verifies that code changes are valid and buildable.
For network use cases:
- Artifacts can be automation scripts, container images, or rendered config files.
- Linting and format checks ensure that YAML, JSON, or Jinja2 templates are syntactically correct and consistent.
- Instead of manually creating static config files, use Jinja2 templates to dynamically generate configurations based on variables like topology, node role, or function. This minimizes human error and increases flexibility.
Continuous delivery (CD)
CD automates the deployment of validated configurations to testing and production environments.
For example:
- Rendered configs are deployed using automation tools and scripts.
- Logging and debug hooks should be built into the pipeline to catch errors early.
- Health checks and validations can confirm that configs are deployed successfully across all network nodes.
While we won’t dive into the full details of building a pipeline (e.g., using GitLab) in this post, it’s important to highlight that the key configuration file in a GitLab CI/CD setup is the .gitlab-ci.yml file.
This YAML-formatted file defines how the pipeline operates, specifying the stages, jobs, and execution logic. It tells GitLab how to orchestrate tasks like configuration rendering, testing, validation, and deployment.
Because this file serves as the blueprint for your entire automation workflow, it’s essential to understand how to structure it properly and define task parameters correctly. In an upcoming post in this series, we’ll take a closer look at how to write and manage a .gitlab-ci.yml file effectively for network automation.
Automated testing and verification
CI/CD pipelines can include automated validation by:
- Running show commands across devices.
- Parsing outputs to check success criteria (e.g., interfaces up, BGP neighbors established).
- Flagging failed deployments before they reach production.
This provides continuous feedback on network health and prevents misconfigurations from propagating.
Using CI/CD with NVIDIA Air
The NVIDIA Air digital twin platform is an advanced simulation environment for modern data centers. It enables the simulation of complex networks using Cumulus Linux, SONIC, and the possibility of simulating host operating systems.
Users can build topologies using:
- A graphical tool (drag-and-drop).
- JSON/DOT files (for programmatic creation).
While manual setup works for general use cases and is very intuitive, CI/CD pipelines offer more professional workflows for rapid iteration, validation, and sharing.
Automating NVIDIA AIR using APIs:
- A REST API for low-level automation
- A Python SDK, which wraps the API and provides automation-friendly abstractions
Using either method, pipelines can:
- Spin up topologies.
- Inject configurations.
- Trigger validation scripts.
- Destroy and rebuild labs for repeatability.
Practical use cases for CI/CD and NVIDIA Air
Network engineers can use CI/CD with NVIDIA Air for:
- Config integration: Tie config generation directly into automation pipelines.
- Workshops and demos: Auto-generate consistent, reproducible labs for workshops, training,s or demonstrations.
- Partner solutions: Create shareable templates that deliver custom topologies to customers or partners.
- Automated testing: Quickly validate changes across diverse topologies with zero manual effort.
Example CI/CD pipeline for a data center simulation environment on NVIDIA Air
The following is a real life example from our development team of a CI/CD pipeline with NVIDIA Air, simulating a data center use case:
- Pull relevant repositories from their sources: There are multiple git repositories used for various purposes(AIR automation code, Network configuration rendering are stored on separate repositories), this job pulls all the sources from repositories, including topology files and configuration scripts, jinja2 templates.
- Run some config file syntax/formatting checks: We need to validate if the topology files are following formatting requirements and can be parsed by the Air API.
- Create topology as an AIR simulation: We create an AIR topology from a dot or a json file.
- Configure topology parameters: Modify topology parameters like organization selection or expiry of the simulation.
- Start simulation and configure network devices and servers: We start AIR simulation usign the API calls, and copy rendered configuration files to network devices and servers.
- Validate topology with various show commands and ping tests: Validate if topology is correct to check whether cabling is according to the design or not.
- Save everything and turn off simulation: Save the simulation for later use and turn it off.
Conclusion
CI/CD pipelines—standard tooling in software engineering—are now a crucial part of network automation. With platforms like Cumulus Linux and NVIDIA Air, network engineers can bring the same agility, reliability, and efficiency to their operations.
By combining CI/CD best practices with powerful simulation tools, we can deliver highly scalable, error-free, and rapid network deployments—whether in a virtual lab or production data center.
Learn more
- An Introduction to NVIDIA Air
- Connect Simulations with the Real World Using NVIDIA Air Services
- Advantages of External File Uploads for Scalable, Custom Network Topologies in NVIDIA Air
- Automating Network Design in NVIDIA Air with Ansible and Git
- NVIDIA Air Documentation
- NVIDIA Cumulus Linux datasheet
- NVIDIA Cumulus Linux documentation
