Introduction à l'intégration continue avec Jenkins

Introduction

Jenkins, je l'ai utilisé pendant plus de 6 ans, chez Epiconcept, Cardiologs, Coopengo et SFR Business Team. C'est l'outil qui m'a fait découvrir l'intégration continue et qui a façonné ma compréhension du DevOps. Aujourd'hui, je recommande plutôt GitHub Actions pour les nouveaux projets, mais Jenkins reste un choix pertinent pour les organisations qui l'utilisent déjà et qui ont investi dans son écosystème. Voici mon retour d'expérience sans filtre, avec les forces réelles et les douleurs que j'ai vécues au quotidien.

Jenkins chez Epiconcept : 4 ans de production pour l'INSERM et les Armées

Chez Epiconcept, Jenkins servait l'INSERM et les Armées pendant mes 4 ans de mission. Le serveur Jenkins tournait sur une VM dédiée Debian avec 30+ jobs configurés, depuis les builds d'applications PHP et Python jusqu'aux déploiements Ansible sur 200+ serveurs. Les pipelines intégraient les tests unitaires et d'intégration avec MariaDB comme service container, le lint PHP, et le packaging des artefacts.

La force de Jenkins dans ce contexte : sa stabilité éprouvée. Le même serveur a tourné pendant 4 ans avec une disponibilité de 99.5%. Les rares indisponibilités étaient dues à des mises à jour de plugins mal planifiées -- j'y reviendrai dans les défis. La configuration via Jenkinsfile (Pipeline as Code) versionnée dans Git assurait la traçabilité de chaque changement de pipeline, un prérequis dans un contexte militaire. L'interface Blue Ocean de Jenkins, bien que parfois capricieuse, offrait une visualisation claire des stages du pipeline pour les développeurs non-ops.

Jenkins sur instances Spot AWS chez Coopengo : -30% sur la facture CI

Chez Coopengo, dans le contexte HDS (Hébergement de Données de Santé) sur AWS, j'ai optimisé l'infrastructure Jenkins pour réduire les coûts tout en maintenant la fiabilité. Le master Jenkins restait sur une instance On-Demand m5.large pour la stabilité (les credentials, la configuration, le job history ne doivent pas disparaître en cas de récupération Spot). Mais les agents de build -- les machines qui exécutent réellement les tests et les builds -- tournaient sur des instances Spot EC2 provisionnées à la demande via le plugin EC2 de Jenkins.

Résultat : une réduction de 30% sur la facture CI mensuelle, sans impact mesurable sur la fiabilité. Les instances Spot étaient configurées avec un fallback On-Demand : quand AWS récupérait une instance Spot (environ 5% du temps), Jenkins relançait automatiquement le job sur un autre agent. Le temps moyen de rebuild était de 2 minutes supplémentaires. Sur un mois avec 500+ builds, le surcoût en temps était négligeable comparé aux économies. Cette architecture a prouvé que Jenkins pouvait être à la fois économique et fiable sur le cloud.

Les défis honnêtes de Jenkins : la maintenance qui pèse

Soyons francs : Jenkins a des faiblesses structurelles que j'ai subies pendant 6 ans. La maintenance du serveur est une charge non négligeable : mises à jour Java (Jenkins tourne sur la JVM), mises à jour de plugins (certains plugins sont maintenus par un seul développeur), gestion des credentials (UI peu intuitive pour la rotation), et nettoyage des workspaces qui s'accumulent sur le disque.

Chez Cardiologs, une mise à jour du plugin Pipeline a cassé 3 pipelines en production un vendredi après-midi. La cause : une incompatibilité entre la nouvelle version du plugin et une syntaxe Groovy que nous utilisions. Diagnostic et correction : 4 heures de stress. La leçon : ne jamais mettre à jour les plugins Jenkins un vendredi, toujours tester sur un environnement de staging d'abord, et épingler les versions de plugins critiques. La configuration "ClickOps" via l'interface web est un anti-pattern majeur : les jobs créés via l'UI ne sont pas versionnés dans Git. J'ai toujours préféré les Jenkinsfile, mais les jobs legacy créés avant mon arrivée étaient souvent en ClickOps.

Jenkins vs GitHub Actions : ma comparaison après 6 ans de chaque

Après avoir utilisé les deux intensivement, voici ma comparaison sans partialité. Jenkins excelle en : personnalisation illimitée via son écosystème de 1800+ plugins, contrôle total sur l'infrastructure (on-premise, air-gapped possible), support de l'existant (migrations progressives), et intégration avec n'importe quel outil via les plugins. GitHub Actions excelle en : zero maintenance serveur (pas de JVM, pas de plugins à mettre à jour, pas de disque à surveiller), intégration native avec GitHub (PR checks, OIDC, environments), démarrage rapide (un fichier YAML suffit), et ecosystem de marketplace.

Pour un nouveau projet hébergé sur GitHub, je recommande GitHub Actions sans hésiter. Le coût total de possession est inférieur. Pour une organisation qui a déjà Jenkins avec 100+ jobs, des plugins custom et un serveur bien rodé, migrer n'est pas toujours pertinent -- le coût de migration peut dépasser les bénéfices à court terme. Chez Epiconcept, on a migré progressivement vers GitHub Actions, job par job, sur 6 mois. Les nouveaux projets partaient directement sur GitHub Actions, les anciens migraient quand ils nécessitaient une modification de pipeline.

L'héritage Jenkins : le standard qu'il a créé

Jenkins a démocratisé la CI/CD. Avant Jenkins (anciennement Hudson), seules les grandes entreprises avec des budgets conséquents pouvaient se permettre des serveurs d'intégration continue (CruiseControl, Bamboo). Jenkins, gratuit et open source, a rendu la CI accessible à tous. Les concepts de Pipeline as Code, de stages visuels, de parallélisation des builds que l'on retrouve dans GitHub Actions, GitLab CI, CircleCI et tous les outils modernes ont tous été popularisés ou perfectionnés par Jenkins.

Mon parcours en est la preuve : j'ai découvert la CI avec Jenkins chez SFR Business Team en 2015, j'ai approfondi le Pipeline as Code chez Epiconcept, j'ai optimisé les coûts avec les agents Spot chez Coopengo, et j'ai finalement migré vers GitHub Actions quand l'écosystème a mûri. Chaque étape m'a appris quelque chose que j'applique encore aujourd'hui. Même si GitHub Actions est plus moderne, l'héritage de Jenkins dans l'écosystème DevOps est indéniable et durable.

Conclusion

Jenkins reste un outil solide pour l'intégration continue, surtout pour les organisations qui l'utilisent déjà. Son écosystème de plugins, sa flexibilité et sa stabilité prouvée en production sur des contextes exigeants (INSERM, Armées, HDS) sont des atouts réels. Mais pour les nouveaux projets, les alternatives modernes (GitHub Actions, GitLab CI) offrent une meilleure expérience avec un coût de maintenance proche de zéro. Le choix dépend de votre contexte -- et après 6 ans sur chaque outil, je peux vous aider à faire le bon.