Guide - AZ-400 Microsoft Azure DevOps Engineer Expert

Appliquer la qualité du code (build, test, couverture) avant de fusionner une pull request.

Sur la branche cible, configurez une politique de validation de build qui déclenche un pipeline lors de la création d'une PR. Le pipeline doit publier les résultats de couverture de code. Définissez une politique de branche pour une couverture minimale.

Pourquoi: Cela applique la qualité avant la fusion. Un déclencheur CI standard s'exécute après la fusion. Les portes de release sont pour les déploiements, pas les PRs.

Sélectionner une stratégie de branchement Git qui minimise les conflits de fusion et supporte le déploiement rapide et continu en production.

Implémentez le développement basé sur le tronc avec des branches de fonctionnalités de courte durée qui sont fusionnées fréquemment avec `main` (quotidiennement ou plus).

Pourquoi: Empêche les branches de diverger significativement, réduisant les conflits de fusion et garantissant que la branche `main` est toujours proche d'un état livrable.

Protéger une branche critique (par exemple, `main`) en appliquant les revues de code, les builds réussis et le lien vers les éléments de travail avant les fusions.

Configurez les politiques de branche sur la branche `main` dans Azure Repos. Activez les politiques pour un nombre minimum de réviseurs, la validation de build et le lien vers les éléments de travail.

Pourquoi: Les politiques de branche fournissent une application côté serveur qui ne peut pas être contournée par les développeurs, assurant une qualité et une conformité de processus constantes.

Sélectionner une stratégie de branchement Git pour une équipe avec des releases planifiées, un développement de fonctionnalités en parallèle, et un besoin de branches de hotfix dédiées.

Implémentez le modèle de branchement GitFlow, qui utilise les branches `main`, `develop`, `feature/*`, `release/*` et `hotfix/*`.

Pourquoi: GitFlow fournit un cadre robuste pour gérer des cycles de release complexes, isolant le nouveau développement de la stabilisation des releases et des correctifs d'urgence.

Un secret a été accidentellement committé et poussé. Il doit être complètement supprimé de tout l'historique Git.

D'abord, faites pivoter le secret exposé. Ensuite, utilisez un outil comme `git-filter-repo` ou BFG Repo-Cleaner pour réécrire l'historique, en supprimant le fichier. Forcez le push des changements et notifiez tous les développeurs de re-cloner.

Pourquoi: Un simple `git rm` ou revert ne supprime pas le secret de l'historique. La réécriture de l'historique est requise pour une purge permanente.

Modéliser un workflow complexe avec des étapes parallèles et des dépendances entre les étapes.

Utilisez les pipelines YAML multi-étapes. Utilisez le mot-clé `dependsOn` pour les dépendances d'étape et configurez des jobs parallèles au sein des étapes.

Pourquoi: YAML offre l'approche la plus flexible et basée sur le code pour l'orchestration complexe, supérieure aux pipelines classiques ou à l'enchaînement de pipelines séparés.

Implémenter un déploiement sans interruption et à faible risque pour une application web avec une capacité de rollback instantané.

Utilisez les slots de déploiement Azure App Service. Déployez sur un slot de staging (vert), validez, puis effectuez un échange de slot avec la production (bleu).

Pourquoi: Un échange de slot est une opération atomique, quasi-instantanée qui redirige le trafic. Le rollback est aussi simple que de rééchanger.

Référence

Minimiser la duplication de pipeline pour de nombreux microservices qui partagent des étapes de build/déploiement communes mais nécessitent des personnalisations spécifiques.

Créez des templates YAML dans un dépôt central. Dans chaque pipeline spécifique au service, utilisez le mot-clé `extends` et passez des paramètres pour la personnalisation.

Pourquoi: `extends` promeut les principes DRY et applique les standards tout en permettant la flexibilité via des paramètres. Plus puissant que les groupes de tâches pour des structures de pipeline entières.

Restreindre une étape de pipeline (par exemple, déploiement en production) à s'exécuter uniquement lors des fusions vers une branche spécifique (par exemple, main).

Utilisez une `condition` sur l'étape ou le job. Par exemple, `condition: and(succeeded(), eq(variables['Build.SourceBranch'], 'refs/heads/main'))`.

Pourquoi: Les builds de validation de PR utilisent une référence de branche source différente (par exemple, `refs/pull/...`), donc cette condition empêche correctement le déploiement pendant le cycle de vie de la PR.

Déployer des applications d'Azure DevOps vers des serveurs on-premises derrière un pare-feu d'entreprise.

Installez des agents auto-hébergés sur les serveurs on-premises. Enregistrez-les dans un pool d'agents dans Azure DevOps.

Pourquoi: Les agents auto-hébergés initient une communication sortante vers Azure DevOps, donc aucune règle de pare-feu entrante n'est nécessaire. Ils peuvent accéder aux ressources du réseau local pour le déploiement.

Exiger une approbation multi-personnes pour les déploiements en production et les restreindre à des fenêtres de maintenance spécifiques.

Définissez un environnement Azure DevOps pour la production. Configurez les approbations avec les approbateurs requis. Ajoutez un contrôle "Business Hours" comme porte pour faire respecter la plage horaire.

Pourquoi: Les environnements centralisent les contrôles de déploiement. Les approbations et les portes offrent une application robuste et automatisée des politiques avant l'exécution d'une étape.

Contrôler l'exposition des fonctionnalités aux utilisateurs sans redéployer l'application, avec des mises à jour quasi-en temps réel.

Utilisez Azure App Configuration pour la gestion des fonctionnalités. Instrumentez l'application pour lire les drapeaux et activez ses capacités de rafraîchissement dynamique.

Pourquoi: Découple les releases de fonctionnalités des déploiements. App Configuration fournit une UI centralisée et des SDK pour les mises à jour dynamiques, évitant les redémarrages d'application.

Gérer l'état d'un cluster Kubernetes de manière déclarative, où Git est la seule source de vérité et les changements sont automatiquement appliqués.

Déployez un agent GitOps comme Flux ou ArgoCD sur le cluster AKS. Configurez l'agent pour qu'il surveille un dépôt Git contenant les manifestes Kubernetes et synchronise automatiquement l'état du cluster.

Pourquoi: Ce modèle basé sur le "pull" permet une réconciliation continue et une détection de dérive, ce qui est au cœur de GitOps. Il est plus robuste que les pipelines `kubectl` basés sur le "push".

Gérer l'état Terraform pour la collaboration d'équipe, en assurant la sécurité et en empêchant les modifications concurrentes.

Configurez le backend Terraform pour utiliser un compte de stockage Azure. Cela fournit un stockage d'état distant, avec un verrouillage d'état géré via le bail de blob Azure.

Pourquoi: Empêche la corruption du fichier d'état due à des opérations `apply` simultanées et maintient les données d'état sensibles hors du contrôle de code source.

Référence

Dans un monorepo, déclencher le pipeline CI d'une application uniquement lorsque des fichiers dans son répertoire spécifique (ou un répertoire partagé) sont modifiés.

Dans le YAML du pipeline, utilisez le filtre `trigger.paths.include` pour spécifier les répertoires pertinents, par exemple, `include: ['/apps/frontend/**', '/apps/shared/**']`.

Pourquoi: Cela évite les builds inutiles pour des changements de code non liés, économisant du temps CI et des ressources de calcul.

Optimiser une étape de test avec des tests rapides (unitaires) et lents (d'intégration) pour un feedback plus rapide.

Exécutez les tests unitaires et les tests d'intégration dans des jobs parallèles au sein de la même étape.

Pourquoi: L'exécution parallèle fournit les résultats des tests unitaires beaucoup plus rapidement tandis que les tests plus lents s'exécutent simultanément. La durée totale de l'étape est déterminée par le job le plus long, et non par la somme.

Versionner automatiquement un package de bibliothèque basé sur l'historique des commits pour communiquer clairement l'impact des changements (cassant, fonctionnalité, correction).

Intégrez un outil comme GitVersion dans le pipeline CI. Il analyse les messages de commit, les branches et les tags pour calculer automatiquement une version SemVer (Majeur.Mineur.Patch).

Pourquoi: SemVer fournit un versionnement significatif sur lequel les consommateurs peuvent compter pour la gestion des dépendances, contrairement aux numéros de build ou aux hachages de commit.

Déployer une application dans plusieurs régions géographiques une par une, avec validation après chaque déploiement régional.

Utilisez un pipeline YAML multi-étapes avec des étapes séquentielles, une pour chaque région, en utilisant `dependsOn` pour appliquer l'ordre. Utilisez des portes d'environnement entre les étapes pour la validation.

Pourquoi: Ce modèle de déploiement basé sur des anneaux contient le rayon d'impact d'un mauvais déploiement à une seule région, permettant un rollback avant d'impacter tous les utilisateurs.

Configurer un pipeline pour supporter un modèle de développement basé sur le tronc, garantissant que la branche principale est toujours déployable.

Configurez un déclencheur CI sur la branche `main`. Appliquez les PRs avec une politique de validation de build qui exécute des tests rapides et complets. Intégrez des notifications rapides (par exemple, vers Teams/Slack) pour les échecs de build.

Pourquoi: Un feedback immédiat est critique dans le développement basé sur le tronc. Cette combinaison empêche le code cassé de fusionner et assure une correction rapide lorsque des problèmes surviennent.

Transférer de gros artefacts (par exemple, des modèles ML, >5 Go) entre les étapes de pipeline de manière efficace.

Téléchargez le grand artefact vers Azure Blob Storage dans l'étape productrice. Passez l'URI du blob à l'étape consommatrice comme variable de sortie.

Pourquoi: Azure Blob Storage est plus rentable et plus performant que les artefacts de pipeline intégrés pour les fichiers de plusieurs gigaoctets.

Réduire les temps de build en évitant de retélécharger les dépendances (par exemple, NuGet, npm) à chaque exécution.

Utilisez la tâche `Cache@2`. Définissez une clé basée sur le fichier de verrouillage du package (par exemple, `packages.lock.json`). La tâche stockera et restaurera le dossier de dépendances.

Pourquoi: Peut économiser plusieurs minutes par build en restaurant depuis un cache local rapide au lieu de récupérer depuis des dépôts externes.

Construire ou déployer le même code sur plusieurs cibles (par exemple, différents OS, régions) en parallèle.

Utilisez une `strategy: matrix` dans le job du pipeline YAML. Définissez des variables pour chaque combinaison, ce qui générera un job pour chaque entrée de la matrice.

Pourquoi: Une stratégie de matrice maintient la définition du pipeline DRY, créant plusieurs variations de job à partir d'une seule définition et les exécutant en parallèle.

Implémenter un déploiement Canary sur AKS qui déplace automatiquement le trafic et promeut ou annule en fonction de métriques en temps réel.

Utilisez un contrôleur de livraison progressive comme Flagger, intégré à un service mesh (par exemple, Istio) et un fournisseur de métriques (par exemple, Prometheus).

Pourquoi: Flagger automatise l'ensemble du processus d'analyse Canary, offrant une livraison progressive plus sûre et plus fiable que les scripts manuels.

Un pipeline d'application doit se déclencher lorsque le code change dans son propre dépôt OU dans un dépôt de bibliothèque partagée séparé.

Dans le YAML de l'application, définissez la bibliothèque partagée sous `resources.repositories` et configurez un bloc `trigger` sur cette ressource.

Pourquoi: Crée une dépendance déclarative entre les dépôts, garantissant que l'application est toujours reconstruite avec les derniers composants partagés.

Un pipeline doit créer une infrastructure temporaire pour les tests et s'assurer qu'elle est détruite après, même si les tests échouent.

Utilisez un pipeline multi-étapes avec des étapes d'application et de destruction séparées pour l'IaC (Terraform/Bicep). Configurez l'étape de destruction avec `condition: always()` ainsi que l'étape de création.

Pourquoi: La condition `always()` garantit que l'étape de nettoyage s'exécute indépendamment du succès ou de l'échec des étapes précédentes, évitant les ressources orphelines.

Empêcher un déploiement en production de se poursuivre à moins qu'il n'y ait une demande de changement approuvée dans un outil ITSM comme ServiceNow.

Configurez une porte d'environnement qui invoque la porte "Query ServiceNow" pour vérifier le statut de la demande de changement.

Pourquoi: Automatise l'intégration avec les processus de gestion du changement d'entreprise, garantissant la conformité sans transferts manuels.

Fournir un pool d'agents de build auto-hébergés qui s'adapte dynamiquement à la demande pour réduire les temps d'attente et contrôler les coûts.

Configurez un pool d'agents Azure DevOps en utilisant un groupe de machines virtuelles identiques Azure (VMSS), configuré pour s'adapter automatiquement en fonction du nombre de jobs en attente.

Pourquoi: Les agents VMSS combinent la personnalisation des agents auto-hébergés avec l'élasticité des agents hébergés dans le cloud, optimisant les performances et les coûts.

Déployer les changements de schéma de base de données d'une manière qui prévient la perte de données et supporte les rollbacks.

Utilisez un outil de migration (par exemple, Flyway, DbUp). Implémentez le pattern expand/contract pour les changements de schéma afin de maintenir la compatibilité descendante.

Pourquoi: Les outils de migration fournissent la gestion de version et le contrôle. Le pattern expand/contract découple les rollbacks d'application et de base de données, permettant des déploiements plus sûrs.

Les agents auto-hébergés manquent d'espace disque à cause des artefacts de build accumulés.

Dans le YAML du pipeline, au niveau du job, configurez `workspace: clean: all`.

Pourquoi: Cette configuration préventive du pipeline résout la cause première sans nécessiter d'intervention manuelle ou de changements continus d'infrastructure.

Les tests d'intégration nécessitent une instance de base de données isolée pour chaque exécution de pipeline.

Définissez une ressource de conteneur (par exemple, SQL Server, Postgres) comme service dans le YAML du pipeline. Le job de test peut alors se connecter à ce service éphémère.

Pourquoi: Fournit des dépendances rapides, isolées et automatiquement nettoyées pour les tests, évitant les interférences de test et simplifiant la configuration.

Améliorer la fiabilité et la performance de la restauration de packages depuis des dépôts publics (par exemple, npmjs, nuget.org).

Dans Azure Artifacts, créez un flux et configurez des sources amont pointant vers les dépôts publics. Faites en sorte que les clients consomment des packages depuis le flux Azure Artifacts.

Pourquoi: Le flux met en cache les packages des sources amont, protégeant contre les pannes des dépôts publics et accélérant les restaurations pour les packages fréquemment utilisés.

Déployer un chart Helm dans plusieurs environnements (dev, prod) avec des valeurs de configuration différentes.

Utilisez des fichiers `values-<env>.yaml` séparés pour chaque environnement. Dans la tâche `HelmDeploy`, utilisez l'entrée `valueFile` pour spécifier le fichier approprié et `overrideValues` pour injecter des valeurs dynamiques comme les tags d'image.

Pourquoi: Ce modèle sépare la configuration statique de l'environnement des variables de pipeline dynamiques, gardant les déploiements propres et maintenables.

Gérer et consommer en toute sécurité des secrets (par exemple, des chaînes de connexion) dans les pipelines sans les coder en dur.

Stockez les secrets dans Azure Key Vault. Dans Azure DevOps, créez un groupe de variables lié au Key Vault. Référencez les secrets du groupe de variables dans le pipeline.

Pourquoi: Centralise la gestion des secrets, permet la rotation sans modifications de pipeline, et fournit un contrôle d'accès robuste et un audit via Key Vault.

Implémenter l'analyse de sécurité dans le pipeline CI pour détecter les vulnérabilités dans le code de l'application (SAST) et les dépendances tierces (SCA).

Intégrez l'extension Microsoft Security DevOps, qui inclut plusieurs scanners. Envisagez également GitHub Advanced Security pour Azure DevOps pour une suite native et complète.

Pourquoi: Cette approche "shift-left" identifie les vulnérabilités tôt dans le cycle de vie du développement, réduisant les coûts et les risques.

Restreindre l'accès des développeurs aux environnements de production pour empêcher les modifications directes, tout en permettant un accès d'urgence audité.

Supprimez les rôles permanents de Contributeur/Propriétaire. Utilisez les connexions de service de pipeline pour les déploiements. Pour les urgences, utilisez Azure AD Privileged Identity Management (PIM) pour un accès élevé Just-In-Time (JIT).

Pourquoi: PIM fournit un accès élevé limité dans le temps, avec approbation et entièrement audité, adhérant au principe du moindre privilège.

Fournir des secrets aux microservices dans AKS de manière sécurisée, avec rotation automatique et accès spécifique à la charge de travail.

Utilisez Azure Key Vault intégré avec le Secrets Store CSI Driver pour AKS. Utilisez l'identité de charge de travail pour les pods afin de s'authentifier auprès de Key Vault.

Pourquoi: Monte les secrets directement dans les pods depuis Key Vault, évitant les Secrets Kubernetes. Permet l'identité au niveau du pod et une rotation transparente des secrets.

Référence

Appliquer que seules les images conteneur scannées et signées peuvent être déployées sur un cluster Kubernetes de production.

Utilisez le Content Trust d'Azure Container Registry (ACR) pour la signature d'images. Utilisez Microsoft Defender for Containers pour l'analyse. Utilisez Azure Policy pour Kubernetes pour appliquer les politiques sur AKS.

Pourquoi: Fournit une stratégie de défense en profondeur complète, basée sur des politiques, pour la sécurité des images conteneur, du build à l'exécution.

Connecter Azure Pipelines aux ressources Azure sans utiliser de secrets client ou de certificats.

Créez une connexion de service Azure Resource Manager en utilisant "Workload Identity Federation".

Pourquoi: Élimine le besoin de gérer et de faire pivoter les secrets, améliorant la posture de sécurité du système CI/CD.

Déployer sur l'abonnement Azure d'un client depuis votre organisation Azure DevOps sans échanger de secrets.

Déployez un agent auto-hébergé au sein de l'environnement Azure du client. Attribuez une identité managée à la VM/VMSS de l'agent et accordez-lui les rôles RBAC nécessaires.

Pourquoi: Maintient tous les principaux d'authentification au sein du locataire du client, adhérant à un modèle de confiance zéro. Aucun secret ne traverse les limites des locataires.

Gérer le travail de plusieurs équipes sur un grand produit, en permettant l'autonomie des équipes tout en offrant une visibilité inter-équipes à la direction.

Utilisez un seul projet avec des chemins d'accès de zone pour chaque équipe afin de leur donner des backlogs filtrés. Utilisez les plans de livraison pour visualiser la progression et les dépendances entre les équipes.

Pourquoi: Permet des rapports de rollup et le suivi des dépendances tout en permettant à chaque équipe de gérer ses propres sprints et éléments de travail indépendamment.

Lier automatiquement les commits/PRs aux éléments de travail et faire passer l'état de l'élément de travail (par exemple, à "Résolu") lors de la fusion d'une PR.

Dans les paramètres du projet, activez "Compléter automatiquement les éléments de travail avec les pull requests". Les développeurs doivent utiliser `#<ID>` dans les messages de commit ou lier les PRs.

Pourquoi: Réduit la charge de travail manuelle pour les développeurs, maintient le statut des éléments de travail à jour et améliore la traçabilité entre le code et les exigences.

Mesurer les métriques clés de processus comme le temps de cycle, le temps de livraison et les métriques DORA pour l'analyse de la chaîne de valeur.

Utilisez le service Azure DevOps Analytics et son flux OData. Connectez Power BI ou utilisez les widgets de tableau de bord intégrés pour visualiser ces métriques.

Pourquoi: Le service Analytics fournit les données sous-jacentes pour les métriques clés de flux et SRE, permettant l'amélioration des processus basée sur les données.

Enquêter sur les temps de réponse lents intermittents qui sont masqués par les métriques de performance moyennes.

Dans Application Insights, utilisez la lame Performance avec l'analyse des percentiles (P95, P99) et la recherche de transactions pour explorer des échantillons de requêtes lentes spécifiques.

Pourquoi: Les moyennes peuvent être trompeuses. Les percentiles révèlent la "longue traîne" des problèmes de performance, qui représentent souvent les utilisateurs les plus frustrés.

Tracer une seule requête utilisateur lorsqu'elle traverse plusieurs microservices pour identifier les goulots d'étranglement ou les points de défaillance.

Instrumentez tous les services avec le SDK Application Insights. Il propage automatiquement un ID de corrélation W3C Trace Context à travers les appels de service.

Pourquoi: Fournit une vue unifiée d'une transaction distribuée dans la carte d'application, permettant de déboguer des interactions complexes.

Surveiller de manière proactive l'objectif de niveau de service (SLO) d'une application et être alerté *avant* que le SLO ne soit violé.

Définissez des SLIs à l'aide de requêtes KQL dans Azure Monitor. Créez une règle d'alerte qui se déclenche en fonction du taux de consommation du budget d'erreur (à quelle vitesse le budget est consommé).

Pourquoi: Les alertes de taux de consommation sont prédictives, donnant le temps de réagir avant qu'un SLO ne soit violé et que les utilisateurs ne soient significativement impactés.

Valider qu'un déploiement a été fonctionnellement réussi du point de vue de l'utilisateur, et non seulement que les tâches du pipeline se sont terminées.

Comme étape post-déploiement ou porte de release, exécutez des tests de disponibilité d'Application Insights (surveillance synthétique) qui simulent les flux utilisateur clés.

Pourquoi: Le succès du pipeline indique seulement que les bits ont été déplacés. Les tests synthétiques confirment que l'application fonctionne réellement, détectant les mauvaises configurations ou les échecs de dépendance.

Corréler visuellement les événements de déploiement avec les changements de performance d'application et les métriques de taux d'erreur.

Utilisez la tâche Azure Pipelines pour créer des "Annotations de Release" dans Application Insights, ce qui place un marqueur sur les graphiques de métriques.

Pourquoi: Fournit un feedback visuel immédiat pour identifier rapidement si un déploiement récent a introduit une régression de performance ou un bug.

Tester de manière proactive la résilience des applications et de l'infrastructure aux pannes de manière contrôlée.

Intégrez Azure Chaos Studio dans les pipelines de release. Créez des expériences qui injectent des pannes (par exemple, arrêt de VM, latence réseau) et validez le comportement du système.

Pourquoi: Dépasse les tests de comportement attendu pour tester les pannes inattendues, renforçant la confiance dans la résilience du système.