Optimiser vos CI gitlab avec les DAG

Lorsque l’on utilise GitLab CI/CD, les pipelines traditionnels fonctionnent de manière séquentielle, chaque étape attendant la fin de la précédente. Cela peut entraîner une perte de temps considérable, surtout pour les projets complexes.C’est là qu’intervient le DAG (Directed Acyclic Graph) : il permet d’exécuter les jobs en parallèle, en fonction de leurs dépendances réelles. Avec l’attribut needs:, on optimise l’ordre d’exécution et on réduit le temps total du pipeline.

Qu’est-ce qu’un DAG dans GitLab CI/CD ?

Définition du Directed Acyclic Graph (DAG)

Un DAG (Directed Acyclic Graph) est une méthode d’organisation des tâches dans un pipeline permettant une exécution optimisée et parallèle. Contrairement à l’approche traditionnelle en stages, où les jobs s’exécutent séquentiellement, un DAG définit des dépendances directes entre les jobs, réduisant ainsi le temps d’exécution.

Dans un DAG :

• Les jobs sont exécutés dès que leurs dépendances sont satisfaites.
• Il n’y a pas de cycle, ce qui signifie qu’un job ne peut pas dépendre de lui-même.
• Les tâches sont organisées en graphe, plutôt qu’en étapes fixes.

Configuration de base d’un pipeline avec DAG

Un pipeline GitLab CI/CD est défini dans un fichier .gitlab-ci.yml, où l’on décrit les jobs, les stages, et les conditions d’exécution. Par défaut, GitLab exécute les jobs stage par stage, dans l’ordre défini.

Exemple de pipeline sans DAG :

stages:
  - build
  - test
  - deploy

build:
  stage: build
  script:
    - echo "Compilation"

test:
  stage: test
  script:
    - echo "Tests"

deploy:
  stage: deploy
  script:
    - echo "Déploiement"

Ici, tous les jobs d’un même stage doivent être terminés avant de passer au suivant, ce qui peut ralentir l’exécution.

• Tous les jobs d’un même stage sont exécutés en parallèle.
• Un stage entier doit être terminé avant de passer au suivant.
• Même si un job ne dépend pas réellement des autres, il doit attendre la fin du stage précédent.

Cela pose problème lorsque certains jobs peuvent s’exécuter indépendamment et plus rapidement que d’autres.

Introduction à l’attribut needs: pour créer un DAG

L’attribut needs: permet de définir directement les dépendances entre les jobs, sans être limité par les stages.

Exemple avec DAG :

build:
  stage: build
  script:
    - echo "Compilation"

lint:
  stage: test
  script:
    - echo "Linting"
  needs: ["build"]

unit_tests:
  stage: test
  script:
    - echo "Tests unitaires"
  needs: ["build"]

functional_tests:
  stage: test
  script:
    - echo "Tests fonctionnels"
  needs: ["build"]

deploy:
  stage: deploy
  script:
    - echo "Déploiement"
  needs: ["unit_tests", "functional_tests"]

Optimisation obtenue :

• lint, unit_tests et functional_tests commencent dès que build est terminé.
• deploy démarre dès que unit_tests et functional_tests sont finis, sans attendre lint.
• Temps global du pipeline réduit, grâce à l’exécution parallèle.

Visualisation du pipeline dans l’interface GitLab

GitLab permet de visualiser les pipelines DAG sous forme de graphe. Pour voir le graphe :

1. Aller dans Builds > Pipelines.
2. Cliquez sur Visualize.

Cela montre les dépendances entre les jobs, et non un simple enchaînement par stages.

Bonnes pratiques et pièges à éviter

Bien structurer son pipeline pour un DAG efficace

Un DAG mal conçu peut ralentir le pipeline au lieu de l’accélérer. Pour tirer parti de l’exécution parallèle, il faut structurer correctement ses dépendances.

Bonnes pratiques :

• Limiter les dépendances : Un job ne doit dépendre que de ce qui est strictement nécessaire.
• Diviser les tâches lourdes : Si un job est trop long, il peut être découpé en plusieurs tâches plus rapides.
• Prioriser les jobs critiques : Les tests unitaires et fonctionnels doivent commencer dès que possible pour ne pas retarder le déploiement.
• Vérifier le graphe du pipeline : L’interface GitLab permet de visualiser l’ordre d’exécution des jobs.

Éviter les boucles accidentelles et dépendances croisées

Un DAG est un graphe acyclique, ce qui signifie qu’un job ne peut pas dépendre de lui-même ou d’un job en aval.

Mauvaise configuration (dépendance circulaire) :

job_a:
  stage: test
  script:
    - echo "Job A"
  needs: ["job_b"]

job_b:
  stage: test
  script:
    - echo "Job B"
  needs: ["job_a"]

Erreur : job_a dépend de job_b, qui dépend lui-même de job_a → Blocage du pipeline.

Solution : Supprimer la dépendance circulaire en revoyant la structure du pipeline.

Conclusion

Les DAG dans GitLab CI/CD permettent d’exécuter les jobs plus rapidement et plus efficacement en parallèle, au lieu de les exécuter de façon séquentielle. Grâce à l’attribut needs:, on peut organiser un pipeline de manière intelligente, en réduisant les dépendances inutiles et en optimisant le temps d’exécution.

Que ce soit pour un déploiement multi-environnement, la gestion de microservices, ou un pipeline CI/CD automatisé, l’utilisation des DAG améliore la fluidité et la rapidité des workflows.

Si tu veux optimiser ton propre pipeline GitLab, commence par analyser tes dépendances actuelles, visualise ton graphe CI/CD et teste une structure plus efficace avec needs:.