Comprendre les stratégies de déploiement progressif (blue-green, canary) et savoir préparer un plan de retour en arrière fiable avant toute mise en production.
Avoir vu les fiches précédentes sur le déploiement de service et les tests d'intégration/acceptation. Notions de base en conteneurisation (Docker) utiles mais non obligatoires.
Aucun déploiement n'est garanti à 100 % sans risque, même après des tests rigoureux : un comportement imprévu peut n'apparaître qu'en conditions réelles de production. Un plan de retour en arrière (rollback) documenté permet de revenir rapidement à la version stable précédente, plutôt que de tenter de corriger en urgence sur un service déjà en panne.
Deux environnements de production identiques coexistent : « bleu » (la version actuelle, qui reçoit tout le trafic) et « vert » (la nouvelle version, déployée et testée en parallèle, sans trafic réel). Une fois la version verte validée, le trafic bascule instantanément vers elle. En cas de problème, revenir au bleu est immédiat puisqu'il est resté disponible et inchangé.
| Avantage | Limite |
|---|---|
| Rollback quasi instantané (simple bascule) | Nécessite de doubler temporairement l'infrastructure |
| Validation possible en conditions réelles avant bascule | Les migrations de base de données restent délicates à gérer entre les deux versions |
Plutôt qu'une bascule totale, la nouvelle version n'est exposée qu'à une petite fraction du trafic réel (ex: 5 % des utilisateurs), pendant que la majorité continue d'utiliser la version stable. Si aucune anomalie n'est détectée, la part de trafic dirigée vers la nouvelle version augmente progressivement jusqu'à 100 %.
Exemple de progression d'un déploiement canary : Étape 1 : 5 % du trafic vers la nouvelle version → surveillance des erreurs Étape 2 : 25 % du trafic vers la nouvelle version → surveillance des erreurs Étape 3 : 50 % du trafic vers la nouvelle version → surveillance des erreurs Étape 4 : 100 % du trafic vers la nouvelle version → ancienne version retirée
Les instances de l'application (ex: plusieurs conteneurs derrière un répartiteur de charge) sont remplacées une par une par la nouvelle version, en gardant toujours une partie des instances disponibles. C'est la stratégie par défaut de nombreux orchestrateurs (Docker Swarm, Kubernetes).
| Stratégie | Granularité de la bascule | Complexité de mise en place |
|---|---|---|
| Blue-green | Bascule totale et instantanée | Moyenne (double infrastructure) |
| Canary | Progressive, par pourcentage de trafic | Élevée (nécessite un routage fin du trafic) |
| Rolling update | Progressive, instance par instance | Faible à moyenne (souvent natif aux orchestrateurs) |
Le choix dépend des contraintes réelles du projet : criticité du service, budget infrastructure disponible, outillage déjà en place, et capacité de l'équipe à surveiller un déploiement progressif en temps réel.
| Contexte | Stratégie souvent adaptée |
|---|---|
| Service critique, budget infrastructure suffisant | Blue-green |
| Grand nombre d'utilisateurs, besoin de détecter les bugs progressivement | Canary |
| Petite structure, orchestrateur de conteneurs déjà en place | Rolling update |
| Projet pédagogique ou environnement de test simple | Sauvegarde + redéploiement manuel suffisant, sans stratégie avancée |
✅ Réponse : Un comportement imprévu peut n'apparaître qu'en conditions réelles de production
✅ Réponse : Faire coexister deux environnements identiques et basculer le trafic instantanément vers le nouveau
✅ Réponse : Une exposition progressive de la nouvelle version à une part croissante du trafic
✅ Réponse : Rolling update
✅ Réponse : Une sauvegarde de la version précédente avec un script de redéploiement testé