Stratégies de déploiement et de test des applications

Last reviewed 2023-07-20 UTC

Ce document présente les modèles de test et de déploiement d'applications couramment utilisés. Il décrit le fonctionnement des modèles, les avantages qu'ils offrent et les éléments à prendre en compte lorsque vous les mettez en œuvre.

Supposons que vous souhaitiez mettre à niveau une application en cours d'exécution vers une nouvelle version. Pour garantir un déploiement fluide, vous devez généralement prendre en compte ce qui suit :

  • Comment réduire les temps d'arrêt de l'application, le cas échéant
  • Comment gérer et résoudre les incidents avec un impact minimal sur les utilisateurs
  • Comment gérer les déploiements ayant échoué de manière fiable et efficace
  • Comment réduire les erreurs humaines et de traitement pour obtenir des déploiements prévisibles et reproductibles

Le modèle de déploiement que vous choisissez dépend en grande partie de vos objectifs commerciaux. Par exemple, vous devrez peut-être déployer des modifications sans temps d'arrêt, ou déployer des modifications dans un environnement ou auprès d'un sous-ensemble d'utilisateurs avant de rendre une fonctionnalité accessible à tous. Chaque méthodologie présentée dans ce document tient compte des objectifs spécifiques que vous devez atteindre avant qu'un déploiement soit considéré comme réussi.

Ce document est destiné aux administrateurs système et aux ingénieurs DevOps qui travaillent à la définition et à la mise en œuvre de stratégies de publication et de déploiement pour divers systèmes, applications et frameworks.

Stratégies de déploiement

Lorsque vous déployez un service, il n'est pas toujours immédiatement exposé aux utilisateurs. Parfois, ce n'est que lorsque le service est publié que les utilisateurs voient les modifications dans l'application. Cependant, lorsqu'un service est publié sur place, le déploiement et la publication se produisent simultanément. Dans ce cas, lorsque vous déployez la nouvelle version, elle commence à accepter le trafic de production. Il existe également des stratégies de déploiement permettant de provisionner plusieurs versions de service en parallèle. Ces modèles de déploiement vous permettent de contrôler et de gérer la version qui reçoit une requête entrante. Consultez la page Kubernetes et les défis de la livraison continue de logiciels pour en savoir plus sur les déploiements, les publications et les concepts associés.

Les modèles de déploiement décrits dans cette section vous donnent plus de flexibilité quant à la publication de nouveaux logiciels. L'approche qui vous convient le mieux dépend de vos objectifs.

Modèle de déploiement de type "recréation"

Avec un déploiement de type "recréation", vous réduisez complètement la version de l'application existante avant de la faire évoluer vers la nouvelle version.

Le schéma suivant illustre le fonctionnement d'un déploiement de type "recréation" pour une application.

Flux d'un déploiement de type "recréation"

La version 1 représente la version actuelle de l'application et la version 2 représente la nouvelle version de l'application. Lorsque vous mettez à jour la version actuelle de l'application, vous réduisez d'abord les instances dupliquées existantes de la version 1, puis vous déployez simultanément les instances dupliquées avec la nouvelle version.

Principaux avantages

L'avantage de l'approche de recréation est sa simplicité. Vous n'avez pas besoin de gérer plusieurs versions d'application en parallèle. Vous évitez ainsi les problèmes de rétrocompatibilité pour vos données et vos applications.

Remarques

La méthode de recréation implique un temps d'arrêt pendant le processus de mise à jour. Les temps d'arrêt ne sont pas un problème pour les applications pouvant gérer les intervalles de maintenance ou les interruptions. Toutefois, si vous avez des applications critiques avec des contrats de niveau de service et des exigences de disponibilité élevés, vous pouvez choisir une autre stratégie de déploiement.

Modèle de déploiement par mise à jour progressive

Avec un déploiement par mise à jour progressive, vous mettez à jour un sous-ensemble d'instances d'application en cours d'exécution au lieu de mettre à jour simultanément chaque instance d'application, comme le montre le schéma suivant.

Flux d'un déploiement par mise à jour progressive

Dans cette approche de déploiement, le nombre d'instances que vous mettez à jour simultanément est appelé taille de la fenêtre. Dans le schéma précédent, la taille de la fenêtre est de 1 pour la mise à jour progressive. Une seule instance d'application est mise à jour à la fois. Si votre cluster est volumineux, vous pouvez augmenter la taille de la fenêtre.

Grâce aux mises à jour progressives, vous disposez de la flexibilité nécessaire pour mettre à jour votre application :

  • Vous pouvez faire évoluer les instances d'application avec la nouvelle version avant de réduire l'ancienne version (processus connu sous le nom de mise à niveau de la surutilisation).
  • Vous pouvez spécifier le nombre maximal d'instances d'application qui restent indisponibles pendant le scaling de nouvelles instances en parallèle.

Principaux avantages

  • Aucun temps d'arrêt. En fonction de la taille de la fenêtre, vous mettez à jour de manière incrémentielle les cibles de déploiement, par exemple, une par une ou deux par deux. Vous dirigez le trafic vers les cibles de déploiement mises à jour uniquement lorsque la nouvelle version de l'application est prête à accepter le trafic.
  • Réduction des risques liés au déploiement. Lorsque vous déployez une mise à jour de manière incrémentielle, toute instabilité dans la nouvelle version n'affecte qu'une partie des utilisateurs.

Remarques

  • Rollback lent. Si le nouveau déploiement est instable, vous pouvez arrêter les nouvelles instances dupliquées et redéployer l'ancienne version. Cependant, comme pour un déploiement, un rollback est un processus progressif et incrémentiel.
  • Rétrocompatibilité. Étant donné que le nouveau code et l'ancien code coexistent, les utilisateurs peuvent être routés vers l'une des versions de manière arbitraire. Par conséquent, assurez-vous que le nouveau déploiement est rétrocompatible, c'est-à-dire que la nouvelle version de l'application peut lire et gérer les données que l'ancienne version stocke. Ces données peuvent inclure des données stockées sur un disque, dans une base de données ou dans le cadre de la session du navigateur d'un utilisateur.
  • Sessions persistantes. Si l'application requiert la persistance de session, nous vous recommandons d'utiliser un équilibreur de charge compatible avec la persistance et le drainage de connexion. En outre, nous vous recommandons d'appeler le partage de session lorsque cela est possible (via la réplication de session ou la gestion de session à l'aide d'un datastore) afin que les sessions puissent être dissociées des ressources sous-jacentes.

Modèle de déploiement bleu-vert

Avec un déploiement bleu-vert (également appelé déploiement rouge-noir), vous effectuez deux déploiements identiques de votre application, comme le montre le schéma suivant.

Flux d'un déploiement bleu-vert

Dans le schéma, le bleu représente la version actuelle de l'application et le vert la nouvelle. Une seule version est disponible à la fois. Le trafic est acheminé vers le déploiement bleu pendant que le déploiement vert est créé et testé. Une fois les tests terminés, vous acheminez le trafic vers la nouvelle version.

Une fois le déploiement réussi, vous pouvez conserver le déploiement bleu pour un éventuel rollback ou le mettre hors service. Vous pouvez également déployer une version plus récente de l'application sur ces instances. Dans ce cas, l'environnement actuel (bleu) sert de zone de préproduction pour la prochaine release.

Principaux avantages

  • Aucun temps d'arrêt. Le déploiement bleu-vert permet un basculement rapide sans temps d'arrêt.
  • Rollback instantané. Vous pouvez effectuer un rollback à tout moment pendant le processus de déploiement en ajustant l'équilibreur de charge de manière à diriger le trafic vers l'environnement bleu. L'impact du temps d'arrêt est limité au temps nécessaire pour basculer le trafic vers l'environnement bleu après la détection d'un problème.
  • Séparation des environnements. Le déploiement bleu-vert garantit que le démarrage d'un environnement vert parallèle n'affecte pas les ressources utilisées dans l'environnement bleu. Cette séparation permet de réduire les risques liés à votre déploiement.

Remarques

  • Coûts opérationnels et autres coûts. L'adoption du modèle de déploiement bleu-vert peut augmenter les coûts opérationnels et les autres coûts, car vous devez gérer des environnements en double avec une infrastructure identique.
  • Rétrocompatibilité. Les déploiements bleu et vert peuvent partager des points de données et des datastores. Nous vous recommandons de vérifier que les deux versions de l'application peuvent utiliser le schéma du datastore et le format des enregistrements. Cette rétrocompatibilité est nécessaire si vous souhaitez basculer facilement entre les deux versions en cas de rollback.
  • Basculement. Si vous envisagez de mettre la version actuelle hors service, nous vous recommandons d'autoriser le drainage de connexion approprié sur les transactions et sessions existantes. Cette étape permet aux requêtes traitées par le déploiement en cours d'être terminées ou arrêtées en douceur.

Stratégies de test

Les modèles de test décrits dans cette section sont généralement utilisés pour valider la fiabilité et la stabilité d'un service sur une période raisonnable, avec un niveau de simultanéité et de charge réaliste.

Modèle de test Canary

Avec les tests Canary, vous déployez partiellement une modification, puis évaluez ses performances par rapport à un déploiement de référence, comme le montre le schéma suivant.

Configuration d'un test Canary

Dans ce modèle de test, vous déployez une nouvelle version de votre application avec la version de production. Vous devez ensuite diviser et acheminer un pourcentage du trafic de la version de production vers la version Canary, et évaluer les performances de la version Canary.

Vous sélectionnez les métriques clés pour l'évaluation lorsque vous configurez la version Canary. Nous vous recommandons de comparer la version Canary à une référence équivalente et non à l'environnement de production actif.

Pour réduire les facteurs susceptibles d'affecter votre analyse (tels que la mise en cache, les connexions à longue durée de vie et les objets de hachage), nous vous recommandons de suivre la procédure suivante pour la version de référence de votre application :

  • Assurez-vous que les versions de référence et de production de votre application sont identiques.
  • Déployez la version de référence en même temps que la version Canary.
  • Assurez-vous que le déploiement de référence (tel que le nombre d'instances d'application et les règles d'autoscaling) correspond au déploiement Canary.
  • Utilisez la version de référence pour diffuser le même trafic que la version Canary.

Dans les tests Canary, le déploiement partiel peut suivre différentes stratégies de partitionnement. Par exemple, si l'application dispose d'utilisateurs répartis géographiquement, vous pouvez d'abord déployer la nouvelle version dans une région ou un emplacement spécifique. Pour en savoir plus, consultez la page Automatiser l'analyse Canary sur GKE avec Spinnaker.

Principaux avantages

  • Capacité à tester le trafic de production en temps réel. Au lieu de tester une application en utilisant le trafic simulé dans un environnement de préproduction, vous pouvez exécuter des tests Canary sur le trafic de production en temps réel. Avec les déploiements Canary, vous devez déterminer les incréments de publication de la nouvelle application et à quel moment vous souhaitez déclencher l'étape suivante de la publication. La version Canary nécessite suffisamment de trafic pour que la surveillance puisse détecter clairement les problèmes.
  • Rollback rapide. Vous pouvez effectuer un rollback rapide en redirigeant le trafic utilisateur vers l'ancienne version de l'application.
  • Aucun temps d'arrêt. Les versions Canary vous permettent d'acheminer le trafic de production en temps réel vers différentes versions de l'application sans aucun temps d'arrêt.

Remarques

  • Déploiement lent. Chaque release incrémentielle nécessite une surveillance pendant une période raisonnable et, par conséquent, peut retarder la release globale. Les tests Canary peuvent souvent prendre plusieurs heures.
  • Observabilité. Pour mettre en œuvre des tests Canary, vous devez impérativement pouvoir observer et surveiller efficacement votre infrastructure et votre pile d'application. La mise en œuvre d'une surveillance robuste peut nécessiter un effort considérable.
  • Rétrocompatibilité et sessions persistantes. Comme pour les mises à jour progressives, les tests Canary peuvent présenter des risques au niveau de la rétrocompatibilité et de la persistance de session, car plusieurs versions d'application s'exécutent dans l'environnement pendant le déploiement Canary.

Modèle de test A/B

Avec les tests A/B, vous testez une hypothèse à l'aide de mises en œuvre de variantes. Les tests A/B permettent de prendre des décisions commerciales (et pas seulement de réaliser des prédictions) en fonction des résultats issus des données.

Lorsque vous effectuez un test A/B, vous acheminez un sous-ensemble d'utilisateurs vers une nouvelle fonctionnalité basée sur des règles de routage, comme le montre le schéma suivant.

Configuration d'un test A/B

Les règles de routage incluent souvent des facteurs tels que la version du navigateur, l'user-agent, la géolocalisation et le système d'exploitation. Après avoir mesuré et comparé les versions, vous mettez à jour l'environnement de production avec la version qui a généré les meilleurs résultats.

Principaux avantages

Les tests A/B permettent de mesurer l'efficacité des fonctionnalités d'une application. Les cas d'utilisation des modèles de déploiement décrits précédemment sont axés sur la publication sécurisée de nouveaux logiciels et le rollback prévisible. Avec les tests A/B, vous contrôlez l'audience cible des nouvelles fonctionnalités et surveillez les différences statistiquement pertinentes dans le comportement des utilisateurs.

Remarques

  • Configuration complexe. Les tests A/B nécessitent un échantillon représentatif permettant de prouver qu'une version est meilleure que l'autre. Vous devez pré-calculer la taille de l'échantillon (par exemple, à l'aide d'un calculateur de taille d'échantillon de test A/B) et exécuter les tests sur une période raisonnable pour atteindre une pertinence statistique d'au moins 95 %.
  • Validité des résultats. Plusieurs facteurs peuvent fausser les résultats du test, y compris des faux positifs, un échantillonnage biaisé ou des facteurs externes (tels que la saisonnalité ou les promotions marketing).
  • Observabilité. Lorsque vous exécutez plusieurs tests A/B sur un trafic qui se chevauche, les processus de surveillance et de dépannage peuvent être difficiles. Par exemple, si vous testez la page A du produit par rapport à la page B du produit, ou la page C du règlement par rapport à la page D du règlement, le traçage distribué devient important pour déterminer des métriques telles que la répartition du trafic entre les versions.

Modèle de test "dark launch"

Des techniques de test séquentielles telles que les tests Canary peuvent potentiellement exposer les clients à une version d'application inférieure lors des premières phases du test. Vous pouvez gérer ce risque en utilisant des techniques hors ligne telles que la simulation. Cependant, certaines de ces techniques ne permettent pas de valider les améliorations de l'application, car il n'y a aucune interaction des utilisateurs avec les nouvelles versions.

Avec le test "dark launch", vous déployez et exécutez une nouvelle version avec la version actuelle, mais de manière à masquer la nouvelle version pour les utilisateurs, comme le montre le schéma suivant.

Configuration d'un test "dark launch"

Une requête entrante est mise en miroir et relue dans un environnement de test. Ce processus peut se produire en temps réel ou de manière asynchrone après la relecture d'une copie du trafic de production précédemment capturé sur le service nouvellement déployé.

Vous devez vous assurer que les tests "dark launch" ne déclenchent aucun effet secondaire susceptible de modifier l'environnement de production existant ou l'état de l'utilisateur.

Principaux avantages

  • Aucun impact en production. Comme le trafic est dupliqué, les bugs dans les services qui traitent les données dupliquées n'ont aucun impact en production.
  • Tester de nouvelles fonctionnalités de backend à l'aide de la charge de production. Lorsque vous utilisez des outils tels que Diffy, le fait d'effectuer un "dark launch" vous permet de mesurer le comportement de votre service par rapport au trafic de production en temps réel. Cela vous permet de tester les erreurs, les exceptions, les performances et la parité des résultats entre les versions de l'application.
  • Réduction des risques liés au déploiement. Le test "dark launch" est généralement associé à d'autres approches, telles que les tests Canary. Après avoir testé une nouvelle fonctionnalité à l'aide du test "dark launch", vous testez l'expérience utilisateur en publiant progressivement la fonctionnalité auprès d'un nombre croissant d'utilisateurs. Aucun déploiement complet n'est effectué tant que l'application ne répond pas aux exigences de stabilité et de performances.

Remarques

  • Effets secondaires. Avec le test "dark launch", vous devez faire attention à la façon dont vous gérez les services qui modifient l'état ou interagissent avec des services tiers. Par exemple, si vous souhaitez tester le service de paiement d'une plate-forme de panier d'achat en mode "dark launch", les clients pourraient payer deux fois leur commande. Pour éviter que les tests "dark launch" entraînent des mutations indésirables ou d'autres interactions à risque, nous vous recommandons d'utiliser des bouchons ou des outils de virtualisation tels que Hoverfly plutôt que des systèmes ou des datastores tiers.
  • Coûts opérationnels et autres coûts. Le test "dark launch" est assez complexe à configurer. En outre, comme les déploiements bleu-vert, les déploiements "dark launch" entraînent des coûts et des conséquences opérationnelles, car la configuration nécessite l'exécution et la gestion de deux environnements en parallèle.

Choisir la bonne stratégie

Vous pouvez déployer et publier votre application de plusieurs manières. Chacune présente des avantages et des inconvénients. Le meilleur choix dépend des besoins et des contraintes de votre entreprise. Réfléchissez aux éléments suivants :

  • Quelles sont vos principales exigences ? Par exemple, les temps d'arrêt sont-ils acceptables ? Avez-vous un budget limité ? Votre équipe dispose-t-elle des compétences nécessaires pour effectuer des configurations de déploiement et de rollback complexes ?
  • Avez-vous mis en place des contrôles de test stricts ou souhaitez-vous tester les nouvelles releases sur le trafic de production pour garantir leur stabilité et limiter tout impact négatif ?
  • Souhaitez-vous tester des fonctionnalités auprès d'un groupe d'utilisateurs pour effectuer une vérification croisée de certaines hypothèses commerciales ? Pouvez-vous contrôler si les utilisateurs ciblés acceptent la mise à jour ? Par exemple, les mises à jour sur les appareils mobiles nécessitent une action explicite de l'utilisateur et peuvent nécessiter des autorisations supplémentaires.
  • Les microservices de votre environnement sont-ils entièrement autonomes ? Ou avez-vous une combinaison d'applications de type microservice et d'applications traditionnelles difficiles à modifier ? Pour en savoir plus, consultez la section Modèles de déploiement dans des environnements hybrides et multicloud.
  • La nouvelle release implique-t-elle des modifications de schéma ? Si oui, les modifications de schéma sont-elles trop complexes pour être dissociées des modifications de code ?

Le tableau suivant récapitule les caractéristiques essentielles des modèles de déploiement et de test décrits précédemment dans ce document. Lorsque vous évaluez les avantages et les inconvénients des différentes approches de déploiement et de test, tenez compte des besoins de votre entreprise et de vos ressources technologiques, puis choisissez l'option qui vous convient le mieux.

Modèle de déploiement
ou de test		 Aucun temps d'arrêt Test du trafic de production réel Publication auprès des utilisateurs en fonction de certaines conditions Durée du rollback Impact sur les coûts liés au matériel et au cloud
Recréation
La version 1 est arrêtée et la version 2 est déployée.		 X x X Rapide, mais peut être perturbé en raison de temps d'arrêt Aucune configuration supplémentaire requise
Mise à jour progressive
La version 2 est déployée progressivement et remplace la version 1.		 ✓ X X Lent Peut nécessiter une configuration supplémentaire pour les mises à niveau de la surutilisation
Déploiement bleu-vert
La version 2 est publiée avec la version 1 ; le trafic passe sur la version 2 après le test.		 ✓ X X Instantané Maintien simultané des environnements bleu et vert
Canary
La version 2 est publiée pour un sous-ensemble d'utilisateurs, suivie d'un déploiement complet.		 ✓ ✓ X Rapide Aucune configuration supplémentaire requise
A/B
La version 2 est publiée, sous certaines conditions, auprès d'un sous-ensemble d'utilisateurs.		 ✓ ✓ ✓ Rapide Aucune configuration supplémentaire requise
Dark launch
La version 2 reçoit le trafic réel sans affecter les requêtes des utilisateurs.		 ✓ ✓ X Non applicable Maintien d'environnements parallèles pour capturer et relire les requêtes des utilisateurs

Bonnes pratiques

Afin de limiter les risques liés au déploiement et aux tests, les équipes d'applications peuvent adopter plusieurs bonnes pratiques :

  • Rétrocompatibilité. Lorsque vous exécutez plusieurs versions d'application en même temps, assurez-vous que la base de données est compatible avec toutes les versions actives. Par exemple, une nouvelle release nécessite une modification de schéma dans la base de données (une nouvelle colonne, par exemple). Dans un tel scénario, vous devez modifier le schéma de la base de données afin qu'il soit rétrocompatible avec l'ancienne version. Une fois le déploiement complet terminé, vous pouvez arrêter d'utiliser l'ancien schéma pour ne conserver que la nouvelle version. Pour assurer la rétrocompatibilité, vous pouvez dissocier les modifications de schéma des modifications de code. Pour en savoir plus, consultez les schémas de propagation parallèle du changement et de refactorisation de base de données.
  • Intégration continue/déploiement continu (CI/CD). L'intégration continue permet de s'assurer que le code enregistré dans la branche de fonctionnalité ne fusionne avec sa branche principale qu'après avoir réussi les tests de dépendance, les tests unitaires et d'intégration, et le processus de compilation. Par conséquent, chaque modification apportée à une application est testée avant d'être déployée. Avec le déploiement continu, l'artefact de code intégré à l'intégration continue est empaqueté et prêt à être déployé dans un ou plusieurs environnements. Pour en savoir plus, consultez la page Créer un pipeline CI/CD avec Google Cloud.
  • Automation. Si vous diffusez des mises à jour d'application en continu auprès des utilisateurs, nous vous recommandons de mettre en place un processus automatisé qui compile, teste et déploie votre logiciel de manière fiable. Les modifications de code doivent automatiquement transiter par un pipeline CI/CD chargé de la création de l'artefact, des tests unitaires et fonctionnels, et du déploiement en production. À l'aide d'outils d'automatisation tels que Cloud Build, Cloud Deploy, Spinnaker et Jenkins, vous pouvez automatiser les processus de déploiement pour être plus efficaces, plus fiables et plus prévisibles.
  • IaC et GitOps Si vous devez gérer des stratégies complexes de déploiement et de test, envisagez d'utiliser les outils IaC (Infrastructure as Code) et GitOps. L'utilisation de l'IaC avec Terraform et Config Connector peut vous aider à utiliser le langage déclaratif pour définir votre infrastructure et vos stratégies. L'utilisation de GitOps avec Config Sync et Argo CD peut vous aider à gérer votre code avec git.
  • Stratégie de rollback. Parfois, les erreurs se produisent. Nous vous recommandons de créer une stratégie de rollback à suivre lorsque les choses ne vont pas comme prévu. Une stratégie de rollback fiable peut aider les administrateurs et les ingénieurs DevOps à gérer les risques. Vous pouvez créer une stratégie de rollback à l'aide d'une plate-forme qui accepte les rollbacks en tant que fonctionnalité intégrée, par exemple App Engine et Cloud Run. Pour répondre à vos besoins de rollback, vous pouvez également utiliser des outils d'automatisation des versions tels que Cloud Deploy, Spinnaker et Argo RollOuts.
  • Surveillance post-déploiement. Pour surveiller les métriques critiques et alerter l'équipe responsable en cas d'échec d'un déploiement ou d'un test, créez un système de surveillance à l'aide de Google Cloud Observability. Vous pouvez également activer les rollbacks automatisés pour les déploiements qui échouent aux vérifications de l'état. L'utilisation d'Error Reporting, de Cloud Trace et de Cloud Profiler peut vous aider à trouver la cause de problèmes de post-déploiement simples et complexes.

Étapes suivantes