Votre stratégie de déploiement détermine déjà la difficulté de votre reprise

La plupart des équipes considèrent la reprise après incident comme quelque chose à gérer après une panne. Elles écrivent un script de rollback, conservent une sauvegarde de l'ancien artefact, et espèrent ne jamais en avoir besoin. Mais la vérité, c'est que la partie la plus difficile de la reprise n'est pas le rollback en lui-même. C'est la situation dans laquelle vous vous trouvez lorsque vous réalisez que vous ne pouvez pas revenir en arrière proprement à cause de la façon dont vous avez déployé initialement.

Imaginez ce scénario. Votre équipe pousse une nouvelle version en production. Tous les serveurs sont remplacés d'un coup. L'ancienne version s'arrête, la nouvelle version démarre, tous les utilisateurs sont maintenant sur le nouveau code. Puis les alertes de monitoring se déclenchent. Quelque chose ne va pas. Votre seule option est un rollback complet. Chaque serveur, chaque utilisateur, chaque connexion. Il n'y a pas de terrain d'entente. Vous êtes soit entièrement sur la version défectueuse, soit entièrement sur l'ancienne. Et pendant que vous effectuez ce rollback, chaque utilisateur subit le problème.

Comparez cela à une équipe qui utilise le déploiement blue-green. Ils ont deux environnements identiques. L'un est en production et sert les utilisateurs. L'autre a la nouvelle version prête. Quand il est temps de publier, ils basculent simplement le trafic de l'environnement bleu vers le vert. Si quelque chose tourne mal, ils rebasculent le trafic. L'ancien environnement est toujours en cours d'exécution. Le rollback prend quelques secondes. Pas de changement de code, pas de changement de configuration, pas d'attente qu'un pipeline se termine.

La différence ne réside pas dans le fait d'avoir un meilleur script de rollback. La différence réside dans le choix d'une stratégie de déploiement qui limite le rayon d'explosion avant que quoi que ce soit ne tourne mal.

Le déploiement blue-green rend la reprise quasi instantanée

Le déploiement blue-green n'est pas seulement un motif élégant pour des releases sans temps d'arrêt. C'est un mécanisme de reprise déguisé en stratégie de déploiement. L'idée clé est de maintenir l'ancien environnement en fonctionnement jusqu'à ce que vous soyez sûr que le nouveau fonctionne. Si la nouvelle version échoue, vous n'avez pas besoin de reconstruire quoi que ce soit. Vous redirigez simplement le trafic vers l'ancien environnement.

Cela fonctionne bien pour les applications sans état où l'environnement n'est que calcul et configuration. Mais cela devient plus délicat lorsque vous avez des changements de schéma de base de données. Si la nouvelle version exécute une migration qui modifie la structure de la base de données, l'ancienne version pourrait ne pas fonctionner avec le nouveau schéma. Dans ce cas, rebasculer le trafic ne suffit pas. Vous devez également annuler la migration de la base de données, ce qui prend du temps et comporte ses propres risques.

Voici une configuration minimale de Service Kubernetes qui rend le basculement possible. Le sélecteur pointe vers l'environnement actif, et le changer de blue à green (ou l'inverse) redirige tout le trafic instantanément.

apiVersion: v1
kind: Service
metadata:
  name: my-app
spec:
  selector:
    app: my-app
    environment: blue   # basculer sur 'green' pour faire un rollback
  ports:
    - protocol: TCP
      port: 80
      targetPort: 8080

Lorsque la nouvelle version échoue, vous mettez à jour le sélecteur avec environment: green et appliquez le changement. Pas de reconstruction, pas d'attente de pipeline — juste une mise à jour d'un seul champ.

La conclusion pratique est que le déploiement blue-green vous offre une voie de rollback rapide, mais seulement si vous maintenez l'ancien environnement compatible avec l'état actuel de la base de données. Si vous ne pouvez pas garantir cela, votre rollback n'est pas instantané. Il est simplement plus rapide que de reconstruire à partir de zéro.

Le déploiement canary limite le nombre d'utilisateurs impactés

Le déploiement canary adopte une approche différente. Au lieu de basculer tout le trafic d'un coup, vous envoyez un petit pourcentage d'utilisateurs vers la nouvelle version. Peut-être cinq pour cent. Si ce groupe ne montre aucun problème, vous augmentez le pourcentage progressivement jusqu'à ce que tous les utilisateurs soient sur la nouvelle version.

L'avantage en termes de reprise est évident. Si la nouvelle version a un problème, seuls cinq pour cent des utilisateurs sont affectés. Vous pouvez arrêter le canary, renvoyer ces utilisateurs vers l'ancienne version, et enquêter sur le problème sans pression pour tout réparer immédiatement. Le rayon d'explosion est petit par conception.

Le déploiement canary fonctionne bien lorsque vous avez suffisamment de trafic pour détecter les problèmes dans le petit groupe et lorsque votre infrastructure peut gérer l'exécution de deux versions côte à côte. Il nécessite également une bonne observabilité. Vous devez comparer les taux d'erreur, la latence et le comportement des utilisateurs entre le groupe canary et le groupe de contrôle. Sans cela, vous ne faites que deviner si la nouvelle version peut être déployée plus largement.

Le compromis est la complexité. Vous avez besoin d'une logique de routage du trafic, d'une surveillance capable de comparer des groupes, et d'un processus pour décider quand augmenter le pourcentage du canary. Mais pour les équipes qui livrent fréquemment et ne peuvent pas se permettre des rollbacks complets, la complexité en vaut la peine.

Les feature flags permettent une reprise sans déploiement

Les feature flags fonctionnent différemment des autres stratégies. Au lieu de déployer une nouvelle version pour contrôler qui la voit, vous déployez le nouveau code pour tout le monde mais le cachez derrière un interrupteur. Le code est déjà en production. Il n'est simplement pas encore actif pour les utilisateurs. Vous activez l'interrupteur pour un petit groupe, surveillez les résultats, puis élargissez progressivement l'audience.

Si quelque chose tourne mal, vous désactivez l'interrupteur. Pas de rollback, pas de correctif urgent, pas d'attente d'un pipeline. La reprise se produit en quelques secondes avec un simple changement de configuration. C'est l'approche la plus chirurgicale pour limiter le rayon d'explosion. Vous pouvez activer une fonctionnalité d'abord pour les utilisateurs internes, puis pour les bêta-testeurs, puis pour un pourcentage du trafic de production, et enfin pour tout le monde. À tout moment, vous pouvez désactiver la fonctionnalité instantanément.

Les feature flags sont puissants, mais ils ont leurs propres coûts. Vous avez besoin d'un système pour gérer les flags, d'un processus pour nettoyer les anciens flags, et de la discipline pour éviter la prolifération des flags. Chaque flag dans votre code ajoute une logique conditionnelle qui rend les tests plus difficiles. Si vous ne supprimez jamais les flags après qu'une fonctionnalité est stable, votre codebase devient un labyrinthe de branches mortes.

La vraie valeur des feature flags n'est pas de livrer plus vite. C'est d'avoir un mécanisme de reprise qui ne nécessite aucun déploiement. Cela change le profil de risque de chaque release.

Votre stratégie de déploiement est votre plan de reprise

Voici l'idée centrale qui relie tout cela. Vous ne pouvez pas séparer votre stratégie de déploiement de votre plan de reprise. Les décisions que vous prenez sur la façon de déployer une nouvelle version déterminent les options de reprise dont vous disposez quand quelque chose tourne mal.

Le diagramme ci-dessous montre comment chaque stratégie gère un échec, de la détection à la reprise.

Si vous déployez en remplaçant tous les serveurs d'un coup, votre seule option de reprise est un rollback complet. Si vous utilisez blue-green, vous avez un rebasculement instantané. Si vous utilisez canary, vous limitez le nombre d'utilisateurs affectés. Si vous utilisez des feature flags, vous pouvez désactiver la fonctionnalité problématique sans toucher au pipeline de déploiement.

Chaque stratégie a des compromis. Le blue-green nécessite le double de l'infrastructure. Le canary nécessite une bonne surveillance et un routage du trafic. Les feature flags nécessitent un système de gestion des flags et une discipline de nettoyage. Mais toutes sont meilleures que de n'avoir aucune stratégie et d'espérer que le script de rollback fonctionne quand vous en avez besoin.

Les équipes qui récupèrent le plus rapidement ne sont pas celles qui ont les meilleurs scripts de rollback. Ce sont celles qui ont conçu leur processus de déploiement pour faciliter la reprise dès le départ.

Liste de vérification rapide pour votre prochain déploiement

• Pouvez-vous faire un rollback sans changer de code ni de configuration ?
• Combien d'utilisateurs seront affectés si la nouvelle version échoue ?
• Pouvez-vous tester la nouvelle version en production sans exposer tous les utilisateurs ?
• Avez-vous un moyen de désactiver une fonctionnalité spécifique sans redéployer ?
• Votre ancien environnement est-il toujours en cours d'exécution et compatible avec la base de données actuelle ?

Si vous avez répondu non à la plupart de ces questions, votre prochaine reprise sera plus difficile qu'elle ne devrait l'être.

Ce que cela signifie pour votre équipe

La prochaine fois que vous planifiez un déploiement, ne pensez pas seulement à comment mettre la nouvelle version en production. Pensez à comment vous la retirerez si quelque chose tourne mal. Choisissez une stratégie qui vous donne des options. Vous-même dans le futur, debout devant un tableau de bord plein d'alertes rouges, vous remerciera.