Une PME peut préparer deux versions d’une application et déplacer progressivement le trafic entre elles. La méthode blue green simplifie le retour vers la version précédente, à condition de traiter les données, les sessions et les dépendances avec soin.
Comprendre le principe
L’environnement actif reçoit les utilisateurs. L’environnement inactif contient la nouvelle version et peut être vérifié avant la bascule. Le nom des couleurs importe peu, mais la séparation doit être visible dans la configuration, les journaux et les tableaux de bord.
Déployez d’abord l’application inactive avec une version identifiable. Lancez les contrôles techniques puis un parcours fonctionnel avec un jeu de données de test. Les vérifications doivent couvrir authentification, recherche, écriture et appels vers les services externes utilisés en production.
Traiter la compatibilité des données
Une base partagée complique le retour arrière. Si la nouvelle version modifie une table ou un format de message, l’ancienne version doit encore fonctionner pendant la transition. Ajoutez d’abord les champs compatibles, déployez le code qui les utilise, puis retirez l’ancien format lorsque la version précédente n’est plus nécessaire.
Les migrations destructives demandent une sauvegarde vérifiée et un plan distinct. Restaurer une base peut prendre plus de temps que rediriger le trafic. Documentez le temps attendu, les données créées pendant la bascule et la manière de les conserver si vous revenez en arrière.
Choisir une méthode de bascule
Le changement peut se faire avec un routeur, un équilibreur, un service de déploiement ou un réglage DNS. Le DNS dépend du cache des résolveurs, ce qui rend le délai moins prévisible. Un routeur applicatif permet souvent de réduire le trafic vers la nouvelle version, mais il doit être inclus dans les tests.
Avant la bascule, vérifiez les certificats, les règles réseau, les variables d’environnement et les tâches planifiées. Deux environnements actifs peuvent exécuter une tâche de traitement deux fois. Gardez les jobs exclusifs dans un seul environnement ou utilisez un mécanisme de verrouillage explicite.
Observer la première période
Pendant la bascule, comparez les erreurs, la latence et les conversions avec la version précédente. Regardez les logs des appels externes et le nombre de sessions ouvertes. Un service peut sembler sain côté serveur alors qu’une incompatibilité JavaScript bloque une partie des utilisateurs.
Définissez avant l’opération les seuils qui imposent un retour. Un taux d’erreur supérieur au niveau convenu, des paiements en échec ou une file qui augmente rapidement peuvent déclencher la décision. La personne autorisée à revenir en arrière doit être joignable et connaître la commande ou l’action à effectuer.
Tester le retour arrière
Un bouton de bascule n’est pas un plan complet. Répétez l’opération sur la préproduction, puis vérifiez qu’un retour conserve les données utiles et ne réactive pas une tâche déjà exécutée. Mesurez la durée entre la décision et la restauration du trafic.
Conservez les versions, les configurations et les variables nécessaires aux deux environnements. Une image supprimée ou une configuration modifiée après le déploiement peut rendre le retour impossible au moment où il devient nécessaire. Notre article sur le plan de retour arrière avec une base de données complète cette préparation.
Réduire la durée de coexistence
Après validation, retirez les ressources inactives selon une procédure documentée. Gardez les journaux assez longtemps pour comparer les erreurs et confirmer que les tâches prévues ont fonctionné. Vérifiez aussi que les coûts temporaires sont visibles dans le suivi cloud.
La méthode blue green convient surtout quand les environnements peuvent être reproduits et quand l’application accepte une période de compatibilité. Pour une migration plus progressive, un déploiement canary peut exposer une petite part du trafic avant chaque étape. Sky Vaults peut vous aider à cadrer vos déploiements DevOps au Maroc.
Sources : AWS Well-Architected, planifier les changements infructueux, Google Cloud, patterns de déploiement.