Continuous Integration/Continuous Delivery (CI/CD)
![](https://pubhub.devnetcloud.com/media/network-automation-delivery-model/docs/img/phases-last4.png#developer.cisco.com)
Introduction
Continuous Integration/Continuous Delivery (CI/CD) is the process of automating the delivery of software into production environments. As the name hints at CI/CD consists of two parts:
Continuous Integration (CI) is a development practice where a system is automatically and continuously built, integrated and tested when code or sourced components change Continuous Delivery (CD) automatically takes the artifacts created in the CI step and performs full staging, acceptance testing and creates a release of the system Continuous deployment can then automatically push the release created in the delivery step to the production environment, usually with a manual trigger.
DevOps is another term that is often mentioned in the same context and is a combination of culture and practices that merges the development and operation of a system into one single context. Having a strong CI/CD process is needed to develop a DevOps mindset, but it is not enough on its own.
Why CI/CD?
An NSO deployment is a continuously evolving project, where the NSO platform is generally part of a larger solution and technology stack including component such as:
- Systems north of NSO, e.g. order manager, ITSM, or customer care system
- Custom function packs running for a specific use case, e.g. L3 VPN, security policy, or service chain
- Network Element Drivers from Cisco
- Core Function Packs from Cisco or other code from third party vendors
- Systems east / west of NSO, with integration points to the function Pack, e.g. inventory systems, IPAM, or resource management
- Physical and virtual network devices, e.g. routers, switches, or firewalls
When trying to integrate these components it is important to have an automated process that enables easy upgrade of any of these components. It is also important to have a division of responsibility, to ensure that components are first tested in isolation and than together as a full system.
It is important to remember that even though each part is tested in isolation, integration and end to end-testing is needed to ensure that the components work together in the desired way. This is especially important when one component is being upgraded, which might change how it interacts with the other components.
NSO Deployments
An NSO Deployment is almost never a project that is developed and released once, it is a continuous cycle of development and improvement where requirements change and new features are added.
Examples of this could be:
- Additions of new Function Packs for new services and uses cases, like L3VPN and SDWAN.
- Improvements of existing Function Pack, for example enhancing a L3VPN service with bandwidth on demand changes.
The processes, tools and skill sets of the team (the Automation group) that owns the NSO deployment need to support this ever changing environment so that quality can be maintained over multiple iterations.
CI/CD Tooling
Starting up CI/CD relies on tool support. The most fundamental are the tools for keeping order:
- A version control system (such as git) for storing your code and being able to trace where it came from and when a change was introduced
- An artifactory for storing artifacts such as binaries and completed packages, to be able to test the exact same code that you run
- An issue tracking system (such as JIRA) for tracking tickets (bugs & features) and how they relate to the code and the releases
Then an automated test and build system like Jenkins is needed. For any change to any of the components of the solution (i.e. Function Pack code, NSO version, NED version, or an external system) it should test and integrate the solution as well as create deployable artifacts.
Maintaining and improving the quality of this system is a task that needs to be planned as part of the development roadmap.
A typical pipeline
CI/CD should run in a pipeline with testing done in distinct phases to find errors as quickly as possible and to isolate problems efficiently. For this reason, every step of the pipeline should be fully automated and reproducible, i.e. every part of the pipeline should be zero touch and tests should provide the same results every time they are run.
Note that when a system is built from components, it is the responsible of whoever produces the component to run their own CI/CD-pipeline for that component, which then feeds into the main deployment pipeline that integrates all the components. This is true regardless of if the components comes from Cisco, from a third party vendor or is created internally by an independent team.
Splitting an automated CI/CD pipeline into different phases has many advantages:
- Time to production is reduced significantly
- Proactively catch bugs during development of Function Pack code (using phases will help locating where a bug is)
- Upgrades of individual components, for example a new NED version, in the technology stack can be verified in minutes rather than weeks)
Best Practices
- The CI/CD pipeline should be the only way to deploy code to production
- The development process and definition of done should include passing the CI/CD and test pipelines
- The CI/CD pipeline and related software should be treated as critical infrastructure for the network automation project
Checklist
- All of your source code is stored in version control
- Automatic builds are triggered on each commit
- Builds are stored in a special artifactory
- There is an automated deployment from build to production
- Someone is responsible for maintenance and improvement of the CI/CD pipeline