Thank you for Subscribing to Telecom Business Review Weekly Brief
Telecom Business Review | Saturday, December 16, 2023
Infrastructure should include continuous testing from the start, as post-deployment testing could add months.
FREMONT, CA: Continuous integration, delivery/deployment, CI/CD, and continuous testing (CT) are components of the telecom industry's more significant push for full automation. When introducing CT to live networks, it is crucial to establish and design this architecture from the beginning. Service providers will begin this journey at various times, but most will start with low-hanging fruit. Automating all validation and verification tasks is a typical CI/CD entry point. Other quick wins include software download-related jobs and low-level software preparation and deployment tasks. Automated individual processes can coordinate into more significant parts and ultimately into a complete CI/CD flow with reduced manual intervention.
When introducing continuous testing to live networks, it is crucial to build and design for this framework from day one rather than waiting until the end of the life cycle to consider testing. In an always-on, cloud-native environment, always-on testing becomes as vital as a fundamental connection. By default, the infrastructure should include continuous testing capabilities from day one. Attempting to implement testing after the fact could add months to deployment schedules. The transition from deterministic lab environments to unknown production environments, such as 5G, makes the network significantly more dynamic and unpredictable than previous network environments.
Stay ahead of the industry with exclusive feature stories on the top companies, expert insights and the latest news delivered straight to your inbox. Subscribe today.
A network element built may initially serve users and two application types, but it may need to handle people accessing a dozen distinct application types in a year. Testing can no longer be performed if network behavior is no longer deterministic. Instead, certification labs should verify that new pieces are scalable and adaptable enough to expand with the network. A series of triggers for CI/CD in a decentralized telecom network is a source code change occurs; CI/CD initiates the creation of new artifacts.
The process is slightly different in the network and telecom space. In the network and telecom space, [CI/CD] combines DevOps and GitHub because the cycle is triggered by a vendor's injection of new software. In addition to modifying a file in the source code, a new component must be added. The transition to Open RAN, which disaggregates Radio Access Network (RAN) functionality from specialized hardware to vendor-neutral hardware and software-defined technology, will provide operators with new flexibility and innovation.
Adding more manufacturers creates integration issues and necessitates more software changes. A CI/CD system made expressly for Open RAN across many hardware and software manufacturers would solve this problem by enabling RAN software upgrades' rapid and automatic distribution. Using automation and the feedback loop, CI/CD delivers every change made to the RAN program to a joint staging environment – a duplicate of a production environment for software testing. RAN software in the CD environment is always ready to be tested and deployed with a single click.
More in News