J’ai eu la chance d’intervenir dans la mise en place de plateformes digitales pour des entreprises dont le cœur de l’activité se faisait en ligne ou qui accordaient une place importante à leur présence en ligne.
De ce fait, les projets sur lesquels j’ai travaillé étaient à gros budgets, avec de nombreux enjeux et défis à relever.
Le déploiement représentait toujours une étape assez critique, qui a elle seule pouvait faire basculer le projet et entrainer un échec s’il n’était pas préparé minutieusement.
Dans un tel contexte, le modèle de déploiement traditionnel des applications n’était pas envisageable. Il n’était pas question de programmer un déploiement à des heures de faible trafic (couramment les weekends à minuit) et rendre inaccessible la plateforme durant les heures de déploiement. Les déploiements devaient se faire de façon transparente pour les utilisateurs finaux, tout en évitant les downtimes.
De plus, avec ce mode de déploiement, en cas d’un imprévu, notamment une contrainte technique liée à l’évolution de l’infrastructure pour répondre aux prérequis de l’application ou un bogue important en production, comment réagir ? Le premier cas peut entrainer un temps de déploiement plus long : ce qui aura pour conséquence de rallonger le temps durant lequel la plateforme est hors ligne. Ce qui peut entrainer un manque à gagner important pour une entreprise.
Le second cas est d’autant plus problématique dans la mesure où l’on ne sait pas le temps que cela prendra pour livrer un correctif. Faut-il garder le site en production le temps qu’un correctif soit livré ? Faut-il faire un rollback vers la version précédente ? Quoi qu’il en soit, le choix à adopter aura un impact sur la visibilité de la plateforme. Le déploiement d’un correctif va entrainer un downtime, tout comme un rollback. Et, le risque est plus important pour un retour à la version précédente, d’autant plus que l’infrastructure devra revenir à son état initial.
Comment adresser ces problèmes dans sa stratégie de déploiement ? La démarche DevOps, qui prône une livraison fréquente des évolutions aux utilisateurs finaux, propose plusieurs moyens pour faire face à de telles situations en production. Je me propose de vous présenter quelques-uns dans ce billet de blog.
Éviter les Downtimes et réduire les risques lors du déploiement avec le Blue Green Deployment
Dans un environnement de développement agile, les évolutions doivent être livrées de façon continue, chaque fois qu’elles ont traversé toutes les étapes de validation mises en place par l’équipe projet (tests unitaires, tests d’intégration, tests d’interface utilisateur, etc.). Au vu de la fréquence des déploiements, les downtimes ne sont pas envisageables lors des déploiements.
Le Blue Green Deployment offre une approche de déploiement et de migration de son application en souplesse en production, tout en évitant que la plateforme ne soit hors ligne.
Concrètement, le Blue Green Deployment repose sur deux environnements de production, qui doivent être à la base identiques. Supposons que notre application est déployée dans l’environnement de production Blue. Nous voulons procéder à un nouveau déploiement. Notre application sera déployée dans un premier temps dans le second environnement de production (Green). Une fois l’application déployée dans cet environnement, nous pouvons simplement router nos utilisateurs vers ce dernier, qui devient désormais notre environnement de production.
Avec cette approche, zero-downtime. Et en cas de bogue on peut simplement switcher vers l’environnement de production précédent. De plus avant, avant d’aller en production avec l’environnement Green, on peut effectuer de nombreux tests (Performance tests, Capacity tests, Stress tests, Load tests) pour évaluer les performances et la réactivité du site Web dans un environnement proche de la production.
Une fois l’environnement Green en production, l’environnement Blue garde la version précédente de la plateforme pour parer à toute éventualité, jusqu’à la livraison d’une nouvelle version. Celle-ci sera déployée dans l’environnement Blue, qui sera ensuite switché en production. Le cycle sera répété à chaque livraison.
Blue-Green Deployment et Exposition progressive
Le Blue-Green Deployment et l’exposition progressive offrent encore plus de souplesse et réduisent de façon drastique le risque de bogue en production.
Le principe de l’exposition progressive est assez simple : la nouvelle version de l’application est rendue disponible à un nombre restreint d’utilisateurs. Plus elle est stable et plus l’on est satisfait de sa réactivité, plus elle est accessible à un nombre important d’utilisateurs, jusqu’à une exposition complète à l’ensemble des utilisateurs.
De façon pratique, une fois que l’application est déployée dans l’environnement Green, un petit nombre d’utilisateurs sont redirigés vers cette dernière, tandis que l’environnement Blue continue à recevoir le gros du trafic. Des indicateurs de télémétrie sont alors utilisés pour évaluer la nouvelle application. Ensuite, un Load Balancer entre en scène pour gérer la répartition des charges entre les deux environnements.
Finalement, on se retrouve en production avec une version assez mature et qui a quasiment déjà fait ses preuves.
La gestion de la base de données dans une approche Blue-Green Deployment.
Il va de soi que les deux environnements vont partager la même base de données en production. Comment gérer les évolutions de la base de données ? Les équipes projet doivent maintenir en tout temps une compatibilité entre les schémas de la base de données pour les deux versions de l’application. Si la nouvelle version introduit un nouveau schéma, le schéma de la base de données doit être refactorisé pour être compatible avec les deux versions.
Le gros bémol de cette approche est la maintenance de deux environnements de production. Et pour une application exigeante en ressources, cela peut être assez onéreux.
Exemple d’implémentation du Blue-Green Deployment : les slots de déploiement d’Azure Web Apps.
J’ai déjà publié sur ce blog un billet sur les slots de déploiement d’Azure Web Apps. Il s’agit d’une implémentation concrète du Blue-Green Deployment. En effet, lorsque vous créez une Web Application sur Azure, vous disposez par défaut d’un slot de production.
Chaque fois que vous déployez votre application, cette dernière est déployée par défaut sur ce slot. Azure Web Apps vous offre cependant la possibilité de créer un autre emplacement de déploiement (staging) dans le même service plan. Une fois une nouvelle version de votre application prête à entrer en production, vous la déployez dans un premier temps sur le slot Staging. Ensuite, à partir du portail Azure, vous pouvez définir le pourcentage d’utilisateurs qui seront redirigés vers cette nouvelle version et effectuer vos tests de performance en production (A/B testing). Une fois cette dernière prête à entrer en utilisation, en un clic, vous effectuez un swap entre les deux versions. La version sur le slot staging devient la version en production et celle qui était en production précédemment passe en staging. En cas d’un bogue important le retour à la version précédente est tout aussi simple.
Un autre point intéressant est le fait que vous pouvez partager le même groupe de ressources (mémoire, processeurs, etc.) entre les slots, ce qui vous permet de mieux contrôler les coûts.
Canary Release
Il est fréquent dans des projets de développements Web, d’adopter une phase de bêta public de l’application. Durant cette phase, la nouvelle plateforme est disponible pour un nombre limité d’utilisateurs, tandis que la version en production continue à servir le plus grand nombre.
L’approche permettant d’adresser le mieux cette problématique est le Canary Releasing.
Le principe du Canary Release est assez similaire au Blue-Green deployment, mais offre aux équipes projet une étape durant laquelle l’application est testée en production par un nombre restreint d’utilisateurs, sans impacter l’expérience utilisateur de la majeure partie des utilisateurs.
Ce mode est à privilégier sur le Blue Green Deployment si vous n’êtes pas certain que la nouvelle version de votre application fonctionnera correctement en production. Cette approche permet de réduire énormément le risque de bogue et de rollback en production.
De façon pratique, l’approche Canary Realse nécessite la disponibilité de plus d’un serveur en production. La nouvelle version d’une application est initialement publiée sur l’un des serveurs en production et un petit nombre d’utilisateurs est dirigé vers cette dernière. Durant cette phase, les feedbacks des utilisateurs peuvent être récupérés, les correctifs publiés pour stabiliser l’application, etc. Une fois l’application assez stable, celle-ci est déployée en production.
Il s’agit de l’approche adéquate pour le A/B testing. Car les tests sont effectués en production par des utilisateurs finaux et l’on est en mesure de recueillir des métriques en situation d’utilisation normale de l’application.
Feature Flags (feature toggle)
Cette approche consiste à marquer les fonctionnalités avec un drapeau dans le code. Ce drapeau permettra de rendre disponible ou non une fonctionnalité. Initialement, les nouvelles fonctionnalités de l’application ont une étiquette « Off ». Au déploiement de l’application, elles ne sont pas accessibles. Bien après le déploiement, ces fonctionnalités peuvent être activées. En cas de bogue important, la fonctionnalité sera simplement désactivée au lieu qu’un rollback complet de l’application soit effectué.
Avec ce modèle, vous êtes en mesure d’activer ou désactiver une fonctionnalité en production sans avoir à toucher au code source.
Il existe sur le marché de nombreux frameworks permettant de mettre en œuvre les Feature Flags.
Dark Launch
Le Dark Launching exploite le feature toggle dans une stratégie d’intégration et de déploiement continus. Concrètement, la nouvelle fonctionnalité lorsqu’elle est encore au stade de préversion est livrée en production avec les autres mises à jour et correctifs de la version en production. Celle-ci est ensuite activée pour un nombre réduit d’utilisateurs. Ceci peut se faire suivant un certain nombre de critères : zone géographique, sexe ou en utilisant un message pour inviter des utilisateurs à tester cette nouvelle fonctionnalité. Les équipes projet seront alors en mesure d’obtenir les retours des utilisateurs sur la fonctionnalité, analyser le comportement de ceux-ci face à cette dernière, évaluer le degré de satisfaction, évaluer l’impact de la fonctionnalité sur les performances du système, etc.
Au fil des déploiements, la fonctionnalité est améliorée en tenant compte du feedback des utilisateurs et des indicateurs de télémétrie, jusqu’à son élargissement à l’ensemble des utilisateurs.
Cette approche est très utilisée par les géants du Web, notamment Facebook, Google et Microsoft.
Conclusion
L’adoption de l’une de ces approches doit se faire en tenant compte des exigences du projet sur lequel vous travaillez. Les équipes projet ne doivent pas prendre à la légère cette étape, car un mauvais cycle de déploiement pourrait avoir de lourdes conséquences.