How Do You Set Up a Network CICD Pipeline?



Delivering on an "always-on" network infrastructure to support the larger digital business requirements demands a disruption of your existing processes and communication silos. Continuous integration and development (CICD) pipelines are targeted at helping implement network changes quickly and pushing them into production networks while minimizing network outages.

This approach has been employed in the software engineering community for a long time now to develop and roll out new applications. This has helped software development teams to deliver on changing business needs at a faster rate. There's a lot that we could pick up from it and help make the network much more agile.

One of the fundamental shifts that need to happen is to remove the human element from the direct control path of the network. Having a network engineer maintain direct control over the network by forming a manual, human pipeline for making changes to the network has proven to get in the way of delivering an "instant-on" network.


A manual human pipeline illustration. | @Oreilly

A manual human pipeline illustration. | @Oreilly

What is: CI and CD?

CI is an acronym for Continuous Integration, a common practice in the software development community whereby all developers merge code changes in a central repository multiple times a day. CD is Continuous Delivery which refers to automating the entire software release process.

With CI, each change in code triggers an automated build-and-test sequence for the given project, providing feedback to the developer(s) who made the change.

Continuous Delivery includes infrastructure provisioning and deployment, which may be manual and consist of multiple stages. What’s important is that all these processes are fully automated, documented and visible to the entire team.


What is a Network CICD Pipeline?

A Network CI/CD pipeline helps you automate steps in your network provisioning process, such as initiating config builds, running automated tests, and deploying changes to a production network. Automated pipelines remove manual errors and help implement standardized change processes.

A network CICD pipeline typically consists of four main stages; Creating, Building, Testing, and Deploying configuration as code. It is also important to note that we are not reinventing the wheel. CICD pipelines and DevOps are techniques that have been in use in the software development industry for a long time now. We are simply translating those DevOps processes and concepts of Infrastructure as code to represent device configs as code while leveraging software-defined networking.


Network Configuration CICD Pipeline

Continuous Integration employs direct device-to-device communication, whereby network devices and automation tools get to directly share data and traffic telemetry between each other.

With this approach, the network configurations are treated as code, just like software applications. The network configuration is stored in version control systems such as Git. To make any change, a network engineer creates a local version of the configuration in a branch. This change is tested locally by the network engineer using custom development environments and when satisfied committed locally and pushed to a shared team repository system kicking off a new build.

Network operations are comprised of many engineers, all working on individual changes and configurations. Eventually, the individual work needs to be brought together and combined into a single configuration base. Individual engineers should be testing their changes as they work. Once integrated, tests can be run verifying that the changes work as designed and as expected.


Network CICD pipelines workflow illustration. |@DevNet

Network CICD pipelines workflow illustration | @DevNet


Generally, a CICD pipeline starts with creating, verifying, pushing and committing your configuration change within the local development config branch. A local development branch is where the network engineer makes all their changes first before pushing them to the production network branch.

At this stage, tools like Git, Ansible, and Vagrant are used. Unit tests are also conducted to verify and validate that the configuration change that you just made and other files or 'artifacts' is as desired. After this is done, you will need to merge and commit your validated configuration into the development configuration branch using Git. Thereafter, using the “git push” command, your configuration is pushed into your build tool such as Drone; an open-source CICD platform. This officially kicks off your Network CICD pipeline.

Git will reach out to your build tool, in our case; Drone, using the same dev branch. Drone will pull down a clone of your dev branch and start executing the pipeline that you initially preconfigured at the start of the project.

The build tool, in our case Drone, will then use Vagrant or another virtual environment e.g GNS3 and Cisco VIRL to start a simulated test network topology. Once that is completed, depending on the pipeline configuration, your build server may use Ansible to configure the virtual test network that you just built.

An Ansible playbook could then be used to conduct integration testing; making sure that all the different components and stages work as expected after making the configuration changes. Upon completion of the end to end tests, the build tool should take down the test network topology and merge the development branch into your production branch.


Test-Driven Development

Network tests are run on a custom development network that ideally closely mimics the production network to ensure the proposed changes don't negatively impact the network when deployed. Alternatively, after the engineer's branch with proposed changes successfully passes the tests, senior engineers can approve and manually merge the branch into the master production branch just so as to maintain control over the changes into the production network.

Another Ansible playbook can then push your configuration into your production network using the build tool. Also note that after the very first step of creating, verifying, pushing and committing your network change as part of dev branch, everything else is handled automatically by your build system, as part of the CICD pipeline, and that is where you see real value in both speed and accuracy of network change deployment.


Start with simple tasks and environments

Enterprise network configurations are often long and complex with a myriad of features, the dangers of implementing network automation within an existing network before the engineering teams are fully trained and comfortable with the tools and strategies can be disastrous. These dangers are increased when you look at implementing network CICD processes.

Therefore it is highly recommended to take a slow and incremental approach to network automation and continuous development in your pipelines. Start with simple tasks and environments, then improve and scale on those processes with time as you get more confident and skilled.

How can automation tools be used to deliver a CICD pipeline

In this section, we will set up a simple development and production network with a functional CICD pipeline. You'll see how various automation tools can be used together to deliver a complete Continuous Integration and Delivery (CICD) pipeline for the network.

To test our proposed network changes our pipeline will automatically instantiate a "test network" on the development environment. The full "Network as Code" configuration will be applied to the test network and tested to verify functionality. After testing, the test network will be destroyed.


This is how our workflow will look like:

  1. A network engineer stores initial device config in a version control system (Gitlab). This version control system will be our single source of truth for all production network configurations.
  2. A new git branch is created for each config change that is to be made on the network devices.
  3. A pull request alongside a review process is initiated for each change.
  4. An automated test is executed to validate the changes using Ansible.
  5. After a successful change review, the pull request is merged and changes deployed into the production network.


Either Vagrant, GNS3, Cisco VIRL and/or Eve-ng will be used to spin up both our development/test and production virtual network environments. By the end of that lab, we will have created a simple CICD pipeline for network configuration. The lab will demonstrate how the phases from a software CICD pipeline could map to network configurations.


Leave a comment

Please note, comments must be approved before they are published