Migrating to Kubernetes Part 1 – Introduction

Written by: Pirmin Gersbacher, Can Kattwinkel, Mario Sallat


The great challenge of collaborative working in a software developer team is to enable a high level of developer activity while ensuring a high product quality. In order to achieve this often CI/CD processes are utilized.

Talking about modern development techniques the terms Continuous Integration (CI) and Continuous Delivery (CD) are frequently used. CI/CD provide automation and monitoring throughout an application life-cycle. The integration phase, test phase, deployment and implementation phase are packed together in a CI/CD pipeline.

This blog article is based on the source code of a client/server application that can be found here.


The exemplary single page application is written with Angular and has a NodeJS backend. It is built in a classic 3-tier-architecture, consisting of Client Tier (Client), Logic Tier (Server) and Data Tier (DB).

The plan was to create a CI/CD pipeline for this exemplary application. The project ought to be deployed on Kubernetes and Gitlab CI had to be used as CI tool. To manage Kubernetes the package manager Helm, respectively Helm-Charts, are used.

Tests will be executed automatically including a readyness probe. Multiple internal test environments should be created: an internal test environment identical to the current live state of the application (staging), an internal test environment for the master branch (dev), and an internal test environment for each feature branch (/feature). This is intended to create a special Developer Experience having a separate environment for production, staging and each review branch. This way, each new feature can be viewed individually and it is possible to see which effects each feature has on the application as a whole. New features can be presented to third parties, such as customers, in their own review app.

Continuous Integration

In the concept of Continuous Integration each developer in a team merges their local changes in the main branch as often as possible. The developers should commit their changes at least once a day. A build is created that runs through automated tests. The fast build gives developers a quick feedback. This prevents integration problems which usually occur when developers are waiting to merge changes until the release date.

Continuous Delivery

Continuous Delivery extends Continuous Integration. It ensures that changes in code can be deployed quickly and sustainably. Release-processes are automated and applications can be deployed by pushing a button. In the concept of CD the created application is automatically imported into a development, test and (if wanted) production environment after the CI build. The creation of a CI/CD pipeline can lead to reliable, fast and repeatable deployments.


Recently more and more web application companies are discovering the advantages of working with containers. Using containers can facilitate the development, deployment and orchestration of web applications. But working with containers is also often associated with a huge management effort. Administration tools, such as the open source application Kubernetes, can simplify this process. Kubernetes is a platform-independent orchestration tool. It supports developers during maintenance and scaling of applications organized in containers and their automated execution. A variety of container tools are supported, including Docker.

The System Engineering and Management lecture provided practical insight into these processes and allowed new experiences to be gained. The goal of the semester project was to set up a CI/CD pipeline and to deploy the project on Kubernetes. The scenario was realized with an exemplary single page application.


Part 1 – Introduction

Related Sources

  1. https://de.atlassian.com/continuous-delivery/principles/continuous-integration-vs-delivery-vs-deployment
  2. https://kubernetes.io/