Construire un pipeline CI/CD robuste avec GitLab : guide pratique

Introduction

Un pipeline CI/CD bien conçu est la colonne vertébrale d’une organisation DevOps mature. GitLab CI/CD offre une solution intégrée, puissante et flexible pour automatiser votre chaîne de livraison logicielle, du commit initial au déploiement en production.

Dans cet article, nous allons construire ensemble un pipeline complet qui couvre les étapes essentielles : lint, tests, build Docker, push vers le registre et déploiement automatique.

Pourquoi GitLab CI/CD ?

GitLab se distingue de ses concurrents par plusieurs atouts majeurs :

Intégration native : pas de plugin supplémentaire à installer, le CI/CD est inclus dans la plateforme
.gitlab-ci.yml versionnée : votre pipeline est du code, versionné comme le reste
Registre Docker intégré : images Docker hébergées directement sur votre instance GitLab
Environnements et déploiements traçés : visibilité complète sur ce qui est déployé et où

Structure d’un pipeline efficace

Un pipeline CI/CD mature suit généralement quatre étapes principales :

1. Étape de vérification (lint & scan)

lint:
  stage: verify
  image: node:22-alpine
  script:
    - npm ci
    - npm run lint
    - npm run type-check
  rules:
    - if: $CI_PIPELINE_SOURCE == "merge_request_event"
    - if: $CI_COMMIT_BRANCH == "develop"

Cette étape intercepte les problèmes de qualité au plus tôt, avant même de lancer les tests.

2. Tests automatisés

test:unit:
  stage: test
  script:
    - npm ci
    - npm run test:coverage
  coverage: '/Lines\s*:\s*(\d+\.?\d*)%/'
  artifacts:
    reports:
      coverage_report:
        coverage_format: cobertura
        path: coverage/cobertura-coverage.xml

L’export du rapport de couverture permet à GitLab d’afficher le pourcentage directement dans la MR.

3. Build et publication de l’image Docker

docker:build:
  stage: build
  image: docker:24
  services:
    - docker:24-dind
  before_script:
    - docker login -u $CI_REGISTRY_USER -p $CI_REGISTRY_PASSWORD $CI_REGISTRY
  script:
    - docker build -t $CI_REGISTRY_IMAGE:$CI_COMMIT_SHORT_SHA .
    - docker push $CI_REGISTRY_IMAGE:$CI_COMMIT_SHORT_SHA

L’utilisation de $CI_COMMIT_SHORT_SHA comme tag d’image garantit une traçabilité parfaite entre le commit et l’image déployée.

4. Déploiement avec rollback possible

deploy:staging:
  stage: deploy
  script:
    - ssh $DEPLOY_USER@$DEPLOY_HOST "docker pull $CI_REGISTRY_IMAGE:$CI_COMMIT_SHORT_SHA && ..."
  environment:
    name: staging
    url: https://staging.monapp.fr
  rules:
    - if: $CI_COMMIT_BRANCH == "develop"

Bonnes pratiques

Utilisez les règles (rules:) plutôt que only/except : la syntaxe rules: est plus expressive et évite les surprises sur les pipelines de MR.

Protégez vos variables sensibles : dans Settings → CI/CD → Variables, marquez les secrets comme “protected” et “masked” pour éviter leur exposition dans les logs.

Cachez les dépendances : pour Node.js, activez le cache des node_modules avec une clé sur le lockfile pour éviter de reinstaller à chaque pipeline.

Pensez aux notifications : configurez les webhooks Slack ou Teams pour être alerté en cas d’échec en production.

Conclusion

Un pipeline CI/CD GitLab bien structuré réduit drastiquement le time-to-production tout en maintenant un haut niveau de qualité. La clé est d’itérer progressivement : commencez par automatiser les tests, puis le build Docker, enfin le déploiement.

Chez aCloud.Digital, nous accompagnons les équipes dans la mise en place et l’optimisation de leurs pipelines CI/CD. Contactez-nous pour un audit de votre chaîne de livraison.