CI/CD

What does CI - Continuous Integration mean

CI stands for “Continuous Integration”. This means that introduced code changes immediately lead to a build and automated tests are carried out. In this way, developers quickly receive feedback on whether an error has occurred. CI should therefore help to recognise errors quickly and to be able to react to them.

CI is usually divided into these phases:

  1. Plan
  2. Code
  3. Build
  4. Test

What does CD – Continous Delivery mean

CD means “continuous delivery”. CD describes that new versions of the software can be provided automatically. Classically, the process consists of four steps:

  1. Release
  2. Deploy
  3. Operate
  4. Monitor

What are the elements of a CI/CD pipeline?

The pipeline summarises the individual steps of CI and CD. It consists of jobs (What is to be done?) and stages (Which jobs are to be executed when?).

The basic elements of a CI/CD pipeline are described below. 

Step Action
Plan
Requirements are defined and used to create a product roadmap.
Code
Development starts. A developer changes the code.
Build
An installation package for the application is created.
Test
Automated tests take place. It is ensured that everything works properly.
Release
The build is ready for deployment in the production environment.
Deploy
The (automatic) provision of the software takes place.
Operate
The new version is live. Now it will be ensured that everything runs smoothly.
Monitor
Data is collected to improve the software. After that, the "plan phase" begins again.

CI/CD in practice

While the graphic above shows an “ideal” CI/CD pipeline, in practice “real” CI/CD pipelines often end after automated testing. 

Deployment in production systems in particular is usually not automated. The “plan” step is also usually only rudimentarily integrated, e.g. by automatically creating comments with references to commits in the ticketing system where planning takes place. 

Operations and monitoring are often detached processes that are handled by separate teams. 

Particularly optimistic is the ideal that feedback from operations and monitoring flows back into the “plan” process – which is only very rarely the case (if then for major bugs) and also does not happen automatically. 

The steps “build”, “deploy to internal test systems” and “test” often take place repeatedly in multiple “sub-circles” for different staging systems with different test cases – even before a “release” step that implies public availability.

For many types of tests, deployment (i.e. installation of the software with all dependencies and components in a test or staging environment) is necessary. These “internal” deployment processes are often fully or largely automated, but usually cannot be directly reused for deployment in production.

Subscribe to the Cloudomation newsletter now

Become a Cloudomation Insider. Always receive new news on “Remote Development Environments” and “DevOps” at the end of the month.