Déploiement progressif : réduire le risque sans adopter Kubernetes
Canary, blue-green et feature flags : choisir un déploiement progressif adapté à son stack pour limiter les incidents sans complexité inutile.
Vous n’avez pas besoin de Kubernetes, d’un service mesh ni d’une plateforme dédiée pour déployer progressivement. Limitez l’exposition d’une version, observez son effet, puis revenez en arrière avec un mécanisme déjà testé.
Choisissez l’option compatible avec votre architecture et vos capacités réelles d’observation. Un pipeline validé ne couvre pas toujours les vraies données, les dépendances tierces, la charge ou les parcours peu fréquents : le déploiement progressif réduit donc le nombre d’utilisateurs affectés par un défaut.
Choisir le mécanisme adapté
Utilisez un canary si vous pouvez exécuter deux versions et répartir le trafic entre elles. Un load balancer, un reverse proxy, ou un CDN proposant du traffic splitting peut suffire ; assurez-vous surtout de distinguer les métriques de chaque version.
Évitez cette approche si les sessions sont difficiles à répartir, si les écritures en base sont incompatibles entre versions ou si aucun signal fiable n’est disponible peu après le déploiement. Un canary est alors une exposition limitée, mais pas une validation exploitable.
Choisissez le blue-green si vous pouvez maintenir deux environnements capables de servir l’application et basculer rapidement le trafic. Deux groupes d’instances, des slots de déploiement ou deux environnements PaaS conviennent ; Azure App Service documente par exemple les deployment slots.
Cette bascule ne rend pas une migration de données irréversible. Les deux versions doivent pouvoir cohabiter pendant le changement, ou la migration doit suivre une stratégie séparée et réversible.
Employez un feature flag pour livrer du code sans activer immédiatement une fonction. Il permet une activation par équipe, compte, segment ou pourcentage d’utilisateurs, sans redéploiement ; Unleash, LaunchDarkly et des outils internes peuvent la piloter.
Un flag convient aux changements de comportement applicatif, pas à une image défaillante, une dépendance absente ou une erreur d’infrastructure. Donnez à chaque flag temporaire un propriétaire et une date de suppression afin d’éviter des branches permanentes dans le code.
Définir l’observation et le retour arrière
Fixez la règle de rollback avant le déploiement : métrique, valeur habituelle, fenêtre d’observation, seuil et action. Suivez notamment les erreurs HTTP 5xx ou métier, la latence des requêtes importantes, les échecs de parcours critiques, ainsi que la saturation des ressources et les erreurs de dépendances.
Vous pouvez arrêter un canary si son taux d’erreurs dépasse celui de la version stable durant une fenêtre définie, ou si un parcours critique échoue. Le seuil doit s’appuyer sur la baseline du service ; un chiffre générique ne protège pas votre application.
Le rollback doit être court et connu : remettre la pondération à zéro, rebascule du load balancer, redéploiement de l’image précédente ou désactivation du flag. Testez cette procédure lors d’un exercice contrôlé : un retour arrière jamais exécuté reste une hypothèse.
Commencer simplement
Commencez avec un service stateless et un changement à risque modéré. Validez d’abord la boucle complète : déployer deux versions ou isoler une fonction, observer les métriques, puis revenir à l’état précédent sans intervention manuelle complexe.
- Avec deux cibles derrière un répartiteur, adoptez un canary à trafic limité.
- Avec deux environnements et une bascule de cible, de slot ou de load balancer, adoptez le blue-green.
- Pour une fonction métier isolable, commencez par un feature flag.
- Si vous ne pouvez ni mesurer ni annuler rapidement, améliorez d’abord logs, métriques et procédure de rollback.
GitHub Actions, GitLab CI/CD, Jenkins ou un script peuvent orchestrer cette séquence sans connaître Kubernetes. Journalisez la version déployée et l’heure de chaque étape pour relier les alertes au changement ; cette approche complète un pipeline CI/CD fiable sans usine à gaz.