L'intégration continue avec Jenkins : Pourquoi et comment l'adopter
Introduction
Jenkins est l'outil CI que j'ai le plus utilisé au début de ma carrière, notamment chez Coopengo et Cardiologs. Il reste pertinent en 2024, même si GitHub Actions l'a remplacé dans beaucoup de contextes. Voici un retour d'expérience honnête : ses forces, ses faiblesses, et quand le choisir.
Jenkins chez Coopengo : 2 ans de production HDS
Chez Coopengo (CDI, 2 ans), Jenkins était le coeur de la CI/CD pour une infrastructure Kubernetes AWS en contexte HDS. Le choix de Jenkins était historique et justifié par les besoins de personnalisation avancée. J'ai configuré des pipelines Declarative (Jenkinsfile) pour le build des images Docker, l'exécution des tests, et le déploiement sur EKS. L'astuce qui a fait la différence : exécuter les builds sur des instances Spot EC2, avec un mécanisme de fallback sur les instances à la demande. Résultat : -30% sur les coûts CI sans aucun impact sur la fiabilité. Le Jenkinsfile était versionné dans chaque repo, reviewé comme du code.
Migration Helm v2 vers v3 via Jenkins
L'une de mes réalisations chez Coopengo a été la migration des Helm charts de v2 à v3. Cette migration a été orchestrée via les pipelines Jenkins : chaque chart était rebuiltdé, testé, et déployé séquentiellement. Jenkins gérait la complexité de cette migration grâce à ses stages conditionnels. La suppression de Tiller (composant serveur de Helm v2) a amélioré la sécurité du cluster en éliminant un composant avec des privilèges admin. Le pipeline Jenkins validait automatiquement que chaque chart migré se déployait correctement sur un environnement de test avant de passer au suivant.
Jenkins chez Cardiologs : CI sur Azure
Chez Cardiologs (MedTech), Jenkins tournait sur Azure et gérait les pipelines d'une application de diagnostic cardiaque par IA. Le contexte était différent : des builds lourds (modèles ML + application web), des tests d'intégration qui nécessitaient une base PostgreSQL, et des exigences de conformité médicale. Jenkins permettait cette orchestration complexe grâce à ses agents dynamiques et son écosystème de plugins. Les résultats des tests de performance étaient historisés dans Jenkins, permettant de détecter les régressions de performance au fil du temps.
Les limites de Jenkins : quand migrer
Jenkins a des défauts réels. La maintenance est lourde : mises à jour du serveur, des plugins, de Java. L'interface est vieillissante. La configuration XML sous-jacente est fragile. Chez Epiconcept, quand j'ai pris la main sur l'infrastructure, j'ai migré de Jenkins vers GitHub Actions. Le gain en maintenance a été immédiat : plus de serveur Jenkins à patcher, plus de plugins à mettre à jour, plus de backups de configuration à gérer. Pour les nouveaux projets, je recommande GitHub Actions ou GitLab CI. Jenkins reste pertinent pour les organisations qui l'utilisent déjà et qui ont investi dans un écosystème de plugins spécifique.
Monitoring de Jenkins lui-même
Un Jenkins mal surveillé est un point de défaillance unique. Chez Coopengo, j'avais configuré Prometheus pour collecter les métriques Jenkins (queue length, build duration, executor utilization) via le plugin Prometheus. Un dashboard Grafana dédié affichait la santé de Jenkins en temps réel. Quand la queue dépassait 10 builds en attente, une alerte Slack partait. Les backups quotidiens du répertoire Jenkins HOME assuraient une récupération rapide en cas de crash. Cette rigueur a évité plusieurs incidents potentiels sur les 2 ans de mission.
Conclusion
Jenkins est un outil mature et puissant, particulièrement adapté aux environnements complexes avec des besoins de personnalisation avancée. Mes retours d'expérience chez Coopengo et Cardiologs le confirment. Cependant, pour les nouveaux projets, GitHub Actions offre un meilleur rapport simplicité/fonctionnalités. Le choix dépend de votre contexte existant et de vos contraintes.