Choisir comment déployer une nouvelle version sans casser la production

Vous venez de terminer une nouvelle fonctionnalité. Le code a passé tous les tests, les tests sont verts, l'artefact est prêt. Maintenant se pose la vraie question : comment mettre cette nouvelle version sur le serveur sans mettre vos utilisateurs en colère ?

La réponse la plus simple est d'arrêter le serveur, de remplacer les fichiers et de le redémarrer. Cela fonctionne si votre application est utilisée par une poignée de personnes qui savent qu'une interruption arrive. Mais pour tout ce qui sert de vrais utilisateurs, cette approche casse immédiatement. Les gens voient des pages d'erreur. Les requêtes échouent. La confiance s'effrite.

Le problème central est que vous devez mettre du nouveau code en production pendant que l'ancien code sert encore le trafic. Vous ne pouvez pas tout échanger d'un coup. Vous avez besoin d'une stratégie qui permette de passer d'une version à l'autre sans interrompre le service.

Il existe trois stratégies courantes pour cela : la mise à jour progressive (rolling update), le déploiement bleu/vert (blue/green deployment) et le déploiement canari (canary deployment). Chacune résout le même problème d'une manière différente, et chacune correspond à une situation différente.

Mise à jour progressive : remplacer un serveur à la fois

La mise à jour progressive est la stratégie la plus utilisée. L'idée est simple : au lieu de remplacer tous les serveurs à la fois, vous les remplacez un par un ou par petits lots.

Imaginez que vous ayez dix serveurs qui exécutent votre application. Avec une mise à jour progressive, vous mettez deux serveurs hors ligne, installez la nouvelle version sur ceux-ci, puis les remettez en ligne. Une fois que ces deux-là exécutent la nouvelle version, vous passez aux deux suivants. Vous répétez l'opération jusqu'à ce que les dix serveurs exécutent la nouvelle version.

Le grand avantage ici est que vous n'avez pas besoin de serveurs supplémentaires. Vous réutilisez la même infrastructure. Le coût est minimal car vous ne provisionnez pas d'environnements en double.

Voici à quoi ressemble une mise à jour progressive dans un manifeste de Deployment Kubernetes :

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-app
spec:
  replicas: 10
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 1
      maxUnavailable: 0
  template:
    spec:
      containers:
        - name: app
          image: my-app:2.0.0

Cette configuration garantit qu'un seul nouveau Pod est créé à la fois (maxSurge: 1) et qu'aucun ancien Pod n'est arrêté tant que le nouveau n'est pas prêt (maxUnavailable: 0). La mise à jour progresse pod par pod, en maintenant le service disponible tout au long du processus.

Mais il y a un hic. Pendant la mise à jour, deux versions de votre application s'exécutent en même temps. Certains utilisateurs tombent sur l'ancienne version, d'autres sur la nouvelle. Si le contrat de l'API a changé entre les versions, les requêtes peuvent échouer. Un utilisateur peut envoyer une requête qui est traitée par l'ancien serveur, mais le format de réponse a changé. Ou le nouveau serveur attend un champ que l'ancien client n'envoie pas.

La mise à jour progressive fonctionne bien lorsque les changements sont rétrocompatibles. Si vous ajoutez un champ, pas si vous en supprimez un. Si vous étendez une API, pas si vous changez sa forme. Si vos changements de schéma de base de données sont additifs, pas destructifs. Pour les changements petits et sûrs, la mise à jour progressive est efficace et simple.

Déploiement bleu/vert : deux environnements complets

Le déploiement bleu/vert adopte une approche différente. Vous maintenez deux environnements identiques. Appelez-les bleu et vert. À un moment donné, un seul d'entre eux sert le trafic en direct. L'autre reste inactif ou exécute la version précédente.

Voici comment cela fonctionne. Vos utilisateurs frappent actuellement l'environnement bleu. Vous déployez la nouvelle version sur l'environnement vert. Une fois que l'environnement vert est complètement prêt et que vous avez vérifié qu'il fonctionne, vous basculez le trafic. Tous les utilisateurs frappent maintenant l'environnement vert. Si quelque chose tourne mal, vous rebasculez vers le bleu. Le rollback est instantané.

Cette stratégie est plus sûre car il n'y a jamais de mélange de versions. Les utilisateurs passent d'une version complète à une autre. Il n'y a pas de période où la moitié des serveurs exécutent l'ancien code et l'autre moitié le nouveau. La transition est propre.

La contrepartie est le coût. Vous avez besoin de doubler les ressources. Deux environnements complets, chacun avec la même capacité, fonctionnant en même temps. Pour les petites applications, cela peut être abordable. Pour les grandes, le coût peut être significatif.

Le bleu/vert est idéal pour les applications critiques où l'indisponibilité est inacceptable et où le rollback doit être rapide. Si vous déployez un changement majeur, une migration de base de données, ou quelque chose qui touche de nombreuses parties du système, le bleu/vert vous offre un filet de sécurité.

Déploiement canari : tester d'abord sur un petit groupe

Le déploiement canari ressemble à une mise à jour progressive, mais plus prudent. Au lieu de remplacer les serveurs par lots, vous commencez par un très petit pourcentage. Peut-être 5 % de vos serveurs reçoivent la nouvelle version. Le reste reste sur l'ancienne version.

Vous observez ce petit groupe pendant un certain temps. Si le taux d'erreur reste normal, les temps de réponse sont bons et personne ne signale de problème, vous augmentez le pourcentage. Peut-être à 20 %. Puis 50 %. Puis 100 %.

L'idée est de limiter le rayon d'impact. Si la nouvelle version a un bug, seule une petite fraction des utilisateurs en fait l'expérience. Vous attrapez le problème avant qu'il ne devienne une panne complète.

Le déploiement canari nécessite une bonne supervision. Vous devez savoir à quoi ressemble la normale. Vous avez besoin de tableaux de bord qui montrent les taux d'erreur, la latence et le débit en temps réel. Sans cette visibilité, vous volez à l'aveugle. Vous ne saurez pas si le canari est en bonne santé ou non.

Cette stratégie fonctionne bien lorsque vous voulez valider un changement en production avant de vous y engager pleinement. Elle est particulièrement utile pour les changements de performance, les nouveaux algorithmes, ou tout ce dont le comportement sous trafic réel est incertain.

Choisir la bonne stratégie

Il n'existe pas de meilleure stratégie unique. Chacune correspond à une situation différente.

Le diagramme suivant peut vous aider à décider quelle stratégie correspond à votre situation.

La mise à jour progressive est la valeur par défaut pour la plupart des équipes. Elle est économe en ressources et fonctionne bien pour les changements de routine. Utilisez-la lorsque vos changements sont rétrocompatibles et que vous n'avez pas besoin d'un rollback instantané.

Le bleu/vert est le choix le plus sûr. Utilisez-le pour les déploiements critiques, les changements de version majeurs, ou lorsque vous devez revenir en arrière immédiatement. Soyez prêt à payer pour l'infrastructure supplémentaire.

Le canari est le plus prudent. Utilisez-le lorsque vous voulez observer l'impact d'un changement avant de vous y engager. Il nécessite une bonne supervision et un processus pour décider quand augmenter le pourcentage.

De nombreuses équipes commencent par des mises à jour progressives et passent au bleu/vert ou au canari à mesure que leur application devient plus critique et que leur base d'utilisateurs grandit. La stratégie que vous choisissez aujourd'hui n'a pas à être celle que vous utiliserez pour toujours.

Liste de contrôle pratique avant de choisir

• Le changement est-il rétrocompatible ? Si oui, la mise à jour progressive est suffisante.
• Avez-vous besoin d'un rollback instantané ? Si oui, le bleu/vert est plus sûr.
• Avez-vous une supervision en temps réel ? Si non, le canari est risqué.
• Pouvez-vous vous permettre une infrastructure doublée ? Si non, évitez le bleu/vert.
• Voulez-vous tester sous trafic réel ? Si oui, le canari vous le permet.

Ce qui compte le plus

La stratégie n'est pas la partie difficile. La partie difficile est de comprendre le comportement de votre application pendant une transition. Gère-t-elle deux versions fonctionnant en même temps ? Peut-elle tolérer une brève période de contrats d'API mixtes ? Avez-vous l'observabilité nécessaire pour détecter les problèmes avant que les utilisateurs ne les signalent ?

Choisissez une stratégie qui correspond à votre tolérance au risque et à votre budget d'infrastructure. Ensuite, testez-la. Pas seulement en préproduction, mais en production avec des schémas de trafic réels. La première fois que vous faites un basculement bleu/vert ou un déploiement canari, faites-le pendant une période de faible trafic. Surveillez les métriques. Apprenez à quoi ressemble la normale.

Le déploiement ne consiste pas à déplacer des bits d'un endroit à un autre. Il s'agit de garder vos utilisateurs heureux pendant que vous améliorez le produit. La bonne stratégie rend cela possible. La mauvaise le rend douloureux.