Progressive delivery chez Bedrock — Argo Rollouts pour 50+ équipes produit

TL;DR

Chez Bedrock Streaming (20M+ viewers hebdomadaires, 1000+ nœuds Kubernetes), j’ai déployé Argo Rollouts comme framework standard de progressive delivery pour 50+ équipes produit. Des gates basés sur des métriques (Apdex, taux d’erreur, KPIs métiers) ont remplacé les simples health checks, avec des contributions upstream pour supporter KEDA et Gloo Gateway.

Contexte

Les déploiements chez Bedrock ont un impact direct sur des utilisateurs payants, souvent en temps réel. Le trafic varie énormément selon les horaires et les événements, et ne ressemble pas du tout à celui du staging.

Avant ce projet, les déploiements reposaient sur GitHub Actions et des templates maison accumulés au fil des années. Ils fonctionnaient, mais étaient devenus très fragiles. Chaque équipe avait des besoins spécifiques. Chaque modification risquait de casser le pipeline de quelqu’un d’autre.

Le seul vrai garde-fou était le health check Kubernetes. Si le pod était Ready, le déploiement était considéré comme bon. Mais un pod peut être « healthy » tout en renvoyant des 5xx sur un endpoint critique ou en ajoutant 200 ms de latence.

Résultat : les problèmes apparaissaient lentement en production, les dashboards s’allumaient, le support remontait des tickets, et l’équipe plateforme devait coordonner le rollback.

Ce modèle ne tenait plus à cette échelle.

Contraintes

• Utilisateurs réels, pas de fenêtre de déploiement « safe ».
• Les équipes restent responsables de leurs releases.
• Stack réseau non standard : Gloo au lieu de NGINX.
• Usage de KEDA pour l’autoscaling événementiel.
• 1000+ nœuds opérés par une petite équipe.
• Workloads variés : stateless, stateful, workers, migrations complexes.

Décision

On a découplé le déploiement du CI.

ArgoCD pour le GitOps. Argo Rollouts pour la stratégie de déploiement.

Objectifs :

1. Retirer l’équipe plateforme du babysitting quotidien.
2. Redonner la responsabilité de la stratégie de release aux équipes produit.

Ce que j’ai construit

Librairie Helm

Des templates Helm avec des defaults intelligents :

• Canary par défaut pour les services HTTP stateless
• Blue/green pour les services avec session en mémoire
• Rolling update + monitoring de lag pour les workers

Gates basés sur des métriques

AnalysisTemplates connectés à :

• New Relic (Apdex)
• Taux de 5xx avec seuils progressifs
• Success rate
• Temps de réponse
• KPIs métiers optionnels

On couvre : pod OK, réponses OK, expérience utilisateur OK.

Pattern de canary

5% → 25% → 50% → 100% avec des pauses de 10 minutes et des seuils de plus en plus stricts.

Discipline pour le stateful

• Expand & contract pour les schémas
• Pas de canary pour les bases
• Blue/green pour les sessions
• Monitoring du lag pour les workers

Le problème Gloo + KEDA

Argo Rollouts ne gérait pas correctement notre stack réseau. J’ai contribué au plugin Gateway API pour permettre :

• La découverte dynamique des routes via labels
• Le support HTTPRoute, GRPCRoute, TCPRoute
• La gestion automatique des poids pendant le canary

Cela a évité un fork interne.

Onboarding

Migration progressive : staging, sessions accompagnées, puis production.

Résultat

Le vrai cas où ça a tout changé

Une régression sur un endpoint critique. Le canary à 5% a fait chuter l’Apdex en quelques minutes. Rollout automatiquement abort. 95% du trafic servi par la version stable.

Sans ça, déploiement global.

Le faux positif

Rollback causé par une dépendance upstream dégradée.

Leçon :

Un gate de canary doit mesurer la qualité du changement déployé, pas la santé de tout le call graph.

Résultats concrets

• 50+ équipes en progressive delivery
• Équipe plateforme sortie du chemin critique
• Contributions upstream
• Playbook clair pour les workloads stateful

Ce que je ferais différemment

J’ajouterais dès le jour 1 l’observabilité des gates (notifications Slack avec les métriques exactes et les seuils).

---

← Toutes les études de cas