Remarque
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de vous connecter ou de modifier des répertoires.
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de modifier des répertoires.
À présent, déployez la solution dans l’environnement Azure en direct en suivant la stratégie planifiée. Cette phase inclut les préparations finales, l’exécution du déploiement et la vérification et la prise en charge après le déploiement.
Préparer les parties prenantes pour les déploiements natifs cloud
Annoncez la planification du déploiement et l’impact attendu. Avant de commencer le déploiement de production, communiquez le plan et la valeur à toutes les parties prenantes pertinentes. Annoncez la planification du déploiement et les effets utilisateur attendus. Par exemple, pour les nouvelles fonctionnalités, notez les temps d’arrêt ou les modifications visibles par l’utilisateur à l’avance. Les parties prenantes peuvent identifier les conflits avec les événements d’entreprise ou susciter des préoccupations au sujet du moment. Fournissez un canal pour les commentaires et vérifiez que la fenêtre de déploiement s’aligne sur les priorités opérationnelles. Ajustez la planification si nécessaire pour éviter toute interruption.
Notifier les équipes de support et les groupes concernés. Assurez-vous que les équipes de support sont en veille et sachent ce qui est publié afin qu’elles puissent gérer les problèmes ou demandes de l’utilisateur. Si le déploiement peut affecter les utilisateurs finaux ou d’autres systèmes, informez-les également.
Définissez les attentes en matière de fonctionnalités pendant la fenêtre de déploiement. Une fenêtre de déploiement peut impliquer des retards temporaires ou des fonctionnalités réduites. Informez les parties prenantes de ces conditions pour éviter toute confusion et assurer la continuité de l’activité. Incluez des procédures de secours ou des solutions de contournement le cas échéant.
Effectuez un examen de préparation au prédéploiement. Une révision de préparation confirme que toutes les équipes comprennent leurs rôles et ont un accès nécessaire. Organisez une réunion avec des représentants de chaque équipe de support pour examiner le plan de déploiement, les critères de réussite et les critères de retour arrière. Vérifiez que les équipes de support disposent des outils d’accès système et de surveillance appropriés configurés. Cette préparation garantit une réponse coordonnée aux problèmes qui surviennent lors de la migration.
Exécuter les déploiements natifs dans le cloud
Les étapes de déploiement diffèrent légèrement selon qu’il s’agit d’une nouvelle charge de travail autonome ou d’une mise à jour de fonctionnalité vers un système existant :
Déployer de nouvelles charges de travail conçues pour le cloud
Créez un environnement de production. Utilisez votre pipeline CI/CD pour déployer le pipeline de production à l’aide de la même configuration testée en préproduction. Utilisez les mêmes artefacts de build, modèles IaC et scripts de déploiement qui ont passé la validation en préproduction. Étant donné que vous effectuez un déploiement dans un environnement distinct, créez toutes les ressources Azure nécessaires via vos modèles IaC, puis déployez le code ou les artefacts de l’application.
Test de fumée. Une fois déployé, effectuez des tests de fumée en production (vérifications de base) pour vous assurer que tous les services sont en cours d’exécution et que les fonctionnalités principales fonctionnent dans l’environnement actif. Vérifiez que les services clés s'exécutent, que les bases de données sont accessibles et que l'application répond (visualisez un point de vérification de santé ou quelques pages principales). Vérifiez Azure Service Health pour connaître les problèmes de plateforme dans votre région susceptibles d’affecter vos composants. Ce test est une vérification avant que les utilisateurs ne soient dirigés vers le système.
Déploiement sur un petit groupe d’utilisateurs. Implémentez le déploiement progressif en exposant le nouveau système à un petit ensemble d’utilisateurs. Ce déploiement peut être effectué en libérant une fonctionnalité uniquement pour les utilisateurs internes, ou en acheminant un petit pourcentage de live vers le nouveau déploiement. Surveillez étroitement les erreurs ou les problèmes de performances. Utilisez Application Insights et des tableaux de bord personnalisés pour observer les taux d’erreur, les temps de réponse et l’utilisation des ressources en temps réel. Rassemblez également des commentaires qualitatifs de tous les utilisateurs pilotes sur la version canary.
Surveillez et développez progressivement. Le déploiement progressif réduit les risques et permet une validation réelle avant la mise en production complète. Relâchez l’application sur un petit groupe d’utilisateurs canary. Utilisez un équilibreur de charge, tel qu’Azure Front Door ou Traffic Manager, pour router un sous-ensemble de trafic vers le nouveau déploiement. Collectez les commentaires et surveillez les performances. Effectuez un scale-up ou ouvrez l’accès à tous les utilisateurs après la validation réussie.
Déployer de nouvelles fonctionnalités natives cloud sur une charge de travail existante
Lorsque vous déployez une nouvelle fonctionnalité sur une charge de travail cloud native existante, choisissez la stratégie de déploiement qui s’aligne sur votre tolérance de risque, vos contraintes d’infrastructure et vos objectifs de déploiement. Deux approches courantes sont le déploiement sur place et le déploiement bleu-vert (environnement parallèle).
Utiliser le déploiement sur place pour le déploiement progressif dans le même environnement
Utilisez le déploiement sur place lors de l’ajout d’une nouvelle fonctionnalité à une charge de travail existante sans provisionner un environnement distinct. Cette approche permet un déploiement sécurisé et incrémentiel avec une surcharge minimale de l’infrastructure.
Activer la fonctionnalité pour le petit segment utilisateur Déployez la nouvelle fonctionnalité dans l’environnement existant à l’aide des indicateurs de fonctionnalité ou des bascules de configuration. Commencez par activer la fonctionnalité pour un public limité, comme les utilisateurs internes, les testeurs bêta ou un faible pourcentage de trafic en direct. Cette approche permet une validation réelle tout en conservant la possibilité de désactiver rapidement la fonctionnalité en cas de problèmes. Vérifiez que les interactions utilisateur sont marquées pour faire la distinction entre les utilisateurs ou les sessions avec la fonctionnalité activée ou désactivée, ce qui permet une comparaison côte à côte.
Test de fumée. Une fois déployé, effectuez des tests de fumée en production (vérifications de base) pour vous assurer que tous les services sont en cours d’exécution et que les fonctionnalités principales fonctionnent dans l’environnement actif. Vérifiez que les services clés s'exécutent, que les bases de données sont accessibles et que l'application répond (visualisez un point de vérification de santé ou quelques pages principales).
Surveillez et développez progressivement. Surveillez en continu l’intégrité, les performances et les taux d’erreur des applications à l’aide d’outils comme Application Insights ou Azure Monitor. Comparez les métriques entre les utilisateurs et sans la fonctionnalité activée pour détecter les anomalies. Si aucun problème n’est détecté, augmentez progressivement le pourcentage de déploiement de l’indicateur de fonctionnalité ou développez le groupe d’utilisateurs. Répétez la surveillance après chaque incrément. Après le déploiement complet, effectuez une validation finale pour garantir un comportement cohérent entre toutes les instances et les segments utilisateur.
Déployer de nouvelles fonctionnalités dans un environnement parallèle
Utilisez un déploiement bleu-vert lors de l’introduction d’une nouvelle fonctionnalité à une charge de travail existante en la déployant dans un environnement de production parallèle. Cette approche réduit les risques en autorisant la validation complète avant de basculer le trafic utilisateur vers la nouvelle version.
Créez un environnement parallèle (vert). Utilisez votre pipeline CI/CD pour déployer le pipeline de production à l’aide de la même configuration testée en préproduction. Utilisez les mêmes artefacts de build, modèles IaC et scripts de déploiement qui ont passé la validation en préproduction. Étant donné que vous effectuez un déploiement dans un environnement distinct, créez toutes les ressources Azure nécessaires via vos modèles IaC, puis déployez le code ou les artefacts de l’application.
Test de fumée de l’environnement parallèle. Une fois déployé, effectuez des tests de fumée en production (vérifications de base) pour vous assurer que tous les services sont en cours d’exécution et que les fonctionnalités principales fonctionnent dans l’environnement actif. Vérifiez que les services clés s'exécutent, que les bases de données sont accessibles et que l'application répond (visualisez un point de vérification de santé ou quelques pages principales). Vérifiez Azure Service Health pour connaître les problèmes de plateforme dans votre région susceptibles d’affecter vos composants. Ce test de fumée est une vérification avant que les utilisateurs ne soient dirigés vers le système.
Acheminer un sous-ensemble de trafic vers un environnement parallèle. Le déploiement progressif réduit les risques et permet une validation réelle avant la mise en production complète. Relâchez l’application sur un petit groupe d’utilisateurs canary. Utilisez un équilibreur de charge, tel qu’Azure Front Door ou Traffic Manager, pour router un sous-ensemble de trafic vers le nouveau déploiement. Vous pouvez également exposer la nouvelle fonctionnalité uniquement à un segment d’utilisateur spécifique via des règles de routage ou des indicateurs de fonctionnalité. Surveillez les performances, les taux d’erreur et l’expérience utilisateur à l’aide d’Application Insights ou d’Azure Monitor. Comparez le trafic utilisateur entre les environnements bleus et verts pour détecter les régressions ou anomalies.
Surveillez et développez progressivement. Si la nouvelle version fonctionne correctement, augmentez de façon incrémentielle le routage du trafic jusqu’à ce qu’elle gère 100% de la charge. Promouvoir le déploiement « vert » comme principal. L’ancien déploiement « bleu » est conservé intact pendant ce processus, ce qui facilite la restauration. Si un problème grave est détecté, vous pouvez basculer instantanément tout le trafic vers la version stable.
Finaliser le basculement. Une fois la validation réussie, routez tous les utilisateurs vers le nouveau système ou annoncez-le officiellement en direct s’il a été masqué. L’ancien environnement, s’il en existe un pour une fonctionnalité mise à jour, peut maintenant être envisagé pour désaffectation après une période de validation sécurisée.
Valider la réussite du déploiement
Après avoir déployé une nouvelle charge de travail ou une nouvelle fonctionnalité, il est essentiel de vérifier que le système fonctionne correctement, techniquement et du point de vue de l’utilisateur.
Valider les parcours utilisateur critiques. Dépassez les tests de fumée pour vérifier que tous les flux utilisateur clés fonctionnent comme prévu dans l’environnement actif. Utilisez des suites de test automatisées ou un contrôle qualité manuel pour valider des scénarios réels. Concentrez-vous sur des chemins à valeur élevée tels que l’authentification, les transactions et les flux de travail de données. Ce test s’applique si le déploiement a introduit un nouveau système ou amélioré un système existant.
Vérifiez les processus et intégrations en arrière-plan. Vérifiez que les processus en arrière-plan, les intégrations et les travaux planifiés s’exécutent correctement. Vérifiez les journaux, les états des travaux et les points de terminaison d’intégration pour vous assurer qu’ils fonctionnent comme prévu. Cette étape empêche les échecs silencieux qui peuvent ne pas être immédiatement visibles par les utilisateurs.
Passez en revue les tableaux de bord de surveillance pour l’intégrité du système. Utilisez Azure Monitor et Application Insights pour inspecter les données de journal et les métriques. Recherchez les anomalies dans les taux d’erreur, la latence, l’utilisation du processeur/mémoire et le débit. Vérifiez que les données de surveillance circulent correctement et qu’aucune donnée n’est manquante ou mal acheminée.
Inspectez les alertes pour les déclencheurs inattendus. Passez en revue les alertes configurées pour les taux d’échec, la latence ou l’utilisation des ressources. Vérifiez qu’aucune alerte ne se déclenche de manière inattendue. Si des alertes sont déclenchées, examinez les causes racines et évaluez si elles indiquent un problème lié au déploiement.
Effectuez des vérifications des parties prenantes et des utilisateurs. Il est également judicieux d’avoir un contrôle rapide avec quelques utilisateurs finaux ou parties prenantes après le déploiement pour obtenir la confirmation humaine que les choses fonctionnent du point de vue de l’utilisateur.
Déclarez le déploiement terminé uniquement après la validation complète. Considérez uniquement le déploiement une fois que toutes les étapes de validation sont réussies et que le système répond à vos critères d’acceptation. Si des problèmes sont détectés, corrigez immédiatement les problèmes critiques. Consignez des problèmes mineurs pour la résolution dans les futures mises à jour.
Prendre en charge les charges de travail pendant la stabilisation
Établir une surveillance et une posture de support accrues. Le déploiement en production n’est pas la fin du parcours. Dans les heures et les jours qui suivent immédiatement une mise en service, augmentez votre surveillance et votre vigilance en matière de support tandis que le système se met en place sous la charge réelle. Il est conseillé d’avoir l’équipe de développement en appel en même temps que l’équipe des opérations pour examiner et résoudre rapidement les problèmes, car ils connaissent les nouveaux changements le mieux.
Suivez en continu les métriques système et les commentaires des utilisateurs. Traitez la première semaine ou deux comme une période de stabilisation. Surveillez les métriques telles que l’UC, la mémoire, les taux d’erreur et les temps de réponse à l’aide d’Azure Monitor et d’Application Insights. Collectez les commentaires des utilisateurs par le biais de canaux de support ou d’une sensibilisation directe. Cela permet de détecter les problèmes que les systèmes automatisés peuvent manquer.
Ajustez les configurations en fonction du comportement observé. Modifiez les configurations si nécessaire. Par exemple, augmentez le scale-out si l’utilisation est plus élevée que prévu. Si les journaux sont trop détaillés ou trop épars, modifiez les niveaux de journalisation. Ces modifications permettent de maintenir les performances et l’observabilité pendant les pics d’utilisation. Vérifiez que les problèmes détectés dans cette phase sont résolus ou entrés dans votre système de suivi pour une amélioration future.
Journaliser et trier tous les problèmes détectés lors de la stabilisation. Cette phase de support active intercepte les problèmes qui ne se révèlent que dans des conditions de production et garantit que le flux de travail répond réellement à ses objectifs. Après cette période de stabilisation, et une fois que vous êtes confiant dans les performances du système, vous pouvez passer aux opérations normales et aux procédures de surveillance.
Définissez les critères de sortie pour la stabilisation. Définissez des seuils clairs pour les performances du système, les taux d’erreur et la satisfaction des utilisateurs. Une fois que le système répond à ces critères de manière cohérente, passez aux procédures de surveillance et d’exploitation standard. Ces critères garantissent un transfert fluide et évitent la fermeture prématurée de la phase de support.