Docker a tué Jenkins... mais sera peut être aussi son renouveau.
Ces dernières années, Jenkins 2 était présenté comme le grand refactor technico-fonctionnel de Jenkins.
Jenkins 2 surfait sur les lettres de noblesse de Jenkins (1).
Mais les utilisateurs ont déchanté. Et en 2 ans, la confiance à plus que chuté envers Jenkins 2.
Si bien qu’actuellement, on parle déjà de Jenkins 3 pour enfin tourner la page.
Mais que s’est il passé ?
Jenkins s’est perdu en philosophies et en approches fonctionnelles différentes.
Combien de modèles de jobs pouvez-vous monter ? Réponse : TROP !
Environ 6 types différents et la moitié est dépréciée... mais pas dépréciée par la communauté de devs Jenkins, seulement par les utilisateurs.
Le grand espoir est venu de Docker. Car oui, en parallèle, le coup d’éclat DevOps de ces dernières années est venu de Docker. Et Jenkins n’y a pas échappé.
L’approche Docker + Jobs par DockerFile comble presque tous les défauts de Jenkins 2.
Si bien que la communauté dev de Jenkins s’est concentré dessus. Mais en contrepartie, il ne reste plus grand monde pour toutes ces autres approche dysfonctionnelles ou dépréciées.
Et surtout, il n’y a pas grand monde pour communiquer sur les tendances à venir. La solution reste d’écumer les forum et les ticket Jenkins.
C’était ambitieux de vouloir des interfaces de configuration pour Jenkins 2, et ca a échoué.
L’approche DevOps a eu beaucoup plus de succès.