Ce que vous allez retenir
Fini les YAML illisibles : Dagger permet d’écrire vos pipelines CI/CD en Java, plus lisible et maintenable.
Test en local : exécutez votre CI/CD sur votre machine avant de pusher.
Multi-langages & modulaire : Java, Python… chaque dev code dans son langage sans sacrifier la cohérence.
Dites Adieu aux fichiers YAML
J’ai eu la chance d’assister à la conférence de Jean-Christophe Sirot sur "Dagger Modules : un couteau suisse pour moderniser vos pipelines de CI/CD" lors de la Devoxx 2025. Etant développeur et souvent pas très intéressé par la partie OPS car pour moi cela revenait beaucoup à de l’infra, cette conférence m’a permis de voir la CI/CD d’une nouvelle manière !
Les limitations des CI/CD classiques
Jean-Christophe Sirot a présenté les soucis qu’une équipe peut avoir avec les CI/CD intégrées à github ou gitlab : des fichiers yaml qui se rallongent au fur et à mesure que la pipeline grossit, le code yaml qui n’est pas forcément maitrisé par toute l’équipe et la non possibilité d’éxecuter sa CI/CD en local (ça vous arrive aussi à vous de lancer votre build et tous vos tests en local, tout marche mais soudain sur gitlab la pipeline est k.o ?). Dagger est là pour corriger cela !
Si les fichiers YAML ont souvent été présentés comme une solution simple et lisible pour définir les pipelines de CI/CD, la réalité peut s'avérer bien différente. De nombreux développeurs ne se sentent pas forcément à l'aise avec ce langage de sérialisation, et la syntaxe parfois subtile peut engendrer des erreurs difficiles à traquer.
A mesure que le projet grossit, le fichier commence à être de plus en plus volumineux, et vous pourrez vous retrouver à devoir maintenir un gros fichier dont vous ne maitrisez pas le langage à 100%.
Un autre point noir souvent soulevé est l'incapacité à exécuter une CI/CD complète en local. Les développeurs sont généralement contraints de pousser leurs modifications sur un serveur distant pour tester l'intégralité du pipeline, ce qui rallonge les cycles de feedback et complexifie le débogage.
Dagger à la Rescousse : Une CI/CD Nativement Java, Testable et Locale
Jean-Christophe Sirot a présenté Dagger Modules comme une réponse élégante à ces défis. En permettant de définir l'ensemble du pipeline de CI/CD en Java, Dagger offre une série d'avantages concrets :
Dites adieu au YAML Complexe : Les développeurs Java peuvent enfin utiliser un langage qu'ils connaissent et maîtrisent pour définir leurs pipelines, tirant parti du typage fort, de la complétion automatique des IDE et des outils de refactoring.
Maintenance Simplifiée : La modularité inhérente à Java et à la conception de Dagger permet de structurer les pipelines en étapes logiques et réutilisables, facilitant grandement la maintenance et l'évolution. La navigation et la compréhension du flux de travail sont intrinsèquement améliorées grâce à la structure du code Java.
CI/CD Locale Enfin Possible : L'un des avantages les plus séduisants de l'approche Dagger est la possibilité d'exécuter des portions, voire l'intégralité du pipeline, directement sur la machine du développeur. Grâce à la nature déclarative de Dagger et à sa capacité à gérer les dépendances localement, les développeurs peuvent tester et déboguer leurs étapes de CI/CD dans un environnement isolé avant de les pousser, accélérant considérablement le cycle de développement.
Démonstration : Dagger en Action pour un Pipeline Java
Pour illustrer la puissance de Dagger, Jean-Christophe Sirot a probablement présenté une démonstration concrète de la création d'un pipeline de CI/CD en Java, décomposé en différentes étapes :
Build : Un module Dagger en Java pourrait être responsable de la compilation du projet en utilisant Maven ou Gradle. Ce module déclarerait sa dépendance aux fichiers sources et produirait les artefacts compilés.
Test : Un autre module prendrait en entrée les artefacts compilés et exécuterait les tests unitaires et d'intégration (JUnit, TestNG, etc.). Il produirait un rapport de tests.
Création de l'Image Docker : Un module suivant consommerait les artefacts compilés et le Dockerfile pour construire une image Docker de l'application. Il déclarerait sa dépendance à l'outil Docker.
Déploiement : Enfin, un module de déploiement prendrait l'image Docker en entrée et la déploierait sur un environnement cible (local, staging, production) en interagissant avec les outils de déploiement appropriés (Kubernetes, Docker Compose, etc.).
Dans cet exemple, Dagger agirait comme un orchestrateur, s'assurant que chaque module reçoit les dépendances nécessaires (sous forme d'objets Java) et exécute sa tâche dans l'ordre logique. La configuration du pipeline se ferait via les annotations Dagger, définissant les dépendances entre les différentes étapes (modules).
L’autre particularité de dagger qui a été présentée est sa modularité. Si votre équipe est composée de développeurs Java en grande partie, mais qu’une petite partie code est en python, et que ces développeurs doivent mettre à jour la pipeline avec un nouveau module qui prendra en compte leur code, ils pourront le développer en python et mettre en place le module. Pour les développeurs Java, ils pourront récupérer ce module et l’utiliser ensuite s’ils le souhaitent, et ce module sera interprété et exposé comme un module java. Cela permet ainsi à tout le monde de comprendre les différents modules dans son langage de confort !
Conclusion
On résume le tout : Dagger c’est un outil qui vous permet :
d’écrire votre CI/CD dans le langage que vous voulez
d’utiliser des modules qui seront interprétés dans le langage que vous voulez
d’exécuter votre CI/CD en local avant de pusher pour éviter de perdre du temps à attendre que celle-ci plante sur gitlab avant de le corriger !
Alors, vous aussi vous voulez tenter l’aventure Dagger ?