L’une des mesures les plus critiques dans DevOps est la vitesse à laquelle vous livrez de nouvelles fonctionnalités. En alignant les développeurs, les équipes d’exploitation et le personnel de support, ils mettent rapidement en production de nouveaux logiciels qui génèrent de la valeur plus rapidement et peuvent souvent être le facteur décisif pour que votre entreprise prenne l’avantage sur la concurrence.

La livraison rapide raccourcit également le délai entre le développement du logiciel et le retour des utilisateurs, ce qui est essentiel pour les équipes pratiquant l’intégration et le déploiement continus (CI/CD).

Une pratique que vous devriez envisager d’ajouter à votre boîte à outils CI/CD est le déploiement bleu-vert. Ce processus permet de réduire les risques techniques et commerciaux associés aux sorties de logiciels.

Dans ce modèle, deux environnements de production identiques, surnommés « bleu » et « vert », fonctionnent côte à côte, mais seul l’un d’eux est opérationnel et reçoit les transactions des utilisateurs. L’autre est opérationnel mais inactif.

Dans cet article, nous allons voir comment fonctionnent les déploiements bleu-vert. Nous discuterons des avantages et des inconvénients de cette approche pour le lancement de logiciels. Nous comparerons également cette approche à d’autres méthodologies de déploiement et vous donnerons quelques-unes des meilleures pratiques que nous vous recommandons pour garantir le bon déroulement de vos déploiements blue-green.

Dans cet article, nous aborderons les points suivants :

Comment fonctionnent les déploiements bleu-vert ?

L’une des étapes les plus difficiles d’un processus de déploiement est le passage du test à la production. Elle doit se faire rapidement et sans heurts pour minimiser les temps d’arrêt.

Une méthodologie de déploiement bleu-vert relève ce défi en utilisant deux environnements de production parallèles. À tout moment, seul l’un d’entre eux est l’environnement actif qui reçoit les transactions des utilisateurs. Dans l’image ci-dessous, ce serait le vert. Le système bleu inactif est une copie presque identique.

Diagramme de routage d’un déploiement bleu-vert (Source)

Votre équipe utilisera le système bleu inactif comme environnement de test pour effectuer la dernière série de tests lors de la préparation de la sortie d’une nouvelle fonctionnalité. Une fois que le nouveau logiciel fonctionne correctement sur blue, votre équipe des opérations peut changer de routage pour faire de blue le système actif. Vous pouvez alors implémenter la fonctionnalité sur le système vert, qui est maintenant inactif, pour que les deux systèmes soient resynchronisés.

D’une manière générale, c’est tout ce qu’il y a à faire dans un déploiement bleu-vert. Vous avez une grande flexibilité dans la façon dont les systèmes parallèles et les coupures sont structurés. Par exemple, il se peut que vous ne souhaitiez pas maintenir des bases de données parallèles, auquel cas vous ne changerez que le routage vers les serveurs web et les serveurs d’applications. Dans le cadre d’un autre projet, vous pouvez utiliser un déploiement bleu-vert pour publier une fonctionnalité non testée sur le système actif, mais la placer derrière un drapeau de fonctionnalité pour les tests A/B des utilisateurs.

Exemple de déploiement bleu-vert

Disons que vous êtes responsable de l’équipe DevOps d’une entreprise de commerce électronique de niche. Vous vendez des vêtements et des accessoires populaires sur un marché restreint mais à forte valeur ajoutée. Sur votre site, les clients peuvent personnaliser et commander des produits à la demande.

Le backend de votre site se compose de nombreux microservices dans quelques conteneurs différents. Vous avez des microservices pour la gestion des stocks, la gestion des commandes, les applications de personnalisation, et un réseau social intégré pour soutenir la communauté de niche de vos clients.

Votre équipe publiera tôt et souvent, car vous attribuez votre popularité continue à votre modèle CI/CD. Mais cette communauté de niche est mondiale, de sorte que votre site reçoit un trafic relativement stable tout au long de la journée. Trouver une accalmie pour mettre à jour votre système de production est toujours délicat.

Lorsque l’une de vos équipes annonce que la mise à jour de l’interface de personnalisation est prête pour les tests finaux en production, vous décidez de la publier en utilisant un déploiement bleu-vert afin qu’elle puisse être diffusée immédiatement.

Animation d’un équilibreur de charge ajustant le trafic du bleu au vert (Source)

Le lendemain, avant le déjeuner, votre équipe décide qu’elle est prête à lancer le nouveau personnalisateur. À ce moment-là, tout le trafic se dirige vers votre système de production bleu. Vous mettez à jour le logiciel sur votre système vert inactif et demandez aux testeurs de le soumettre à un test de qualité. Tout semble bon, et votre équipe d’exploitation utilise un équilibreur de charge pour rediriger les sessions des utilisateurs du système bleu vers le système vert.

Une fois que le trafic est complètement filtré vers le vert, vous en faites l’environnement de production officiel et mettez le bleu au repos. Votre équipe de développement pousse le code de personnalisation mis à jour vers blue, passe sa commande de déjeuner et jette un coup d’œil à votre carnet de commandes.

Les avantages du déploiement bleu-vert : avantages et cas d’utilisation

L’un des principaux avantages des déploiements blue-green par rapport aux autres stratégies de publication de logiciels est leur flexibilité. Ils peuvent être bénéfiques dans un large éventail d’environnements et de cas d’utilisation.

Libération rapide

Pour les propriétaires de produits travaillant dans des cadres CI/CD, les déploiements bleu-vert sont une excellente méthode pour mettre votre logiciel en production. Vous pouvez publier un logiciel pratiquement à tout moment. Vous n’avez pas besoin de programmer une sortie le week-end ou en dehors des heures de travail car, dans la plupart des cas, il suffit de modifier le routage pour que le logiciel soit mis en production. Comme il n’y a pas de temps d’arrêt associé, ces déploiements n’ont pas d’impact négatif sur les utilisateurs.

Ils sont également moins perturbants pour les équipes DevOps. Elles n’ont pas besoin de se précipiter sur les mises à jour pendant une fenêtre de panne définie, ce qui entraîne des erreurs de déploiement et un stress inutile. Les équipes de direction seront également plus heureuses. Elles n’auront pas à regarder l’horloge pendant les temps d’arrêt, en comptabilisant les pertes de revenus.

Des retours en arrière simples

Le processus inverse est tout aussi rapide. Comme les déploiements bleu-vert utilisent deux environnements de production parallèles, vous pouvez rapidement revenir à l’environnement stable si des problèmes surviennent dans votre environnement réel.

Cela réduit les risques inhérents à l’expérimentation en production. Votre équipe peut facilement supprimer tout problème par un simple changement de routage vers l’environnement de production stable. Il existe un risque de perdre des transactions utilisateur en réduisant la production – ce que nous aborderons un peu plus loin – mais il existe de nombreuses stratégies pour gérer cette situation.

Vous pouvez temporairement configurer votre application pour qu’elle soit en lecture seule pendant les coupures. Ou vous pouvez effectuer des coupures progressives avec un équilibreur de charge pendant que vous attendez que les transactions se terminent dans l’environnement réel.

Reprise après sinistre intégrée

Comme les déploiements bleu-vert utilisent deux environnements de production, ils offrent implicitement une reprise après sinistre pour vos systèmes d’entreprise. Un double environnement de production est sa propre sauvegarde à chaud.

Plusieurs serveurs dans un rack (Source)

Équilibrage de la charge

Les environnements de production parallèles bleu-vert facilitent également l’équilibrage des charges. Lorsque les deux environnements sont fonctionnellement identiques, vous pouvez utiliser un équilibreur de charge ou une bascule de fonctionnalité dans votre logiciel pour acheminer le trafic vers les différents environnements selon les besoins.

Tests A/B plus faciles

Les tests A/B constituent un autre cas d’utilisation des environnements de production parallèles. Vous pouvez charger de nouvelles fonctionnalités sur votre environnement inactif et ensuite diviser le trafic avec un basculement de fonctionnalité entre vos systèmes bleu et vert.

Recueillez des données à partir de ces sessions d’utilisateurs divisées, surveillez vos indicateurs de performance clés, et ensuite, si les analyses de la nouvelle fonctionnalité semblent bonnes dans votre système de gestion, vous pouvez basculer le trafic vers l’environnement mis à jour.

Contre le déploiement bleu-vert : Défis à prendre en compte

Les déploiements blue-green offrent une grande valeur, mais l’intégration de l’infrastructure et des pratiques requises pour les réaliser crée des défis pour les équipes DevOps. Avant d’intégrer les déploiements blue-green dans votre processus CI/CD, il est utile de comprendre ces défis.

Les déploiements bleu-vert sont gourmands en ressources

Comme il est évident maintenant, pour effectuer un déploiement bleu-vert, vous devrez fournir et maintenir deux environnements de production. Le coût de cette opération, en argent et en temps d’administrateur système, peut être trop élevé pour certaines organisations.

Pour d’autres, il se peut qu’elles ne soient en mesure d’engager de telles ressources que pour leurs produits de plus grande valeur. Si c’est le cas, l’équipe DevOps publie-t-elle des logiciels dans un modèle CI/CD pour certains produits mais pas pour d’autres ? Cela peut ne pas être durable.

Gestion de bases de données supplémentaires

La gestion de votre base de données – ou de plusieurs bases de données – lorsque vous avez des environnements de production parallèles peut être compliquée. Vous devez tenir compte de tout ce qui se trouve en aval de la mise à jour logicielle dont vous avez besoin dans vos environnements bleu et vert, comme les services externes que vous invoquez.

Par exemple, que se passe-t-il si votre changement de fonctionnalité vous oblige à renommer une colonne de la base de données ? Dès que vous changez le nom en bleu, l’environnement vert avec l’ancien code ne fonctionnera plus avec cette base de données.

L’ensemble de votre environnement de production peut-il même fonctionner avec deux bases de données distinctes ? Ce n’est souvent pas le cas si vous utilisez vos systèmes bleu et vert pour l’équilibrage de charge, les tests ou toute autre fonction autre que la sauvegarde à chaud.

Un diagramme de déploiement bleu-vert avec une seule base de données (Source)

Gestion des produits

Outre l’administration du système, la gestion d’un produit qui fonctionne sur deux environnements quasi identiques nécessite également davantage de ressources. Les chefs de produit ont besoin d’outils fiables pour suivre les performances de leur logiciel, les services que les différentes équipes mettent à jour et les moyens de surveiller les indicateurs clés de performance associés à chacun. Un tableau de bord fiable de gestion des produits et des fonctionnalités pour surveiller et coordonner toutes ces activités devient essentiel.

Déploiements bleu-vert et déploiements continus

Les déploiements bleus-verts ne sont, bien entendu, pas la seule option pour réaliser des mises à jour rapides de logiciels. Une autre approche populaire consiste à effectuer un déploiement continu.

Les déploiements continus nécessitent également un environnement de production composé de plusieurs serveurs hébergeant une application, souvent, mais pas toujours, avec un équilibreur de charge devant eux pour acheminer le trafic. Lorsque l’équipe DevOps est prête à mettre à jour son application, elle configure une version échelonnée, en la poussant sur un serveur après l’autre.

Pendant le déploiement de la version, certains serveurs actifs exécutent l’application mise à jour, tandis que d’autres disposent de l’ancienne version. Cela contraste avec un déploiement bleu-vert, où le logiciel mis à jour est soit en direct, soit non disponible pour tous les utilisateurs.

Lorsque les utilisateurs lancent des sessions avec l’application, ils peuvent atteindre soit l’ancienne copie de l’application, soit la nouvelle, selon la façon dont l’équilibreur de charge les achemine. Lorsque le déploiement est terminé, chaque nouvelle session d’utilisateur qui arrive atteint la version mise à jour du logiciel. Si une erreur se produit pendant le déploiement, l’équipe DevOps peut interrompre les mises à jour et acheminer tout le trafic vers les autres serveurs connus jusqu’à ce que l’erreur soit résolue.

Un diagramme de déploiement continu (Source)

Les déploiements continus sont une option viable pour les organisations disposant des ressources nécessaires pour héberger un environnement de production aussi vaste. Pour ces organisations, il s’agit d’une méthode efficace pour diffuser de petites mises à jour progressives, comme dans les méthodologies de développement agiles.

Il y a d’autres cas d’utilisation où les déploiements bleu-vert peuvent être mieux adaptés. Par exemple, si vous effectuez une mise à jour importante pour laquelle vous ne voulez pas que les utilisateurs accèdent à l’ancienne version de votre logiciel, vous voudrez adopter une approche  » tout ou rien « , comme un déploiement bleu-vert.

Supposons que votre application nécessite un niveau élevé de support technique ou de support client. Dans ce cas, la charge de support est amplifiée pendant les fenêtres de déploiement continu lorsque le personnel de support ne peut pas savoir quelle version de l’application les utilisateurs utilisent.

Déploiements bleu-vert contre libération de canaris

Les déploiements continus et les déploiements blue-green ne sont pas les seules stratégies de mise à jour existantes. Les versions canari sont une autre alternative. Dans un premier temps, seul un sous-ensemble de tous les environnements de production reçoit une mise à jour logicielle dans une version canari. Mais au lieu de continuer à déployer le reste, cette version partielle est maintenue en place à des fins de test. Un sous-ensemble d’utilisateurs est ensuite dirigé vers le nouveau logiciel par un équilibreur de charge ou un indicateur de fonctionnalité.

La mise en place d’une version canari est utile lorsque vous souhaitez recueillir des données et des commentaires d’un ensemble identifiable d’utilisateurs sur le logiciel mis à jour. La pratique des versions canariées s’accorde parfaitement avec les déploiements continus plus larges, car vous pouvez progressivement déployer le logiciel mis à jour vers des segments de plus en plus larges de votre base d’utilisateurs jusqu’à ce que vous ayez fini de mettre à jour tous les serveurs de production.

Meilleures pratiques de déploiement bleu-vert

Vous disposez de nombreuses options pour diffuser rapidement des logiciels. Si vous envisagez le déploiement bleu-vert comme nouvelle stratégie de diffusion de logiciels, nous vous recommandons d’adopter certaines de ces meilleures pratiques.

Automatiser autant que possible

La création de scripts et l’automatisation d’une grande partie du processus de mise en production présentent de nombreux avantages. Non seulement la transition est plus rapide, mais il y a moins de place pour l’erreur humaine. Un développeur ne peut pas accidentellement oublier un élément de la liste de contrôle si un script ou une plateforme de gestion gère la liste de contrôle. Si tout est regroupé dans un script, tout développeur ou non peut effectuer le déploiement. Vous n’avez pas besoin d’attendre le retour de votre expert système au bureau.

Surveillez vos systèmes

Veillez toujours à surveiller les environnements bleu et vert. Pour qu’un déploiement bleu-vert se déroule sans problème, vous devez savoir ce qui se passe dans vos systèmes actifs et inactifs.

Les deux systèmes auront probablement besoin du même ensemble d’alertes de surveillance, mais avec des priorités différentes. Par exemple, vous voudrez être informé à la seconde où il y a une erreur dans votre système actif. Mais la même erreur dans le système inactif peut devoir être traitée dans le courant de la journée.

Un développeur surveillant le déploiement (Source)

Ecrire du code compatible avec le passé et le futur

Dans certains cas, les nouvelles et anciennes versions de votre logiciel ne pourront pas fonctionner simultanément pendant la transition. Par exemple, si vous devez modifier le schéma de votre base de données, il serait utile de structurer vos mises à jour de manière à ce que les systèmes bleu et vert soient fonctionnels pendant toute la durée de la transition.

Une façon de gérer ces situations est de décomposer vos versions en une série de paquets de versions encore plus petits. Disons que notre société de commerce électronique approfondit son inventaire et doit mettre à jour sa base de données en changeant le nom d’un champ de « chemise » à « chemise_à_manches_longues » pour plus de clarté.

Elle pourrait décomposer cette mise à jour comme suit :

  • En publiant une version intermédiaire de leur code qui peut interpréter les résultats de « shirt » et « longsleeve_shirt » ;
  • Exécution d’une migration de renommage sur l’ensemble de leur base de données pour renommer le champ ;
  • Publier la version finale du code – ou inverser leur drapeau de fonctionnalité – afin que le logiciel n’utilise que « longleeve_shirt ».

Faire plus, avec des déploiements plus petits

Des mises à jour plus petites et plus fréquentes sont déjà une pratique intégrale du développement agile et du CI/CD. Il est encore plus important de suivre cette pratique si vous souhaitez effectuer des déploiements bleu-vert. La réduction des délais de déploiement raccourcit les boucles de rétroaction, informant la prochaine version, rendant chaque mise à niveau incrémentielle plus efficace et plus précieuse pour votre organisation.

Restructurer vos applications en microservices

Cette approche va de pair avec la réalisation de déploiements plus petits. La restructuration du code des applications en ensembles de microservices vous permet de gérer plus facilement les mises à jour et les modifications. Les différentes fonctionnalités sont compartimentées de manière à faciliter leur mise à jour de manière isolée.

Utiliser des indicateurs de fonctionnalité pour réduire davantage les risques

En soi, les déploiements bleu-vert créent une fenêtre de risque unique et courte. Vous mettez tout à jour, tout ou rien, mais vous pouvez revenir en arrière si nécessaire en cas de problème.

Les déploiements bleu-vert ont également une quantité assez constante de frais généraux administratifs qui viennent avec chaque changement. Vous pouvez réduire ces frais généraux grâce à l’automatisation, mais vous allez tout de même suivre le même processus, que vous mettiez à jour une seule ligne de code ou que vous remaniiez l’ensemble de votre suite de commerce électronique.

Service AB Tasty feature flag

Les drapeaux de fonctionnalités peuvent offrir un niveau de contrôle très granulaire sur la manière et le moment où les utilisateurs découvrent les logiciels nouvellement disponibles. Les Feature Flags sont comme de puissantes instructions « if », à partir desquelles au moins un des deux ou plusieurs chemins de code différents est suivi au moment de l’exécution en fonction d’une condition donnée.

Ces conditions peuvent être de simples vérifications « oui/non » ou des arbres de décision complexes. Les drapeaux de fonctionnalités aident à rendre les versions de logiciels plus faciles à gérer en contrôlant ce qui est activé ou désactivé au niveau de chaque fonctionnalité.

Par exemple, notre société de commerce électronique peut effectuer un déploiement bleu-vert de son microservice de personnalisation, mais laisser le nouveau code désactivé derrière un drapeau de fonctionnalité dans le système actif. Ensuite, l’équipe DevOps peut activer cette fonctionnalité selon les conditions qu’elle souhaite, quand cela lui convient.

L’équipe peut vouloir effectuer d’autres tests A/B en production. Ou peut-être qu’elle veut effectuer d’autres tests d’aptitude. Ou il pourrait être plus logique pour l’équipe de faire une version canari du customizer pour un ensemble identifié d’adopteurs précoces.

Vos indicateurs de fonctionnalités peuvent fonctionner en conjonction avec un équilibreur de charge pour gérer quels utilisateurs voient quelle application et quels sous-ensembles de fonctionnalités tout en effectuant un déploiement bleu-vert. Au lieu de basculer des applications entières en une seule fois, vous pouvez passer à la nouvelle application, puis activer et désactiver progressivement des fonctionnalités individuelles sur les systèmes actifs et inactifs jusqu’à ce que vous ayez effectué la mise à niveau complète. Ce processus progressif réduit les risques et vous aide à détecter les éventuels bogues au fur et à mesure que les fonctionnalités individuelles sont mises en service.

Vous pouvez contrôler manuellement les indicateurs de fonctionnalités dans votre base de code, ou utiliser des services d’indicateurs de fonctionnalités pour un contrôle plus robuste. Ces plateformes offrent des rapports détaillés et un suivi des indicateurs clés de performance ainsi qu’un ensemble d’outils de gestion DevOps.

Nous recommandons d’utiliser des indicateurs de fonctionnalités dans toute version majeure d’une application lorsque vous effectuez un déploiement bleu-vert. Ils sont précieux même dans les petits déploiements où vous ne changez pas nécessairement d’environnement. Vous pouvez activer les fonctionnalités progressivement, une par une, sur le système bleu, en laissant le système vert en réserve comme sauvegarde à chaud si un problème majeur survient. La combinaison des drapeaux de fonctionnalités et des déploiements bleu-vert est un excellent moyen de réaliser une livraison continue à n’importe quelle échelle.

Pensez à ajouter les déploiements bleu-vert à votre arsenal DevOps

Les déploiements bleu-vert sont une excellente méthode pour gérer les versions logicielles de toute taille, qu’il s’agisse d’une application complète, de mises à jour majeures, d’un microservice unique ou d’une petite mise à jour de fonctionnalité.

Il est essentiel d’examiner dans quelle mesure les déploiements blue-green s’intégreront à votre processus de livraison existant avant de les adopter. Cet article a détaillé le fonctionnement des déploiements blue-green, les avantages et les inconvénients de leur utilisation dans votre processus de livraison, et comment ils se positionnent par rapport aux autres méthodes de déploiement possibles. Vous devriez maintenant mieux savoir si les déploiements bleu-vert peuvent être une option viable pour votre organisation.

Vous voulez voir d’autres façons d’améliorer votre processus de livraison ? Demandez dès aujourd’hui une démonstration de la plateforme phare d’AB Tasty.

Déploiement de Canary : Tout ce que vous devez savoir

Déploiement de Canary : Tout ce que vous devez savoir

Le choix d'une stratégie de déploiement efficace est une décision importante pour chaque équipe DevOps. Il existe de nombreuses options, et vous devez trouver la stratégie qui correspond le mieux à votre façon de travailler. Êtes-vous une organisation agile ?...

Un guide simple pour augmenter les conversions

Un guide simple pour augmenter les conversions

En marketing, un appel à l'action ou CTA fait référence à un élément dont la formulation incite les utilisateurs à prendre une action immédiate ou à répondre. Les appels à l'action sont absolument nécessaires dans les campagnes de marketing et constituent un moyen de...

0 commentaires

Soumettre un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *