Pourquoi Jenkins devient le moteur des devops

Des tendances telles que le développement agile, les devops et l'intégration continue témoignent du besoin de l'entreprise moderne de créer des logiciels de manière très efficace - et, si nécessaire, de passer à la vitesse supérieure.

Cette dernière manœuvre est la façon dont CloudBees est devenu l'entreprise qu'elle est aujourd'hui. Autrefois fournisseur indépendant et public de Cloud PaaS pour les codeurs Java (très bien noté par Andrew Oliver dans «Quel PaaS flippant dois-je utiliser?»), CloudBees a fortement pivoté il y a 18 mois pour se relancer en tant que principal fournisseur de Jenkins, un open outil source pour gérer le processus de développement logiciel.

Selon le PDG Sasha Labourey, en tant que fournisseur de Java PaaS, CloudBees avait "bien progressé", mais "beaucoup de gros joueurs avec les plus gros chèques" hésitaient à s'engager dans un marché PaaS volatil qui manquait de standardisation. Au même moment, Jenkins décollait comme une fusée - et Labourey voyait une grande opportunité, d'autant plus que CloudBees proposait déjà Jenkins en tant que service et avait déjà embauché Kohsuke Kawaguchi, le créateur de Jenkins. Le plat d'accompagnement Jenkins est devenu le plat principal.

Le mastodonte Jenkins

Qu'est-ce qui se cache derrière la popularité de Jenkins? En termes simples, Jenkins est devenu le standard open source pour gérer le côté développement des devops, de la gestion du code source à la livraison du code à la production. Selon Labourey, «La communauté considère Jenkins comme un moteur d'orchestration et d'automatisation ... Je pense que la raison pour laquelle Jenkins est devenu le moteur de facto est parce qu'il est extrêmement connectable.» Un écosystème de plus de 1100 plug-ins a émergé, permettant aux clients d'ajouter toutes sortes de fonctionnalités et d'intégrer Jenkins à tout, d'Active Directory à GitHub en passant par OpenShift PaaS.

Jenkins est une solution d'intégration continue (CI) et de livraison continue (CD). L'idée de CI est de fusionner le code de développeurs individuels dans un projet plusieurs fois par jour et de tester en continu pour éviter les problèmes en aval. CD va encore plus loin pour s'assurer que tout le code fusionné est toujours prêt pour la production. Jenkins permet aux développeurs d'automatiser ce processus autant que possible - jusqu'au point de déploiement. Labourey donne un exemple:

Supposons qu'une entreprise utilise Chef ou Puppet pour se déployer sur AWS. Jenkins ne remplacera pas cela. Jenkins va appeler Puppet pour le faire - OK, voici les éléments, alors appelons ce script Puppet et voyons comment cela fonctionne. Et le résultat de l'exécution de Puppet importera à Jenkins car il pourrait décider de dérouler le déploiement et de prendre d'autres mesures. Nous l'appelons «le pipeline». C'est vraiment cette série d'étapes. Cela pourrait être cinq étapes ou 50 étapes.

Jenkins sert de moteur de flux de travail pour gérer ce pipeline CI / CD de la source à la livraison, dit Labourey, mais en cours de route, de nombreux outils différents peuvent être appelés à exécuter différentes fonctions.

Docker est l'un de ces outils et Docker, en conjonction avec Jenkins, a un effet profond sur les équipes de développement. Tout le monde sait que Docker rationalise le développement et facilite considérablement le déploiement, mais Labourey observe que cela aide également à garder les développeurs honnêtes: ils ne peuvent plus blâmer une mauvaise configuration de l'environnement de développement lorsqu'une build plante et brûle. Sur une machine physique, l'environnement de développement est progressivement corrompu, provoquant par inadvertance la rupture des builds. Mais lorsque vous codez sur une image Docker vierge, vous n'avez que votre propre code défectueux à blâmer lorsque les versions ne s'exécutent pas.

Ensemble, Jenkins et son écosystème intégré fournissent l'infrastructure logicielle de coordination pour le développement agile et forment plus largement «le cœur de l'initiative devops», déclare Labourey.

Comment y arriver à partir d'ici

Toute cette automatisation et cette efficacité du devops semblent excellentes, mais qu'en est-il des organisations qui se sont à peine concentrées sur le développement agile? Labourey propose des conseils pour patauger en CI / CD:

Je pense que la meilleure façon de faire est de commencer petit. Choisissez un projet. Ne dites pas: "OK, maintenant nous sommes un magasin de livraison continue, tout se passe de cette façon." Commencez par une équipe qui est disposée, qui est peut-être plus flexible que les autres équipes, peut-être des membres plus récents de l'équipe, moins ancrée dans la façon de faire existante. Choisissez un projet facile. N'essayez pas d'utiliser cela pour dire si celui-ci fonctionne, tout fonctionnera. N'essayez pas d'échouer; essayez de réussir. Choisissez une équipe volontaire, choisissez un projet facile, allez-y. Cette équipe sera votre meilleur vendeur car vous pouvez maintenant montrer que cela fonctionne. Ils peuvent parler de la façon dont leur travail s'est amélioré parce que, franchement, l'ancienne méthode est ennuyeuse.

Une partie du processus, note Labourey, consiste à "extraire les connaissances qui se trouvent tranquillement dans le cerveau des gens et les mettre dans le pipeline en tant que logique". Cela ne se fait pas du jour au lendemain. Souvent, les organisations de développement commencent par élaborer l'IC et progressent vers le CD au fil du temps.

Les organisations de développement ont tendance à avoir des exigences très variées et très spécifiques. CloudBees propose donc à la fois une version SaaS générique basée sur un abonnement et exécutée par CloudBees et une version «SaaS privée», que les clients peuvent déployer sur AWS ou Azure (ou localement sur OpenStack) et la personnaliser à leur guise.

Il est difficile de surestimer l'importance d'orchestrer, d'automatiser et de rationaliser le processus de développement. CI / CD est au cœur des devops, et une implémentation réussie de devops a à son tour des implications qui vont au-delà de l'informatique pour les entreprises elles-mêmes. L'amélioration continue des logiciels améliore continuellement les produits et services. Tesla, par exemple, a connu un sérieux revers avec l'un de ses modèles prenant feu - et le déploiement d'une mise à niveau logicielle a résolu le problème du jour au lendemain.

«C'est intéressant si vous obtenez 10% d'efficacité en plus; si vous dépensez 100 millions de dollars par an en informatique, c'est parfait - vous avez 10 millions de dollars que vous pouvez dépenser ailleurs», déclare M. Labourey. "Mais le véritable avantage est lorsque l'entreprise se rend compte qu'en tirant parti de ces outils et de cette façon de faire les choses, elle peut augmenter ses ventes de 10%."