Back to Posts

Share this post


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

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.

Network Changes with NetDevOps Pipeline

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.

Network Changes with NetDevOps Pipeline

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.

1 Star2 Stars3 Stars4 Stars5 Stars (1 votes, average: 5.00 out of 5)


Comments (6)

  • David Rojas Reply

    Great article and very useful just a quick question when you refer to “build server” what tool is that? Jenkins? etc?

    October 31, 2018 at 10:27 am
    • Paul Adam Reply

      Thank you for dropping and leaving a comment. Build server referred to is Drone (open source, free as in Free) https://github.com/drone/drone .. Jenkins would be an overkill for this task.

      Feel free to let us know if you have any other questions.

      October 31, 2018 at 5:49 pm
      • David Rojas Reply

        So in the case of network ansible playbooks drone will automatically run the playbook against lets say a GNS3 lab environment? and provide results of the tests? of am I missing what it does?

        November 1, 2018 at 10:59 am
        • Paul Adam Reply

          Yes. You will need to create your pipeline file that will guide the overall CICD steps including testing with GNS3 or Cisco VIRL.

          November 1, 2018 at 1:12 pm
          • David Rojas

            One more question we have Jenkins setup along with Ansible tower (AWX) and GNS3 but having trouble figuring out how Jenkins talks to GNS3. I know we can setup jobs to run playbooks from AWX to hit the GNS3 instance but can we have Jenkins talk to GNS3 directly to for example setup the test environment? or setup a new config on a device in a lab we setup there etc? I was looking for a GNS3 CLI but not sure if there is one?

            November 8, 2018 at 10:39 am
          • Paul Adam

            You would need to use RESTful APIs that come with GNS3 for integration purposes. I have never used Jenkins (overkill for NetDevOps use case), but obviously it should work just fine.

            November 14, 2018 at 1:53 pm

Leave a Reply

Your email address will not be published.

Back to Posts
sample guides, quizzes and discount
We hate spam as much as you do.