Continuous Integration/Continuous Delivery (CI/CD)

CI/CD

In the context of network automation, Continuous Integration (CI) and Continuous Delivery (CD) imply full network automation of tasks. This pipeline should be abstracted as an orchestrated chain of automated actions and events based on intent. Through the build–test–release cycle, CI/CD can be achieved. CI enables distributed software development across many teams. Small but frequent incremental changes are continuously integrated into the master branch. CD then automatically deploys these changes to the production network.

Build

A build is a software product in its final, consumable form. While builds are not a necessary part of using Ansible for network automation, they can be used to perform CI/CD. Network reconnaissance playbooks are completely harmless to execute automatically and run every time a pull request merges code into the master branch. Pull requests trigger automated builds, which in turn trigger Ansible playbooks. This is the CI in the CI/CD pipeline.

Test

Automated testing can be triggered by the automated build. Builds are deployed to test specific lab environments, a Virl environment, or a Jenkins environment. Unlike software that is easily tested in virtual environments, depending on the environment, network testing may not apply to network automation playbooks. Instead, testing could be incorporated directly into an Ansible playbook.

Release

Releasing network configurations is driven by Ansible playbooks as the final step in the CI/CD pipeline. Builds are scheduled or triggered by pull requests. Ansible playbooks are built into the release steps in TFS. While highly exciting, automated releases should be carefully considered and performed with a full understanding of the impact of the change. Disruptive changes may require specially coordinated releases while routine pre-approved changes can be continuously delivered in real-time. Check mode, documentation playbooks, automated testing playbooks, and reviewing commits in the pull request are all validation steps used to ensure the CI/CD pipeline does not have unintended consequences.

There can be great reluctance to move to a full CI/CD pipeline with fully automated changes being made to the production network. After all, if great care is not taken in developing, testing, retesting, and documenting code, a mistake can be automated and- possibly take down the network. However, when successfully implemented, automation using a CI/CD pipeline can transform an organization’s entire approach to designing and operating the enterprise network.

This is a revolutionary opportunity!