The requisite for Continuous Integration and Deployment (CI/CD) pipeline being used in the network is growing. Continuous Integration and deployment helps counteract inaccuracies in daily network deployments and changes, hence is critically required. The upshot for change release and automated network testing is that changes are simplified, done more quickly and more streamlined, with CI/CD.
One step at a time
When making a manual network changes via the CLI, best practice would always suggest making incremental changes. For example, copying into the CLI a hundred lines of configuration changes (this might be on one device or multiple devices spanning different data centres and regions) and then having to troubleshoot what part of that broke the network. Figuring out what part of the change was not working was troublesome, and often could create service downtime, an outage, or at a minimum a few hours of frustration.
The CI/CD pipeline’s main attribute is that changes are somewhat small and the changes are steady and frequent – decreasing the change risk. Even with small changes, an outage can occur. However, due to the small incremental changes, it is easy to identify what change caused the outage, and reverting smaller changes is much more simple.
The web UI in GitLab lets you visualise CI/CD pipelines
and see how changes are progressing.
Validation throughout
Within the CI/CD network pipeline, when a change is required it is initially run and verified automatically within a test environment, and Intuitive Test Automation is run against the proposed change. If this passes your defined QA, and all the tests pass, it is either automatically deployed or the person making the change is given the option to deploy this on the production side of the network. This method of quality control and automation is the future in our network’s fast-paced ‘software-centric’ ecosystem. With network engineers sometimes being required to make change requests as high as five thousand per week, network engineers can now update all of these changes rapidly with less error in the new ‘software-centric’ ecosystem.
Making the move to CI/CD
Moving to CI/CD will change the network dramatically. It will make the changes more productive and lead to more established and better networks. There are steps like automated testing that are required to get started with first, but it should be noted that automated testing is not a tool to build an enhanced network, but a development tool to build a more predictable network. Once this is set up, the benefits of deploying changes several times a day, with greater confidence, can be achieved.
Cisco DevNet – Getting Started and Learning More!
Now that you have read how a CI/CD pipeline speeds up workflows and how this can encourage the teams to push every change often and more quickly without being scared of creating an outage or causing downtime, where can you go now and either start or learn more? Cisco DevNet is a great place to go. Wherever you are on the network automation journey, you’ll find all kinds of helpful information – including learning labs, sandboxes, and API documentation – in the Networking Dev Center.
For access to DevNet and all developer resources you can sign up for DevNet here, or use this QR code.
We’d love to hear what you think. Ask a question or leave a comment below.
And stay connected with Cisco DevNet on social!
Twitter @CiscoDevNet | Facebook | LinkedIn
Visit the new Developer Video Channel
I am interested in what type of network is being discussed here. I'm especially interested in understand the statement: "With network engineers sometimes being required to make change requests as high as five thousand per week".
What is this network doing that it requires thousands of changes per week? Is this a cloud platform?
Thanks,
vrs
Hey Vincent! Thanks for reading, great question. When I was at Cisco Live Barcelona this year, we had two awesome gentlemen come to the DevNet booth we had on network automation and CI/CD. They were interested in how we had set up the demo and spoke of their high volume of changes and their desire to automate their changes. I was not able to ask them how they got this number or if this was an all-time record or how they counted changes for that matter (for example, one customer change that requires adding additional configuration to say 20 devices is one change or 20 changes?). I was certainly taken back as the number is very very high. You are correct, as they did mention to us they both work for a very large managed cloud service/provider. Thanks again. Stuart. 🙂