Déploiement continu vers Azure

Le déploiement continu (CD) publie automatiquement en production chaque modification qui réussit les tests CI, sans intervention manuelle. La livraison continue est une version plus souple : elle automatise le déploiement jusqu’à un environnement de Staging et nécessite une gate d’approbation humaine avant la mise en production. Ces deux pratiques reposent sur la même infrastructure de Pipeline. Dans Azure Pipelines, le CD est mis en œuvre en ajoutant des stages de déploiement après le stage CI et en ciblant des Environments Azure avec des gates d’approbation si nécessaire.

Une Pipeline CI/CD complète comporte au moins trois stages : Build (compiler, tester, publier l’artefact), Deploy to Staging (déployer l’artefact dans un slot hors production) et Deploy to Production (permuter le slot ou déployer après approbation). Les stages transmettent l’artefact via le stockage d’Artifacts de la Pipeline. Le stage de Staging exécute automatiquement des tests d’intégration ou des tests de fumée ; le stage de Production attend une approbation manuelle avant de continuer.

Utilisez des jobs deployment (et non des jobs job classiques) pour les stages de déploiement. Les jobs de déploiement prennent en charge les stratégies de déploiement (runOnce, rolling, canary), assurent le suivi de l’historique des déploiements par environnement et doivent référencer les Environments Azure DevOps. Un environnement enregistre les Pipelines qui y ont effectué un déploiement, la version actuellement active et l’état de santé des ressources, et fournit les gates d’approbation et les vérifications dans un tableau de bord unique.

La tâche AzureWebApp@1 déploie une application web vers Azure App Service. Elle prend en charge le déploiement vers un slot spécifique (par exemple, Staging), ainsi que le déploiement de paquets ZIP, d’images Docker ou de fichiers JAR/WAR. Après un déploiement dans un slot de Staging, utilisez la tâche AzureAppServiceManage@0 pour permuter le slot de Staging avec Production : il s’agit de la stratégie de déploiement privilégiée sans interruption pour App Service.

Après le déploiement vers Staging, exécutez des tests de fumée : un ensemble minimal de tests qui vérifient que le déploiement a réussi et que l’application répond correctement. Les tests de fumée appellent généralement les principaux points de terminaison d’API et vérifient les codes d’état et le contenu de réponse attendus. S’ils échouent, la Pipeline s’arrête avant la permutation vers Production ou la demande d’approbation, empêchant ainsi une version défectueuse d’atteindre les utilisateurs.

Ajoutez des gates d’approbation aux Environments Azure DevOps pour exiger une approbation manuelle avant la poursuite des déploiements. Accédez aux paramètres de l’environnement et ajoutez des approbations — indiquez les utilisateurs ou les groupes qui doivent approuver. Lorsque la Pipeline atteint un job de déploiement ciblant cet environnement, elle se met en pause et envoie une notification par e-mail. Les approbateurs peuvent consulter les détails du déploiement et approuver ou rejeter celui-ci dans le portail Azure DevOps ou via le lien de l’e-mail de notification.

Déployez des applications conteneurisées vers AKS à l’aide de la tâche KubernetesManifest@0. Cette tâche applique les manifestes YAML Kubernetes au cluster, avec une prise en charge intégrée de imagePullSecrets et des déploiements canary. Connectez-vous au cluster AKS à l’aide d’une connexion de service Kubernetes configurée dans Azure DevOps. La tâche utilise kubectl apply en arrière-plan et attend la fin du déploiement progressif avant de marquer l’étape comme réussie.

Étiquetez les images de conteneur avec l’ID de compilation ($(Build.BuildId)) ou le SHA du commit Git ($(Build.SourceVersion)) afin de toujours pouvoir relier un conteneur en cours d’exécution à la révision exacte du code qui l’a généré. Évitez d’utiliser l’étiquette latest en production : Kubernetes la met en cache et peut ne pas télécharger la nouvelle version. Stockez l’étiquette d’image spécifique comme variable de Pipeline et injectez-la dans les manifestes Kubernetes au moment du déploiement à l’aide de envsubst ou sed.

Définissez une stratégie de restauration pour les déploiements en production afin de pouvoir récupérer rapidement après une mauvaise mise en production. Pour App Service, restaurer signifie rééchanger l’emplacement de production avec la version précédente de préproduction. Pour AKS, utilisez kubectl rollout undo. Créez un pipeline de restauration dédié ou ajoutez une tâche de restauration manuelle qui peut être déclenchée depuis le portail Azure DevOps. Documentez la procédure de restauration et entraînez-vous régulièrement : une restauration non testée n’est pas une restauration.

Après chaque déploiement en production, exécutez automatiquement une vérification de surveillance pour confirmer que la nouvelle version fonctionne correctement. Utilisez la vérification de pipeline AzureMonitor@1 pour interroger les métriques d’Azure Monitor ; si le taux d’erreurs augmente après le déploiement, bloquez la progression du pipeline et déclenchez une restauration. Envoyez des notifications de déploiement à Microsoft Teams ou à Slack via des tâches webhook afin que l’équipe sache quand un déploiement est terminé et quelle version est active.

Suivez ces bonnes pratiques de déploiement continu : déployez fréquemment (de petits lots réduisent les risques), utilisez des indicateurs de fonctionnalité pour dissocier le déploiement de la mise en production, automatisez tous les contrôles de qualité avant la production, mettez en place une préproduction similaire à la production afin que les différences ne masquent pas les bogues, surveillez les fenêtres de déploiement avec des vérifications automatisées de l’état de santé et disposez toujours d’un plan de restauration testé. Un pipeline de CD mature transforme le déploiement en événement anodin plutôt qu’en opération très stressante.

Testez votre compréhension des concepts de Microsoft Azure Fundamentals (AZ-900) présentés dans cette leçon.

Dans cette leçon, vous avez appris que les pipelines YAML à plusieurs étapes enchaînent les étapes Build, Staging et Production en transmettant des artefacts, que les tâches de déploiement avec Environments permettent de mettre en place des contrôles d’approbation et un suivi des déploiements, et que les tests de fumée exécutés après le déploiement en préproduction empêchent les mises en production défectueuses. Nous allons maintenant étudier GitHub Actions sur Azure.