Building upon our DevOps knowledge base, in this article, I will go over a practical version of a complete NetDevOps delivery pipeline.

Cisco DEVASC 200-901 DevNet Associate 200-Hour Learning and Study Plan

Cisco DEVCOR 350-901 DevNet Professional Core Exam 115-Hour Learning and Study Plan

Before we proceed any further, let me set the stage a little bit by settling a couple of new terms. Overall, NetDevOps pipeline consists of four major steps, Creating, Building, Testing and Deploying Config-as-Code. During those steps, we will perform both unit and integration testing to ensure that our network change doesn’t and will not Kaput the production network or result in a downtime. Build and Test stages combined make up our automated NetDevOps CICD pipeline. I will explain those in detail in a moment as we discuss each stage. While we are at it, let me also say that we’re not trying to reinvent something here with NetDevOps pipeline, the whole process is nothing but repurposing DevOps toolchain and concept of Infrastructure as Code or IaC, to express Config-as-Code while leveraging network programmability.

Last but not least, the operating principle behind NetDevOps pipeline is based on the fact that the most fundamental metric to evaluate network change outcomes is the network uptime.

Now, you can divide the overall NetDevOps pipeline execution into four major steps.

Creating, verifying, committing and pushing your configuration change within the development configuration branch

Step #1. It consists of creating, verifying, committing and pushing your configuration change within the development configuration branch. What do I mean by development branch? Within an organization, where developers are writing new features or fixing bugs, they do so by cloning or pulling down a main or a master branch as a development or dev branch. Then, they make all their changes first into that dev branch, as opposed to adding them directly to main or master code.

Now, let’s revisit DevOps toolchain. During this step, your toolchain would include GitHub, Ansible, and a tool to help you build the topology for unit testing, for example using Vagrant or Cisco VIRL in case if the device or unit is from Cisco. Let me clarify unit testing here. In this context, unit testing means verifying and validating the configuration change that you just made as a NetDevOps. This kind of unit testing is also known as white box testing. Once unit testing is successfully completed, you will need to merge and commit your validated configuration into dev configuration branch, again using GitHub or another similar tool. When you do a push, say you use “git push” command, then your configuration is pushed into your build tool such as Jenkins or Drone which is another open source CICD platform. Once you “push” your configuration, this officially initiates and kicks off your NetDevOps CICD pipeline.

Before we proceed further, let me clarify one of many DevOps jargon. Git or GitHub, as used in this context, are referred to as Version Control System or VCS and also Source Control Management or SCM. Now, SCM that I just mentioned, is NOT be confused with Software Configuration Management which is a much bigger and separate topic.

Build system validates network changes with integration testing and merges dev into main branch

Step #2. During step #1, as soon as you performed the “git push”, git will reach out to your build tool using the same dev branch. Your build tool will pull down a clone of your dev branch and start executing the pipeline that you configured it with.

First step, in your CICD pipeline, will likely be to start your simulated test network topology. How does that happen? Obviously, you will be using a virtual topology, so your build tool will need to use Vagrant or Cisco VIRL to perform that action. Once that is completed, depending on the pipeline configuration, your build server may use Ansible to configure your virtual test network that you just built. In order to conduct effective integration testing, you will need a testing strategy, let’s say in the form of an Ansible playbook, that allows you to validate that your test network is working as expected with the modified network configuration. Let me clarify. The purpose of integration testing, as opposed to unit testing, is to ensure that entire existing network continues to work without any hiccups after your configuration changes are committed. Now, before you say, wow I need to write test plans too! Listen, in a medium to large organization, you can expect integration testing playbooks to be written by dedicated QA or Test engineers. Once test validation is successfully completed, your build tool should take down the integration test network topology and merge the validated dev branch into your master or main branch.

Build system validates network changes with a production test network and builds master branch with configuration changes

Step #3. Your build system builds the master branch and repeats all the steps carried out in step #2. Let’s revisit the steps again. Your build server will kick off CICD pipeline by creating a simulated version of your production network, validate your network change as part of master branch using the test topology, if everything goes fine, it will take down the test topology and complete building the master configuration branch.

Build system deploys final configuration using Ansible deployment playbook

Step #4. Once master branch build is successfully done, depending on your pipeline configuration, your build server should push your configuration into your production network using perhaps yet another Ansible playbook.

While all of this may sound overwhelming but let me assure you that once you have configured a pipeline and corresponding ansible playbooks a few times, it will all come as second nature to you. Beyond the very first step where you create, verify, commit and push your network change as part of dev branch, everything else is handled automatically by your build system, as part of CICD pipeline, and that is where you see real value in both speed and accuracy of network change deployment.

Now, last but not least, I invite you to come and join me on Full Stack Networker Blog. I will soon be discussing NetDevOps delivery pipeline in more detail along with actual Ansible playbooks and toolchain configuration.

Please feel free to share your questions or comments, I will be answering them over the next few days.