Microsoft AZ-400: Pipelines CI/CD avec Azure Pipelines — 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.

Déploiements, Environnements, Stratégies et Portes

Les travaux de déploiement fournissent une sémantique de CD de premier ordre. Un travail de déploiement cible un environnement et s’exécute selon une stratégie qui contrôle les déploiements progressifs (rollouts) et les hooks de cycle de vie :

• Les environnements représentent les cibles de déploiement (par ex., dev, test, prod) et peuvent contenir des ressources comme des clusters Kubernetes, des machines virtuelles, ou des ressources génériques « none » pour des déploiements agnostiques à la plateforme. Les environnements unifient la télémétrie, les approbations et les vérifications.
• Les approbations et les vérifications sont attachées aux environnements et aux connexions de service. Les approbations requièrent des approbateurs désignés avant que le déploiement ne continue. Les vérifications agissent comme des portes (gates) qui évaluent des conditions telles que les heures de bureau, les éléments de travail requis, les signaux Azure Monitor, l’appel d’API REST ou d’Azure Functions, et la protection de branche. Celles-ci empêchent la promotion si les lignes de base de performance ou les conditions de conformité ne sont pas satisfaites.
• Les stratégies façonnent la manière dont les mises à jour sont déployées :
  • runOnce applique les changements en une seule vague, avec des hooks preDeploy et postDeploy.
  • rolling déploie par lots sur les instances, avec des seuils maxParallel et de défaillance pour une progression sûre.
  • canary déplace le trafic progressivement par incréments, avec des phases routeTraffic et postRouteTraffic pour valider avant le déploiement complet.
  • blue-green (aussi appelé red/black) est implémenté en déployant sur un environnement ou un slot parallèle et en basculant le trafic au niveau du répartiteur de charge ou par un échange de slot App Service. Bien que blue-green ne soit pas une stratégie YAML nommée, elle est réalisée via des environnements, du routage et des tâches d’échange, et fournit un retour en arrière rapide en restaurant le trafic.

Encodez la logique de déploiement en tant que travail de déploiement par étape d’environnement. Tirez parti des vérifications d’environnement pour des portes robustes, plutôt que d’utiliser des interrogations par script ad-hoc. Lorsque des secrets sont nécessaires, récupérez-les depuis Azure Key Vault via une connexion de service plutôt que de les intégrer dans des variables.

Artefacts, Mise en Cache et Connexions de Service

Les artefacts et la mise en cache améliorent la réutilisation et les performances :

• Les artefacts de pipeline sont le moyen natif de publier et de consommer les sorties de build. Utilisez PublishPipelineArtifact pour publier des artefacts nommés et DownloadPipelineArtifact pour les récupérer depuis l’exécution actuelle ou une exécution spécifique. Ils sont optimisés pour la fiabilité et le partage entre étapes en YAML. Pour consommer depuis un autre pipeline, déclarez une ressource de pipeline et utilisez le nom de sa ressource d’artefacts pour une récupération précise.
• Les paquets universels (Universal packages) fournissent une distribution binaire versionnée et immuable via Azure Artifacts pour les actifs non spécifiques à un langage (par ex., outils CLI, fichiers de données). Publiez et téléchargez avec les tâches Universal Packages, organisez via des vues de flux (par ex., prerelease vs release), et gérez la rétention dans les flux.
• La mise en cache de pipeline accélère la restauration des dépendances. La tâche Cache utilise une clé et un chemin. Les clés doivent hasher les fichiers de verrouillage (package-lock.json, Pipfile.lock, packages.lock.json, go.sum) ainsi que les versions de l’OS et des outils pour une invalidation précise. Les clés de restauration (restore keys) fournissent des correspondances de repli pour les correspondances partielles de cache (cache hits). Évitez d’intégrer des secrets dans les chemins de cache, respectez les limites de taille du cache, et désactivez la mise en cache pour les outils éphémères lorsque les fichiers de verrouillage sont instables. Observez cacheHitVar pour conditionner le comportement des tâches.

Les connexions de service définissent l’identité qu’Azure Pipelines utilise pour atteindre les systèmes externes :

• Les types incluent Azure Resource Manager (pour les abonnements et groupes de ressources Azure), GitHub (lecture/écriture de dépôt, rapport de statut), et Docker/Container Registry (Docker Hub, ACR). D’autres existent pour AWS, GCP, des points de terminaison de service génériques, et des registres de paquets.
• La fédération OIDC (workload identity federation) supprime les secrets à longue durée de vie en établissant une confiance entre Azure DevOps et les fournisseurs d’identité cloud. Pour ARM, configurez une application Entra ID avec une information d’identification fédérée liée à l’émetteur Azure DevOps et aux revendications de dépôt/pipeline. À l’exécution, Azure DevOps échange un jeton à courte durée de vie contre un jeton d’accès au cloud, éliminant les secrets de principal de service et réduisant le risque de fuite d’informations d’identification.
• Le cadrage (scoping) et la gouvernance sont essentiels. Limitez la portée des connexions ARM au moindre privilège (idéalement au niveau du groupe de ressources avec un RBAC personnalisé). Désactivez « Accorder l’autorisation d’accès à tous les pipelines » et autorisez plutôt explicitement les pipelines. Attachez des approbations et des vérifications aux connexions de service pour exiger une revue humaine ou une validation de politique avant utilisation.

Pipelines classiques vs YAML et migration

Les pipelines classiques utilisent le concepteur visuel avec des concepts distincts de Build et de Release. Ils offrent une création basée sur les tâches, la gestion des variables, des environnements de mise en production et des portes (gates). Les pipelines YAML fournissent le pipeline-as-code, l’unification multi-étapes, des modèles (templates) et un versionnement robuste avec le dépôt. La parité des fonctionnalités est en grande partie atteinte : les approbations et les vérifications d’environnement remplacent les portes de mise en production ; les travaux de déploiement modélisent les environnements ; les artefacts de pipeline remplacent les artefacts de build ; et les modèles (templates) et extends implémentent une gouvernance centrale à grande échelle. Les différences restantes concernent généralement les interventions manuelles basées sur l’interface utilisateur et certaines fonctionnalités de niche du concepteur de release, qui sont couvertes en YAML via les tâches de validation manuelle (Manual Validation) et les vérifications d’environnement.

Un parcours de migration pragmatique est le suivant :

1. Inventorier les définitions de build et de release classiques, les tâches, les variables, les environnements, les approbations et les portes (gates).
2. Convertir le build en YAML à l’aide de l’assistant ou de l’exportation vers YAML, puis le refactoriser en modèles (templates) pour la réutilisation et la maintenabilité.
3. Modéliser chaque environnement de mise en production comme une étape (stage) YAML avec un travail de déploiement (deployment job) ciblant un environnement. Traduire les portes de mise en production (release gates) en approbations et vérifications d’environnement (par exemple, les vérifications de requête Azure Monitor, les vérifications de requête d’élément de travail).
4. Externaliser les variables partagées dans des groupes de variables et lier Key Vault pour les secrets. Remplacer les secrets de principal de service par des connexions de service basées sur OIDC.
5. Remplacer les déclencheurs d’artefact de release par des déclencheurs de ressource de pipeline. Publier les artefacts de pipeline en CI et les consommer dans les étapes de CD.
6. Valider la parité en exécutant temporairement les deux pipelines, puis basculer et retirer les définitions classiques avec des plans de restauration (rollback) appropriés.

Scénario de Problème Pratique

Starbucks standardise la livraison pour une plateforme de microservices et doit migrer des releases classiques vers YAML tout en appliquant des portes de performance, en réduisant le risque lié aux informations d’identification et en accélérant les builds.

1. Créer un YAML multi-étapes avec des modèles extends

• Approche : Créer un modèle extends central au niveau de l’organisation qui injecte des étapes communes pour l’analyse statique, la SCA et les contrôles de sécurité, ainsi que des notifications standard. Chaque pipeline de service étend ce modèle et définit des étapes de build et de déploiement spécifiques au service.
• Justification : Extends applique la gouvernance de manière uniforme et maintient les pipelines de service légers tout en garantissant les étapes de conformité requises.

2. Implémenter les déclencheurs CI, PR, de planification et de pipeline

• Approche : Configurer les déclencheurs CI et PR avec des filtres de chemin pour chaque service ; ajouter une planification nocturne pour les tests d’intégration de longue durée ; chaîner un pipeline de packaging pour déclencher un pipeline de déploiement via des ressources de pipeline.
• Justification : Assure un retour rapide sur les modifications de code, des contrôles de santé périodiques et une promotion déterministe des artefacts connus.

3. Utiliser une stratégie d’agents mixtes avec des pools d’agents

• Approche : Les travaux de build s’exécutent sur des agents ubuntu-latest hébergés par Microsoft pour l’élasticité ; les travaux de déploiement s’exécutent sur des agents auto-hébergés à l’intérieur du VNet de Starbucks avec accès aux clusters internes. Isoler les agents par pools pour chaque environnement et restreindre l’utilisation des pools.
• Justification : Les agents hébergés minimisent la maintenance pour la CI ; les agents auto-hébergés fournissent une portée réseau sécurisée pour la CD. La portée des pools applique le principe du moindre privilège.

4. Gérer les variables avec des groupes de variables et des paramètres d’exécution

• Approche : Placer les valeurs partagées non secrètes dans des groupes de variables, récupérer les secrets depuis Azure Key Vault via des groupes de variables liés, et exposer un paramètre booléen enablePerfGate pour activer/désactiver les portes de performance dans les branches de non-production.
• Justification : La configuration centralisée évite la duplication ; Key Vault protège les secrets ; les paramètres pilotent les choix de structure au moment de la compilation.

5. Définir les travaux de déploiement avec des environnements, des approbations et des vérifications

• Approche : Modéliser dev, staging et prod comme des environnements. Ajouter des approbations pour staging et prod. Ajouter des vérifications : heures ouvrables pour prod, et une vérification de requête Azure Monitor qui bloque la promotion si la latence en staging dépasse la ligne de base.
• Justification : Les approbations et les vérifications au niveau de l’environnement implémentent une promotion contrôlée et appliquent les SLO avant le déploiement en production.

6. Appliquer des stratégies canary puis blue-green

• Approche : Utiliser une stratégie canary en staging pour valider les incréments. En production, déployer sur un slot/environnement parallèle et basculer le trafic (blue-green/red-black) avec une capacité de restauration instantanée.
• Justification : La stratégie canary réduit le risque pendant la validation ; la stratégie blue-green minimise le temps de déploiement et fournit la restauration la plus rapide.

7. Optimiser avec les artefacts de pipeline et la mise en cache

• Approche : Publier les sorties de build en tant qu’artefacts de pipeline ; les consommer dans les étapes de déploiement. Mettre en cache la restauration des dépendances en utilisant des clés basées sur le hachage du fichier de verrouillage (lockfile) avec restoreKeys comme solution de repli.
• Justification : Les artefacts assurent une promotion immuable et traçable ; la mise en cache réduit considérablement les temps de build sans sacrifier la justesse.

8. Sécuriser les connexions de service avec OIDC et des permissions délimitées

• Approche : Créer des connexions de service ARM en utilisant la fédération d’identité de charge de travail (workload identity federation) avec une portée limitée aux groupes de ressources. Exiger des approbations et des vérifications pour les connexions de service, et désactiver « Accorder l’accès à tous les pipelines ».
• Justification : Supprime les secrets à longue durée de vie et applique le principe du moindre privilège avec des approbations auditables.

Cette conception de bout en bout aligne la gouvernance YAML-as-code avec des approbations et des vérifications de niveau entreprise, accélère la livraison grâce à la mise en cache et aux artefacts, et renforce la sécurité via OIDC et des connexions de service à portée délimitée.

← Gestion du code source et des dépôts · Tous les domaines · Infrastructure en tant que code et gestion de la configuration →

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

Parcourir Microsoft →