Pour une autre idée de la CI, sur la machine du développeur, avec Dagger

DevoxxFR 2025

Dans l’informatique, il est souvent question de cycles, encore et encore. Client lourd, léger, rendu côté serveur, côté client, etc. Mais s’il y a bien un domaine qui n’a pas trop bougé, c’est celui de la CI, de l’intégration continue. Depuis des années maintenant, on utilise principalement des solutions comme Jenkins ou GitHub Action qui vont exécuter, de manière plus ou moins centralisée, toutes les tâches nécessaires, à distance. Le développeur pousse son code, les serveurs de CI vont exécuter ce qui doit l’être.

Néanmoins, dans une idée d’efficacité et avec la puissance actuelle des machines de développement, ne serait-il pas intéressant de ramener une partie de l’integration continue au plus proche des développeurs, directement sur leurs machines ?

Bien évidemment, cela voudrait aussi dire qu’il faut de nouveaux outils, avec de nouveaux paradigmes.

Explorons ensemble les raisons qui pourraient —ou non— amener à déplacer la CI sur la machine du développeur et comment un outil tel que Dagger (qui plus est avec le nouveau SDK Java) peut aider à cette transition.

Transcript

1. Yves Brissaud DevoxxFR 2025 Pour une autre idée de la CI Sur la machine du développeur avec Dagger
2. 𝕏 🦋 Yves Brissaud @_crev_ @yves.brissaud.name
3. Il fut un temps où… Généralement, on n’avait pas de CI On était trop occupé à migrer sous svn • Tests sur la machine de dev • Pas toujours automatisés • Intégration manuelle • Procédures écrites • …
4. Et un jour… Les CI sont arrivées ! • Hudson (2005) • Jenkins (2011) • Travis CI / Circle CI (2011) • Semaphore (2012) • GitLab CI (2015) • GitHub Actions (2018/2019) • …
5. Et un jour… Git ! • Git (2005) • GitHub (2008) • 2011 > SourceForge / Google Code
6. Et un jour… All IN! • Machine de dev → serveur CI • Tests • Builds • Lint • …
7. Et un jour… All IN! 🚙 🚀 • Machine de dev → serveur CI
8. Aujourd'hui Habitudes / culture Pull request Commits Automated CI ⏳
9. Pourquoi une CI ? On souhaite s’assurer que : • Le code respecte les standards • Les tests passent • Les assets sont buildables • Déployable • …
10. Pourquoi une CI ? On souhaite s’assurer que : ✓La tâche a été lancée ✓La tâche a été un succès ✓Le résultat est stable
11. Centralisation +Assurance - Lenteur / feedback loop
12. Un autre monde est-il possible ? Sans pour autant perdre en assurance Pourrait-on arriver au même résultat, aux mêmes garanties, sans CI centralisée ?
13. 🚙 🚀 • Machine de dev - serveur CI Aujourd’hui… 🚀 🚙
14. Aujourd’hui… Push and 🙏
15. https://x.com/dhh/status/1785016820740788495
16. Contraintes ✓La tâche a été lancée ✓La tâche a été un succès ✓Le résultat est stable ➡ Enregistrement de l’état ➡ Outil local ➡ Conteneurs Sans bash, makefile, etc Sans Yaml
17. Dagger
18. Dagger Open-source runtime for composable workflows
19. Dagger Tous langages Toutes plate-formes
20. Dagger
21. Dagger Observabilité
22. Dagger
23. Dagger Modularité
24. Dagger LLM
25. Dagger Démo
26. Et ma CI ?
27. Oui… mais https://github.com/basecamp/gh-signoff
28. Dagger Démo
29. https://github.com/dagger/dagger Discord Community call 1 jeudi / 2 Dagger Join the community
30. Merci 🙏 𝕏 🦋 @_crev_ @yves.brissaud.name Session Feedback Slides Discord