Apparue en 2010 à travers le livre “Continuous Delivery” de Jez Humble et David Farley, la méthode Blue/Green favorise un déploiement optimal de vos solutions logicielles. Alors qu’est-ce que le Blue/Green DevOps ? Est-ce la seule stratégie de déploiement ? Quels sont les avantages et les inconvénients ? Les réponses sont ici. 

‍

Qu’est-ce que le Blue/Green DevOps ?

‍

L’objectif des équipes DevOps étant de déployer des logiciels ou des applications en continu sans interrompre les services, ils ont généralement besoin de deux environnements de production : un pour les utilisateurs et un autre pour effectuer les mises à jour. C’est justement tout le principe de la méthode Blue/Green. 

‍

Concrètement, lorsque des modifications doivent être apportées, l’environnement contenant la version initiale est dupliqué. La solution logicielle est alors présente sur deux environnements distincts : 

• Une version Green qui reste à disposition des utilisateurs. 
• Une version Blue sur laquelle les développeurs peuvent travailler sans impacter les services. 

Dès lors que les modifications sont validées sur la version Blue, elles sont implémentées dans l’environnement Green. Cela dit, la version initiale peut aussi être conservée en parallèle, notamment pour des tests A/B.

‍

Grâce à cette méthode, il n’y a aucune interruption de service (c’est un Zero Downtime Deployment (ZDD). À ce titre, le déploiement Blue/Green s’inscrit pleinement dans le mouvement DevOps. Dans les deux cas, l’objectif est de déployer rapidement une solution logicielle de qualité. 

‍

Quelles sont les autres stratégies de déploiement ?

‍

Au delà de la méthode Blue/Green, les DevOps peuvent aussi utiliser d’autres modèles de déploiement, tels que : 

• Déploiement progressif (ou Rolling) :  il s’agit d’échelonner les modifications sur sur des serveurs ou instances. 
• Déploiement Canary : la méthode est totalement différente, puisqu’aucun autre environnement n’est créé. Dans ce cadre, les modifications sont échelonnées sur un nombre restreint d’utilisateurs, appelés les canary. 
• Déploiement par versions : similaire au déploiement canary, il permet toutefois aux utilisateurs de choisir une version. 
• Déploiement Rip-and-Replace : il s’agit de remplacer le vieux par le neuf. Pour cela, il est préférable d’avoir une infrastructure stable dans le temps.

‍

Quels sont les avantages du Blue/Green deployment ?

‍

Le Blue/Green DevOps est l’une des méthodes de déploiement les plus populaires. Et pour cause, elle présente une multitude d’avantages. 

‍

Le déploiement en production 

‍

Avec le modèle de déploiement Blue/Green, les DevOps peuvent tester et vérifier de nouvelles fonctionnalités sur un serveur inactif, alors que les utilisateurs continuent d’accéder aux services du logiciel. Comme tous les éventuels bugs auront été identifiés en amont sur le serveur inactif, le risque d’erreur est limité. Ainsi, la satisfaction client reste optimale. 

‍

La stabilité du système 

‍

Avec le déploiement Blue/Green, il y a toujours un serveur en stand by en cas de défaillance du système. Ce qui permet de bénéficier d’un niveau élevé de gestion des risques. 

En effet, si l’objectif du Blue/Green DevOps est d’apporter des améliorations, d’autres problèmes sans rapport avec les nouvelles mises à jour peuvent survenir (comme un logiciel malveillant ou un ransomware). Dans ce cadre, l’environnement mis en réserve permet d’avoir une solution de secours. Même si les modifications ont été perdues, les développeurs du back-end pourront toujours rediriger le trafic utilisateur vers l'ancienne version. L’application reste fonctionnelle aux yeux des utilisateurs. En parallèle, les DevOps peuvent identifier facilement les solutions aux problèmes rencontrés par l'autre serveur. 

‍

La rapidité du déploiement

‍

Lorsque toutes les modifications sont vérifiées et validées, les DevOps n’ont plus qu’à changer de routage pour que le logiciel ou l’application soit mis en production. Ce qui favorise le déploiement continu des solutions logicielles. 

Ce déploiement rapide et sans interruption participe à l’amélioration de l’expérience utilisateur. 

‍

L’A/B Testing 

‍

Si les développeurs veulent apporter des améliorations à une application ou un logiciel, cela ne signifie pas qu’elles soient toujours pertinentes. Ces modifications peuvent être inadaptées à une application web ou comporter une erreur de codage entraînant un dysfonctionnement de l'ensemble du système. 

Heureusement, le déploiement Blue/Green DevOps permet de localiser rapidement la source du problème, mais aussi de revenir à l'ancienne version facilement. Il est donc plus facile de tester différentes fonctionnalités, sans prendre trop de risques, notamment en termes de satisfaction des utilisateurs. 

‍

L’absence d’interruption de service 

‍

Impossibilité d’accès à une application, indisponibilité d'un logiciel ou d’un site web, toutes ces situations sont décourageantes pour les utilisateurs. C’est d’autant plus important pour les institutions financières ou les marchés en ligne qui génèrent des milliers de transactions chaque heure. Pour ces dernières, les conséquences d'un temps d'arrêt sont catastrophiques. 

Avec la méthode de déploiement Blue/Green DevOps, ces interruptions de service sont inexistantes. Que ce soit pour des contrôles de maintenance ou pour résoudre activement un problème récurrent, les utilisateurs ne se rendent même pas compte que les DevOps améliorent le produit en même temps. 

Quels sont les inconvénients du Blue/Green DevOps ?

‍

Malgré tous ses avantages, le déploiement Blue/Green DevOps rencontre quelques limites. 

‍

Le coût 

‍

Toutes les entreprises ne disposent pas des ressources financières suffisantes en interne pour mener à bien les processus de déploiement Blue/Green. En effet, pour créer plusieurs environnements, les organisations doivent doubler le montant consacré à l'infrastructure. Sans oublier que ces environnements nécessitent également des ressources humaines importantes pour surveiller et exploiter les serveurs. 

Que ce soit en termes de budget ou de collaborateurs, le manque de ressources freine la démocratisation de la méthode Blue/Green. 

‍

Les bases de données

‍

Bien souvent, une nouvelle version peut apporter des modifications avec la base de données actuelle. Dans ce cadre, les équipes DevOps peuvent implémenter un schéma de base de données hybride (avec deux versions) ou intégrer une database unique. 

Quelle que soit l’option choisie, les DevOps doivent redoubler de vigilance lorsqu’ils déplacent des bases de données d’un environnement à l’autre. En effet, cette manipulation peut provoquer de nombreuses erreurs. 

‍

La scalabilité 

‍

La méthode Blue/Green DevOps a tendance à se complexifier au fur et à mesure que l'entreprise se développe (notamment en termes de fonctionnalités proposées et de nombre d'utilisateurs). Il est donc primordial d’avoir une équipe DevOps capable de gérer une infrastructure de plus en plus complexe, afin de maintenir l'homogénéité entre les deux environnements.

‍

En conclusion : 

‍

• Le déploiement Blue/Green DevOps permet de répondre parfaitement aux exigences d’intégration et de livraison en continu (et sans interruption de service). 
• Cette méthode favorise les tests en production, la rapidité du déploiement, la stabilité du système et l’expérience utilisateur. 
• Cependant, pour mettre en place ce modèle de déploiement, les organisations doivent disposer de ressources (humaines et financières) suffisantes.