Définition, tenants et aboutissants du Continuous Delivery

Les utilisateurs attendent plus de livraisons et de fonctionnalités que le mode de développement en cascade ne peut pas offrir. Pour reprendre Bob Dylan, « les temps, ils ont changé ».

French - Ron Gidron
Ron Gidron, July 13, 2017 11:45 am
Blog > DevOps | Continuous Delivery | Agile > Définition, tenants et aboutissants du Continuous Delivery

A l’ère numérique, la vitesse a la priorité absolue et personne ne veut rester à la traîne. Etre longue à la détente est le premier, sinon le dernier clou qui scelle le cercueil, pour une entreprise du 21eme siècle. La rigidité de l’approche de développement traditionnelle, en « cascade » a été détrônée par la philosophie « agile ». Et avec l’agilité, les choses ont changé, car elle est parvenue à matérialiser le concept de livraison continue (Continuous Delivery)

Evoluez avec votre temps ou restez à la traîne

Commençons par une définition du Continuous Delivery. Pour dire les choses simplement, il s’agit de la capacité à mettre en œuvre tout type de changement, que ce soit une nouvelle fonctionnalité, des mises à jour de code, des correctifs, dans des environnements de production, rapidement et de manière sécurisée. Mais pas seulement. Toute livraison doit être stable et durable. La livraison continue élimine les processus chronophages et les interruptions de service, en éliminant le besoin de silos dédiés d’intégration et de test. On y parvient en concevant du code qui est toujours prêt à être déployé. En théorie, le Continuous Delivery permet de livrer un code stable en production à tout moment –une approche indispensable aux besoins des utilisateurs finaux, mais impossible à réussir par le biais d’un développement en cascade.

Ceux qui ont adopté le Continuous Delivery en récoltent déjà les fruits. Ils constatent à quel point le CD améliore le délai de commercialisation : en effet, les changements pouvant être publiés quasi instantanément, une planification rigide de livraison n’est plus de mise. La réactivité est bien plus rapide, que ce soit pour éliminer les anomalies ou pour livrer des fonctionnalités. Les clients sont plus satisfaits que jamais, ce qui est le but ultime de toute entreprise.

L’étape de livraison, notamment, a toujours été capitale, nous en sommes fiers, et à juste titre. Eliminer ces anomalies, livrer des fonctionnalités tant attendues n’est pas chose aisée et requiert un investissement énorme de la part de tous les participants.

Rien de pire que d’effectuer une livraison, pour s’apercevoir qu’il y a de nouveaux bugs, ou que le logiciel tombe en panne. Le Continuous Delivery permet (en théorie), de livrer constamment, mais pas forcément aux clients. Pousser votre code, stabilisé, vers les environnements UAT de test ou de simulation réduit le risque de la livraison en production. Désormais, vous ne déployez plus une fois tous les x mois, vous pouvez le faire quotidiennement.

Il y a souvent des obstacles, de l’inefficacité et des coûts cachés dans le cycle de livraison, qui passent traditionnellement inaperçus jusqu’au lancement. Le Continuous Delivery met en lumière ces anomalies, de façon à conférer au management et aux métiers la visibilité nécessaire à la prise de décision. Les processus deviennent beaucoup plus transparents : on sait où et quand l’intervention manuelle, humaine, sera requise, où les goulets d’étranglement apparaîtront, et où l’automatisation peut être implémentée. Le processus incite clairement à planifier dynamiquement la livraison logicielle. Oubliées, les fenêtre de maintenance longues et pénibles, et l’insatisfaction qui en découlait.

La souplesse est l’un des principaux arguments de vente de ce modèle. Bien sûr, il y a un investissement initial en termes d’infrastructure, aussi bien dans des architectures opérationnelles que logicielles, mais une fois mise en place, il ne reste plus qu’à en récolter les bénéfices. Les fonctionnalités et les correctifs sont désormais prêts à être transmis à des individus en particulier, ou à des sous-groupes de clients, afin de valider que la fonctionnalité s’exécute comme prévu. Ou les fonctionnalités peuvent être intégrées au produit, mais désactivées, en attendant une future livraison, déclenchée par une opération marketing, par exemple. Il n’y a pas si longtemps, concevoir une fonctionnalité de la sorte aurait représenté un casse-tête logistique et coûteux. Pas avec le Continuous Delivery,

Les bénéfices sont clairs. Comme je l’ai mentionné, le Continuous Delivery est simple –en théorie. Les difficultés apparaissent lors de l’implémentation.

Les difficultés liées au changement

Le principal défi auquel vous serez confronté en essayant d’implémenter le Continuous Delivery sera sans doute d’ordre organisationnel. Bien que de plus en plus d’entreprises travaillent à l’implémentation d’une culture DevOps, elles ne sont peut-être pas prêtes pour le Continuous Delivery.

Il existe d’innombrables divisions au sein de nombreuses entreprises, avec chacune des produits, fonctionnalités, codes spécifiques. Chaque division aura ses objectifs, et les KPIs doivent être respectés. Si vous essayez de réunir ces factions opposées, cette démarche pourrait bien tourner au cauchemar logistique, anéantissant vos rêves d’agilité.

Voilà le problème. Les grandes entreprises peuvent mettre des mois, sinon des années, à transférer leurs applications complexes vers le Continuous Delivery. Il est indispensable de changer complètement d’état d’esprit pour s’adapter à ce nouveau processus. Les nouveaux comportements et pratiques doivent être apprises, l’architecture devra sans doute être revisitée, ainsi que les processus de développement. Les changements devront être décidés en haut lieu avant d’être appliqués aux équipes, et ce afin de promouvoir une culture de la collaboration.

En toute honnêteté, le concept de Continuous Delivery peut sembler difficile à présenter, et donc à« vendre » aux équipes dirigeantes, pour de nombreuses raisons. D’abord, ils ont leurs propres tâches quotidiennes, qui, en fonction de leur place dans la hiérarchie, peut leur prendre beaucoup de temps. Ensuite, ils ne sont peut-être pas aussi orientés technique de vous, et ne verront peut-être pas les bénéfices de l’implémentation immédiatement. Enfin, ils ont aussi leur propre opinion, priorités et objectifs, pouvant différer des vôtres.

Les obstacles à la mise en œuvre du Continuous Delivery peuvent parfois paraître insurmontables, mais, comme nous l’avons vu, les bénéfices de cette approche sont éloquents. Voilà comment vous deviez la vendre à vos responsables. 

L’automatisation est capitale

Le Continuous Delivery a révolutionné la façon dont nous développons et livrons des logiciels, mais sans l’automatisation, elle ne serait sans douta pas possible du tout. L’automatisation du processus dans son intégralité, de la soumission de code aux déploiements dans les environnements, en passant par la phase de test est critique pour obtenir une authentique livraison continue.

Cette philosophie complète est conçue sur la souplesse, l’agilité ; les changements de code et les livraisons peuvent se produire à tout moment. Sans les processus d’automatisation adéquats, qui éliminent les interventions manuelles à tous les stades, nous reviendrons à la case départ : l’approche en cascade. Reprendre l’intervention manuelle pour chacun de ces processus trahirait complètement l’objectif du Continuous Delivery. Mais, comme le dit Bob Dylan, « les temps, ils ont changé ».

DevOps
Continuous Delivery
Agile
Back to the blog
French - Ron Gidron

Ron Gidron

Ron Gidron est Directeur du Marketing produit Release Automation chez Automic Software. Il a 14 ans d’expérience dans le marketing produit, le management de produit et l’avant-vente à la fois dans des startups et des grandes entreprises. Ron est fasciné par l’intersection des logiciels, des utilisateurs et des tendances du marché.