Continuous Delivery

Continuous delivery is a software development approach where teams update software in short cycles to quickly and frequently release changes to code. Bug fixes, feature releases, and other enhancements are delivered in small modular packages more often, instead of the traditional approach of accumulating changes and releasing large software packages less frequently.

CD fits perfectly with network automation, especially after we’ve achieved complete network configuration management coverage and full idempotency. All future changes and all bug fixes or configuration deficiencies are added quickly and modularly. Most importantly, it is automatic as changes are merged into the master branch.

Think of the new workflow:

1. Refresh local repository through Git pull
2. Commit often
3. When ready, create pull request
4. Manage approvals and changes
5. Review, approve, and merge pull request into the master branch
6. Automated build triggered
7. All network documentation refreshes automatically to reflect a changed or new state
8. Automated testing occurs
9. Build passes testing
10. Automated release triggered
11. Changes delivered to the production environment
12. Working branch closed
13. Analytics, change history, version control, and other metrics are all available for the life cycle of change

At no point is anyone connecting to network devices to use the CLI.

Release

Along with the enterprise software release cycle, there now exists a need to establish a network release cycle. This goes beyond standard approved change windows or quarterly maintenance windows.

Determine the cadence of automated releases, as well as what constitutes changes that are approved for a regular automated release cycle.

Unlike software or applications whose impact is localized to a specific application or piece of software, the impact to automated network changes has a significantly larger blast radius. The closer to the network core (moving from access, and distribution, the WAN, the data center, or the DMZ), the more significant an automated change’s damage can be to the network.

Some pre-approved, non-impactful changes should be bundled into an hourly or daily release.

For example:

• Changing access ports
• Adding common features like new VLANs, port-channels, SVIs, routes, or other functions at the access and distribution layers

Changes that impact the core, or cause a known outage or impact to the performance of the network, should be scheduled as their own special release and be released during an approved change window.

In terms of the NDLC, ideally, we want to release assembled-configure-campus.yml on a daily, hourly, or weekly basis. This should be triggered in the source or version control software after the automated build, documentation, and testing have been performed, passing all quality checks built into the pipeline. The automated release is then updated to reflect the new build and is released to production on the predetermined schedule. Putty starts to collect dust, as the only reason anyone needs to connect to the CLI is to occasionally troubleshoot problems. Otherwise, the enterprise network has been completely automated.

The steps to create an automated release are very similar to creating an automated deployment or automated test. Create the new release definition and add the Ansible playbook, and any other automated tasks, in sequence. Then, configure scheduling.