Skip to content
Learni
Voir tous les tutoriels
DevOps

Comment configurer GitLab CI/CD en 2026

12 minBEGINNER
DevOpsCI/CDGitLabYAML
Read in English

Introduction

GitLab CI/CD est un outil puissant intégré à GitLab pour automatiser les pipelines de développement : builds, tests, déploiements. En 2026, avec l'essor des déploiements continus, maîtriser GitLab CI/CD est essentiel pour tout développeur, même débutant. Contrairement à Jenkins qui nécessite une configuration serveur, GitLab CI/CD est gratuit sur GitLab.com, géré et scalable.

Ce tutoriel vous guide pas à pas pour créer un pipeline complet sur un projet Node.js simple. Vous apprendrez les bases du fichier .gitlab-ci.yml, les stages, les jobs parallèles, Docker, artifacts et variables. À la fin, vous aurez un workflow professionnel bookmarqué par les seniors. Imaginez : un push sur main déclenche tests, build et preview auto – zéro intervention manuelle. Prêt à booster votre productivité ? (128 mots)

Prérequis

  • Compte gratuit sur GitLab.com
  • Git installé (version 2.30+)
  • Node.js 20+ pour l'exemple
  • Connaissances de base en YAML et Bash (indentation stricte !)
  • Un nouveau projet vide sur GitLab (créez-le via 'New Project > Create blank project')

Initialiser le projet local Node.js

terminal
mkdir mon-app-ci
cd mon-app-ci
npm init -y
npm install express
mkdir src
cat > src/index.js << 'EOF'
const express = require('express');
const app = express();
app.get('/', (req, res) => res.send('Hello GitLab CI/CD!'));
app.listen(3000, () => console.log('Server on 3000'));
EOF
cat > package.json << 'EOF'
{
  "name": "mon-app-ci",
  "version": "1.0.0",
  "scripts": {
    "start": "node src/index.js",
    "test": "echo 'Tests OK' && exit 0"
  }
}
EOF
git init
git add .
git commit -m 'Initial commit'
git remote add origin https://gitlab.com/VOTRE_USERNAME/mon-app-ci.git
git branch -M main
git push -u origin main

Ce script initialise un projet Node.js minimal avec un serveur Express et un test mock. Il commit et push vers votre repo GitLab (remplacez VOTRE_USERNAME). Une fois poussé, GitLab détecte automatiquement le CI/CD si .gitlab-ci.yml existe plus tard. Piège : vérifiez l'URL remote exacte pour éviter les erreurs 403.

Premier pipeline : job basique

Maintenant, ajoutez votre premier fichier .gitlab-ci.yml à la racine. GitLab exécute les jobs sur des runners partagés (gratuits). Chaque push déclenche le pipeline visible dans 'CI/CD > Pipelines'. Commençons simple : un job qui affiche un message.

Premier .gitlab-ci.yml simple

.gitlab-ci.yml
hello-job:
  stage: build
  script:
    - echo "Hello GitLab CI/CD !"
    - echo "Pipeline déclenché avec succès."

Ce YAML définit un job hello-job dans le stage build (défini implicitement). Le script s'exécute ligne par ligne sur un runner Linux. Copiez-collez, committez et pushez : observez le pipeline vert en 10s. Piège : YAML est sensible à l'indentation (2 espaces, pas de tabs).

Structurer avec des stages

Les stages organisent les jobs en séquence : build → test → deploy. Les jobs d'un stage finissent avant le suivant. Ajoutons un stage test avec npm test. Les jobs parallèles dans un même stage accélèrent tout.

.gitlab-ci.yml avec stages build/test

.gitlab-ci.yml
stages:
  - build
  - test

build-job:
  stage: build
  script:
    - echo "Installation des dépendances"
    - npm install
    - echo "Build OK"

test-job:
  stage: test
  script:
    - echo "Lancement des tests"
    - npm test
  needs: [build-job]

Ici, stages définit l'ordre. test-job dépend de build-job via needs pour parallélisme optionnel. npm install simule un build réel. Le pipeline passe au test seulement si build réussit. Piège : sans needs, jobs parallèles ; omettez npm ci en prod pour vitesse.

Utiliser Docker pour isolation

Les runners GitLab utilisent des images Docker par défaut. Spécifiez image: node:20 pour un env Node reproductible. C'est comme un conteneur jetable : zéro pollution entre jobs. Ajoutons un job lint.

.gitlab-ci.yml avec Docker et lint

.gitlab-ci.yml
image: node:20

stages:
  - build
  - test
  - lint

build-job:
  stage: build
  script:
    - npm install

lint-job:
  stage: lint
  script:
    - npm install -g eslint
    - eslint src/index.js
  needs: [build-job]

test-job:
  stage: test
  script:
    - npm test

L'image globale applique Node 20 à tous les jobs. lint-job installe ESLint dynamiquement (en prod, ajoutez-le à package.json). Jobs parallèles dans stages différents attendent. Piège : volumes montés persistent ; utilisez before_script pour setup commun.

.gitlab-ci.yml avec artifacts et cache

.gitlab-ci.yml
image: node:20

stages:
  - build
  - test

cache:
  paths:
    - node_modules/

variables:
  NPM_CONFIG_CACHE: "$CI_PROJECT_DIR/.npm"

build-job:
  stage: build
  script:
    - npm install
  artifacts:
    paths:
      - node_modules/
    expire_in: 1 hour

test-job:
  stage: test
  script:
    - npm test
  dependencies:
    - build-job

Le cache accélère npm install (réutilise node_modules). artifacts passe les fichiers au job suivant (téléchargeables UI). dependencies lie artifacts. En prod, cela divise les temps par 5. Piège : cache par branche ; expirez artifacts pour économie stockage.

Déploiement automatisé

Ajoutons un stage deploy conditionnel sur main. Utilisez variables GitLab (Settings > CI/CD > Variables) pour secrets comme HEROKU_API_KEY. Règle : ne committez jamais de secrets !

.gitlab-ci.yml complet avec deploy

.gitlab-ci.yml
image: node:20

stages:
  - build
  - test
  - deploy

cache: {}

build-job:
  stage: build
  script: [npm install]
  artifacts:
    paths: [dist/, node_modules/]
    expire_in: 30 mins

test-job:
  stage: test
  script: [npm test]
  dependencies: [build-job]

deploy-job:
  stage: deploy
  script:
    - apt-get update -qq && apt-get install -y -qq heroku
    - heroku login -i --token $HEROKU_TOKEN
    - git push heroku main
  rules:
    - if: $CI_COMMIT_BRANCH == "main"
  environment: production
  dependencies: [build-job]

Stage deploy ne s'exécute que sur main via rules. HEROKU_TOKEN est une variable GitLab masquée. environment tracke déploiements. Adaptez à Vercel/Netlify. Piège : testez rules en merge request ; apt-get pour outils runtime.

Bonnes pratiques

  • Utilisez rules ou workflow: rules pour pipelines conditionnels (branches, tags).
  • Cachez node_modules et .npm : gagnez 80% temps install.
  • Artifacts pour rapports/tests : JUnit XML pour UI GitLab.
  • Variables masquées pour API keys ; protected: true pour branches protégées.
  • Runners custom si besoins GPU/ML : GitLab.com suffit pour débutants.

Erreurs courantes à éviter

  • Indentation YAML : 2 espaces fixes, pas de tabs – cause 'jobs:build invalid'.
  • Oublier image : jobs sur Alpine basique, npm absent → 'command not found'.
  • Secrets en clair : jamais dans repo ; utilisez GitLab Variables.
  • Pas de needs/dependencies : jobs redownloadent tout, lent et gaspille.

Pour aller plus loin

Maîtrisez les GitLab Runners auto-scaling, Helm charts pour Kubernetes, ou intégrations SonarQube. Consultez la doc officielle GitLab CI. Pour une formation experte, découvrez nos formations DevOps Learni. Prochain défi : migrez vers GitLab Premium pour approbations manuelles.