When bringing CT to live networks, it’s important to build and design for this framework from day one
The move towards continuous integration and continuous delivery/deployment or CI/CD and continuous testing (CT) is part of the telecom industry’s larger push for full automation. According to Ericsson, service providers will all begin this journey at different stages, but most will find “some low hanging fruits to start with.”
“A typical CI/CD entry point is the automation of all validation and verification activities. Additional quick wins include software download-related tasks and selected low-level tasks in software preparation and deployment,” the vendor wrote in a blog post. “All these individual automated steps can then be orchestrated into larger sections, and finally into a complete CI/CD flow with less manual intervention.”
When bringing continuous testing to live networks, it’s important to build and design for this framework from day one, rather than waiting to consider testing towards the end of the life cycle.
“In an always-on cloud-native world, always-on testing becomes as important as basic connectivity,” stated Doug Roberts, general manager of lifecycle service assurance at Spirent Communications. “Continuous testing capabilities should therefore be embedded into the infrastructure, by default, from day one. If they’re not? You might find yourself adding months to deployment timelines trying to implement testing after the fact.”
Roberts further suggested embracing the shift from deterministic lab environments to unknown production environments because with 5G, the network becomes much more dynamic and unpredictable when compared to previous network environments. “A network element deployed today might initially support 3,000 users and two application types, but a year from now, it might need to support 100,000 users accessing a dozen different application types,” he explained. “If network behavior is no longer deterministic, testing can’t be either. Instead, certification labs should focus more on verifying that new elements are scalable and flexible enough to change with the network as it evolves.”
CI/CD in a disaggregated telecom network: A series of triggers
Historically, whenever a change is made to the source code, CI/CD triggers the build of new artifacts. In the case of classic CT, this build then triggers testing, and if the test passes, the build is pushed through to production; if it fails, it’s rejected.
In the network and telecom space, though, explained Tibor Fabry-Asztalos, SVP product develop engineering, Dell Technologies Telecom Systems Business, the process is slightly different: “When it comes to the network and telecom, [CI/CD] is more a combination of DevOps and GitHub [a hosting service for software development] because the cycle is triggered by the injection of new software from a vendor. And It’s not just changing a file in the source code, but actually bringing in a new component.”
The move to Open RAN, which disaggregates Radio Access Network (RAN) functionality from specialized hardware to vendor-neutral hardware and software-defined technology, promises a new level of flexibility and innovation for operators. However, more vendors in the mix means integration challenges, as well as more software upgrades to keep on top of. Looked at another way: Network disaggregation means more software changes, which means more triggers, or as Fabry-Asztalos put it: “triggers, kicked off by other triggers.”
A CI/CD environment that is developed specifically for Open RAN across many hardware and software vendors will address this challenge by ensuring the speedy and automatic delivery of RAN software upgrades. With CI/CD, any and every single change made to the RAN software is delivered to a joint staging environment — a replica of a production environment for software testing — using automation and the feedback loop. This means that at any time, RAN software in the CD environment is ready to be tested and deployed with the push of a button. And this speed, of course, is critical because, as Fabry-Asztalos pointed out, the ability to “absorb” innovation faster is one of the biggest reasons to adopt Open RAN principles in the first place.
