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:
- Plan
- Code
- Build
- 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:
- Release
- Deploy
- Operate
- 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.
Read more about CI / CD:
