Continuous Delivery, Continuous Value for Business – Publié dans IT Expert

Il y a quelques mois, nous vous parlions du Continuous Delivery dans IT Expert. Vous n’aviez pas vu passer l’article ? Pas de panique, le voici : 

Le Continuous Delivery est une stratégie de développement logiciel qui permet aux organisations de livrer des mises à jour fréquentes et incrémentales, au lieu de mettre plusieurs mois à livrer des mises à jour majeures incluant de nombreuses évolutions via des approches « Big Bang ». De petites évolutions sont amenées jusqu’en production plus rapidement, réduisant ainsi drastiquement le délai entre l’idée et la mise à disposition du logiciel aux utilisateurs. Il s’agit d’embrasser les principes de l’Agilité. L’objectif est de mettre en place une exécution fréquente et fiable de tâches répétitives. On pense « automatisation ».

Le Continuous Delivery ne consiste pas seulement à automatiser des tâches unitaires mais à penser produit, de bout en bout :

• Des équipes agiles : pour une production rapide de nouvelles fonctionnalités.
• La prise en compte du mouvement DevOps : la transition d’équipes organisées par technologie vers des équipes intégrées, dédiées à un produit ou une fonctionnalité.
• La qualité à tous les niveaux : code, livraison et système.
• Une automatisation maximale : les interventions manuelles sujettes à erreurs doivent être limitées.

Mais pourquoi engager mon SI vers le Continuous Delivery ? Quels intérêts pour une DSI d’adopter les méthodologies des grands du Web (Facebook, Twitter, Google, etc.) qui déploient plusieurs fois par jour en production ? Comment le mettre en place et avec quels outils ?

Pourquoi mettre en place le Continuous Delivery ?

Les mises en production réalisées quelques fois par an sont toujours des moments extrêmement risqués.

D’une part d’un point de vue business :

• Est-ce que les nouvelles fonctionnalités vont apporter la valeur attendue aux clients ?
• Les fonctionnalités sont-elles toujours d’actualité ?
• Est-ce que la qualité du site ou de l’application (rapidité de chargement, visuel, adaptation aux différentes tailles d’écran) est au rendez-vous ?

D’autre part, d’un point de vue technique :

• Les installations sont longues, complexes et impliquent un grand nombre de personnes.
• Il est difficile d’effectuer des retours en arrière si quelque chose se passe mal ou si des anomalies sont détectées.
• La disponibilité du système informatique n’a pas forcément été anticipée. Ainsi, l’environnement de production n’est pas prêt.

A l’instar de ce qui est réalisé avec l’agilité au sein des équipes de développement, le but du Continuous Delivery est d’apporter des fonctionnalités jusqu’en production le plus fréquemment et rapidement possible.

Les bénéfices du Continuous Delivery sont multiples :

• Des applications de plus grande qualité.
• Des fonctionnalités plus en ligne avec les besoins des clients.
• Une plus grande collaboration entre les équipes et, en particulier entre équipes de Développement et Opérations IT.

Amélioration de la qualité des développements

L’un des piliers du Continuous Delivery est l’automatisation des tests (unitaires, d’intégration, de performances) et du déploiement.

Cette automatisation permet d’améliorer grandement la qualité du logiciel produit. L’automatisation des tests permet de fournir un retour rapide aux développeurs afin de détecter au plus tôt une anomalie et, donc, de la corriger sans avoir à attendre un déploiement dans les environnements de recette ou – pire – de production. Plus une anomalie est détectée tôt, moins elle coûte cher à corriger.

Cette automatisation assure également une plus grande reproductibilité du système. Il est ainsi possible de recréer en quelques minutes et de manière automatique un environnement semblable à la production afin de tester une anomalie, une régression de performances ou une nouvelle fonctionnalité. Il est même possible de lancer plusieurs environnements identiques afin d’explorer différentes pistes en parallèle (A/B testing).

L’utilisation d’une procédure de déploiement automatique commune à tous les environnements (du développement à la production) permet aussi de s’assurer que cette procédure est à jour, maintenue et utilisable. Les problèmes d’infrastructure ne sont ainsi plus rencontrés en phase de pré-production mais dès l’étape de développement, ce qui facilite grandement leur prise en compte rapide par l’équipe projet.

En plus d’améliorer la qualité du livrable par l’automatisation des tests et des déploiements, le Continuous Delivery améliore également la qualité du produit via l’augmentation des cadences des mises en production.

Mettre en production une application quotidiennement implique une diminution du nombre de fonctionnalités par livraison. En cas de problème, le MTTR (« Mean Time To Recover », temps moyen de remise en route) est donc fortement réduit par l’identification rapide de la fonctionnalité défaillante. Il n’est plus nécessaire de passer des heures à chercher ce qui a été modifié par la livraison courante, les suspects se comptant sur les doigts d’une main.

Un développement orienté business

Dans un monde où tout évolue de plus en plus rapidement, il est vital pour une entreprise de répondre au plus vite aux besoins de ses clients. Il en va de même pour un système informatique.

Le Continuous Delivery, en permettant des livraisons très régulières, répond clairement à cette problématique en réduisant le « Time to Market » d’un nouveau service. Il n’est plus nécessaire d’attendre 6 mois pour obtenir une nouvelle fonctionnalité en production mais uniquement quelques semaines : le temps du développement, des tests (automatiques) et du déploiement (automatique) de la fonctionnalité.

Il est ainsi possible de valider rapidement si un nouveau service plaît aux clients et le cas échéant le faire évoluer tout aussi rapidement.

C’est également une des bases du Continuous Delivery : fournir rapidement des retours sur une nouvelle fonctionnalité via un monitoring adapté.

Enfin, pouvoir mettre une évolution en production en quelques heures évite le fameux « effet tunnel » où une fonctionnalité, voire même tout un projet, est obsolète avant même sa mise à disposition aux clients.

Une plus grande coopération des équipes

De par l’unicité nécessaire des procédures d’installation sur les environnements de développement et de production, le « Continuous Delivery » implique naturellement une plus forte collaboration entre les équipes projets et opérationnelles.

La création de synergies entre ces équipes est le but du mouvement « DevOps » et fait partie intégrante du Continuous Delivery. Ainsi les pertes de production dues aux conflits entre la vision des équipes de développement et celle des équipes d’opérations, ne seront qu’un mauvais souvenir.

Cas client – Société Générale CIB

Mise en place d’un pipeline de déploiement continu sur le projet SPark à la SGCIB

Contexte

Au sein de la SGCIB, le projet SPark a l’ambition de devenir l’unique référentiel de la banque pour la gestion complète du cycle de vie des produits structurés.

Le développement a démarré en octobre 2011 en méthodes agiles et l’application est en production depuis juin 2012.

Enjeux business

Être capable de livrer les nouvelles fonctionnalités de l’application au plus tôt, en calquant le rythme de livraison sur celui des sprints (2 semaines).

Solution

Mise en place d’un processus de livraison continue s’appuyant sur Git, Jenkins et XL Deploy (anciennement Deployit).

 

Déploiement pipeline du projet SPark

Points forts de la solution

 

• Livrables standardisés quel que soit l’environnement.
• Tests de non régression / mise en place de Behaviour Driven Development (BDD).
• Transformation en un système à flux tendus (juste-à-temps).
• Les livraisons sont des non-événements (push-button).

Chiffres clés

• Plus de 3000 déploiements en 1 an et demi, tous environnements confondus (développement, test, recette et production).
• 10 déploiements / jour.

La transformation d’un projet vers le Continuous Delivery apporte des gains non négligeables et mesurables. Le fait de pouvoir livrer rapidement et régulièrement des produits de grande qualité est un avantage concurrentiel important. De plus, impliquer les différentes équipes au sein d’un même projet est motivant et créateur de liens.

Comment mettre en place le Continuous Delivery ?

Comme nous l’avons vu, les raisons d’instaurer le Continuous Delivery sont nombreuses. Néanmoins, sa mise en place n’est pas toujours aisée.

Afin de réussir cette transformation, il convient de respecter quatre règles.

 Règle n°1 : Eviter les approches « Big Bang »

Il est évident que les entreprises ne peuvent – et ne doivent – pas essayer d’adopter une stratégie de Continuous Delivery pour toutes leurs divisions d’un seul coup.

Le plus simple consiste à commencer par un projet et construire ensuite sa Value Stream Map ou VSM afin d’identifier les différentes étapes nécessaires à une mise en production et ainsi repérer les premiers points de blocage à améliorer et automatiser. La VSM est un outil provenant du Lean qui consiste à visualiser toutes les étapes de la chaîne de valeur d’un projet, depuis la définition d’un nouveau besoin jusqu’à sa disponibilité auprès des utilisateurs sur l’environnement de production. Une fois réalisée, elle permet de mettre en évidence les tâches à forte valeur ajoutée et d’identifier celles qui sont le plus coûteuses.

 

 

Les tâches à faible valeur et dont le coût est le plus important sont celles auxquelles il convient de porter un maximum d’attention. Qu’il s’agisse de la réalisation des tests, du build de l’application ou de son déploiement, l’amélioration de chacune de ces tâches permettra de fluidifier le processus de livraison. Une automatisation de ces étapes est généralement la solution privilégiée.

Règle n°2 : Mettre en place un pipeline de déploiement

Plusieurs bonnes pratiques sont à suivre lorsque l’on souhaite mettre en place un pipeline de déploiement efficace :

• Construisez votre application une seule fois et faites de la promotion de build d’un environnement à l’autre. Cela implique que votre application puisse être configurée par environnement et que vous livriez en production le même binaire ayant été testé en recette, validation métier, etc.
• Déployez de la même manière sur chacun de vos environnements, que ce soit sur le poste de travail du développeur, sur un environnement de test ou en production.
• Exécutez systématiquement un « smoke test » lors de chaque déploiement de votre application afin de vérifier que celle-ci est bien disponible. Ce « smoke test » doit rester simple (par exemple, vérifier la disponibilité de votre page d’accueil) afin de pouvoir être rapide, systématique et maintenable dans le temps.
• Essayez de déployer sur des environnements similaires à la production. Il est conseillé de maintenir les environnements simples et d’automatiser leur provisionning.
• Chaque changement doit parcourir l’ensemble du pipeline afin que les erreurs soient détectées au plus tôt.
• En cas d’échec sur l’une des étapes, la chaîne doit être interrompue et la priorité de tous doit devenir la correction du problème. Cela est indispensable pour maintenir un processus de déploiement rapide, répétable et sûr.

Règle n°3 : Faire coopérer vos équipes

La coopération des différentes équipes est une condition sine qua none à la réussite du Continuous Delivery. Afin d’améliorer cette culture de la collaboration, cinq actions peuvent être prises :

• Impliquer les Ops dans la constitution du Product Backlog et cela, dès le début du projet.
• Changer la « Definition of Done » des développeurs pour inclure qu’une tâche est terminée lorsque celle-ci est activée en production avec succès.
• Mettre en place des rétrospectives entre les Devs et les Ops suite aux mises en production.
• Accroître la transparence entre les équipes en partageant le monitoring et l’alerting.

Règle n°4 : Mettre en place une stratégie de livraison

Maintenant que votre projet s’appuie sur un pipeline de déploiement continu, vos équipes sont capables de livrer chaque modification de votre application en production. Or, le développement des nouvelles fonctionnalités peut parfois prendre du temps ou être lié à des d’applications tierces dont le cycle de livraison n’est pas calqué sur le vôtre.

Dans ces cas de figure, il est possible de mettre en place un mécanisme appelé « Toggle Feature » qui consiste à activer ou non une fonctionnalité de votre application indépendamment de votre cycle de livraison. Sa mise en place permettra de maintenir une branche unique de développement (Trunk Based Development) et d’intégrer au plus tôt l’ensemble des fonctionnalités de votre application, quelle que soit la durée de leur développement.

Afin de mesurer les apports et les manques d’une nouvelle version de votre application, il est également possible d’instaurer un mécanisme d’A/B testing, dont le principe consiste à faire cohabiter en production plusieurs versions de votre application. Grâce à la mesure des performances et du comportement de vos utilisateurs sur la version la plus récente de votre application, vous serez capable d’évaluer les impacts de ces nouvelles fonctionnalités.

Les bonnes pratiques citées ci-dessus vous aideront à réussir la transformation vers le Continuous Delivery. Un ensemble d’outils adaptés constituera le second point d’attention afin d’appliquer ces principes tout au long du projet, du développement à la production.

Avec quels outils mettre en place le Continuous Delivery ?

La première étape de tout projet est la mise en place des outils de développement tels que :

• Un dépôt de code versionné : Git ou Mercurial feront le travail sans difficulté.
• Un serveur d’intégration continue : Jenkins, de par sa simplicité d’usage et ses nombreux plugins, est très populaire. On peut également citer TeamCity ou Bamboo.
• Un dépôt d’artefacts : si le projet produit des artefacts Java (WAR par exemple) alors un dépôt tel que Nexus ou Archiva est à conseiller. Dans le cas contraire, il faut produire des paquets systèmes adaptés à la distribution (.deb ou .rpm) et les distribuer via les dépôts ad-hoc.

Une fois les livrables produits, il est important de pouvoir les installer sur des environnements provisionnés automatiquement. Cela implique d’avoir une couche de virtualisation permettant de scripter le démarrage de nouvelles ressources automatiquement. On peut citer pour cette partie des outils tels que VMWare Cloud Template ou AWS CloudFormation.

Après le provisionnement de l’environnement, il faut gérer sa configuration. Des outils permettent de réaliser cette étape de manière automatique et reproductible. Ansible, Chef, Puppet ou Salt sont utilisés quotidiennement par les grands acteurs du Web.

Une fois l’environnement configuré, il reste encore à y déployer les livrables (idéalement automatiquement). Si le format choisi pour les livrables est le paquet système (.deb ou .rpm par exemple) alors les outils présentés dans le paragraphe précédent pourront sans aucune difficulté les déployer. Néanmoins, il faudra gérer au sein de ces paquets des opérations telles que les retours arrière en cas de problème et la gestion de configuration par environnement cible. Pour cela, il est possible d’utiliser une solution comme XL Deploy (de XebiaLabs) qui permet de déployer et configurer les différentes versions de vos applications sur vos différents environnements et de gérer toute la traçabilité associée.

Ces outils permettent de simplifier la mise en place du Continuous Delivery en offrant l’ensemble des fonctionnalités nécessaires du développement à la mise en production des livrables en passant par l’automatisation complète de la création de l’infrastructure.

Le Continuous Delivery n’est pas une utopie mais un mode de fonctionnement d’ores et déjà mis en place par certaines organisations IT (grands comptes ou entreprises de taille plus modeste).

Nous insistons sur le fait que la démarche et les concepts présentés dans cet article ne constituent pas une recette miracle et que le changement présente toujours des difficultés. En revanche, les gains constatés sont à la hauteur des espérances : une accélération du time-to-market et des applications de plus grande qualité notamment.

Alors si vous aussi vous souhaitez livrer en une heure au lieu d’un mois n’hésitez plus ! Et rappelez-vous qu’une application n’apporte un bénéfice métier que lorsqu’elle est en production.