#CI/CD#GitLab#Jenkins#Quality

Continuous integration: from GitLab CI to Jenkins

Alexandre Jeffroy

Software Engineer

|24 March 2026|2 min read

Continuous integration (CI) means building and testing the code automatically on every change. In industry, where codebases sometimes live for more than a decade, it becomes a safety net you can no longer do without once you have tasted it.

Why CI changes everything

Without CI, a defect can sit hidden in the code until the next release, exactly where it costs the most to fix. With CI, every change is checked immediately. Within minutes you know whether something broke, and above all you know where to look.

A minimal GitLab CI pipeline

For a C++ project, a .gitlab-ci.yml file of a few lines is enough to set up the build and test stages.

yaml

1stages:
2  - build
3  - test
4
5build:
6  stage: build
7  script:
8    - cmake -B build -DCMAKE_BUILD_TYPE=Release
9    - cmake --build build -j
10
11test:
12  stage: test
13  script:
14    - ctest --test-dir build --output-on-failure

The same spirit with Jenkins

When the environment mandates Jenkins, you find exactly the same logic in a Jenkinsfile.

groovy

1pipeline {
2  agent any
3  stages {
4    stage('Build') {
5      steps {
6        sh 'cmake -B build && cmake --build build -j'
7      }
8    }
9    stage('Test') {
10      steps {
11        sh 'ctest --test-dir build --output-on-failure'
12      }
13    }
14  }
15}

What CI delivers in practice

▸Regressions are caught within minutes rather than during acceptance testing.
▸Releases become reproducible, identical from one time to the next.
▸The whole team dares to evolve the code, because a guardrail is checking behind them.

The principle over the tool

GitLab CI or Jenkins, it hardly matters: the tool counts for less than the principle it serves, that of checking continuously and without human intervention. When I join a project that has no CI yet, it is almost always the first thing I put in place.