ericsson.

com/ci-cd

CI/CD:
continuous software
for continuous change

March 2021
2 Ericsson  |  CI/CD: continuous software for continuous change
CI/CD today
and tomorrow
05 CI/CD with Ericsson We believe continuous integration and
continuous deployment (CI/CD) is the
08 CI/CD in practice cornerstone of true digital transformation.
Our society is on a journey to
10 Towards zero-touch automation digitalization, expanding to virtually all
industries. New use cases such as Massive
and Critical IoT, public safety solutions and
various 5G-enabled services are emerging.
This increases demand for features and
higher performance from communication
networks. Perhaps most importantly,
as digitalization affects more and more
processes around us it requires connections
that are secure and high quality.
With this evolution, innovative
communications service providers (CSPs)
are asking for speed and agility to launch
new features and functionalities in their
networks. A continuous flow of new
capabilities and improvements – especially
with the advent of 5G – is becoming a
necessity for them to stay competitive,
which is where CI/CD comes into
the picture.
In dialogue with CSPs, we see
different automation ambitions and
considerations of how CI/CD will impact
their ways-of-working.
5G’s complexity needs to be handled
by the production system, whether it relies
on purpose-built hardware, is executed
on off-the-shelf hardware in virtualized
deployment scenarios, or is run in a
cloud-native environment. Likely, all
these will coexist.
Figure 1: Benefits of CI/CD in telecom networks
Increased efficiency Reduced risks
• Zero-touch deployment and testing • Latest software release
• Engineering and operations streamline • Remove risks that arise from manual
ways-of-working ways-of-working
• Manage new services and increased traffic • Up-to-date security
more efficiently • Gradual and frequent updates instead of
large upgrade projects
CI/CD and automated life cycle
management (LCM) is particularly
expected for the cloud-native product
portfolio, with 5G being a prime candidate.
But the demand is not limited to 5G
products. The same requirements exist for
the cloud-native implementations of the
OSS and BSS portfolio.
The vision for CI/CD in telecom networks
The ultimate goal of CI/CD is to allow for
automated, repeatable, low-risk updates
of all components and layers of the
architecture stack. This includes the cloud
infrastructure, software applications for
network and IT domains like OSS/BSS,
management of network slices for
end-to-end services and exposure of APIs.
To meet CSP requirements, new
releases from suppliers need to be
continuously delivered, integrated,
verified, validated and deployed. This
flow should be fast, and each step
automatically triggered by input from
the previous one. With updated software
made available to CSP repositories,
automation will pull new and
accepted deliveries into the next
environment, facilitating a flow
between test and production, or
central and national operations.
This will be a journey for the industry,
where certain parts still need to be defined
and developed, but one that is necessary
to reap the full benefits of 5G and beyond.
Service agility
• Shorter time to market (TTM)
• Latest capabilities ready for activation
• Ready to address the diversity of
new services
3 Ericsson  |  CI/CD: continuous software for continuous change
Figure 2: The general CI/CD flow for a CSP
Continuous
delivery
Continuous
release
R&D and
service delivery
Software
supply
improvement
The CI/CD pipeline
Figure 2 illustrates the CI/CD flow from a
CSP perspective. Suppliers continuously
release new software releases, which
then must be delivered into the CSP
domain. There, they are integrated into
larger systems, configured in line with
CSP needs and then validated against
set specifications. These activities are
summarized as continuous integration in
lab, test or staging environments.
New software releases are either
rejected for further improvement
or accepted for production at the
continuous deployment phase, where
they may be upgraded in service, canary
tested and then operated. This process
can be executed repetitively across sites.
A key aspect of CI/CD is the collection
of data when monitoring application
execution, which is analyzed through
data analytics and used for both the
software supplier and CSP’s continuous
improvement processes.
Key steps are executed and tested
multiple times in different environments
before deployment in a CSP production
network, providing software quality
assurance and a trusted process.
Multi-vendor aspects
CI/CD flows need to be implemented
for all applications, whether third party
or internally developed. With little
standardization currently, harmonization
Continuous
integration Software testing
and end-to-end testing
Customization,
tuning, integration Service
provider
collection
Feedback
Continuous
is achieved through aligning key
steps in the flow, best practices and
their implementation based on
best-of-breed tooling. Therefore,
either software suppliers need to plug
their automation into a given CI/CD
implementation, or CSPs need to
take strong ownership of all
automation assets.
State of the industry in CI/CD
Current upgrade procedures are, at best,
semi-automated. In telecoms,
CI/CD and cloud-native application design
is, to a large extent, still in its infancy.
Leading CSPs who have progressed in
network functions virtualization (NFV)
transformation and plan to soon introduce
cloud-native 5G core are trialing
CI/CD. They have ambitious goals for
multi-vendor pipelines and run their own
transformation projects. Targets include
bi-weekly software upgrades
and significantly reduced lead times.
On the vendor side, automated delivery
and deployment have been used in
delivery projects for a few years for a large
number of CSPs.
For RAN, continuous software
deployments for physical nodes started as
early as 2015 in some markets like the US,
to replace the legacy release verification.
Today, about 20 CSPs use this process
and the upgrade frequency has gone from
bi-yearly to bi-weekly.
Continuous Phased
deployment release to
production site
and slices
Validation
and monitoring
Data
Continuous
improvement
For the cloud-native CI/CD flow, several
trials are ongoing where software
application LCM is automated in the CSP’s
lab. The current steps performed are:
• automated software download and
integrity checks
• LCM procedure for software update and
installation (including canary testing,
with the possibility to roll back in case
of failures)
• automatic acceptance testing
There are examples of leading CSPs who
have reduced acceptance testing from
four weeks to two hours, allowing for more
frequent, better validation of new software
releases and deployment.
A small number of leading CSPs are
close to a fully interconnected CI/CD
pipeline, from software intake all the way
to production.
How can CSPs get started?
All basic, repetitive, time-consuming
activities that can be automated have to
be automated, as they represent the best
potential for savings. 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.
All these individual automated steps
can then be orchestrated into larger
sections, and finally into a complete CI/CD
flow with less manual intervention.
4 Ericsson  |  CI/CD: continuous software for continuous change
Figure 3: Impact on ways-of-working as more CI/CD automation is added
Use CI/CD and automation
acceptance testing in delivery projects
Phase 1
• Significant transformation of skills
and ways-of-working for vendor
service delivery
• Mapping of test object lists and creation
of new test cases in test tools
• Coexistence of manual and automatic
acceptance testing
CSPs’ needs and approach to CI/CD will
vary depending on network size and
operational and service ambitions.
Innovative CSPs want to transform
their ways-of-working and their
operational procedures to become truly
agile in the marketplace. They want to
continuously get the latest software
releases, even at microservice level.
They are in the process of architecting
and implementing CI/CD pipelines
based on IT best practices to handle
LCM of products from all their suppliers
in a common way.
Conservative CSPs want CI/CD
automation benefits within their existing
operational procedures and architecture,
giving them faster product validation
and quality at a reduced cost. They do
not expect a higher release cadence,
frequent updates or a continuous
software flow.
Whichever road is taken, the journey
to a 5G network, which will require a
virtualized network and cloud-native
technologies, will mandate some type of
viable CI/CD flow. This is a fundamental
change from the physical nodes where
software upgrades could be postponed
for years or indefinitely.
Challenges in implementing CI/CD
Upgrade modularity
To support rapid innovation and
increased features, reuse based on
modular architectures is a prerequisite
as solutions are composed of many
components, each with their own life
cycle. Operating a well-performing
solution depends in many ways on the
ability to validate a new component
release with improved characteristics
quickly and safely in the system context.
Continuous software delivery to
customer lab and and pre-production
Phase 2
• Transformation of skills and
ways-of-working for service provider
• Service provider engineering and
operations working as one
• Streamlined processes and trust in
automation tools
• Approval process to mark software in
catalog as ready for production
Continuity in air gap environment
The CI/CD pipeline assumes a seamless
automated flow, which means that the
vendor environments, pre-production
and production networks must be
interconnected. This is often not the
case due to “air gaps” (that is, physically
isolated networks), so mechanisms
that allow a controlled, secure and
automated pull into the next
environment are required.
Security
A high level of security must be
maintained, and vulnerabilities
mitigated quickly. Instead of waiting
for new system releases and their
validation in the larger context, in the
future individual microservices with
security fixes will be delivered and
need validation, ideally through canary
testing and deployment in the network.
Traditional, manual ways of delivering
and testing software become prohibitive
due to the cost, as well as the risk of
increased errors during manual work.
Cost of extensive regression testing
When the cost and time involved in
updates increases, even small risk-
free updates may be delayed, instead
bundled into a larger release that poses a
quality risk and takes longer to stabilize.
Updates could even be cancelled;
imagine a brilliant, low-cost idea that
could be rolled out the next day – were
it not for the costs of ensuring quality of
the total solution.
Continuous software delivery
to customer production
Phase 3
• Processes for approval and roll-out
in large-scale production network
• Procedures and inbuilt capabilities
are designed to handle failure as a
normal situation
• Defined responsibilities between
service provider, application and
pipeline vendors
Operations and mandatory upgrades
A CSP needs to make large changes
to operational processes, tools and
skills. We have learnt from the NFV
transformations that operational
changes are often challenging and
time-consuming. Several components
will require frequent updates, like
security patches and Kubernetes
releases, so new processes must be
implemented quickly.
Current CI/CD standardization and
open-source projects
CI/CD addresses automation needs
beyond the management capabilities
standardized, for example, in
ETSI NFV, ONAP or ORAN. It looks
beyond a particular architecture at
software LCM from development
to operations.
In open source, a broad ecosystem
of interlinked tools has evolved to solve
current and upcoming automation
needs. Underlying technologies, such
as Kubernetes for cloud native, are
innovating LCM capabilities rapidly.
Inspired by these developments, in the
CSP domain, further standardization
increasingly covers CI/CD principles
and their implementation. Standardized
management functions need to further
evolve to benefit from these advances.
Applying intent-based management
as implemented in Kubernetes,
when managing network functions,
is just one example.
While a broad ecosystem of CI/CD
tooling stimulates innovation, it makes
the reuse of automation assets difficult
across implementations based on
differing tools. Efforts in the Continuous
Delivery Foundation harmonize key
CI/CD aspects across open-source
tooling, to facilitate reuse of these assets
across implementations.
5 Ericsson  |  CI/CD: continuous software for continuous change

CI/CD with Ericsson

We have followed a one-track software design philosophy for over 15 years.

This enables continuous, fast, scalable deployments and stable, low-risk roll-outs
of new functionalities. Our cloud-native portfolio is built on this experience.

Cloud native and CI/CD
inside Ericsson R&D
In the cloud-native paradigm, a
product is composed of microservices
with independent life cycles. In CI/CD
pipelines, microservices are continuously
added and verified into the main product
branch. This means each increment
is small and can easily be verified or
rejected, ensuring quality and robustness
of the main software branch.
As our full portfolio implements a
common set of cloud-native principles,
the LCM will be aligned between our
products. We have a unified model which
includes tools, processes and methods
for cloud-native software design: the
Application Development Platform (ADP).
This specifies the principles for CI/CD,
provides and maintains a range of generic
microservices for consumption in any
product and delivers tools and methods
for designing additional services.
For the portfolio that is not
cloud native, automated LCM and
deployment processes are typically
implemented differently depending on
the product domain as it needs to interact
with existing management elements,
Ericsson or third-party solutions, or
open-source tooling.
The ADP Development Environment
implements the CI/CD toolchain and
product LCM systems that connect the
CI/CD tools to certified archives.
It automates much of the product
information creation and validation,
such as license management and
trade compliance adherence. This
allows us to move towards a true
DevOps model, for such CSPs that
can consume it. Our solution for a
continuous flow, Continuous Delivery
and Deployment (CDD), is fully
prepared for this engagement model.
A cornerstone in the CI/CD
transformation is the inclusion of
automation capabilities in the products
and providing product-specific CI/CD
assets with them. CDD will inject those
assets and orchestrate the automation,
meaning products are “CI/CD-ready”.
Extending CI/CD pipelines
to the CSP environment
To capture the full value of cloud native
and the one-track way of designing
software, pipelines must extend all the
way to the target environment, whether
that is verification or production.
As the vast majority of target
environments are managed by CSPs
(we also run some Ericsson applications
as-a-service) there are air gaps and
discontinuities in the end-to-end
pipeline, which can also be described
as a sequence of pipelines.
While each sequential pipeline has a
different context and life cycle, we apply a
common approach to automation. When
automation is used in a CSP domain, it has
therefore been verified and used in previous
steps. CDD combines our own developments
with industry-standard CI/CD tooling.
When building the CSP CI/CD flow
and automation assets, we utilize our
years of experience from the automation
implemented inside our R&D organizations
for one-track and continuous integration,
extensive automated validation and
continuous release and delivery of
products and systems.

Our portfolio is built on our 15 years of experience using a one-track software design philosophy
6 Ericsson  |  CI/CD: continuous software for continuous change
Meeting unified and diverse
CSP expectations
CSPs that subscribe to continuous
software releases of our products expect
consistent ways-of-working in their
environment. They also expect that
available software is automatically
validated and deployed in lab and
production networks.
CI/CD implementation based on
CDD automatically updates the CSP lab
and production networks as part of our
enhanced Ericsson Software Subscription
and Product Support (SSPS) service.
Our customers benefit from a
solution that is independent of product
domain or underlying technology. CDD
is the foundation for customer CI/CD
pipelines in their staging and production
environments, providing a uniform way
of delivering, preparing, deploying and
validating software.
CSP-specific CI/CD requirements,
for example additional test cases
and integration of test tools, can be
accommodated. Our standard delivery
and deployment flows, as provided by
each product, can be customized to add
functionality or remove individual tasks
from the flow.
For CSPs requiring a higher level of
flexibility and who want to take ownership
of their CI/CD pipelines, we offer Ericsson
We offer a choice of products and solutions to support CSPs on their unique journeys to full automation
Cloud Deployment Engine (ECDE).
It is based on CDD and enriched with
additional capabilities, such as additional
test tool support, and can be further
extended into a multi-vendor
CI/CD implementation.
Ericsson service delivery organizations
are shifting competence from traditional,
manual ways-of-working to using the
CI/CD pipelines and corresponding
automation. Cloud-native software
delivery will bring the proliferation of
CI/CD in service delivery from vendors to
CSPs. Adopting CI/CD-based software
delivery means moving away from distinct,
time-bound, project-based engagements
to a continuous engagement model
between vendors and CSPs. CSPs will
adopt CI/CD in a stepwise manner, where
each stage will result in changes to their
processes and ways-of-working.
We also provide CI/CD-related services
such as Consulting, Managed Services
and Application Development and
Maintenance (ADM) in order to support
CSPs’ plans and transitions towards
CI/CD models.
CDD and its ecosystem
Any continuous delivery and deployment
solution includes not only orchestration
but also other tools and systems. These
are typically health checks, test tools
and LCM systems. We have a portfolio
of products on the market and CDD is
well prepared for integration with that
portfolio. The underlying principle is to
use the existing ecosystem created
around these products.
Once automation is enabled and
delivered, orchestration can still be a
manual process. For the individual node
software changes, the lead time may
not be that different from when it is
orchestrated. However, CDD will provide
the ability to scale and do many things in
parallel, spread over time and location in
a predictable and reliable way. CDD, as
described in Figure 4, is based on three
main principles:
• It is product-agnostic to scale across
the entire portfolio.
• It uses selected de facto industry
standards, for example Spinnaker,
Ansible and YAML.
• It provides integration points for tools
and products used in the specific
target environment.
This allows the solution to be used and
configured for ETSI MANO-compliant
cloud-native network functions (CNFs),
as well as for IT applications that are not
managed according to ETSI standards. Our
OSS and BSS products, which are not CNFs,
fall into the IT applications category.
7 Ericsson  |  CI/CD: continuous software for continuous change
Figure 4: CDD in CI/CD flow
Automated by CDD
Ericsson tool
Industry standards
tool
Continuous
delivery
Continuous
release
R&D and
service
delivery Software
supply
The way to support all known and
not-yet-known products is to provide a
framework into which product-specific
automation is injected. For our products
this is achieved by creating the automation
files as part of the design process and
delivering it with the product itself,
also known as “pipeline-as-code”. The
automation files are then embedded in
CDD in the target environment. Such
automation files can also be created
offline and injected, which creates the
opportunity for our products that have not
yet implemented the automation files, or
for third-party products, to be orchestrated.
Today, cost and lead time in software
change is driven partly by the actual
software update, but even more so by
post-update testing and verification.
These steps are therefore critical in the
orchestration process. CDD initiates
preparatory controls of the software
packages, and a health check of the
system is carried out before orchestrating
software change and testing. The health
check is based on a selection of criteria
that will be specific per product, and
therefore part of the product
specific automation.
Third-party or Ericsson software is
distributed to the CSP either through
an automated upload mechanism or by
automated download after a notification
of it being available. In both cases
software will be available to the CSP,
then pass security checks to ensure
that the software package has
not been compromised. Software
preparation will take care of all
Ansible
Continuous deployment
Spinnaker
Continuous
integration AAT
Software testing
and end-to-end testing
Customization,
Service
tuning, integration
provider
CDA
Feedback
Continuous
improvement
activities required prior to a maiden
installation or software update.
This includes loading automation
configurations and the handling of
configuration data.
In the software upgrade phase the
LCM procedure for maiden installation or
software update is executed. This includes
pre-update health checks, potential traffic
evacuation, the actual software update
and basic post-update health checks.
The actual software change for a
network function (NF) is executed by a
NF Manager; our product is the
Ericsson Orchestrator and the
Embedded VNF Manager (EVNFM).
With the new software release up
and running, testing can take place in
the validation and verification step,
with various test suites being executed
towards the new software release. We
provide the Automated Acceptance Test
(AAT) product for this purpose. This
is a framework for test execution and
can connect to several test services. It
also includes bespoke test services as
provided by products. Which tests are
run is specified in the product-specific
automation but can also be configured
per site.
CDD monitors and logs the execution
and expects a verdict after each step. We
offer a Core Network Operation Manager
(CNOM) with Continuous Data Analytics
(CDA) for monitoring the network. CDA
will deliver verdicts based on thresholds
and policies to the pipeline throughout the
process. If a step fails or if the verdict for
any other reason is negative, the software
EVNFM/EO Phased
release to
production site
and slices
Validation
and monitoring
CNOM
Data
collection
Continuous
improvement
change will be stopped, and the target
product rolled back to the original release.
To close the DevOps loop, data
collection and feedback is fundamental.
It is understood that sharing data
generated in CSP domains is based on
commercial agreements and may differ.
CDD can be configured for more than
one target environment, for more than one
product in each environment and for more
than one instance in each environment.
Designing 5G applications
with automation in mind
The 5G portfolio is implemented based
on five cloud-native design principles:
orchestration and automation,
agnosticity, decomposed software
and LCM, application resiliency and
state-optimized design. This allows
drastically simplified network operations
and provides a more agile platform to
bring new services to market faster.
New NFs can be introduced faster
in the network thanks to cloud-native
technology. Both the provisioning and
integration of new NFs can be carried
out more simply compared to traditional
physical or virtual products.
The possibility to add new
functionality, quickly introduce new
features in a very agile way with
scale-in/out capacity and carry out
in-service software upgrades (ISSU) will
allow the creation and deployment of
new services in hours. Orchestration and
automation of processes based on
cloud-native deployment also enables
radical simplification of LCM.
8 Ericsson  |  CI/CD: continuous software for continuous change
CI/CD in practice
We’re leveraging our network and IT expertise to automate 100 percent of our 5G
offering. Today we have more than 150 CI/CD engagements worldwide, and the
approach varies depending on network size and operational and business ambitions.
Evolution of RAN
continuous deployment (CD)
For RAN, the foundation of the CI/CD
pipeline started in 2012. It focused on
continuous integration and verification,
including continuous upgrade capabilities
and the automation of test cases in all
levels of the development flow. In 2015,
T-Mobile US was the first CSP to run a
CD pilot in phase 1 (see Figure 3) as a
proof of concept, taking regular deliveries
from the pre-commercial main track, and
make release verification in live networks
continuous. One year later, CD replaced
the earlier release verification setup and
seven CSPs, including Swisscom, were
onboarded for a long-term partnership
with Ericsson, as described in phase 3
(Figure 3).
This involved continuously deploying
bi-weekly, pre-commercial software
into their commercial networks in a
continuous loop as visualized in the
general CI/CD flow (Figure 2). As of early
2021, Ericsson RAN collaborates closely
on CD with 18 CSPs.
“We introduced CD into our network
during Q2 2020. It has allowed us
to considerably speed up software
validation by trying the functionality
in advance, reducing the time
substantially from commercial
release to customer roll-out
compared to earlier releases,
even while our staff were
working remotely due to
COVID-19 lockdowns.”
Elio Iacovacci,
Head of Mobile Access
Telecom Italia
Through continuous automatic data
collection from the CD zones, the
feedback loop is closed, enabling insights
and resolution of issues from the software
main track deployed in commercial
networks. Close collaboration with
CD customers taking pre-commercial
deliveries from the RAN software provides
critical feedback about both legacy and
new functionality and is an integral part
of the R&D CI/CD pipeline.
The CD setup serves multiple purposes.
CSPs benefit from early access to new
functionality, giving them a competitive
edge in their markets, and early verification
to manage risks associated with
CSP-specific configurations in small-scale
deployments, minimizing impact on users.
We benefit from early and continuous
feedback on how the latest functionality
behaves in a live environment at limited
scale, a form of canary deployment to
collect feedback and adjust solutions before
releasing to a global audience. The CI/CD
pipeline has also proven to be an enabler
for more frequent commercial releases.
“CD is key for us to win the
network performance benchmarks,
and has given us the confidence to
deploy RAN software nationwide
in just two days. The total effort
associated with network upgrades
is similar to before, but is now spent
earlier and is more evenly spread
in time, enabling more efficient
planning and the possibility to
continuously allocate a small
team instead of organizing major,
infrequent projects.”
Mark Dusener,
Head of Mobile Network
Swisscom
9 Ericsson  |  CI/CD: continuous software for continuous change
CD and Ericsson Network Manager
CD collaboration has been happening for
some years for Ericsson Network Manager.
The concept is as follows:
• New Ericsson Network Manager
software release
• First lab upgrade a couple of days later
• Regression testing over 10 days
• First product upgrade
• Second lab and product upgrades a
couple of days later
• New Ericsson Network Manager
software release (and so on)
CSPs benefit from having Ericsson Network
Manager R&D support throughout the
year and being first to implement new
functionalities. This flexibility is needed in
order to run other CI/CD projects in the RAN
or 5G core domains, as the deployment of
these new node releases often depends
heavily on new peer-functionality in
Ericsson Network Manager.
The benefit for us is early and thorough
software testing in live environments,
Our CSP partners are already reaping the benefits of moving towards automated software pipelines
with a very broad spectrum of features,
deployed node types and also integration
with third-party northbound systems. This
leads to a short and extensive feedback
loop with possibilities for design to collect
logs immediately and test workarounds and
configuration parameters together with the
Ericsson customer unit and the customer.
Core networks
Core networks, and the cloud-native
5G Core in particular, are also domains
collaborating with CSPs to explore the
CI/CD concept. Publicly announced early
adopters of our CI/CD functionality include
BT (UK), China Mobile, Elisa (Finland),
KDDI (Japan) and Softbank (Japan).
China Mobile is working with us on a
cross-vendor CI/CD pipeline to facilitate
the multiple and iterative testing activities
required for cloud deployments. We are
the first vendor to complete successful
integration in the lab with the
China Mobile cloud pipeline. With
successful integration, the Cloud
Execution Environment’s (CEE) next
related release update invokes automatic
deployment and system testing in the
China Mobile customer lab, and provides
feedback to the Ericsson product and
solution owners.
China Mobile has continuously
deployed and tested our solution over
10 times within 2 months, with less
than 7 hours for each cycle. These joint
achievements in CI/CD and automation
are enabling China Mobile to deploy its
cloud network with amazing efficiency
and quality.
CD collaborations over the years
are good proof points to show how
early feedback from CSP environments
improves quality, gives early access
to new functionality and reduces lead
time. For cloud native, the focus is on
leveraging technology advances through
the flow – from design to CSP – by using
the cloud-native CI/CD pipeline and
supporting additional opportunities to
reduce product complexity.
10 Ericsson  |  CI/CD: continuous software for continuous change

Towards zero-touch
automation

The more that CSPs follow cloud-native best practices and

standardized, common ways-of-working, the closer they’ll
move to the end goal of a zero-touch automated pipeline.

Today, CSPs are addressing the
big-ticket items, such as automated
software downloads and integrity
checks using tools such as AAT. CSPs
already see significantly higher efficiency
and agility from these changes, and
the next step is more automation along
the chain. Applying automated LCM
procedures for software update and
installation is the natural next step;
thereafter the more complex tasks
such as automation of configuration
management, network slices and
services will be automated.
We see the real business benefits
when we accelerate software deployment
to the production network, and to do
this we must have confidence in both
the product quality and automation that
will execute the LCM procedure. CSPs
are therefore expanding automation
gradually into the network, starting with
the lab and then reaching further out into
production. Cloud native is an enabler
for trust in deployment of software to the
production network. Correctly designed
cloud-native applications can seamlessly
add a new software release in small
increments and gradually move and
validate traffic.
Significant changes are needed
to reach the end goal of zero-touch
software deployment. CSPs are now in
the process of streamlining approval
processes, defining monitoring and
stand-by procedures for continuous
upgrades and making sure engineering
and operations teams work closely
together. Trusting the automation
tools and making sure that the CI/
CD procedures are applied with inbuilt
capabilities for handling failure will allow
CSPs to gradually remove the manual
check points.
Accelerating LCM
With our product portfolio being
implemented as cloud-native
applications, more opportunities arise
to automate delivery and LCM on a
fine-grained microservice level. We can
start to truly leverage the advances in the
cloud-native space for CI/CD. Additionally,
with advanced automation comes the
opportunity to significantly accelerate
innovation on the application side.
It is part of our vision that every
microservice is independently deployable
on Kubernetes and can be canary tested.
This applies to CSP labs and staging,
production, as-a-service deployment and all
microservices and cloud-native applications
independent of the application domain.
It will equally apply to microservices
deployed into resource-constrained
environments with tight dependencies
on physical resources.

Insights drive LCM on the microservice level towards zero-touch automation

11
Figure 5: CI/CD pipelines interacting with the infrastructure directly
Cloud-native
applications and NF
SO
MANO/OSS
NFVO
VNFM
abstractions
VIM
Kubernetes
Cloud native (in scope)
We share a common view with CSPs whose
CI/CD expectations are increasingly based
on LCM best practices for cloud native,
leveraging readily available low-level
automation in the Kubernetes layer (see
Figure 5). Going forward, CI/CD pipelines
for applications should be implemented
at the lowest level of the management
system, where they interact with the
infrastructure directly and give us a
common approach for LCM of all Ericsson
cloud-native software workloads, both
applications and microservices. This would
automatically be the common foundation
for multi-vendor CI/CD support. When
CI/CD pipelines handle basic LCM
procedures on the microservice level they
become generic and independent of the
application domain and vendor.
The CI/CD pipeline, in combination
with a management system, shall be
able to provide sufficient abstraction
in the management space to allow for
an evolution of both the management
and orchestration concepts and the
functionality provided in the infrastructure
space, independently and transparently.
In short, we allow the CI/CD pipeline
to benefit from the latest and future
developments in Kubernetes. It would
equally fit into an ETSI NFV, ONAP or
CDF context.
Ericsson  |  CI/CD: continuous software for continuous change
OSS/BSS/IoT/MS
CN application
Intent-based
automation
“Stable” Control
and policy
Microservices
CI/CD pipeline
Infrastructure
Here, higher-level management
functions such as the VNF Manager or
NFV Orchestrator can evolve at their own
pace and provide additional value in
their domain.
One example is implementing
intent-based management (as present
in Kubernetes) in the ETSI NFV space
on top of the CI/CD pipeline, providing
additional opportunities to reduce
product complexity.
Automation does not stop at the
application level. Evolving operating
models for Kubernetes and other
cloud-native technologies are
providing a set of best practices that
unify deployment, management and
monitoring for containerized clusters
and applications today. The same
best practices can be applied all the
way up a system stack and to system
configurations, delivery and deployment
of network services and slices.
When we start treating the definition
of a network service as code, we can use a
developer approach. All elements become
software assets that can be release
controlled, individually delivered, updated
and validated. They become managed in
CI/CD pipelines and we move closer to
zero-touch automation of complete
mobile networks.

Ericsson
SE-164 80 Stockholm, Sweden
Telephone +46 10 719 0000
www.ericsson.com
Ericsson enables communications service providers
to capture the full value of connectivity. The company’s
portfolio spans Networks, Digital Services, Managed
Services, and Emerging Business and is designed to
help our customers go digital, increase efficiency and
find new revenue streams. Ericsson’s investments in
innovation have delivered the benefits of telephony
and mobile broadband to billions of people around
the world. The Ericsson stock is listed on Nasdaq
Stockholm and on Nasdaq New York.
www.ericsson.com
The content of this document is subject to 25/287 01- FGB 101 0909
revision without notice due to continued © Ericsson 2021
progress in methodology, design and
manufacturing. Ericsson shall have no
liability for any error or damage of any kind
resulting from the use of this document