Stratégies de déploiement : Blue-Green vs Rolling

Choisir les bonnes stratégies de déploiement est l'une des décisions les plus critiques au moment de livrer un logiciel, car elle détermine si vos utilisateurs subiront ou non une interruption. Qu'il s'agisse d'un site e-commerce, d'un serveur de jeu ou d'un bot Discord, chaque mise à jour revient en réalité à modifier un système en fonctionnement pendant qu'il continue de tourner. Dans cet article, je compare deux approches courantes, le déploiement blue-green et le rolling, à travers des scénarios réels, et je clarifie laquelle choisir selon la situation.

Pourquoi a-t-on besoin d'une stratégie ?

La méthode la plus simple, « arrêter le serveur, remplacer le code, redémarrer », peut suffire pour un petit projet personnel. Mais dès que vous avez du trafic, chaque seconde d'interruption signifie une perte de revenus, une mauvaise expérience utilisateur et une chute dans le classement des moteurs de recherche. L'objectif commun des stratégies de déploiement modernes est d'atteindre le zéro interruption (zero-downtime). Au-delà, trois attentes fondamentales existent :

• Retour arrière rapide (rollback) : pouvoir revenir à l'état précédent en quelques secondes si la nouvelle version est défaillante.
• Vérification sûre : faire passer la nouvelle version par des contrôles de santé avant de l'exposer au trafic réel.
• Prévisibilité : réaliser chaque déploiement avec les mêmes étapes reproductibles.

Comment fonctionne le déploiement blue-green ?

Dans l'approche blue-green, vous maintenez deux environnements miroirs : blue est la version actuellement en ligne, tandis que green est un environnement identique où vous préparez la prochaine version. Vous déployez le nouveau code sur green, exécutez les migrations et effectuez les contrôles de santé. Si tout va bien, le load balancer ou le reverse proxy bascule le trafic de blue vers green en un seul geste. Green est désormais en ligne ; blue reste intact en tant que sauvegarde.

Imaginez que vous routez le trafic avec un upstream Nginx. La bascule ressemble grosso modo à ceci :

upstream app {
    # server 127.0.0.1:8001;  # blue (ancien)
    server 127.0.0.1:8002;    # green (nouveau)
}

Une fois la configuration modifiée et la commande nginx -s reload exécutée, les nouvelles requêtes vont vers green. Si quelque chose casse, restaurer les lignes et recharger vous donne un rollback instantané, car l'ancien environnement est toujours debout.

Comment fonctionne le déploiement rolling ?

Le déploiement rolling est conçu pour les environnements où vous faites tourner plusieurs copies (instances) de la même application. Au lieu de mettre à jour toutes les copies en même temps, vous les rafraîchissez séquentiellement par groupes. Si vous avez quatre copies, par exemple : vous en retirez une du trafic, déployez la nouvelle version, la réintégrez au pool une fois les contrôles de santé passés, puis passez à la suivante. Lorsque le processus se termine, toutes les copies sont sur la nouvelle version et le système n'est jamais totalement hors service.

Kubernetes propose ce modèle nativement. Lorsque vous mettez à jour un Deployment, la stratégie par défaut est déjà le rolling :

spec:
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxUnavailable: 1
      maxSurge: 1

Ici, maxUnavailable définit combien de pods peuvent être indisponibles à la fois, tandis que maxSurge définit combien de pods supplémentaires peuvent être créés temporairement. Ces deux valeurs vous permettent d'ajuster l'équilibre entre vitesse et sécurité de capacité.

Les deux stratégies côte à côte

Pour voir clairement les différences, comparons les dimensions essentielles :

• Consommation de ressources : le blue-green exige deux environnements complets, soit un coût d'infrastructure temporairement doublé. Le rolling utilise votre capacité existante et ne demande qu'une petite marge.
• Vitesse de rollback : avec le blue-green, le retour est instantané ; rebasculer le trafic vers l'ancien environnement suffit. Avec le rolling, vous devez lancer un nouveau déploiement en sens inverse, ce qui prend du temps.
• Fenêtre de versions mixtes : pendant une mise à jour rolling, l'ancienne et la nouvelle version restent en ligne simultanément pendant un certain temps. Les changements d'API ou de base de données non rétrocompatibles peuvent donc poser problème.
• Simplicité : le rolling est généralement intégré aux outils d'orchestration. Le blue-green demande un peu plus de configuration côté routage et gestion des environnements.

La base de données : la vraie partie difficile

Dans les deux stratégies, l'écueil le plus fréquent concerne les changements de schéma de base de données. Rappelez-vous que l'ancien et le nouveau code écriront dans la même base pendant un certain temps. C'est pourquoi écrire des migrations rétrocompatibles est indispensable. La règle pratique est : ajouter d'abord la colonne, mettre à jour le code, puis supprimer l'ancienne colonne ; ne jamais supprimer une colonne et modifier le code en une seule étape.

Par exemple, si vous voulez renommer une colonne, suivez un chemin en trois phases au lieu d'un simple RENAME : ajoutez la nouvelle colonne, déployez du code qui alimente les deux colonnes, puis supprimez l'ancienne colonne lors d'un déploiement ultérieur. Cette approche empêche les versions qui se chevauchent de se casser mutuellement pendant la livraison.

Laquelle choisir, et quand ?

Il n'y a pas de réponse unique ; cela dépend du contexte. Le blue-green est idéal quand le rollback instantané est critique, pour des versions risquées, et lorsque vous pouvez assumer temporairement l'infrastructure supplémentaire. Le rolling est plus naturel pour les équipes qui font tourner de nombreuses instances, veulent maîtriser les coûts et écrivent déjà des changements rétrocompatibles. De nombreuses équipes matures combinent les deux : l'approche canary, qui dirige un petit pourcentage du trafic vers la nouvelle version, est en réalité une variation prudente du rolling, et peut se mêler à la sécurité du blue-green.

Questions fréquentes

Le déploiement blue-green signifie-t-il un coût doublé ?

Au moment de la bascule, oui, les deux environnements tournent en même temps. Mais cela ne dure généralement que pendant la fenêtre de déploiement ; une fois la bascule terminée, vous pouvez réduire l'ancien environnement ou l'éteindre jusqu'à la prochaine version. Dans le cloud, la facturation à la minute maintient souvent ce surcoût à un niveau bas.

Un petit projet a-t-il vraiment besoin de ces stratégies ?

Pour un projet personnel à faible trafic, la simple méthode « arrêter-mettre à jour-redémarrer » peut suffire. Mais dès que vos utilisateurs commencent à remarquer l'interruption, il vaut la peine de passer au moins à un flux réversible avec contrôles de santé.

Le déploiement canary remplace-t-il ces approches ?

Le canary n'est pas une alternative mais un complément. Vous exposez la nouvelle version à une petite tranche de trafic, surveillez les métriques et l'élargissez progressivement s'il n'y a pas de problème. Il se construit généralement par-dessus une base rolling ou blue-green.

Vous voulez mettre en place le bon flux de déploiement pour votre projet ? Qu'il s'agisse d'un pipeline de livraison sans interruption ou d'une stratégie de migration sûre, planifions-le ensemble. Contactez-moi et discutons de la solution adaptée à vos besoins.