Blue-green vs canary : sécuriser les changements d'API et de base de données

Pourquoi les déploiements deviennent risqués avec des changements de schéma et des mises à jour mobiles lentes

Un déploiement peut sembler parfait en tests et pourtant échouer dès qu'il reçoit du vrai trafic. La raison la plus courante est que votre code n'est pas la seule chose qui change. Votre contrat d'API et le schéma de votre base de données évoluent aussi, et rarement au même rythme.

Les choses cassent quand différentes parties du système ne sont pas d'accord sur ce que signifie « correct ». Un backend récent attend une colonne qui n'existe pas encore. Un backend plus ancien écrit des données dans un format que le nouveau code ne comprend plus. Même de petits changements comme renommer un champ, durcir une validation ou modifier une valeur d'énumération peuvent provoquer des erreurs en production.

Les applications mobiles augmentent les enjeux parce que les anciennes versions restent en circulation. Certains utilisateurs mettent à jour en quelques minutes, d'autres en semaines. Cela signifie que votre backend doit servir plusieurs générations de clients en même temps. Si vous publiez un changement d'API qui fonctionne uniquement avec la dernière app, vous pouvez casser le paiement, l'onboarding ou la synchronisation en arrière-plan pour une partie des utilisateurs sans vous en rendre compte immédiatement.

« Risque de downtime » ne signifie pas seulement le site indisponible. Dans les systèmes réels, cela se manifeste souvent par des pannes partielles :

• un pic d'erreurs 4xx/5xx sur certains endpoints alors que le reste semble normal
• des connexions qui échouent parce que tokens, rôles ou enregistrements utilisateurs ne correspondent plus aux attentes
• des problèmes de données silencieux (mauvaises valeurs par défaut, textes tronqués, relations manquantes) qui n'apparaissent que plusieurs jours plus tard
• des jobs en arrière-plan bloqués qui forment une file d'attente longue à résorber

C'est pourquoi les équipes comparent blue-green vs canary : l'objectif est de réduire le rayon d'impact quand les changements ne sont pas parfaitement compatibles.

Blue-green et canary en clair

Quand on compare blue-green vs canary, la question centrale est généralement : préférez-vous une bascule globale et contrôlée, ou un test prudent et progressif ?

Blue-green : deux versions complètes et un basculement de trafic

Blue-green signifie faire tourner deux environnements complets en parallèle. « Blue » est la version actuelle qui sert les utilisateurs. « Green » est la nouvelle version, déployée et testée en parallèle. Quand vous êtes prêts, vous basculez le trafic de blue vers green.

Cette approche est excellente pour la prévisibilité. Vous pouvez valider la nouvelle version avec des réglages proches de la production avant qu'elle ne serve de vrais utilisateurs, puis faire une seule coupure propre.

Le rollback est aussi simple : si quelque chose casse après la bascule, renvoyez le trafic vers blue. C'est proche d'un retour instantané, mais les caches, les jobs en arrière-plan et les changements de données peuvent compliquer la récupération.

Canary : lancer d'abord un petit pourcentage du trafic

Canary signifie que la nouvelle version est active pour une petite fraction d'utilisateurs ou de requêtes au début. Si tout va bien, vous augmentez ce pourcentage par paliers jusqu'à couvrir tout le trafic.

Canary est préférable quand vous craignez des comportements inconnus sous trafic réel. Vous pouvez attraper les problèmes tôt, avant que la majorité des utilisateurs en soit affectée.

Le rollback consiste à réduire le pourcentage canary à zéro (ou à cesser le routage vers la nouvelle version). C'est généralement rapide, mais pas toujours propre, car certains utilisateurs ont peut-être déjà créé des données ou un état que les deux versions doivent gérer.

Une façon simple de retenir les différences :

• Blue-green favorise des coupures propres et des retours rapides.
• Canary favorise l'apprentissage depuis le trafic réel avec un rayon d'impact limité.
• Aucun des deux ne résout automatiquement le risque côté base de données. Si les changements de schéma ne sont pas compatibles, les deux peuvent échouer.
• Canary dépend de la surveillance parce que vous décidez à partir de signaux vivants.
• Blue-green demande souvent de la capacité supplémentaire car vous faites tourner deux stacks complets.

Exemple : si vous publiez une API qui renvoie parfois un nouveau champ, un canary vous aide à voir si d'anciens clients plantent en recevant des données inattendues. Si le changement nécessite de renommer une colonne que l'ancien code ne sait pas gérer, blue-green ne vous sauvera que si la migration du schéma est conçue pour supporter les deux versions.

Ce qui rend les migrations de base de données différentes des déploiements de code

Un déploiement de code est en général facile à rollbacker. Si la nouvelle version se comporte mal, vous redéployez l'ancienne build et vous retrouvez la situation précédente.

Un changement de base de données est différent parce qu'il transforme la forme des données. Une fois que des lignes sont réécrites, des colonnes supprimées ou des contraintes durcies, revenir en arrière n'est rarement instantané. Même si vous rollbackez le code applicatif, il pourrait ne pas comprendre le nouveau schéma.

C'est pourquoi le risque de downtime lors d'une migration de schéma dépend moins de la méthode de déploiement et plus de la manière dont la migration est conçue.

Principes de base des migrations en ligne

Les migrations les plus sûres fonctionnent pendant que les anciennes et nouvelles versions tournent simultanément. Le modèle est simple : faites d'abord un changement qu'on peut ignorer, mettez à jour le code pour l'utiliser, puis nettoyez plus tard.

Une séquence commune « étendre-puis-réduire » ressemble à ceci :

• Changements additifs d'abord : ajouter une colonne nullable, une nouvelle table, un index sans verrouiller les écritures.
• Comportement dual : écrire à la fois dans l'ancien et le nouveau, ou lire depuis le nouveau avec un fallback sur l'ancien.
• Backfill séparé : migrer les données existantes par petits lots.
• Basculement : déplacer la majorité du trafic vers le nouveau comportement.
• Changements destructifs en dernier : supprimer les anciennes colonnes, retirer les anciens chemins de code, durcir les contraintes.

Les migrations « big bang » combinent les étapes les plus risquées dans une seule release : verrous longs, backfills lourds et code qui suppose que le nouveau schéma est déjà présent partout.

Pourquoi les mises à jour mobiles lentes élèvent la barre

Les clients mobiles peuvent rester sur d'anciennes versions pendant des semaines. Votre backend doit continuer d'accepter d'anciennes requêtes et de produire d'anciennes réponses pendant que la base évolue.

Si une ancienne app envoie une requête sans un nouveau champ, votre serveur ne peut pas soudainement rendre ce champ obligatoire dans la base. Vous avez besoin d'une période où les deux comportements fonctionnent.

Quelle stratégie réduit le risque de downtime pour les migrations de schéma

Le choix le plus sûr dépend moins de l'outil de déploiement que d'une question : les anciennes et nouvelles versions de l'app peuvent-elles fonctionner correctement sur le même schéma de base de données pendant un certain temps ?

Si la réponse est oui, blue-green est souvent l'option la moins sujette à downtime. Vous pouvez préparer le changement de base, garder le trafic sur l'ancien stack, puis basculer d'un coup vers le nouveau. Si quelque chose cloche, vous revenez rapidement.

Blue-green échoue toutefois lorsque la nouvelle app exige le nouveau schéma immédiatement. Exemples courants : suppression ou renommage d'une colonne que l'ancienne version lit, ou ajout d'une contrainte NOT NULL avant que l'app n'écrive la valeur. Dans ces cas, le rollback peut être dangereux car la base est déjà incompatible.

Canary est préférable quand vous avez besoin d'apprendre de la production de manière contrôlée. Une petite fraction du trafic touche la nouvelle version en premier, ce qui vous aide à repérer des cas limites comme des index manquants, des schémas de requête imprévus ou des jobs d'arrière-plan se comportant différemment sous charge réelle. Le compromis est que vous devez maintenir les deux versions compatibles en parallèle, ce qui implique généralement des changements de schéma rétrocompatibles.

Règle pratique de décision

• Choisissez blue-green quand vous pouvez garder la modification de schéma additive et compatible, et que vous souhaitez surtout une bascule propre et rapide.
• Choisissez canary quand vous n'êtes pas sûr du comportement en production, ou si vous pensez que des formes de données rares peuvent avoir de l'importance.
• Si la migration force un changement incompatible immédiat, ne choisissez pas entre blue-green et canary : changez de plan vers un modèle étendre-puis-réduire.

À quoi ressemble « compatible » en pratique

Supposons que vous ajoutiez un nouveau champ à une table orders. Une voie sûre : ajouter la colonne nullable, déployer l'app qui l'écrit, backfiller les anciennes lignes, puis appliquer les contraintes plus tard. Dans ce cas, blue-green vous permet une coupure propre, et canary vous donne un avertissement précoce si un chemin de code suppose encore l'ancienne forme.

Comment les mises à jour mobiles lentes influencent le choix de déploiement

Les utilisateurs web rafraîchissent la page. Les utilisateurs mobiles ne le font pas.

Sur iOS et Android, des personnes restent sur d'anciennes versions pendant des semaines ou des mois. Certaines n'actualisent jamais tant que l'app n'impose pas la mise à jour, et d'autres appareils restent hors ligne longtemps. Donc votre client « ancien » appelle toujours vos API bien après que vous ayez livré un nouveau backend. Les anciens clients deviennent des tests permanents de votre compatibilité ascendante.

Cela déplace l'objectif de « déployer sans downtime » vers « maintenir plusieurs générations de clients fonctionnelles en parallèle ». En pratique, le mobile vous pousse souvent vers une pensée de type canary pour les API, même si vous utilisez blue-green pour l'infrastructure.

Changements rétrocompatibles vs versionnement d'API

La plupart du temps, vous voudrez des changements rétrocompatibles parce qu'ils laissent anciens et nouveaux apps partager les mêmes endpoints.

Exemples rétrocompatibles : ajouter des champs, accepter à la fois d'anciens et nouveaux formats de payload, garder les champs de réponse existants, et éviter de changer le sens d'un champ.

Le versionnement d'API devient utile quand le comportement doit changer (pas seulement ajouter des données), ou quand il faut supprimer ou renommer des champs.

Exemple : ajouter un champ optionnel marketing_opt_in est généralement sûr. Changer la façon dont price est calculé généralement ne l'est pas.

Planifier une fenêtre de dépréciation

Si vous devez imposer un changement incompatible, traitez la fin du support comme une décision produit. Une fenêtre de dépréciation utile se mesure par « utilisateurs actifs encore sur de vieilles versions », pas par des jours calendaire.

Séquence pratique :

• Livrer le backend qui supporte à la fois anciens et nouveaux clients.
• Publier la nouvelle app mobile et suivre l'adoption par version.
• Avertir ou restreindre seulement quand les anciennes versions descendent sous un seuil sûr.
• Retirer l'ancien comportement en dernier, avec un plan de rollback.

Étape par étape : un pattern de déploiement sûr pour API + changements de BD

Quand vous changez une API et une base de données en même temps, le plan le plus sûr est souvent en deux ou trois étapes. Chaque étape doit être sûre à déployer seule, même si des utilisateurs gardent une ancienne app pendant des semaines.

Un pattern de rollout qui évite de casser les anciens clients

Commencez par un changement additif en base. Ajoutez des colonnes ou tables, évitez de renommer ou supprimer quoi que ce soit, autorisez les nulls si besoin, et utilisez des valeurs par défaut pour que l'ancien code ne rencontre pas de contraintes soudaines.

Ensuite, publiez du code applicatif qui tolère les deux formes. Les lectures doivent accepter « champ manquant » et « champ présent ». Les écritures doivent continuer d'alimenter l'ancien champ pour l'instant, et optionnellement écrire le nouveau aussi.

Séquence typique :

• Ajouter les nouvelles pièces du schéma (colonnes, tables, index) sans supprimer les anciennes.
• Déployer du code qui lit l'ancien ou le nouveau et ne plante pas sur des nulls.
• Backfiller les lignes existantes par petits lots, puis vérifier les comptes, taux de null et performance des requêtes.
• Basculer le chemin d'écriture vers le nouveau champ, en gardant les lectures en fallback.
• Quand les anciennes versions mobiles se sont significativement réduites, supprimer l'ancien champ et nettoyer le code.

Backfill et vérification : où se cachent les pannes

Les backfills ratent le plus souvent parce qu'ils sont traités comme un simple script. Exécutez-les graduellement, surveillez la charge et vérifiez les résultats. Si le nouveau comportement a besoin d'un index, ajoutez-le avant de changer les lectures ou écritures, pas après.

Exemple : vous ajoutez phone_country_code pour améliorer le formatage. Ajoutez d'abord la colonne (nullable), mettez à jour l'API pour l'accepter tout en restant fonctionnel si elle est absente, backfillez depuis les numéros existants, puis commencez à l'écrire pour les nouvelles inscriptions. Des semaines plus tard, quand les anciennes apps auront disparu, supprimez le chemin de parsing legacy.

Outils qui rendent les deux stratégies plus sûres (sans complexité excessive)

Vous n'avez pas besoin d'une configuration compliquée pour sécuriser blue-green ou canary. Quelques habitudes réduisent les surprises quand les API et les schémas évoluent à des rythmes différents.

Dual-read et dual-write (gardez temporaire)

Dual-write signifie écrire les données à la fois dans l'ancien et le nouveau emplacement pendant la transition (par exemple users.full_name et un nouveau users.display_name). Dual-read signifie lire de l'un ou l'autre, en préférant généralement le nouveau et en retombant sur l'ancien.

Cela vous donne du temps pour les mises à jour lentes des clients, mais cela doit rester une passerelle courte. Décidez comment la retirer, suivez quel chemin est utilisé (nouveau vs fallback) et ajoutez des contrôles basiques pour assurer la consistance des écritures.

Feature flags pour les changements de comportement

Les feature flags permettent de déployer du code sans activer le comportement risqué. Cela aide pour blue-green comme pour canary, car vous pouvez séparer « déployer » et « activer ».

Exemple : déployez le support d'un nouveau champ de réponse, mais conservez la forme ancienne tant que vous n'êtes pas prêts. Puis activez pour un petit groupe, observez les erreurs et montez progressivement. Si quelque chose casse, désactivez le flag sans redeployer.

Mentalité de contract testing (l'API est une promesse)

Beaucoup d'incidents de migration ne sont pas vraiment des « problèmes de base de données ». Ce sont des problèmes d'attentes côté client.

Traitez l'API comme une promesse. Évitez de supprimer des champs ou d'en changer le sens. Rendre les champs inconnus optionnels. Les changements additifs (nouveaux champs, nouveaux endpoints) sont généralement sûrs. Les changements cassants devraient attendre une nouvelle version d'API.

Jobs de migration de données fiables

Les migrations nécessitent souvent un job de backfill pour copier des données, calculer des valeurs ou nettoyer. Ces jobs doivent être monotones et répétables : sûrs à relancer, capables de retry, faciles à tracer et throttlés pour ne pas provoquer de pics de charge.

Erreurs courantes qui provoquent des pannes pendant les migrations

La plupart des pannes de migration surviennent quand une release suppose que tout bouge ensemble : tous les services se déploient simultanément, toutes les données sont propres et tous les clients se mettent à jour rapidement. Les systèmes réels ne fonctionnent pas comme ça, surtout pour le mobile.

Schémas d'échec fréquents :

• Supprimer ou renommer une colonne trop tôt. L'ancien code, les jobs en arrière-plan ou les apps mobiles plus anciennes peuvent encore l'utiliser.
• Supposer que les clients se mettent à jour vite. Les releases mobiles prennent du temps à atteindre tous les utilisateurs.
• Lancer des migrations qui verrouillent de grosses tables en heures de pointe. Un index « simple » peut bloquer les écritures.
• Tester uniquement sur des données propres. La production contient des nulls, formats bizarres, doublons et valeurs legacy.
• Ne pas avoir de vrai plan de rollback pour code et données. « On peut redeployer la version précédente » ne suffit pas si le schéma a changé.

Exemple : vous renommez status en order_status et déployez la nouvelle API. Le web fonctionne. Les anciens clients mobiles envoient encore status, et l'API rejette leurs requêtes, provoquant des échecs de checkout. Si vous avez supprimé la colonne, restaurer le comportement n'est pas instantané.

Un meilleur comportement par défaut : effectuer des changements en petites étapes réversibles, garder les anciens et nouveaux chemins fonctionnels ensemble, et documenter ce que vous ferez si les métriques grimpent (comment rerouter le trafic, quel feature flag désactive le nouveau comportement et comment valider/réparer les données si un backfill échoue).

Checklist rapide avant un déploiement

Juste avant une release, une courte checklist attrape les problèmes qui mènent aux rollbacks nocturnes. Cela compte surtout quand vous changez API et base de données en même temps, et que les mises à jour mobiles sont lentes.

Cinq vérifications qui évitent la plupart des pannes

• Compatibilité : vérifier que les anciennes et nouvelles versions de l'app fonctionnent toutes deux contre le même schéma. Un test pratique : lancer la build de production actuelle contre une base de staging avec la nouvelle migration appliquée.
• Ordre des migrations : s'assurer que la première migration est additive et planifier les changements destructifs (suppression de colonnes, durcissement de contraintes) pour plus tard.
• Rollback : définir le retour le plus rapide. Pour blue-green, c'est rerouter le trafic. Pour canary, c'est renvoyer 100 % vers la version stable. Si le rollback nécessite une autre migration, ce n'est pas simple.
• Performance : mesurer la latence des requêtes après le changement de schéma, pas seulement la correction. Un index manquant peut faire ressembler un endpoint à une panne.
• Réalité client : identifier la plus ancienne version active de l'app mobile qui appelle encore l'API. Si un pourcentage significatif y est encore, planifiez une fenêtre de compatibilité plus longue.

Scénario de sanity check rapide

Si vous ajoutez un champ preferred_language, déployez d'abord le changement de base en nullable. Ensuite, publiez le code serveur qui le lit s'il est présent mais ne l'exige pas. Ce n'est qu'après que la majorité du trafic utilise des apps mises à jour que vous pouvez le rendre requis ou retirer l'ancien comportement.

Exemple : ajouter un champ sans casser les anciennes apps mobiles

Imaginez que vous ajoutez un champ de profil country, et que le produit veut qu'il soit requis. Cela peut casser à deux endroits : les anciens clients peuvent ne pas l'envoyer, et la base peut rejeter les écritures si vous imposez NOT NULL trop tôt.

Une approche plus sûre est de faire deux changements séparés : d'abord ajouter le champ de façon rétrocompatible, puis imposer le « requis » plus tard, une fois que les clients ont rattrapé leur retard.

Avec blue-green

Avec blue-green, vous déployez la nouvelle version à côté de l'ancienne. Vous devez quand même que le changement de base soit compatible avec les deux versions.

Flux sûr :

• déployer la migration (ajouter country en nullable)
• déployer la version green qui accepte l'absence de country et utilise un fallback
• tester les flows clés sur green (inscription, modification de profil, checkout)
• basculer le trafic

Si ça casse, basculez en arrière. L'essentiel est que le retour arrière fonctionne seulement si le schéma supporte encore l'ancienne version.

Avec canary

Avec canary, vous exposez le nouveau comportement API à une petite tranche (souvent 1 % à 5 %) et surveillez les erreurs de validation liées aux champs manquants, la latence et les erreurs serveur inattendues.

Surprise fréquente : les anciens clients envoient des mises à jour de profil sans country. Si l'API le traite immédiatement comme requis, vous verrez des 400. Si la base impose NOT NULL, vous pourriez voir des 500.

Séquence plus sûre :

• ajouter country en nullable (ou avec une valeur sûre par défaut comme "unknown")
• accepter l'absence de country provenant des anciens clients
• backfiller country pour les utilisateurs existants en job d'arrière-plan
• imposer « requis » plus tard (d'abord dans l'API, puis en base)

Après la release, documentez ce que les vieux clients peuvent envoyer et ce que le serveur garantit. Ce contrat écrit évite que le même problème réapparaisse lors de la prochaine migration.

Si vous construisez avec AppMaster (appmaster.io), la même discipline de rollout s'applique même si vous pouvez générer backend, web et apps mobiles natives depuis un seul modèle. Utilisez la plateforme pour livrer d'abord des changements de schéma additifs et une logique d'API tolérante, puis durcissez les contraintes une fois l'adoption suffisante.