DevOps and Telco Softwarisation - Part 3: A CI/CD setup for a 5G Telco project

In this series of articles, we will explore the convergence happening between the IT and Telecom industries, which is referred to as “Telco Softwarisation”.

Future networks go beyond 5G

• higher speed in data transmissions lower latency  —  therefore greater capacity of remote process execution
• greater number of connected devices 
• the benefit of implementing virtual networks i.e. virtual slicing, providing more adjusted connectivity according to the needs

Software art is a work of art where the creation of software, or concepts from software, play an important role; for example software applications which were created by artists and which were intended as artworks. As an artistic discipline software art has attained growing attention since the late 1990s. 

Onboarding Softwarised Concepts

• Microservices or a microservices architecture is an architectural style that structures an application as collection of services with the following characteristics: highly maintainable and testable, loosely coupled, independently deployable, organised around business capabilities, owned by a small team.
• Disaggregated networks follow the lines of microservices and it is the idea of breaking up a monolithic system for cloud and network service providers while adopting agile, disaggregated, open networking. By unbundling a single network function into separate hardware and software, as well as harnessing software capabilities to install any operating system on open white boxes, operators can achieve new levels of efficiency. The main benefits are flexibility, avoiding vendor lock-in and enabling access to inexpensive products.
• Edge computing is a distributed computing paradigm that brings computation and data storage closer to the location where it is needed, to improve response times and save bandwidth.
• Infrastructure as Code (IaC) helps provisioning and managing computer data centers (infrastructure) using machine readable definition files, rather than physical equipment, such as bare-metal servers, virtual machines and configuration resources. These files can be added in any version control system, such as Git, and therefore they can be managed in the same way as our application code. Terraform and Cloudformation are the biggest names in this topic with the first being the lead player.
• Containerisation is the packaging of software and it’s dependencies in one unit leaving outside the irrelevant functionality and coupling with other software. There is no better place to learn about containers from https://www.docker.com/resources/what-container. By the way, Docker is only one out of a few containerisation technologies, however it has has evolved as the leader and most commonly used in the industry.
• Monitoring across the stack i.e. infrastructure level and application level is a major requirement as entire architectures move from monolithic to microservices. An extensive set of tools are available and can be integrated with the reference system. For example New Relic, Splunk, Datadog, Dynatrace, Pagerduty provide tools to monitor application and infrastructure performance. Additionally development tools such as Kibana, Grafana, Fluentd can integrate with the architecture to help in the development process as well as in production.
• Automation comes in hand with all above technologies and can be found in all stages of the software development process, as well as during monitoring of a software system. It’s also the most important factor of Dev/Ops mindset, which aims to improve team efficiency. I have previously talked about Dev/Ops in the first article of this series.CI/CD in Telco softwarisation projects

• Deployment requirements may vary according to the hardware and software versions requirements in place for the specific area, where the system is utilised.
• Mix of cloud and on-site (bare metal) servers can increase the complexity of the deployments. Distinct configurations for each type of infrastructure is a possible solution.
• The move to Cloud Native applications from legacy on-site systems cannot be done in one step, although this is the obvious goal that will simplify and improve at the same time the efficiency of the system setup and performance(!)
• CI/CD pipeline in a large scale 5G Telco softwarisation project

Gitlab CI/CD Telco pipeline stages and jobs

stages:
  - build
  - analyze
  - unit-test
  - build-docker
  - package
  - deploy
  - e2e-test

build:
  stage: build
  image: 
  script:
    - make build
  artifacts:
    paths:

sca-golint:
  stage: analyze
  image: 
  script:
  - sca golint -set_exit_status 
  
sast-gosec:
  stage: analyze
  image: 
  script:
  - sca gosec 
  variables:

helm-lint:
  stage: analyze
  image:
    name: 
    entrypoint: [""]
  script:
    - helm lint serrvice

unit_test:
  stage: unit-test
  image: 
  script: 
  - make test-cicd

dockerize:
  stage: build-docker
  image: 
  script:

dockerize-e2e:
  stage: build-docker
  image: 
  script:

helm:
  stage: package
  image:
    name:
    entrypoint: [""]
  before_script:
    - /ci-tools/dlhelper dl -t helm
  script:
    - semver print
    - helm template service
    - helm package service --app-version=$(semver docker) --version=$(semver helm)

deploy:
  stage: deploy
  image:
    name: 
    entrypoint: [""]
  before_script:
  script:
    - helm upgrade --install service

e2e-test:
  stage: e2e-test
  image: 
  before_script:
  script:
    - make setup-tools
    - make build
    - make test-e2e
  when: manual

1. Build — builds the application code.
2. Analyze — runs a set of jobs for Helm linting and code security checking.
3. Unit-test — testing the internals of said microservice irrespective of outside dependencies.
4. Build-docker — containerisation of the application.
5. Package — prepares/packages the helm chart and pushes it to Artifactory.
6. Deploy — deployment of the previously created helm chart into the selected environment. In this specific case, the application is deployed in a QA environment, where test team executes automated and manual functional and service tests. It is a manual step because it requires importing dynamic parameters.
7. E2E-test — this is another deployment, but this time to “staging” environment, where all services meet together and the project e2e tests are executed.

Test coverage should follow the 

Test Pyramid

 paradigm

CI/CD pipeline technologies from repository management to deployment in the environmentConclusion