DevOps : Feature Flags, Canary Release, Blue-Green Deployment,

etc. quelle technique adopter en dploiement continu ?

Un tutoriel de Hinault Romaric
Le 26 janvier 2017, par Hinault Romaric, Responsable .NET

DevOps : Feature Flags, Canary Release, Blue-Green Deployment, etc. quelle technique
adopter pour rpondre aux dfis du dploiement continu ?

Jai eu la chance dintervenir dans la mise en place de plateformes digitales pour des entreprises dont le cur
de lactivit se faisait en ligne ou qui accordaient une place importante leur prsence en ligne.

De ce fait, les projets sur lesquels jai travaill taient gros budgets, avec de nombreux enjeux et dfis
relever.
Le dploiement reprsentait toujours une tape assez critique, qui a elle seule pouvait faire basculer le projet
et entrainer un chec sil ntait pas prpar minutieusement.

Dans un tel contexte, le modle de dploiement traditionnel des applications ntait pas envisageable. Il ntait
pas question de programmer un dploiement des heures de faible trafic (couramment les weekends
minuit) et rendre inaccessible la plateforme durant les heures de dploiement. Les dploiements devaient se
faire de faon transparente pour les utilisateurs finals, tout en vitant les downtimes.

De plus, avec ce mode de dploiement, en cas dun imprvu, notamment une contrainte technique lie
lvolution de linfrastructure pour rpondre aux prrequis de lapplication ou un bogue important en
production, comment ragir ? Le premier cas peut entrainer un temps de dploiement plus long : ce qui aura
pour consquence 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 dautant plus problmatique dans la mesure o lon ne sait pas le temps que cela prendra
pour livrer un correctif. Faut-il garder le site en production le temps quun correctif soit livr ? Faut-il faire un
rollback vers la version prcdente ? Quoi quil en soit, le choix adopter aura un impact sur la visibilit de la
plateforme. Le dploiement dun correctif va entrainer un downtime, tout comme un rollback. Et, le risque est
plus important pour un retour la version prcdente, dautant plus que linfrastructure devra revenir son
tat initial.

Comment adresser ces problmes dans sa stratgie de dploiement ? La dmarche DevOps, qui prne une
livraison frquente des volutions aux utilisateurs finals, propose plusieurs moyens pour faire face de telles
situations en production. Je me propose de vous prsenter quelques-uns dans ce billet de blog.

viter les Downtimes et rduire les risques lors du dploiement avec le Blue Green Deployment

Dans un environnement de dveloppement agile, les volutions doivent tre livres de faon continue, chaque
fois quelles ont travers toutes les tapes de validation mises en place par lquipe projet (tests unitaires,
tests dintgration, tests dinterface utilisateur, etc.). Au vu de la frquence des dploiements, les downtimes
ne sont pas envisageables lors des dploiements.
Le Blue Green Deployment offre une approche de dploiement et de migration de son application en souplesse
en production, tout en vitant que la plateforme ne soit hors ligne.

Concrtement, le Blue Green Deployment repose sur deux environnements de production, qui doivent tre la
base identiques. Supposons que notre application est dploye dans lenvironnement de production Blue. Nous
voulons procder un nouveau dploiement. Notre application sera dploye dans un premier temps dans le
second environnement de production (Green). Une fois lapplication dploye dans cet environnement, nous
pouvons simplement router nos utilisateurs vers ce dernier, qui devient dsormais notre environnement de
production.

Avec cette approche, zero-downtime. Et en cas de bogue on peut simplement switcher vers lenvironnement
de production prcdent. De plus avant, avant daller en production avec lenvironnement Green, on peut
effectuer de nombreux tests (Performance tests, Capacity tests, Stress tests, Load tests) pour valuer les
performances et la ractivit du site Web dans un environnement proche de la production.

Une fois lenvironnement Green en production, lenvironnement Blue garde la version prcdente de la
plateforme pour parer toute ventualit, jusqu la livraison dune nouvelle version. Celle-ci sera dploye
dans lenvironnement Blue, qui sera ensuite switch en production. Le cycle sera rpt chaque livraison.

Blue-Green Deployment et Exposition progressive

Le Blue-Green Deployment et lexposition progressive offrent encore plus de souplesse et rduisent de faon
drastique le risque de bogue en production.

Le principe de lexposition progressive est assez simple : la nouvelle version de lapplication est rendue
disponible un nombre restreint dutilisateurs. Plus elle est stable et plus lon est satisfait de sa ractivit, plus
elle est accessible un nombre important dutilisateurs, jusqu une exposition complte lensemble des
utilisateurs.

De faon pratique, une fois que lapplication est dploye dans lenvironnement Green, un petit nombre
dutilisateurs sont redirigs vers cette dernire, tandis que lenvironnement Blue continue recevoir le gros du
trafic. Des indicateurs de tlmtrie sont alors utiliss pour valuer la nouvelle application. Ensuite, un Load
Balancer entre en scne pour grer la rpartition des charges entre les deux environnements.

Finalement, on se retrouve en production avec une version assez mature et qui a quasiment dj fait ses
preuves.

La gestion de la base de donnes dans une approche Blue-Green Deployment.

Il va de soi que les deux environnements vont partager la mme base de donnes en production. Comment
grer les volutions de la base de donnes ? Les quipes projet doivent maintenir en tout temps une
compatibilit entre les schmas de la base de donnes pour les deux versions de lapplication. Si la nouvelle
version introduit un nouveau schma, le schma de la base de donnes doit tre refactoris pour tre
compatible avec les deux versions.

Le gros bmol de cette approche est la maintenance de deux environnements de production. Et pour une
application exigeante en ressources, cela peut tre assez onreux.

Exemple dimplmentation du Blue-Green Deployment : les slots de dploiement dAzure Web

Apps.

Jai dj publi sur ce blog un billet sur les slots de dploiement dAzure Web Apps. Il sagit dune
implmentation concrte du Blue-Green Deployment. En effet, lorsque vous crez une Web Application sur
Azure, vous disposez par dfaut dun slot de production.

Chaque fois que vous dployez votre application, cette dernire est dploye par dfaut sur ce slot. Azure Web
Apps vous offre cependant la possibilit de crer un autre emplacement de dploiement (staging) dans le
mme service plan. Une fois une nouvelle version de votre application prte entrer en production, vous la
dployez dans un premier temps sur le slot Staging. Ensuite, partir du portail Azure, vous pouvez dfinir le
pourcentage dutilisateurs qui seront redirigs vers cette nouvelle version et effectuer vos tests de
performance en production (A/B testing). Une fois cette dernire prte 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 prcdemment passe en staging. En cas dun bogue important le retour la
version prcdente est tout aussi simple.

Un autre point intressant est le fait que vous pouvez partager le mme groupe de ressources (mmoire,
processeurs, etc.) entre les slots, ce qui vous permet de mieux contrler les cots.

Canary Release

Il est frquent dans des projets de dveloppements Web, dadopter une phase de bta public de lapplication.
Durant cette phase, la nouvelle plateforme est disponible pour un nombre limit dutilisateurs, tandis que la
version en production continue servir le plus grand nombre.

Lapproche permettant dadresser le mieux cette problmatique 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 lapplication est teste en production par un nombre restreint dutilisateurs, sans
impacter lexprience utilisateur de la majeure partie des utilisateurs.

Ce mode est privilgier sur le Blue Green Deployment si vous ntes pas certain que la nouvelle version de
votre application fonctionnera correctement en production. Cette approche permet de rduire normment le
risque de bogue et de rollback en production.

De faon pratique, lapproche Canary Realse ncessite la disponibilit de plus dun serveur en production. La
nouvelle version dune application est initialement publie sur lun des serveurs en production et un petit
nombre dutilisateurs est dirig vers cette dernire. Durant cette phase, les feedbacks des utilisateurs peuvent
tre rcuprs, les correctifs publis pour stabiliser lapplication, etc. Une fois lapplication assez stable, celle-ci
est dploye en production.

Il sagit de lapproche adquate pour le A/B testing. Car les tests sont effectus en production par des
utilisateurs finals, et lon est en mesure de recueillir des mtriques en situation dutilisation normale de
lapplication.

Feature Flags (feature toggle)

Cette approche consiste marquer les fonctionnalits avec un drapeau dans le code. Ce drapeau permettra de
rendre disponible ou non une fonctionnalit. Initialement, les nouvelles fonctionnalits de lapplication ont une
tiquette Off . Au dploiement de lapplication, elles ne sont pas accessibles. Bien aprs le dploiement, ces
fonctionnalits peuvent tre actives. En cas de bogue important, la fonctionnalit sera simplement dsactive
au lieu quun rollback complet de lapplication soit effectu.

Avec ce modle, vous tes en mesure dactiver ou dsactiver 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 stratgie dintgration et de dploiement continus.
Concrtement, la nouvelle fonctionnalit lorsquelle est encore au stade de prversion est livre en production
avec les autres mises jour et correctifs de la version en production. Celle-ci est ensuite active pour un
nombre rduit dutilisateurs. Ceci peut se faire suivant un certain nombre de critres : zone gographique,
sexe ou en utilisant un message pour inviter des utilisateurs tester cette nouvelle fonctionnalit. Les quipes
projet seront alors en mesure dobtenir les retours des utilisateurs sur la fonctionnalit, analyser le
comportement de ceux-ci face cette dernire, valuer le degr de satisfaction, valuer limpact de la
fonctionnalit sur les performances du systme, etc.

Au fil des dploiements, la fonctionnalit est amliore en tenant compte du feedback des utilisateurs et des
indicateurs de tlmtrie, jusqu son largissement lensemble des utilisateurs.

Cette approche est trs utilise par les gants du Web, notamment Facebook, Google et Microsoft.

Conclusion

Ladoption de lune 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 lgre cette tape, car un mauvais cycle de
dploiement pourrait avoir de lourdes consquences.