published: 23rd of January 2018
Continuous Integration and Continuous Delivery/Deployment was traditionally reserved for the software development space. With the push towards infrastructure as code now making it to the networking space the idea of bringing CI/CD methodologies down to the network is gaining alot of traction. So what is this CI/CD hoo-ha all about anyway ?
At a high level, the meaning of CI/CD can be expanded as follows.
Continuous Integration (CI) is the process of developers merging their code into the master branch as soon as possible ..... continuously.
Continuous Delivery (CD) is the releasing of small changes to production on a frequent basis. This could be daily, weekly or monthly depending on the business requirements. Continuous delivery requires automated testing, code quality checks and optionally an automated release process (known as a pipeline) to gain the maximum benefits.
Continuous Deployment (also CD) takes it to the EXTREME !!!!! With continuous deployment, changes that pass the deployment pipelines tests are immediately delivered to production.
You might also hear people talk about agile and how it relates to CI/CD. If you would like an overview of agile see this link.
So how does all this apply to the networking space? Traditionally we configure our networks more like the waterfall model of software development. Waterfall has long development cycles, tightly controlled change windows and yearly or bi-yearly releases.
Although there is not a 1 to 1 correlation between CI/CD for software development and CI/CD for network engineering, if we apply some of the methodologies of CI/CD to the network this would translate to smaller, more frequent changes with automated pre and post change testing resulting in far lower risk, with a much higher degree of confidence in the changes success.
This series on bringing CI/CD to the network will consist of multiple parts (currently number of parts unknown) that covers;
The following software will be used throughout this series.
I will utilize Vagrant to build the topology below (apart from the Slack component). The goal is to build the spine and leaf switches creating two new pods with a series of tests to validate the deployment and confirm host01 and host02 have connectivity.
The CI/CD methodology has alot of advantages for network engineers over the way we traditionally operate a network and looks like it will have a major role in the future of networking. Alrighty then, with all that out of the way lets get cracking on Part 2 of this series: Utility server setup.