1. Blue/Green + Canary : deux concepts, un objectif commun

a) Blue/Green Deployment

Le Blue/Green Deployment consiste à faire cohabiter deux versions complètes d’un site web (une “active”, une “candidate”) sur deux instances distinctes. Cela permet de basculer d’un environnement à l’autre instantanément.

• Blue : l’environnement actuellement en production
• Green : la nouvelle version candidate

Le basculement entre les deux se fait instantanément, sans downtime, en changeant simplement le routage.

b) Canary Release

Le Canary Release consiste à exposer la nouvelle version à un sous-ensemble d’utilisateurs réels. Cela permet de détecter d’éventuels bugs ou ralentissements en conditions de production, tout en limitant leur impact.

c) Pourquoi combiner les deux ?

En les combinant, on bénéficie :

• D’un environnement de test réel (production live, vraies données)
• D’une progressivité dans le déploiement
• D’une possibilité de rollback immédiat
• Architecture technique mise en place
• Routage dynamique avec Traefik

2. Architecture

a) Traefik pour le routage dynamique

Nous utilisons Traefik en mode “watch”, capable de détecter dynamiquement les services et de router selon des règles définies :

• X-Canary: true ou IP autorisée → version Canary
• X-Stable: true → version stable
• Aucun en-tête → routage par load balancer avec stickiness par cookie et répartition progressive du trafic

Chaque instance expose un endpoint /api/health vérifié toutes les 5 secondes. Si l’instance échoue à ces checks, elle est automatiquement exclue du trafic.

b) Intégration continue avec Jenkins

Notre pipeline Jenkins automatise toutes les étapes :

• Build de la nouvelle version
• Déploiement sur l’instance libre (Blue ou Green)
• Démarrage via PM2
• Exposition restreinte via routage Canary

Le shift progressif est ensuite déclenché manuellement après validation, avec la possibilité de rollback instantané.

3. Les bénéfices

a) Pour la QA

• Tests sur environnement réel
• Détection précise des erreurs d’intégration

b) Pour les développeurs

• Livraison anticipée
• Vérification rapide de la stabilité en production

c) Pour les DevOps

• Préparation en amont
• Contrôle total du trafic
• Rollback sans friction

d) Pour les clients

• Accès anticipé à la nouvelle version
• Choix du moment exact pour la bascule
  

4. Mise en situation : un cas réel de production

Prenons un exemple :

• La version v1.3 est déployée sur l’instance "Green" par Zento
• L’équipe QA de Zento et le client la testent pendant 2 jours avec X-Canary: true
• Après validation, un script de shift est lancé
• Le trafic réel est dirigé progressivement vers cette version : 10%, 30%, 60%, 100%
• En cas d’erreur ou de ralentissement → rollback immédiat vers l’environnement "Blue"

Cette stratégie permet une validation progressive, tout en maintenant une expérience utilisateur optimale.

5. Bonnes pratiques à respecter

Maintenir deux versions actives en parallèle demande de la rigueur :

• Évolutions compatibles (pas de changements destructifs dans les modèles)
• Caches isolés entre versions pour éviter les effets de bord
• Tracking différencié : ne pas mélanger les metrics canary et stable
• Gestion des écritures sensibles (transactions, bases de données partagées)
  
  

Conclusion

La combinaison Blue/Green + Canary permet à Zento de proposer des mises en production modernes, progressives et sécurisées, tout en gardant le contrôle sur chaque étape. Ce modèle améliore la qualité logicielle, réduit les risques et aligne toutes les parties prenantes (dev, QA, client) autour d’une même vision : livrer mieux, sans rupture.