1.6 KiB
1.6 KiB
title, created, updated, type, tags, confidence, contested, sources
| title | created | updated | type | tags | confidence | contested | sources | ||||
|---|---|---|---|---|---|---|---|---|---|---|---|
| Déploiement Canary | 2026-06-06 | 2026-06-06 | concept |
|
high | false |
|
🐤 Déploiement Canary
Définition Courte
Stratégie qui déploie progressivement une nouvelle version à un petit pourcentage d'utilisateurs (les "canaris"), surveille les métriques, puis étend si tout va bien.
Explication Détaillée
Étapes typiques :
- Déployer la v2 sur 1% du parc.
- Surveiller pendant X minutes (erreurs, latence, CPU).
- Si OK, étendre à 10%, 25%, 50%, 100%.
- Si problème à une étape, rollback instantané.
- Une fois à 100%, décommissionner la v1.
Critères d'analyse :
- Taux d'erreur 5xx.
- Latence p95/p99.
- Métriques métier (conversion, rétention).
- CPU/RAM inhabituel.
Comparaison :
- Blue-Green : tout bascule d'un coup.
- Canary : bascule progressive, plus granulaire.
- Feature Flags : contrôle par user, pas par % global.
Cas d'Usage
- Apps à fort trafic où un bug toucherait beaucoup d'utilisateurs.
- Refonte majeure (changement d'architecture).
- Modèles ML (peut-être que la nouvelle version dégrade la qualité).
Outils Liés
- Kubernetes : Argo Rollouts, Flagger.
- Istio : traffic shifting basé sur poids.
- AWS CodeDeploy, Google Cloud Deploy.
- LaunchDarkly, Flagsmith (feature flag services).
Pages Liées
Questions Ouvertes
- Combien de temps faut-il observer à chaque étape ?
- Comment choisir le critère de promotion automatique vs manuel ?