Pour l’analyste de Forrester, Kurt Bittner (photo à droite) durant le CD Summit qui se déroule cette semaine à Londres, le continuous Delivery commence seulement à se faire connaître : » 
En fait, le Continuous delivery ( CD) c’est surtout associé au mot devops qui lui est sur toutes les lèvres, cela veut dire développement et opérations. Il y a de ce côté parfois une confusion. On en parle surtout des techniciens qui sont dans les data centers et qui paramètrent les serveurs et les systèmes de stockage. Ils sont aussi parfois en charge des OS et des applications à distribuer sur les différents serveurs.
Mais pour les ingénieurs-développeurs qui sont eux réellement dans le code des applications, c’est une autre approche, ce sont ceux qui surveillent le développement d’applications et qui veillent, entre autres, à leur portage et leur compatibilité, on parle de Delivery dans la mesure où le logiciel lui même est prêt à l’emploi et prêt à être vendu. Les compétences sont très différentes. Il y a trois ans, c’était encore une curiosité, même si depuis deux décennies, les grandes entreprises suivent les principes ITIL qui sont assez lourds. Mais depuis le succès des « apps », tout le monde veut suivre cette tendance et maintenant, ce sont entre autres les compétences en gestion de projets qui font défaut ».
CloudBees en pointe sur les logiciels Jenkins
Le CD Summit a été pour la firme CloudBees l’occasion de mettre en avant sa nouvelle plate-forme qui rassemble deux versions avancées (mais aussi propriétaires) du logiciel Open source Jenkins. Celui-ci est connu dans ce domaine depuis sa création chez Sun sous le nom Hudson. Il permet de fabriquer pour la partie intégration le « Build » (l’assemblage de l’environnement et du code source), d’assurer certains tests, la vérification du code et du côté livraison, le « stage » et le déploiement des applications. Jenkins est devenu en quelque sorte la norme pour l’automatisation des processus de livraison de logiciels et l’orchestration des pipelines, quels que soient les langages et les plateformes utilisées. 
Pour une direction informatique en charge de la création d’applications, Jenkins permet d’avoir par exemple une vue d’ensemble d’une organisation de développement, de son travail et de ses équipes. Plus d’une douzaine d’intégrateurs présents à Londres proposaient des solutions clés en main en particulier pour la création d’applications pour les mobiles. C’est d’ailleurs les mobiles et le portage des mêmes applications sur différents systèmes d’exploitations qui ont fait décoller ce secteur vers une démarche plus industrielle.
La référence pour le suivi de programmes java
L’outil open source Jenkins est devenu en moins de 10 ans un standard pour l’intégration et la livraison continue de programmes, et serait utilisé réellement dans plus de 100.000 installations actives. Rédigé au départ exclusivement en Java, il offre plus de 1000 plugins pour soutenir la construction, les tests et la livraison de pratiquement tous projets. Certains s’en servent lors de la programmation classique comme d’un outil de gestion de projets mais aussi pour la création de composants modulaires qui existent aussi, comme les logiciels, sous différentes versions plus ou moins évoluées.
Les grands clients cités par la firme CloudBees, la firme qui pousse « l’univers Jenkins », sont Netflix, Symantec, EBay, Mac Afee, Cisco, Nokia, Ericsson. Elles s’en servent tous les jours pour tenir un suivi précis de leurs différents programmes et revenir en cas de bugs sur des codes plus anciens.
L’homme derrière Jenkins
Koshuke Kawaguchi, (photo) le créateur de la plate forme Hudson chez Sun, il y a 15 ans, soulignait l’importance qu’ont pris les outils de suivis d’application. « Chez Amazon web service, il y a par exemple 450 000 serveurs, nous, Jenkins, fonctionnons sur plus de 350 000 serveurs indépendants, cela commence à faire beaucoup ». Jenkins n’est pas bien sûr le seul environnement à proposer des outils de continuous Delivery, mais son existence en mode gratuit a permis à des nombreux développeurs de « se faire la main » sans débourser un centime. Bamboo, Teamcity, Serena software, Xebialabs proposent aussi des combinaisons de vérifications assez poussées autour du produit open source et ce foisonnement de développeurs a facilité sa croissance.
Koshuke Kawaguchi est aussi le directeur technique de CloudBees, celui qui a mené le projet open source à bout de bras pendant plus de 10 ans, ce qui peut laisser croire que Jenkins n’est pas Open source. Kawaguchi reste l’un des principaux contributeurs du projet qui progresse toujours à la faveur d’extensions, de plug-ins. Pour Koshuke Kawaguchi que nous avons pu interroger sur les obstacles que rencontrait CloudBees, nous a répondu simplement et en reprenant les réflexions de l’analyste de Forrester : « Le problème de fond n’est pas tant l’efficacité de certains logiciels, pour suivre et mesurer la qualité d’autres logiciels, le hic, c’est plutôt le nombre de personnes qui connaissent les principes du continuous Delivery. Tous les bons développeurs qui s’engagent dans Jenkins trouvent du travail ». Très modeste et original, il montrait sans complexe au début de la conférence ses travaux personnels, très originaux comme des projets d’algorithme pour optimiser la broderie et le crochet ou de très grandes réalisations en Lego avec ses enfants.
Koshuke Kawaguchi s’affiche comme une sorte d’évangéliste de l’open source. Il est considéré comme le pape du Continuous Delivery et chacune de ses interventions est saluée par des tonnerres d’applaudissement. Un succès, un peu difficile à comprendre, vu de l’extérieur, si l’on ne sait que la plupart des personnes présentes au CD summit doivent leur réussite professionnelle au projet open source Jenkins et donc indirectement à Kawaguchi. « Si on m’avait dit en 2008, à l’époque ou le produit était un peu délaissé à la suite du rachat de Sun par Oracle, qu’il y aurait plus de 500 personnes à chacun de nos séminaires, sept ans après, je ne l’aurais jamais cru.» Jenkins n’est pas le seul repère dans ce domaine, les outils de tests comme Fitneses, HP ALM, Cucumber, Gatling, entre autres, connaissent aussi un certain succès et participent à la gestion et l’évolution de logiciels.
Les conteneurs sont aussi utilisés pour le développement
Pour Harpreet Singh, le vice-président « produits » chez CloudBees : « Dans les entreprises, le continuous Delivery, c’est un problème culturel, penser au cycle de vie des produits au lieu des produits eux-mêmes nécessite un peu de recul et des processus de suivis de contrôle qualité. De notre côté, nous ne cessons d’améliorer nos outils pour les rendre plus simples. Dans notre nouvelle plate-forme CloudBees Jenkins, nous avons « emballé » notre offre pour améliorer le processus de livraison de logiciels. Elle devrait simplifier l’adoption de nouvelles méthodes et technologies telles que Docker, et permettre d’intégrer ses services dans des cloud populaires tels qu’Amazon Web Services.»
Les deux programmes CloudBees Jenkins Enterprise et CloudBees Center Operations Jenkins permettent de suivre les différentes versions du logiciel mais surtout garantissent une parfaite conformité. La version entreprise est sensée éliminer les temps d’arrêt et gérer plus efficacement Jenkins. CloudBees Center Operations Jenkins est comme son nom le laisse penser, le centre des opérations d’intégration continue (CI) et la livraison continue (CD) de logiciels dans une entreprise.
La plate-forme CloudBees Jenkins sera vendue en deux éditions pour permettre une utilisation Jenkins à l’échelle de petites équipes. L’un des arguments du logiciel est de se concentrer sur la productivité du développeur, pour accélérer la livraison des applications.
Après un partenariat avec Pivotal autour du programme cloud Foundry, l’emphase lors du CD summit était donnée par l’adoption de nombreux programmes sur Docker.
Six nouveaux plugins Docker (sur près d’un millier de composants proposés autour de Jenkins) vont permettre le fonctionnement en continu des applications conteneurisées avec Jenkins. Ces nouveaux plugins Docker liées permettront la convergence des conteneurs Docker légers pour des architectures à base de micro services. Sur le stand Pivotal, une firme dans le giron d’EMC et de VMware, le démonstrateur précisait que la notion de conteneur est une expérience qui date des débuts des mainframes et que cela ne remettrait pas encore en cause les hyperviseurs. « IBM, Oracle, faisaient des conteneurs, il y a déjà plus de dix ans. Ce n’est pas une révolution. Nous aussi, on participe à l’établissement de normes autour des conteneurs mais ce ne sont que des packages applicatifs. » Plusieurs développeurs montraient d’ailleurs comment il se servaient de conteneurs, à la manière de boîtes à outils pour accélérer les tests logiciels et ne pas oublier certaines procédures parfois fastidieuses.
puis