Dans partie 1, le azure-pipelines.yml a été fusionné dans la branche main via une Pull Request. Dans cette deuxième partie, nous attachons ce YAML à un pipeline et l’exécutons sur un agent Windows hébergé par Microsoft dans le cloud.

La section Pipelines

La section Pipelines dans la barre latérale contient plus d’éléments que Repos :

  • Pipelines — les pipelines CI (build)
  • Environnements – objectifs de déploiement tels que l’acceptation et la production
  • Releases — les pipelines de versions visuelles classiques (ancien système, remplacé par YAML à plusieurs étapes)
  • Bibliothèque — groupes de variables et fichiers sécurisés
  • Groupes de tâches : blocs de tâches réutilisables pouvant être partagés sur plusieurs pipelines
  • Groupes de déploiement — agents auto-hébergés regroupés par environnement

Sur un nouveau projet, la liste Pipelines est vide.

Page Pipelines vides avec le bouton Créer un pipeline

Créer un pipeline : l’assistant

Via Créer un pipeline, l’assistant en quatre étapes démarre : Connecter → Sélectionner → Configurer → Réviser.

Étape 1 — Connectez-vous : où est le code ? ADO prend en charge Azure Repos Git, GitHub, Bitbucket Cloud, d’autres serveurs Git et Subversion. En bas, il y a également un lien vers l’éditeur classique — l’ancien générateur de pipeline visuel sans YAML. Ceci n’est plus activement développé.

Assistant de pipeline étape 1 : sélection de la source

Étape 2 — Sélectionnez : quel référentiel ? Puisqu’il n’y a qu’un seul dépôt dans le projet, dev-ops-lab01 est la seule option.

Assistant de pipeline étape 2 : sélection d’un référentiel

Étape 3 — Configurer est automatiquement ignorée. ADO détecte qu’un azure-pipelines.yml existe déjà à la racine du dépôt et passe directement à Review.

Étape 4 — Vérifier : le YAML existant est affiché. ADO lit le fichier directement à partir du dépôt — rien n’est copié ou stocké séparément. Le pipeline est le YAML dans le dépôt.

Étape 4 de l’assistant de pipeline : révision YAML avec le code existant

Le YAML créé dans la partie 1 :

 1trigger:
 2  - main
 3
 4pool:
 5  vmImage: 'windows-latest'
 6
 7steps:
 8  - task: PowerShell@2
 9    displayName: 'System information'
10    inputs:
11      targetType: 'inline'
12      script: |
13        Write-Host "Hostname: $env:COMPUTERNAME"
14        Write-Host "OS: $env:OS"
15        Write-Host "Build number: $(Build.BuildNumber)"
16        Write-Host "Branch: $(Build.SourceBranchName)"

Les composants clés :

Mot cléSignification
triggerUn push vers main démarre automatiquement le pipeline
pool.vmImageAgent hébergé par Microsoft : windows-latest est l’image Windows Server la plus récente
stepsLa liste des étapes à exécuter
task: PowerShell@2Une tâche ADO intégrée, version 2
$(Build.BuildNumber)Variable ADO intégrée, renseignée automatiquement
$(Build.SourceBranchName)Variable ADO intégrée avec le nom de la branche

Via Exécuter, le pipeline est démarré pour la première fois.

La première exécution

Après le démarrage, ADO affiche le résumé de l’exécution. Le pipeline s’est terminé avec succès.

Résumé de la course : étape terminée en 15 s

Ce qui est visible :

  • #20260414.1 — numéro de build, construit à partir de la date et du numéro de séquence
  • PR fusionné 1 : ajout d’azure-pipelines.yml — le commit sur lequel il a été exécuté
  • branche main, commit aaedef9f — le commit de fusion exact du PR dans la partie 1
  • Étape : 1 tâche terminée en 15 s – durée d’exécution totale, y compris le provisionnement des agents

Le journal des tâches

En cliquant sur Tâche, vous ouvrez la vue détaillée du journal. La barre latérale gauche affiche toutes les étapes qu’ADO exécute automatiquement autour des étapes YAML personnalisées :

  • Initialiser la tâche — l’agent est configuré
  • Checkout dev-ops-lab01@main — le dépôt est cloné sur l’agent
  • Informations système — la tâche PowerShell personnalisée
  • Post-job : Checkout – nettoyage après le check-out
  • Finaliser le travail : l’agent approuve
  • Rapport sur l’état de la construction — l’état est signalé au dépôt

Journal de travail avec toutes les étapes et horaires

Le journal principal affiche les métadonnées de l’agent : Pool: Azure Pipelines, Image: windows-latest, Agent: Azure Pipelines 1. Il s’agit d’une machine virtuelle jetable dans un centre de données Microsoft qui a été provisionnée à la demande pour cette tâche et détruite une fois terminée.

Sortie PowerShell

Résultat de l’étape Informations système :

Sortie de tâche PowerShell avec nom d’hôte et variables

1Hostname: runnervm67wqg
2OS: Windows_NT
3Build number: 20260414.1
4Branch: main

L’agent est nommé runnervm67wqg : une machine virtuelle Windows hébergée par Microsoft et attribuée de manière aléatoire. Les variables ADO $(Build.BuildNumber) et $(Build.SourceBranchName) ont été automatiquement renseignées par la plateforme avec les valeurs correctes.

Ce qui a été réalisé

Après cette deuxième partie, le fonctionnement d’un pipeline YAML dans Azure DevOps apparaît clairement :

  • L’assistant de pipeline lie un fichier YAML du dépôt à une définition de pipeline
  • ADO détecte automatiquement un azure-pipelines.yml existant
  • Un agent hébergé par Microsoft est provisionné à la demande, exécute la tâche et est ensuite supprimé
  • Les variables ADO intégrées sont disponibles à chaque étape sans aucune configuration
  • Le journal des tâches affiche toutes les étapes, y compris les étapes automatiques ajoutées par ADO lui-même

Dans la troisième partie, nous étendrons le pipeline avec des stages et des jobs — les éléments de base de véritables pipelines CI/CD avec plusieurs environnements.