06 · Infrastructure as code et maintenance des pipelines

Version : 1.1 · Date : 2026-10-22 · Domaine 3 de l'examen : Design and implement build and release pipelines (50 à 55 %)

En une phrase : l'infrastructure se déclare dans Git, se relit (plan, what-if) et s'approuve avant d'être appliquée ; l'état voulu des machines se surveille et se corrige (Azure Machine Configuration) ; et les pipelines eux-mêmes se mesurent, s'optimisent, se purgent et se migrent comme un produit.

Ce que l'examen demande#

Déjà traité ailleurs, à relire plutôt que redire : IaC sécurisée et deployment stacks dans SC-500 § 9 ; Azure Machine Configuration côté sécurité dans SC-500 § 10 ; IaC en couches d'un cluster dans AKS § 3. Les environments, checks et templates YAML sont détaillés au chapitre 04 ; l'authentification sans secret (OIDC, workload identity federation) au chapitre 07.

1. Les bases à maîtriser#

2. Choisir une technologie de configuration#

Microsoft Learn classe les outils d'automatisation des VM en trois familles : configurer les VM (Ansible, Chef, Puppet, Bicep, ARM ; et pour la personnalisation des VM, cloud-init, PowerShell DSC, Custom Script Extension), gérer l'infrastructure (Packer pour les images, Terraform pour le build de l'infrastructure, Azure Automation pour les actions) et livrer les applications (Azure DevOps, Jenkins).

Piège d'examen : « configurer l'état d'une VM » n'est pas « provisionner une VM ». Bicep crée la VM ; Machine Configuration (ou DSC, Ansible) règle ce qu'il y a dedans. Les deux se combinent : Bicep déploie la VM et l'extension, Azure Policy assigne la configuration.

3. Mettre en œuvre la stratégie de configuration#

Une stratégie qui tient en production repose sur quatre règles :

1. Tout est dans Git : templates Bicep / Terraform, playbooks, paquets de configuration, paramètres par environnement.
2. Une seule source de vérité par couche : ne pas laisser Ansible et Machine Configuration régler le même paramètre.
3. Versionner les paquets de configuration comme du code (Machine Configuration accepte un content_uri et un content_hash pour un paquet personnalisé).
4. Mesurer la conformité en continu plutôt qu'au déploiement seulement (Azure Policy, Resource Graph).

Exemple Terraform (azurerm 5.10.0, arguments vérifiés dans le registre) : assigner la baseline Windows à une VM. La VM doit avoir une system-assigned managed identity et l'extension AzurePolicyforWindows (sinon l'assignation existe mais ne s'exécute pas, note de la documentation du provider) :

resource "azurerm_virtual_machine_extension" "guest_config" {
  name                       = "AzurePolicyforWindows"
  virtual_machine_id         = azurerm_windows_virtual_machine.app.id
  publisher                  = "Microsoft.GuestConfiguration"
  type                       = "ConfigurationforWindows"
  type_handler_version       = "1.29"
  auto_upgrade_minor_version = true
}

resource "azurerm_policy_virtual_machine_configuration_assignment" "baseline" {
  name               = "AzureWindowsBaseline"          # paquet intégré : pas de content_uri ni content_hash
  location           = azurerm_windows_virtual_machine.app.location
  virtual_machine_id = azurerm_windows_virtual_machine.app.id

  configuration {
    assignment_type = "ApplyAndMonitor"                 # Audit | ApplyAndMonitor | ApplyAndAutoCorrect | DeployAndAutoCorrect
    version         = "1.*"
    parameter {
      name  = "Minimum Password Length;ExpectedValue"
      value = "14"
    }
  }
}

À grande échelle, on n'écrit pas une assignation par VM : on assigne une initiative Azure Policy (effet DeployIfNotExists) qui installe l'extension et la configuration, voir SC-500 § 10.

4. Définir la stratégie IaC : Git, tests, déploiement#

4.1 Organisation du dépôt#

4.2 Tester avant d'appliquer#

À propos de what-if (Microsoft Learn) :

• il fonctionne aux portées resource group, subscription, management group et tenant ;
• az deployment group create --confirm-with-what-if (ou -c) montre l'aperçu puis demande confirmation ;
• --validation-level (Azure CLI 2.76.0 ou plus) : Provider (défaut, avec contrôle des droits), ProviderNoRbac, Template ;
• --no-pretty-print donne un JSON à analyser dans le pipeline ;
• les ressources déployées par templateLink (template specs liés) ne sont pas évaluées, et certaines propriétés apparaissent à tort comme supprimées (« bruit ») ;
• pour un deployment stack, what-if signale aussi les ressources qui seraient détachées ou supprimées (actionOnUnmanage).

4.3 Le pipeline de référence#

Le schéma ci-dessus suit l'exemple Microsoft « Deploy to Azure infrastructure with GitHub Actions » : deux identités (une en lecture pour le plan en pull request, une en écriture pour l'apply), un environment production avec approbateurs et limité à main, et un state dans un Storage account.

Le backend Terraform recommandé, avec authentification Entra ID au Storage (et non par clé d'accès) :

terraform {
  backend "azurerm" {
    resource_group_name  = "rg-tfstate-prd"
    storage_account_name = "sttfstateprd"
    container_name       = "tfstate"
    key                  = "plateforme/prod.tfstate"   # une clé par environnement
    use_azuread_auth     = true                        # accès Blob par Entra ID, pas de clé
  }
}

Points de Microsoft Learn à connaître :

• le blob est verrouillé (lease) avant toute écriture du state ; erreur « Error acquiring the state lock » si un autre run tient le verrou ou si une coupure a laissé le lease (bouton Break lease en dernier recours) ;
• l'OIDC ne choisit pas à lui seul le mode Entra du backend : sans use_azuread_auth, le backend peut avoir besoin de récupérer une clé du compte ;
• le state est en clair et peut contenir des secrets : restreindre le compte (réseau privé), et ne pas publier un plan sauvegardé comme artefact ouvert ;
• l'identité du pipeline a besoin d'un rôle de données Blob sur le conteneur du state, séparé de ses droits sur l'infrastructure.

Squelette Azure Pipelines (le détail des environments et checks est au chapitre 04) :

trigger:
  branches: { include: [ main ] }
pr:
  branches: { include: [ main ] }

stages:
- stage: plan
  jobs:
  - job: plan
    steps:
    - task: AzureCLI@2
      inputs:
        azureSubscription: sc-tf-lecture        # service connection en workload identity federation
        scriptType: bash
        scriptLocation: inlineScript
        addSpnToEnvironment: true                # expose l'identité au script
        inlineScript: |
          export ARM_USE_OIDC=true ARM_CLIENT_ID=$servicePrincipalId ARM_TENANT_ID=$tenantId ARM_OIDC_TOKEN=$idToken
          terraform init -input=false
          terraform plan -input=false -out=tfplan

- stage: apply
  dependsOn: plan
  condition: and(succeeded(), eq(variables['Build.SourceBranch'], 'refs/heads/main'))
  jobs:
  - deployment: apply
    environment: prod                            # approvals and checks posés sur l'environment
    strategy:
      runOnce:
        deploy:
          steps:
          - checkout: self
          - script: echo "init, plan puis apply avec la service connection en écriture"

Vérifié : addSpnToEnvironment expose servicePrincipalId, tenantId et idToken (ou servicePrincipalKey pour une connection à secret) ; le provider azurerm lit ARM_USE_OIDC, ARM_CLIENT_ID, ARM_TENANT_ID et ARM_OIDC_TOKEN. Pour un apply long, le guide azurerm recommande plutôt de laisser le provider redemander le jeton : ARM_USE_OIDC: true, SYSTEM_ACCESSTOKEN: $(System.AccessToken), SYSTEM_OIDCREQUESTURI: $(System.OidcRequestUri) et ARM_ADO_PIPELINE_SERVICE_CONNECTION_ID (ID de la service connection) dans env: de la tâche AzureCLI@2, car idToken a une durée de vie courte. Le backend azurerm du state se configure aussi en OIDC (use_oidc = true).

5. Desired state configuration#

5.1 Les quatre outils cités par l'examen#

Ce que Microsoft Learn dit d'Azure Automation State Configuration (à connaître pour l'examen, à ne plus choisir) :

• retrait le 30 septembre 2027, migration vers Azure Machine Configuration ;
• DSC pour Linux dans Azure Automation est retiré depuis le 30/09/2023 ;
• modes de configuration des nœuds : ApplyOnly, ApplyAndMonitor, ApplyAndAutoCorrect (seul le dernier corrige seul la dérive) ;
• données d'état des nœuds conservées 30 jours, à envoyer dans Azure Monitor Logs pour les garder plus longtemps.

Ce qu'apporte Azure Machine Configuration (page de migration) : configurations jusqu'à 100 Mo, rapports dans Azure Resource Graph avec l'ID de ressource et l'état, plusieurs configurations sur la même machine, contrôle du moment de la correction, ressources DSC PowerShell pour Windows et Linux, et serveurs hybrides par Azure Arc.

5.2 Détecter et corriger la dérive#

Piège : un terraform plan programmé chaque nuit qui montre des changements alors que Git n'a pas bougé = drift : quelqu'un a modifié la ressource hors du pipeline. On corrige dans Git (ou on réapplique), jamais en retouchant à nouveau le portail.

6. Azure Deployment Environments#

À savoir en priorité : Azure Deployment Environments est retiré le 22 février 2027 (Microsoft Dev Box le 18 septembre 2028). À cette date, créer, déployer et redéployer seront bloqués ; seuls l'inventaire, la lecture et la suppression resteront un temps. Microsoft propose comme remplacement Bicep / ARM directement, les Azure Verified Modules et des workflows Azure DevOps ou GitHub. Le guide d'examen le cite encore : il faut le connaître, sans le proposer pour un nouveau projet.

6.1 Les composants#

Rôles intégrés : DevCenter Owner, DevCenter Project Admin (gère les environment types du projet), Deployment Environments User (crée des environnements), Deployment Environments Reader (lit ceux des autres).

6.2 Le manifeste#

name: WebApp
version: 1.0.0                 # le versioning n'est pas pris en charge : toujours 1.0.0
summary: Azure Web App Environment
description: Deploys a web app in Azure without a datastore
runner: Bicep                  # ARM | Bicep | image de conteneur personnalisée
templatePath: main.bicep

ARM et Bicep ont une image d'exécution standard ; Terraform n'a pas d'image fournie : il faut construire une image de conteneur personnalisée (modèle d'extensibilité, script ou workflow GitHub fournis par Microsoft), la pousser dans un registre et la référencer : runner: "monregistre.azurecr.io/ade-terraform:1.0". Les développeurs créent un environnement depuis le developer portal, l'Azure CLI (az devcenter), azd, ou un pipeline CI/CD.

7. Surveiller la santé des pipelines#

7.1 Azure Pipelines : les rapports intégrés#

L'onglet Analytics d'un pipeline résume le taux de réussite et la durée ; chaque carte ouvre un rapport complet (14 jours par défaut, modifiable) :

Pour aller plus loin : Analytics OData et Power BI (entity sets PipelineRuns, PipelineRunActivityResults, ParallelPipelineJobsSnapshot, TaskAgentPoolSizeSnapshots), et le Historical graph for agent pools (préversion) pour voir la consommation de concurrence.

7.2 Les tests instables (flaky tests)#

Un test flaky donne des résultats différents (succès, échec) sans changement du code ni de l'environnement. Dans Azure DevOps Services (pas sur Azure DevOps Server) :

1. Activer : Project settings > Pipelines > Test management, bouton sur On.
2. Détecter :
   • System detection : un test qui échoue puis passe au rerun de la tâche VSTest (ou au rerun failed jobs) est marqué flaky, pour toutes les pipelines de la branche ;
   • Custom detection : votre outil appelle l'API Result Meta Data - Update (référence du test, flag, branche).
3. Rapporter : par défaut les flaky restent dans le résumé ; on peut les exclure du résumé pour qu'ils ne fassent plus échouer le pipeline (seulement avec les tâches Visual Studio Test et Publish Test Results).
4. Résoudre : marquer / démarquer à la main, créer un bug ; quand le bug est résolu, le test est démarqué.

Changer de système de détection efface tout l'historique de flakiness.

7.3 GitHub Actions#

Dans l'organisation : Insights > Actions Usage Metrics (minutes consommées) et Actions Performance Metrics (durée moyenne, temps d'attente en file, échecs), par workflow, job, dépôt, OS ou type de runner. Le rôle personnalisé « View organization Actions metrics » permet de déléguer la lecture.

8. Optimiser coût, temps, performance, fiabilité#

Le cache Azure Pipelines (Cache@2) :

variables:
  NUGET_PACKAGES: $(Pipeline.Workspace)/.nuget/packages
steps:
- task: Cache@2
  inputs:
    key: 'nuget | "$(Agent.OS)" | $(Build.SourcesDirectory)/**/packages.lock.json'
    restoreKeys: |
      nuget | "$(Agent.OS)"
      nuget
    path: $(NUGET_PACKAGES)
    cacheHitVar: CACHE_RESTORED            # true, inexact (restore key) ou false
- script: dotnet restore --locked-mode
  condition: ne(variables.CACHE_RESTORED, 'true')

À savoir : le cache est immuable, chargé après la dernière étape du job, expire après 7 jours sans usage, sans limite de taille imposée ; on ne peut pas le vider, on change la clé (ajouter version2 |). Côté GitHub, l'équivalent est actions/cache.

9. Optimiser la concurrence#

Un parallel job est la capacité d'exécuter un job à la fois. Il s'achète au niveau de l'organisation et se partage entre tous les projets.

Les projets publics sont retirés : plus de création ; les existants gardent leur gratuité jusqu'à leur conversion en privé en 2027.

Managed DevOps Pools (évolution des scale set agents, VM dans un abonnement Microsoft) :

• coût = services Azure consommés (VM surtout, disques, sortie de données) + parallel jobs self-hosted ;
• Maximum agents ne sert à rien sans autant de parallel jobs self-hosted (avec 1 seul job gratuit, un seul pipeline tourne à la fois) ;
• Standby agent mode : Off (agent créé à la demande, démarrage plus lent), Manual (planning), Automatic (prédiction sur l'historique, du réglage « Most cost effective » au réglage « Best performance ») ;
• Stateless (« Fresh agent every time », recommandé contre les attaques de la chaîne d'approvisionnement) ou stateful (agent réutilisé jusqu'à 7 jours, avec grace period pour les charges en rafales) ;
• jobs jusqu'à 2 jours ; Azure Hybrid Benefit non utilisable.

Dans le YAML, la concurrence se pilote par dependsOn (stages et jobs indépendants en parallèle), strategy: matrix avec maxParallel, et parallel pour découper les tests.

10. Stratégie de rétention#

10.1 Runs et artefacts de pipeline (Azure Pipelines)#

Dans Project settings > Pipelines > Settings (il n'existe plus de règle par pipeline) :

• jours de conservation des artifacts, symbols et attachments ;
• jours de conservation des runs et des pull request runs ;
• nombre de runs récents à garder par pipeline : avec Azure Repos, ce nombre vaut pour la branche par défaut et chaque branche protégée (avec branch policy), plus le pipeline dans son ensemble.

Un run est supprimé quand il dépasse les jours, n'est pas dans les récents, n'est pas marqué « retain indefinitely » et n'est pas retenu par une release. Le traitement passe une fois par jour, et seuls les runs réussis ou partiellement réussis sont retenus. Supprimer un run efface logs, artefacts, symbols, test results, métadonnées et tags ; pas les packages (NuGet, npm, Universal…). Pour garder un run plus longtemps : une retention lease (API ou tâche dans le pipeline), jamais pour moins longtemps.

Les releases classic ont leurs propres réglages (Release retention, Minimum releases to keep par stage) ; les pipelines YAML multi-stage ne permettent pas une rétention par environment.

10.2 Packages (Azure Artifacts)#

Feed settings > Enable package retention :

• Maximum number of versions per package et Days to keep recently downloaded packages : une version n'est supprimée que si les deux conditions sont réunies ;
• une version promue dans une view (@prerelease, @release) est exemptée ; la promotion est irréversible ;
• les packages et feeds supprimés restent 30 jours dans la Recycle Bin (restauration par un feed owner).

10.3 GitHub Actions#

Logs et artefacts : 90 jours par défaut, réglables dans Settings > Actions > General de 1 à 90 jours pour un dépôt public et de 1 à 400 jours pour un dépôt privé, sans dépasser le plafond fixé par l'organization ou l'enterprise ; une durée propre à un artefact se donne dans le workflow (retention-days de actions/upload-artifact).

11. Migrer de classic vers YAML#

1. Créer un pipeline YAML de départ (New pipeline > Starter pipeline).
2. Sur le pipeline classic de build, dans la vue de la définition (pas d'un run) : ⋯ > Export to YAML. Seuls les pipelines créés avec le classic build designer s'exportent.
3. Coller le contenu dans le YAML de départ ; compléter avec le Task Assistant.
4. Releases classic : pas d'export YAML ; reprendre chaque tâche (option View YAML par agent job) et réécrire les stages en stages YAML avec environments, approvals et checks (chapitre 04).
5. Redéfinir les variables créées dans l'UI (dans le YAML ou en variable groups).
6. Revoir les schedules : le YAML est en UTC, le classic suivait le fuseau de l'organisation.
7. Une fois migré : activer Disable creation of classic build pipelines et Disable creation of classic release pipelines (Organization ou Project settings > Pipelines > Settings). Les nouvelles organisations ont ces réglages activés par défaut.

Pourquoi migrer : le YAML se relit en pull request (branch policies), les ressources protégées passent par approvals et checks, et la désactivation des pipelines classic ferme une porte aux définitions modifiables sans relecture.

12. Labs conseillés#

À faire dans une organisation Azure DevOps et un abonnement de test ; supprimer les resource groups à la fin.

1. Pipeline Terraform en deux identités (1 h, coût : un Storage account). Créer le Storage du state, deux service connections en workload identity federation (lecture, écriture), un environment prod avec approbation. Résultat attendu : le plan s'affiche dans la PR, l'apply attend l'approbation, le blob montre un lease pendant l'apply.
2. what-if et dérive (30 min, gratuit hors ressources). Déployer un Bicep, modifier un tag à la main dans le portail, relancer az deployment group what-if. Résultat attendu : le tag apparaît en Modify ; un redeploy le rétablit.
3. Machine Configuration (45 min, coût : une petite VM). Assigner la baseline Windows en ApplyAndMonitor (Terraform de la section 3 ou initiative Azure Policy). Résultat attendu : conformité visible dans Azure Policy après évaluation.
4. Flaky tests (30 min). Activer la détection, lancer un test qui échoue une fois sur deux avec rerun VSTest. Résultat attendu : le test porte le tag Flaky ; avec l'option d'exclusion, le pipeline ne tombe plus.
5. Classic → YAML (30 min). Créer un build classic (si la création est permise sur l'organisation de test), l'exporter, rejouer en YAML, puis désactiver la création de classic. Résultat attendu : même résultat de build, schedule à recaler en UTC.

13. Pièges d'examen#

14. Scénarios corrigés#

1. Une équipe applique Terraform depuis les postes des développeurs ; deux apply simultanés ont corrompu le state. Que mettre en place ?

Un backend azurerm dans un Storage account (verrou par lease, chiffrement au repos, use_azuread_auth), un pipeline qui fait le plan en PR et l'apply sur main derrière un environment approuvé, et retirer aux humains les droits d'écriture directs.

2. Le RSSI veut qu'un changement d'infrastructure soit relu avant d'être appliqué, sans donner aux relecteurs l'accès à Azure.

Plan Terraform (ou what-if Bicep) dans la validation de build de la PR, résumé publié dans la PR, apply seulement après merge et approbation de l'environment. Les relecteurs lisent le plan, pas le portail.

3. Une banque doit garder ses serveurs Windows (Azure et sur site via Arc) conformes à une baseline et corriger toute dérive. Les scripts actuels tournent sur Azure Automation State Configuration.

Migrer vers Azure Machine Configuration (retrait d'Automation State Configuration le 30/09/2027), assigner la baseline par initiative Azure Policy en ApplyAndAutoCorrect, suivre la conformité dans Azure Policy et Resource Graph.

4. Les développeurs veulent créer seuls un environnement de test (App Service + SQL) dans un abonnement sandbox, avec les politiques de l'entreprise. Option citée par le guide ?

Azure Deployment Environments : catalog d'environment definitions, project environment type « sandbox » pointant vers l'abonnement sandbox avec une deployment identity, rôle Deployment Environments User pour les développeurs. À signaler : retrait le 22/02/2027, l'alternative durable est Bicep / AVM dans un pipeline.

5. Le pipeline échoue 1 fois sur 5 sur un test d'intégration réseau, sans changement de code.

Activer flaky test management (system detection avec rerun VSTest), exclure les flaky du résumé pour débloquer la CI, créer un bug pour corriger le test ; suivre la tendance dans le rapport Test failures.

6. Le build .NET passe 6 minutes à restaurer les paquets NuGet à chaque run.

Cache@2 avec une clé OS + hash de packages.lock.json, restoreKeys en repli, et la restauration conditionnée par cacheHitVar.

7. 20 développeurs, des pipelines qui attendent en file malgré 10 agents self-hosted enregistrés.

La file dépend des parallel jobs self-hosted achetés, pas du nombre d'agents : en acheter davantage (ou réduire les runs inutiles par filtres de chemins).

8. Un Managed DevOps Pool démarre ses agents en 10 minutes le matin ; la facture doit rester maîtrisée.

Standby agent mode en Manual sur les heures de travail (ou Automatic équilibré), ou agents stateful avec grace period si la charge arrive en rafales.

9. L'audit exige de garder 2 ans les runs ayant produit une release en production ; la politique du projet est à 30 jours.

Ajouter une retention lease de 2 ans depuis le pipeline (tâche ou API) sur les runs de production ; la règle de projet ne change pas pour le reste.

10. Migration de 40 pipelines classic (build et release) vers YAML.

Builds : Export to YAML. Releases : réécriture en stages YAML avec environments, approvals et checks. Revoir variables et schedules (UTC), puis activer Disable creation of classic build / release pipelines.

15. Pour aller plus loin#

• Deployment stacks avec deny settings : empêcher la modification manuelle des ressources gérées, et what-if des stacks (SC-500 § 9.2).
• Azure Verified Modules : modules Bicep et Terraform maintenus par Microsoft, base saine d'une stratégie de modules.
• Analytics OData et Power BI : tableaux de bord de taux d'échec et de durée sur tous les pipelines de l'organisation.

16. Fiche à retenir#

• Provisionner (Bicep, Terraform) ≠ configurer (Machine Configuration, DSC, Ansible, Chef, Puppet, cloud-init).
• Bicep : idempotent, sans state, what-if ; Terraform : plan, state distant verrouillé (blob lease), use_azuread_auth.
• Pipeline IaC : plan en PR (identité lecture), apply sur main derrière un environment approuvé (identité écriture).
• Azure Automation State Configuration : retrait 30/09/2027 → Azure Machine Configuration (Azure Policy, Arc, Resource Graph).
• Modes : Audit / ApplyAndMonitor (détecte) ; ApplyAndAutoCorrect (corrige).
• ADE : dev center → catalog → environment definition (environment.yaml, runner) → project environment type (subscription, identity, rôles) ; retrait 22/02/2027.
• Santé : onglet Analytics (pass rate, test failures, duration) ; flaky test management (system / custom detection, exclusion du résumé).
• Parallel jobs : achetés par organisation ; hosted gratuit 1 job, 60 min, 1 800 min/mois ; self-hosted gratuit 1 job sans limite.
• Managed DevOps Pools : coût Azure + parallel jobs self-hosted ; standby agents ; stateless recommandé.
• Cache@2 : clé hashée, restoreKeys, immuable, expire après 7 jours sans usage.
• Rétention : réglages de projet (plus par pipeline), retention lease pour garder plus ; packages : versions max + jours, views exemptées, Recycle Bin 30 j.
• Classic → YAML : Export to YAML pour le build seulement ; release réécrite ; schedules en UTC ; désactiver la création de classic.

Références#

Toutes lues le 21/10/2026 :

• Study guide for Exam AZ-400
• Use infrastructure automation tools with virtual machines in Azure
• What is Bicep?
• Bicep what-if: preview changes before deployment
• Preview deployment stack changes by using what-if
• Store Terraform state in Azure Storage
• Troubleshoot common problems when using Terraform on Azure
• Deploy to Azure infrastructure with GitHub Actions
• Terraform azurerm_policy_virtual_machine_configuration_assignment (registre, azurerm 5.10.0)
• Azure Automation State Configuration overview
• Azure Automation State Configuration to machine configuration migration planning
• Remediate noncompliant Azure Automation State Configuration servers
• Key concepts for Azure Deployment Environments
• Azure Deployment Environments retirement guide
• Properties and parameters in environment.yaml
• What is the ADE extensibility model?
• Configure project environment types
• Pipeline reports
• Manage flaky tests
• Metadata reference for Azure Pipelines Analytics
• Viewing GitHub Actions metrics for your organization (GitHub Docs)
• Pipeline caching
• Configure and pay for parallel jobs
• Managed DevOps Pools pricing
• Managed DevOps Pools : configure scaling
• Overview of Managed DevOps Pools
• Retention policies
• Pipeline run retention (leases)
• Delete and recover packages (Azure Artifacts)
• Remove workflow artifacts (GitHub Docs)
• Migrate your Classic pipeline to YAML
• Determine your approach for securing YAML pipelines (disable creation of classic pipelines)