Microsoft AZ-400: Gestion des mises en production et stratégies de déploiement — Guide d'étude

By Laurynas Brazys · 10 August 2026 · #microsoft #az-400 #certification #exam-prep #study-guide

Fait partie du Microsoft DevOps Engineer Expert AZ-400 — Guide d’étude. Entraînez-vous avec des réponses vérifiées dans le centre d’examens Microsoft, ou passez des tests chronométrés sur ExamRoll.io.

Vue d’ensemble

La gestion des mises en production sur Azure repose sur une livraison reproductible et régie par des politiques, qui protège la disponibilité tout en accélérant les retours. La maîtrise des stratégies de déploiement, des validations conditionnelles, de l’exposition par anneaux et des lancements masqués (dark launches) avec des feature flags permet aux équipes de livrer en continu sans sacrifier la sécurité. Azure Pipelines, Azure Deployment Environments, Azure Front Door/Traffic Manager et Azure App Configuration fournissent une chaîne d’outils cohérente pour la livraison progressive, l’orchestration multi-environnements et un contrôle des changements auditable. Cette section explique quand et comment utiliser chaque capacité, comment les connecter entre elles, et quelles sont les pratiques de rollback et de documentation attendues dans des pipelines de qualité production.

Stratégies de déploiement et livraison progressive

Le déploiement bleu-vert (blue-green ou red/black) déploie la nouvelle version sur un environnement parallèle (vert) pendant que l’actuel (bleu) sert le trafic. Sur Azure App Service, les slots de déploiement implémentent le bleu-vert : déployez sur le slot de préproduction (staging), préchauffez-le, puis effectuez une permutation de slots. Le rollback est instantané en effectuant la permutation inverse, c’est pourquoi le bleu-vert est l’option de rollback la plus rapide. Associez les permutations de slots à l’option « Swap with preview » pour valider les liaisons et les paramètres de l’application avant que le trafic ne soit basculé.

Le déploiement canary (canary) déploie d’abord sur un petit sous-ensemble d’utilisateurs, puis augmente progressivement le trafic tant que l’intégrité est maintenue. Sur Azure, implémentez le canary avec :

• Le routage pondéré d’Azure Front Door pour répartir le trafic entre les anciens et les nouveaux backends au niveau de la couche applicative, avec des sondes d’intégrité et un WAF.
• Les points de terminaison pondérés d’Azure Traffic Manager pour des déploiements canary globaux basés sur le DNS lorsque vous avez besoin d’un contrôle au niveau de la région.
• Le déploiement canary sur AKS via un Ingress (par ex., les annotations canary de NGINX) ou la répartition de trafic d’un service mesh. Les portes de validation devraient évaluer les budgets d’erreurs, les centiles de latence et la saturation avant de poursuivre.

Les mises à jour par roulement (rolling updates) remplacent les instances progressivement, évitant le coût d’une double flotte. Dans AKS, configurez rollingUpdate avec maxSurge et maxUnavailable ; assurez-vous que les sondes readiness/liveness probes et les PDBs protègent la disponibilité. Pour les VM Scale Sets, utilisez des stratégies de mise à niveau par roulement avec des sondes d’intégrité applicative. La mise à jour par roulement est économique mais plus lente à restaurer en cas de régressions systémiques que le bleu-vert.

Les feature flags (indicateurs de fonctionnalité) découplent la mise en production du déploiement. Le lancement masqué (dark launching) livre des chemins de code désactivés par défaut, ce qui permet de tester l’infrastructure sans exposer les fonctionnalités. Utilisez les indicateurs pour contrôler des migrations coûteuses, dévoiler progressivement l’interface utilisateur et désactiver rapidement un comportement problématique. Cela complète les déploiements canary et par anneaux : déployez à grande échelle, puis activez progressivement.

Le déploiement par anneaux (ring-based deployment) formalise l’exposition progressive à travers des cohortes. Définissez des anneaux tels que R0 (interne), R1 (clients canary), R2 (une région) et R3+ (mondial). Les critères de passage à l’anneau suivant doivent être objectifs : conformité aux SLO, aucun incident de type Sev2+, et des indicateurs de performance clés (KPIs) métier acceptables. Associez les anneaux au basculement de trafic (Front Door/Traffic Manager), à des vérifications d’environnement et à des portes d’approbation pour arrêter ou effectuer un rollback précoce.

Azure Front Door versus Traffic Manager pour le basculement de trafic progressif : Front Door opère à la couche 7 avec des changements instantanés, des sondes d’intégrité, l’affinité de session, le routage basé sur le chemin et la répartition pondérée — idéal pour les déploiements canary applicatifs et les tests A/B. Traffic Manager opère au niveau DNS ; il est plus adapté pour le géo-routage, le basculement inter-cloud ou les déploiements canary au niveau régional, mais il implique des considérations de TTL DNS et n’a pas de fonctionnalités de couche applicative.

Environnements, approbations et portes de validation

Azure Deployment Environments standardise le provisionnement des environnements de dev/test avec des garde-fous. Les définitions d’environnement sont des modèles d’infrastructure-as-code (Bicep/ARM/Terraform) qui décrivent des piles reproductibles. Les définitions se trouvent dans des catalogues — des dépôts Git enregistrés auprès du service — permettant d’avoir des plans d’environnement versionnés et détectables. Les développeurs provisionnent en libre-service des instances de dev/test contraintes par les politiques de l’entreprise (quotas, RBAC, réseau), éliminant les environnements uniques (« snowflakes ») et alignant les environnements inférieurs sur la topologie de production.

Les approbations établissent des contrôles avec intervention humaine là où c’est nécessaire. Dans Azure Pipelines :

• Les approbations de pré-déploiement bloquent une étape jusqu’à ce que les approbateurs désignés donnent leur accord. À utiliser pour les transitions à haut risque, par ex., du staging à la production ou l’escalade d’anneau au-delà du canary.
• Les approbations de post-déploiement confirment les activités de validation (validation UAT, étapes d’audit) avant que la mise en production ne soit marquée comme terminée.
• Configurez des délais d’expiration pour les approbations afin que les demandes expirent automatiquement ; les approbations expirées font échouer l’étape et empêchent toute dérive non contrôlée. Exigez plusieurs approbateurs ou des approbations séquentielles lorsque la séparation des tâches est nécessaire. Appliquez les approbations aux environnements et aux connexions de service via « Approbations et vérifications » pour une gouvernance cohérente.

Les portes de mise en production (release gates) exigent des preuves objectives avant toute promotion. Azure Pipelines prend en charge des vérifications telles que :

• Les vérifications Azure Monitor qui interrogent des métriques ou des alertes (par ex., aucune alerte Sev2 active, taux d’erreur inférieur au seuil, latence p95 sous la cible). Les portes se réévaluent à un intervalle défini jusqu’au succès/échec ou à l’expiration du délai.
• Les vérifications « Invoke REST API » pour appeler des services de qualité externes, des tests de charge ou des points de terminaison de conformité internes. Analysez les réponses et bloquez si les critères ne sont pas remplis.
• Les vérifications de requêtes d’éléments de travail pour s’assurer que les tâches, bogues ou demandes de changement requis sont dans les bons états avant la mise en production (par ex., tous les défauts « Must Fix » sont résolus). Utilisez des requêtes limitées à la portée de la mise en production ou à la plage de commits.

Implémentez des portes aux frontières des anneaux et pendant le déploiement canary pour passer de décisions de promotion subjectives à des décisions mesurables.

Pipelines multi-environnements, variables et dépendances

Concevez des pipelines YAML multi-étapes avec des dépendances explicites et une portée par environnement. Utilisez des jobs de déploiement avec des blocs de stratégie (runOnce, rolling, canary) pour modéliser un déploiement progressif et incluez des hooks pour preDeploy, routeTraffic, postRouteTraffic et on: failure pour une restauration automatisée. Les étapes (stages) doivent déclarer des dependsOn et des conditions afin que les environnements ultérieurs ne s’exécutent qu’après que les précédents ont passé les portes (gates) et les approbations.

Gérez la configuration spécifique à l’environnement via :

• Des groupes de variables définis par environnement, liés à Azure Key Vault pour les secrets. Référencez les groupes par étape et conservez les valeurs sensibles hors du contrôle de code source.
• Des modèles YAML et des paramètres d’exécution pour standardiser les déploiements entre les services et passer des valeurs spécifiques à l’environnement (chaînes de connexion, valeurs par défaut des feature flags, pondération Front Door).
• Des tâches de tokenisation ou de transformation pour les appsettings et les manifestes Kubernetes, garantissant une configuration as code sans dérive.

Pour les déploiements dans plusieurs environnements, préférez les artefacts immuables avec promotion (construire une fois, déployer plusieurs fois). Liez les work items aux commits et aux builds pour maintenir la traçabilité lorsque le même artefact passe du développement à la production, permettant des notes de version et des audits précis.

Stratégies de restauration et considérations sur les bases de données

Planifiez les restaurations avant de livrer :

• La restauration automatique utilise des signaux de santé pour revenir en arrière sans action humaine. Dans AKS, définissez maxSurge/maxUnavailable de manière conservatrice et activez la restauration automatique en cas d’échec des déploiements ; utilisez kubectl rollout undo ou fiez-vous aux hooks d’échec de la stratégie de déploiement pour déclencher un ReplicaSet précédent. Dans Azure App Service, l’inversion du slot swap est instantanée ; associez-la à des vérifications de l’état de santé et à des portes de déploiement pour décider automatiquement.
• La restauration manuelle est appropriée lorsque la récupération nécessite le jugement d’un opérateur (risque de données, échec partiel). Fournissez des tâches de pipeline en un clic qui redirigent les pondérations de Front Door/Traffic Manager, annulent les slot swaps ou redéploient le dernier build fonctionnel connu. Gardez l’artefact précédent facilement accessible et documentez le processus de décision.
• La restauration de base de données exige une attention particulière. Évitez les changements non rétrocompatibles. Utilisez le pattern expand-contract : ajoutez des colonnes/tables et remplissez-les pendant que les lectures/écritures restent compatibles ; déployez du code qui écrit dans les deux schémas si nécessaire ; ne supprimez les éléments obsolètes que plus tard. Pour Azure SQL Database, combinez :
  • DACPAC ou des frameworks de migration (EF Core) avec des scripts idempotents et versionnés et une validation pré/post-déploiement.
  • Des opérations en ligne (reconstruction d’index avec option resumable, basculement de partition) pour minimiser la contention de verrous.
  • La restauration à un instant T et la géo-réplication active en dernier recours, en reconnaissant le risque de perte de données. Désactivez les fonctionnalités via des feature flags avant toute rétrogradation du schéma. Conditionnez les promotions sur la santé de la base de données (DTU/CPU, deadlocks) capturée dans Azure Monitor et Query Store.

Indicateurs de fonctionnalité avec Azure App Configuration et automatisation des notes de version

Azure App Configuration centralise la gestion des fonctionnalités avec des SDK pour .NET, Java, Node.js, et autres. Utilisez des étiquettes pour délimiter les indicateurs par environnement ou anneau de déploiement et activez l’actualisation dynamique pour que les applications prennent en compte les changements sans redéploiement.

• Les filtres de ciblage permettent une activation granulaire basée sur l’utilisateur/groupe, les revendications (claims), l’appareil ou des attributs personnalisés. Définissez des cohortes (par ex., locataires internes, clients VIP) pour les aligner sur les anneaux de déploiement.
• Le déploiement par pourcentage expose progressivement les fonctionnalités à un sous-ensemble aléatoire. Commencez à 1–5 %, validez les indicateurs de performance clés (KPI), puis augmentez. Coordonnez avec la pondération de Front Door pour un contrôle à plusieurs niveaux, au niveau de l’utilisateur et du trafic.
• Les kill switches (interrupteurs d’urgence) désactivent instantanément une fonctionnalité en cas d’incident. Protégez les chemins à haut risque (paiements, écritures de données) avec un interrupteur global qui ne nécessite aucun déploiement pour être activé. Journalisez toutes les bascules pour l’audit et corrélez-les avec les incidents.

Automatisez les notes de version pour assurer la traçabilité et la communication :

• Imposez la liaison des éléments de travail en exigeant que les messages de commit et les PR fassent référence à des ID. Azure DevOps associe automatiquement les builds et les releases aux éléments de travail et aux commits.
• Générez des journaux de modifications (changelogs) dans les pipelines à l’aide de la tâche Generate Release Notes ou d’appels à l’API REST pour lister les changements et les éléments de travail depuis le dernier déploiement réussi vers l’environnement cible. Produisez du Markdown avec des sections pour les fonctionnalités, les correctifs, les changements de rupture (breaking changes) et les migrations de base de données.
• Publiez les notes sur le Wiki du projet, empaquetez-les en tant qu’artefact de build et joignez-les à la release. Incluez les métadonnées de déploiement (numéro de build, SHA du commit, environnement, approbateurs, portes franchies) pour la conformité.

Scénario de problème pratique

Adobe doit introduire un nouveau moteur de personnalisation sur ses sites marketing hébergés sur Azure sans risquer de baisser les taux de conversion pendant les campagnes de pointe. L’équipe doit déployer fréquemment, exposer la fonctionnalité progressivement, valider les SLO et effectuer un rollback instantané si les KPI se dégradent.

1. Définir les environnements avec Azure Deployment Environments

• Créez des définitions d’environnement (Bicep) pour l’application, AKS, Azure SQL et Front Door dans un catalogue Git. Les développeurs auto-provisionnent dev/test en toute sécurité, garantissant la parité avec la production et permettant des piles de test éphémères pour les expérimentations. ADE applique des quotas et le RBAC pour contrôler les dépenses et les accès.

2. Construire une fois, déployer plusieurs fois avec un YAML multi-étapes

• Un artefact unique est promu à travers les étapes ring-r0, ring-r1, ring-r2 et prod. Les étapes dépendent les unes des autres et utilisent des travaux de déploiement avec une stratégie : canary et rolling le cas échéant, garantissant des binaires cohérents à travers les anneaux.

3. Utiliser le déploiement bleu-vert avec les emplacements (slots) App Service pour la couche web héritée

• Déployez sur un emplacement de préproduction (staging slot), préchauffez-le, puis échangez-le (swap) pour les utilisateurs internes de ring-r0. Si les SLO d’Adobe régressent, un nouvel échange d’emplacement (slot swap back) fournit le rollback le plus rapide avec un temps d’arrêt quasi nul.

4. Introduire le canary via le routage pondéré d’Azure Front Door

• Enregistrez les backends de personnalisation hérités et nouveaux. Commencez avec 1 % du trafic vers le nouveau backend dans ring-r1. Les sondes d’intégrité (health probes) de Front Door et les mises à jour de poids instantanées permettent des ajustements rapides et sûrs, alignés sur les modèles de trafic.

5. Verrouiller les promotions avec des portes de validation objectives

• Ajoutez des vérifications Azure Monitor pour la latence p95, le taux d’erreur et les KPI de conversion provenant d’Application Insights. Ajoutez une vérification via l’API REST au service d’expérimentation interne d’Adobe pour confirmer les métriques de garde-fou. Configurez une vérification par requête d’élément de travail pour s’assurer que les bogues « Must Fix » sont fermés avant de passer à l’anneau suivant. Les portes sont évaluées périodiquement et expirent (time out) pour éviter les changements bloqués.

6. Exiger des approbations aux transitions critiques

• Les approbations de pré-déploiement pour ring-r2 et prod nécessitent la validation du marketing et des SRE, avec un délai d’expiration de 4 heures pour éviter les releases en attente. Les approbations de post-déploiement confirment que les tests d’acceptation utilisateur (UAT) et la validation analytique sont terminés avant de clore la release.

7. Contrôler l’exposition avec les indicateurs de fonctionnalité d’Azure App Configuration

• Mettez en œuvre le lancement furtif (dark launching) afin que le nouveau moteur soit présent mais initialement désactivé. Utilisez des filtres de ciblage pour l’activer pour le personnel interne (ring-r0) et des cohortes de clients sélectionnées (ring-r1). Appliquez le déploiement par pourcentage pour étendre l’exposition. Un kill switch désactive le moteur globalement en quelques secondes sans redéploiement si des anomalies apparaissent.

8. Protéger les données avec des migrations d’expansion-contraction

• Déployez d’abord les changements SQL additifs, remplissez les données de manière asynchrone (backfill) et effectuez une double écriture si nécessaire. Ce n’est qu’après avoir prouvé la stabilité qu’ils suppriment le schéma obsolète. Les portes surveillent les DTU, les interblocages (deadlocks) et les requêtes longues pour empêcher une promotion dangereuse.

9. Automatiser les chemins de rollback

• Les hooks d’échec sur les travaux de déploiement déclenchent le rollback : les poids de Front Door reviennent à 0 % pour le nouveau backend ; App Service effectue un échange d’emplacement (slot swap) inversé ; AKS exécute

undefined

. Un rollback manuel en un clic reste disponible pour les opérateurs dans les scénarios complexes.

10. Automatiser la documentation de la release

• Le pipeline génère des notes de version en Markdown à partir des éléments de travail et des commits associés, en mettant en évidence les fonctionnalités activées, les changements de base de données et les portes franchies. Les notes sont publiées sur le Wiki d’Azure DevOps et jointes à la release, satisfaisant ainsi les exigences d’audit et de visibilité pour les parties prenantes.

Cette approche utilise chaque outil pour ses points forts : ADE pour des environnements sûrs et reproductibles ; les stratégies YAML et les approbations pour un flux gouverné ; Front Door et App Configuration pour une livraison progressive à plusieurs niveaux ; Azure Monitor et les portes pour un contrôle qualité objectif ; et les rollbacks et notes de version automatisés pour la résilience et la traçabilité.

← Conteneurisation et Kubernetes · Tous les domaines · Sécurité →

Entraînez-vous sur ces questions → · Tests chronométrés sur ExamRoll.io →

Parcourir Microsoft →