[Devoxx FR 2012] – import continuous.delivery.*
La livraison est une étape cruciale dans le cycle de vie d’une application. Tellement cruciale, mais aussi tellement complexe, que les jours de livraison il arrive de se retrouver à croiser les doigts tout en espérant éviter le pire. Lors de Devoxx France 2012 nous avons pu assister à une conférence de Jevgeni Kabanov qui travaille pour ZeroTurnaround (si le nom est familier c’est probablement grâce à leur travail sur JRebel), traitant de cet épineux problème et introduisant le concept de Continuous Delivery.
En informatique la livraison est une source d’angoisse, certes, pourtant c’est une étape que nous maîtrisons parfaitement lorsqu’il s’agît d’effectuer des livraisons dans la vie de tous les jours. Si l’on prend l’exemple de Fedex, le processus de livraison est suivi, et en cas de raté, il est quand même extrêmement rare qu’un colis n’arrive pas à destination. Mais qu’est-ce qui différencie à ce point livraison logicielle et livraison Fedex ?
[/caption]
Si une livraison FedEx vient à échouer la probabilité et l’impact de cet échec sont globalement limités (le livrable est rarement détruit, peu de colis en échec en une seule fois, etc). A l’inverse, si un problème survient avec un logiciel, c’est directement un grand nombre d’utilisateurs qui sont impactés. Les échecs sont bien plus probables et leur impact plus grand dans le monde informatique. En effet, une livraison logicielle met en jeu bien plus de paramètres et de variables : c’est un processus compliqué.
De plus en plus de personnes connaissent les techniques d’intégration continue, qui permettent d’automatiser tout ou partie du processus de test et de déploiement. Pourtant sur les environnements de production le déploiement manuel règne encore en maître. Il est également très difficile de savoir ce qui existe réellement en production à chaque instant. Pourquoi se limiter autant et se priver d’outils permettant d’automatiser l’ensemble du processus ? C’est justement cela que la Continuous Delivery se propose de changer.
Selon Jevgeni tout processus de livraison devrait pouvoir répondre aux questions suivantes :
- D’où vient mon livrable ? Puis-je tracer son origine ?
- Où doit-il aller ? Quelle est la cible de la livraison ?
- Comment est-il déployé ? Avec quelles ressources ?
- Quel est le livrable finalement déployé ? Est-il possible à un instant t d’établir la liste des artéfacts présents et passés sur la plateforme ?
En forçant le trait on pourrait affirmer qu’il y a autant de manières de déployer que de projets existant. Bien évidemment la recette miracle n’existe pas. Pour Jevgeni “la” solution permettant de traiter le problème de la livraison est d’adopter une approche de traitement des problèmes complexes. Néanmoins il reste possible de rationaliser le tout en adoptant le concept de Continuous Delivery.
[/caption]
Vu de très haut la Continuous Delivery s’apparente à un pipeline, ou pour être plus précis, à un système de gestion du workflow, le long duquel vont transiter les artéfacts candidats à la livraison. La gestion de ce pipeline repose sur trois piliers que sont :
- Le service d’orchestration (Orchestration service)
- Le gestionnaire de livraison (Delivery manager)
- L’entrepôt d’artéfacts (Artefact repository)
Le service d’orchestration a pour but d’ordonnancer le pipeline en y disposant les différentes vannes et embranchements que constituent les étapes de construction, de packaging et de test des livrables. Ce rôle revient à des logiciels tels que Jenkins.
Le gestionnaire de livraison est, quant à lui, dédié au seul déploiement des artéfacts arrivés à maturité. Il s’agit ici d’une étape supplémentaire par rapport à l’intégration continue car le gestionnaire de livraison traite la question “Où et comment déployer ? “.
Étant donné que le déploiement peut à présent intervenir sur des environnements avec de vrais utilisateurs de nouvelles problématiques surgissent comme par exemple :
- Le mode de déploiement. Déploie-t-on l’artéfact petit à petit ou bien de manière massive ?
- La transparence du déploiement pour les utilisateurs. Comment être résilient face au déploiement ? Comment arriver à conserver la session de l’utilisateur malgré le déploiement ? Est-on capable de faire du hot-swap des artéfacts ?
- La gestion de l’échec. Comment assurer le retour arrière et le rétablissement du précédent artéfact ?
Enfin, contrairement à l’intégration continue où tout artéfact ayant passé les tests d’acceptance est systématiquement déployé, on doit pouvoir décider de l’artéfact a finalement déployer parmi ceux ayant été désignés comme éligibles au déploiement.
Durant cette présentation le rôle de gestionnaire de livraison était tenu par LiveRebel développé par ZeroTurnaround.
L’entrepôt d’artefacts se voit confier la tâche d’identifier tout artefact déployé dans le présent ou le passé selon son origine, sa date et son environnement de destination.
Pour la partie pratique de cette session, Jevegeni nous a montré comment coopéraient Jenkins et LiveRebel pour une livraison continue en production. Dans sa démonstration, nous avons pu voir une mise en production transparente pour les utilisateurs d’une application de chat. La session n’est pas perdue et l’utilisateur bénéficie instantanément des dernières mises à jour ou… du dernier retour en arrière. LiveRebel permet de gérer les différentes versions mises en production et les changements de version à chaud en redirigeant les requêtes d’un serveur à l’autre pendant le switch. Enfin, il donne également une indication de la compatibilité entre les versions que l’on souhaite échanger. Ceci n’est évidemment pas une liste de fonctionnalités exhaustives de LiveRebel, et nous vous invitons à visiter leur site pour vous faire une idée :-).
Au final l’important à retenir de cette présentation est qu’avec un peu d’efforts et les outils appropriés il est tout à fait possible d’automatiser le processus de livraison et donc de le fiabiliser.
Liens :