NETDEVOPS: Understanding Continuous Integration (CI) Pipeline with Gitea and Drone with a Small Network Configuration Change

In this article, I will describe the process of continuous integration (CI) and how you can commit your first NetDevOps config-as-code build using Gitea. It is also my hope that this inspires readers to really commit to transforming their career to network automation engineer or NetDevOps given the enormous potential.

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

Gitea is a self-hosted Git service which means you can install and run it on your workstation as a SaaS service without any external dependency whatsoever. It is similar to GitHub, Bitbucket, and Gitlab. As discussed earlier, I prefer Gitea over Gogs for many good reasons. I am using Gitea within a Docker container that’s running inside my VirtualBox VM which is running on my Ubuntu Linux distro. You can run Git on just about any platform where Go would provide you with an independent binary which obviously includes Linux, Windows and macOS/OSX.

Installing Gitea inside a docker container is pretty straightforward. After starting the Docker setup via docker-compose Gitea should be available using your browser to finalize the installation. You can connect to it using http://localhost:3000 and follow the installation wizard. If you are coming from Gogs, you can refer to details here. You can do a ls docker container to get the details of your installation. It should look similar to what I have below on my machine.

I have seen folks using Gogs, so if you are curious, you can refer to Gitea versus Gogs detailed feature by feature comparison here. At the end of the day, both will perform the needed job of config version control and CI integration.

When you log in, you will come to the following Gitea dashboard.

As you can notice, Gitea has a dashboard and separate links for issues, pull requests and explore. Dashboard features a summary of your config/code integration activity. In my case, I have a dev_branch where I make all my changes, then my Drone server facilitates the testing using dev_branch, followed by testing using a realistic topology and if everything finishes successfully, then merge dev-branch into master before pushing that out to production network.

Let’s now go through an example of the integration part of that NetDevOps pipeline. The handoff between Gitea (CI) and Drone (CI/CD) happens when I commit my config change into dev-branch. As we previously discussed, since Gitea doesn’t support OAUTH2 for a seamless handover between CI and CD stages per se, I have to manually enter my user password each time a commit is permitted to proceed from Gitea to Drone.

CI benefits NetDevOps the most because it allows for config-as-code produced to be automatically tested and continuously “integrated” with other NetDevOps members’ code, and with the existing config or codebase. The NetDevOps team benefits from receiving continuous and immediate feedback regarding their config changes and integration errors. As a member addresses these errors, automated testing tools such as Drone (along with GNS3 or Cisco VIRL) in this stage will report if the errors were successfully fixed and when the config change is accepted. This continuous feedback loop dramatically increases a NetDevOps member’s productivity for making frequent network changes while decreasing the likelihood of a network downtime.

Unless a network change is all about house keeping, Continuous Delivery benefits the business itself who are supposed to benefit from the resulting network changes because as soon as config is successfully accepted in the CI stage and a can be tested, it is deployed to given networking devices. Optionally, business groups can verify that changes meet their expectations and provide feedback to NetDevOps team who then address the feedback in this stage.

Anyhow, now let’s go back to making our first network change. In my example, I will be modifying read and write SNMP community strings to showcase my NetDevOps Gitea/Drone CICD pipeline.

I manually edited my all.yml file that contains the global variables used in my Ansible playbooks. I edited the file and modified the SNMP community string values to NewSecureReadJuly4th and 4NewSecureWriteJuly4th. This was done prior to issuing git add and commit. git add adds your modified files to the queue to be committed later whereas git commit commits the files that have been added and creates a new revision with a log. If you do not add any files, git will not commit anything. You can combine both actions with git commit -a.

Now, the final step before Gitea CI will trigger the Drone CI, involves pushing the config change using git push. git push pushes your changes to the remote repository. You can see what happens once I issue git push in the screenshot below.

Using above, I pushed my changes into dev_branch and it triggered the CI stage in both Gitea as well as Drone which is my build server. You can see 4 objects, since my change calls for removal of two SNMP CLIs which sets the READ and WRITE community strings and then replace them with newer values.

Let’s now look at what happened on Gitea server after my git push.

You can see “-” and “+” denoting what was removed versus added from the configuration, it also shows +2/-2 to describe the same information. 10.0.10.1 is my switch IP address where these changes are to be tested and then committed.

Let’s now look at what happened on Drone server after my git push.

If you follow the commit message, “FullStackNetworker #1”, you can see the there was an initial build->test cycle for dev_branch and after successful completion, it was repeated for master branch before finally deploying it to my switches.

Let’s zoom into each dev_branch first on Drone server. On the right side it shows the steps taken around the Gitea/Drone handoff as part of “Clone” stage within my CICD pipeline configuration. My pipeline consists of build start stage, followed by integration testing and merge change into master and then notify NetDevOps team via Slack.

You can see that for 4 lines of change, the entire pipeline for dev_branch and master branch takes only about 3 minutes or so. If your config changes are larger, or your pipeline is longer or more complex, it will take longer. Drone server simply works as an orchestrator and follows the flow of control within your pipeline file. We will discuss the pipeline in more details in the future posts.

Below is a screenshot from my Slack channel which shows that NetDevOps team was notified for dev_branch and master build completion and pipeline execution success.

If you’re still following, you can easily witness that how network programmability is NOT DevOps, there is a lot more to it than just throwing the Ansible and Python together. NetDevOps is about DevOps toolchain, methods and culture coming to networking.

Now, last but not least, I invite you to come and join me on Full Stack Networker Blog and using our social channels. I will soon be discussing NetDevOps delivery pipeline and network automation in more detail.