Déploiement Blue/Green : quand vous avez besoin d’un basculement et d’un rollback instantanés

Imaginez la scène : votre équipe vient de terminer une refonte majeure de la page d’accueil. Ou peut-être avez-vous remplacé une bibliothèque centrale qui touche chaque partie de l’application. Des changements comme ceux-ci sont difficiles à tester parfaitement en préproduction, car les données de staging et le comportement des utilisateurs ne correspondent jamais vraiment à la production. Vous pourriez essayer une mise à jour progressive (rolling update), mais si quelque chose tourne mal, la moitié de vos utilisateurs verraient la version cassée tandis que l’autre moitié verrait encore l’ancienne. Et le rollback ? Cela signifie attendre que chaque instance revienne une par une. Pas vraiment instantané.

C’est là que le déploiement blue/green entre en jeu. Il résout un problème spécifique : comment basculer tous les utilisateurs vers une nouvelle version en une fois, et comment les ramener en arrière aussi vite si les choses tournent mal ?

Deux environnements identiques, un seul actif à la fois

L’idée est simple. Vous maintenez deux environnements identiques. Appelez-en un bleu et l’autre vert. Les deux exécutent la même infrastructure, la même configuration et la même capacité. La seule différence est lequel sert les utilisateurs en ce moment.

Voyons comment cela fonctionne en pratique.

Le diagramme ci-dessous montre les deux états et les transitions entre eux.

Disons que vos utilisateurs accèdent actuellement à l’environnement bleu, qui exécute la version 1 de votre application. L’environnement vert est également en cours d’exécution, mais il ne reçoit aucun trafic utilisateur. Peut-être que votre équipe l’utilise pour des tests internes, ou peut-être qu’il reste simplement inactif. Quand il est temps de publier la version 2, vous déployez la nouvelle version sur l’environnement vert. Maintenant, le vert a la version 2, tandis que le bleu continue de servir les utilisateurs avec la version 1.

À ce stade, vous pouvez tester la version 2 dans un environnement identique à la production. Exécutez des vérifications de santé. Validez les fonctionnalités. Demandez à quelques personnes internes d’essayer la nouvelle version. Tout se passe sans affecter les utilisateurs réels.

Une fois que vous êtes confiant, vous effectuez le basculement. Le basculement signifie rediriger le trafic utilisateur du bleu vers le vert. Vous pouvez mettre à jour la configuration de votre équilibreur de charge, modifier les enregistrements DNS, ou ajuster le routage dans un service mesh. En quelques secondes, tous les utilisateurs commencent à utiliser la version 2. Il n’y a pas de temps d’arrêt car le vert était déjà en cours d’exécution avec des serveurs chauds, des connexions de base de données ouvertes et l’application entièrement initialisée.

La fonctionnalité clé : le rollback instantané

Le plus grand avantage du déploiement blue/green est la rapidité avec laquelle vous pouvez revenir en arrière. Si la version 2 s’avère problématique après que les utilisateurs ont commencé à l’utiliser, vous redirigez simplement le trafic vers le bleu. Les utilisateurs reviennent à la version 1 instantanément. Pas d’attente pour un redéploiement. Pas de relance d’un pipeline. Le rollback n’est qu’un changement de routage.

Comparez cela à une mise à jour progressive. Si vous devez annuler une mise à jour progressive, vous devez inverser le processus instance par instance. Chacune prend du temps pour redémarrer et se reconnecter. Pendant cette fenêtre, certains utilisateurs pourraient encore rencontrer la version cassée. Avec blue/green, l’ancienne version est toujours en cours d’exécution et prête à servir. Vous actionnez le commutateur et c’est fait.

Le compromis sur le coût

Le déploiement blue/green a un inconvénient évident : le coût. Vous devez exécuter deux environnements complets en même temps. Si votre charge de travail de production nécessite 10 serveurs, blue/green signifie que vous exécutez 20 serveurs pendant la période de transition. Vous payez pour le double de la capacité.

Certaines équipes réduisent ce coût en réduisant la taille de l’environnement inactif. Par exemple, le vert pourrait fonctionner avec seulement 2 serveurs tant qu’il ne sert pas de trafic, puis passer à 10 serveurs juste avant le basculement. Cette approche nécessite une automatisation pour gérer la mise à l’échelle, et elle reste plus coûteuse qu’une mise à jour progressive. Mais pour les changements à haut risque, le coût peut valoir la sécurité.

Quand utiliser Blue/Green

Cette stratégie convient aux changements où le risque est élevé et où le rollback doit être instantané. Pensez à :

• Les refontes majeures de l’interface utilisateur qui affectent la façon dont les utilisateurs interagissent avec votre produit
• Le remplacement de dépendances ou de bibliothèques centrales
• Les modifications de schéma de base de données difficiles à inverser
• Les mises à jour de conformité ou réglementaires où un basculement propre est nécessaire

Mais tous les changements n’ont pas besoin de deux environnements complets. Si vous déployez une petite correction de bug qui a été minutieusement testée, une mise à jour progressive est plus efficace et moins chère. La question devient : quel niveau de risque êtes-vous prêt à accepter, et à quelle vitesse devez-vous récupérer si quelque chose tourne mal ?

Une checklist pratique

Avant d’implémenter le déploiement blue/green, assurez-vous que ces éléments sont en place :

• Environnements identiques. Les deux environnements doivent exécuter la même infrastructure, la même configuration et la même capacité. Des différences entre eux compromettent l’objectif.
• Applications sans état ou conscientes des sessions. Si votre application stocke les données de session localement, les utilisateurs perdront leurs sessions lors du basculement. Utilisez des magasins de session externes comme Redis ou concevez pour l’absence d’état.
• Basculement automatisé. Le basculement manuel est sujet aux erreurs. Automatisez le changement de trafic pour qu’il prenne des secondes, pas des minutes de clics.
• Vérifications de santé sur le nouvel environnement. Ne vous contentez pas de déployer et de basculer. Vérifiez que la nouvelle version réussit les vérifications de santé avant d’y router le trafic.
• Surveillance pendant et après le basculement. Surveillez les taux d’erreur, la latence et les métriques métier immédiatement après le changement. Si quelque chose semble anormal, revenez en arrière rapidement.

L’essentiel à retenir

Le déploiement blue/green vous donne la capacité de basculer tous les utilisateurs vers une nouvelle version instantanément et de les ramener en arrière tout aussi rapidement. Le coût est l’exécution de deux environnements, mais la contrepartie est un filet de sécurité pour les changements à haut risque. Si votre équipe effectue des versions majeures et que vous vous inquiétez du temps de récupération, blue/green vaut l’investissement. Pour les changements plus petits, restez sur les mises à jour progressives. La bonne stratégie dépend du risque, pas de celle qui semble la plus impressionnante.