Azure Pipelines : CI/CD, agents et premiers YAML

À la fin de ce tutoriel, vous saurez ce qu’est Azure Pipelines, comment fonctionne le build process sur un agent éphémère (pool Microsoft-hosted), créer un premier pipeline YAML (hello bash), un pipeline multi-jobs, puis un build ASP.NET Core (.NET Framework) produisant WebApp.zip — sans secrets ni PAT en clair.

Niveau : Débutant · Temps estimé : 50–70 min · Versions testées : Azure DevOps Services (portail 2026), YAML Pipelines, agents Microsoft-hosted · Dernière vérification : 2026-09-12

Slug proposé : azure-devops-azure-pipeline · Post live : #1042 · Série : Hub mega-menu « Azure Pipelines » · Région lab Azure : canadacentral (aucune ressource Azure créée ici)

Prérequis

• Démarrer avec Azure DevOps : organisation, projet ado-lab (Private)
• Repo Git (Azure Repos, GitHub ou Bitbucket) avec branche main
• Droits Build Administrator ou Project Administrator pour Create Pipeline
• Compte MFA ; navigateur récent
• Exemple ASP.NET : solution .sln .NET Framework (sinon exemples 1–2 seulement)
• Minutes Microsoft-hosted Free tier (quelques runs)

Coût estimé : 0 € hors quota Free (souvent 1 800 min/mois Microsoft-hosted — indicatif 2026). Aucune ressource canadacentral ici.

Ce que nous allons construire

Hub Azure Pipelines (vue d’ensemble + 3 labs)
  ├── Concepts : CI/CD, agent VM éphémère, agent pool, types d’agents
  ├── Example-1 : Create Pipeline → Azure Repo → ubuntu-latest + bash echo
  ├── Example-2 : multi-jobs Firstjob / Secondjob (YAML corrigé)
  └── ASP.NET Core (.NET Framework) : windows-latest + NuGet + VSBuild → WebApp.zip
Trigger
  └── Push sur la branche suivie → run automatique

(Schéma texte — alt : « Azure Pipelines : agent pool Microsoft-hosted, jobs YAML et build ASP.NET vers WebApp.zip ».)

Vue d’ensemble du hub Azure Pipelines. Suite : YAML intro, Microsoft-hosted, self-hosted, ci-build, release, pipeline GitHub.

Étape 1 — Azure Pipeline = automation CI/CD

Azure Pipelines fournit l’automation CI/CD : compiler, tester, empaqueter, déployer. Historiquement « Build & Release » (VSTS), le produit unifié s’appelle Azure Pipelines.

Approche	Idée	Usage lab
YAML (recommandé)	Fichier versionné (azure-pipelines.yml)	Reproductible, reviewable en PR
Classic (UI)	Définition côté projet	Legacy / migration

Ce tutoriel (et le hub) privilégie le YAML avec agent Microsoft-hosted, comme le live historique — modernisé pour main, indentation correcte et tâches documentées.

Concept	Rôle
Pipeline	Définition CI/CD (YAML ou classic)
Run	Une exécution concrète
Agent	Machine (VM) qui exécute les jobs
Agent pool	Collection d’agents (ex. « Azure Pipelines »)
Job / steps	Unité de travail + tâches séquentielles
Trigger	Événement qui démarre un run (push, PR, manuel)

Étape 2 — Build process : VM éphémère, repos, pools

Ce que fait un run de build

1. Azure Pipelines alloue une VM (invisible dans vos VMs Azure d’abonnement).
2. L’agent clone le code depuis Azure Repos (ou GitHub / Bitbucket).
3. Les jobs / steps s’exécutent (Windows, Linux ou macOS selon l’image).
4. Fin du build → la VM est jetée : environnement intermédiaire, pas une machine permanente.

Cette VM est un agent, membre d’un agent pool. Le type dépend de vmImage (YAML) ou de la définition classic.

Types d’agents (aperçu hub)

Type	Qui gère	Lab typique
Microsoft-hosted	Microsoft (ubuntu-latest, windows-latest, macOS-latest)	Exemples 1–2 et ASP.NET
Self-hosted	Vous (VM, PC, scale set)	Minutes Free insuffisantes / outils custom — self-hosted

Détail pools/images : agents Microsoft-hosted. CI réelle : ci-build.

Rappel région : toute ressource Azure (App Service, RG…) des labs suivants doit être en canadacentral. Ce chapitre ne crée aucune ressource Azure — seulement des runs d’agents hosted.

Étape 3 — Example-1 : premier pipeline YAML (hello)

Objectif : pipeline minimal ubuntu-latest + step bash — équivalent modernisé du live « Azure Basic Pipeline Code ».

1. Projet ado-lab → Pipelines → Create Pipeline.
2. Where is your code? → Azure Repos Git (ou GitHub / Bitbucket).
3. Sélectionnez le repository.
4. Starter ou Existing Azure Pipelines YAML file ; remplacez par le YAML ci-dessous.
5. Save and run → branche main → Run.

# azure-pipelines.yml — Example-1 hello — PAS de secrets / PAT
# Agent pool = collection de VMs ; ici image Microsoft-hosted Ubuntu
trigger:
  - main

pool:
  vmImage: ubuntu-latest

# Steps = partie d’un job (job implicite si non déclaré)
steps:
  - bash: echo "Azure Basic Pipeline Code"
    displayName: "Hello Azure Pipelines"

Points à retenir :

1. pool.vmImage: ubuntu-latest : agent Linux Microsoft-hosted du pool Azure Pipelines.
2. steps / bash : tâche sur la VM ; un job implicite encapsule les steps sans jobs:.
3. Save and Run enregistre souvent le YAML et lance le premier run.
4. Branche : préférez main ; sur master legacy, alignez trigger et le run.
5. Aucun PAT, connection string ou mot de passe dans le fichier.

Après le run : logs → Azure Basic Pipeline Code. Statut : Succeeded. Suite : yaml-intro.

Étape 4 — Example-2 : multi-jobs Firstjob / Secondjob

Même parcours Create Pipeline, avec plusieurs jobs. Le YAML live historique était cassé (indentation / pool / steps). Version corrigée :

# azure-pipelines.yml — Example-2 multi-jobs — PAS de secrets
trigger:
  - main

# Agent pool : collection de VMs ; ubuntu-latest pour les deux jobs
pool:
  vmImage: ubuntu-latest

jobs:
  - job: Firstjob
    timeoutInMinutes: 10
    steps:
      - bash: echo "The First job"
        displayName: "Echo Firstjob"

  - job: Secondjob
    timeoutInMinutes: 10
    steps:
      - bash: echo "Our Second Pipeline"
        displayName: "Echo Secondjob"

• Chaque job obtient typiquement sa propre VM éphémère.
• timeoutInMinutes: 10 limite la durée (hygiène Free tier).
• Jobs parallèles consomment des parallel jobs du Free tier : en lab, enchaînez ou acceptez l’attente si le quota est saturé.
• displayName rend les logs lisibles dans le portail.

Vérification : un run avec deux jobs verts, messages The First job et Our Second Pipeline.

Étape 5 — ASP.NET Core (.NET Framework) : NuGet + VSBuild → WebApp.zip

Build ASP.NET Core (.NET Framework) sur agent Windows : variables, NuGet restore, packaging IIS (WebApp.zip).

1. Pipelines → New Pipeline.
2. Azure Repo contenant le code ASP.NET Framework.
3. Template ASP.NET Core (.NET Framework) si proposé ; alignez sur le YAML ci-dessous.
4. Save and run.

# ASP.NET Core (.NET Framework) — lab hub Azure Pipelines
# Build + package WebApp.zip — PAS de secrets / PAT
# Doc : https://learn.microsoft.com/azure/devops/pipelines/languages/dotnet-core

# Trigger : tout changement sur main lance le pipeline automatiquement
trigger:
  - main

pool:
  vmImage: windows-latest

variables:
  solution: "**/*.sln"
  buildPlatform: "Any CPU"
  buildConfiguration: "Release"

steps:
  # NuGetToolInstaller@1 : installe / prépare l’outil NuGet sur la VM
  - task: NuGetToolInstaller@1
    displayName: "Install NuGet tool"

  # NuGetCommand@2 : restore des packages pour la solution ($(solution))
  - task: NuGetCommand@2
    displayName: "NuGet restore"
    inputs:
      restoreSolution: "$(solution)"

  # VSBuild@1 : MSBuild + package WebDeploy unique WebApp.zip
  - task: VSBuild@1
    displayName: "Build + WebApp.zip"
    inputs:
      solution: "$(solution)"
      msbuildArgs: '/p:DeployOnBuild=true /p:WebPublishMethod=Package /p:PackageAsSingleFile=true /p:SkipInvalidConfigurations=true /p:DesktopBuildPackageLocation="$(build.artifactStagingDirectory)WebApp.zip" /p:DeployIisAppPath="Default Web Site"'
      platform: "$(buildPlatform)"
      configuration: "$(buildConfiguration)"

Tâche	Rôle
NuGetToolInstaller@1	Préparer NuGet sur la VM Windows
NuGetCommand@2	Restore NuGet ($(solution))
VSBuild@1	MSBuild + WebApp.zip dans $(build.artifactStagingDirectory)

• windows-latest requis pour MSBuild / .NET Framework de cet exemple.
• Variables réutilisées dans les inputs — pas de secrets.
• Zip = artefact de staging ; publication durable : PublishPipelineArtifact (ci-build).
• Déploiement : azure-release-pipeline. GitHub : azure-devops-azure-pipeline-2.

Étape 6 — Note trigger : changement de branche → run auto

Note (live préservé) : avec un trigger sur main (ou master), tout push sur cette branche relance automatiquement le pipeline. Cœur de la CI : plus besoin de Save and Run à chaque commit.

• Limitez le trigger à main pour économiser les minutes Free.
• PR avant merge : pr: + Build validation (yaml-intro).
• Run manuel : Run pipeline sans nouveau commit.
• Jamais de PAT dans un echo ou une variable non secrète.

Étape 7 — Checklist qualité (hub)

• [ ] Expliquer : CI/CD, VM agent éphémère, pool, types d’agents
• [ ] Example-1 : Succeeded + echo "Azure Basic Pipeline Code"
• [ ] Example-2 : Firstjob / Secondjob verts (YAML corrigé)
• [ ] (Option) ASP.NET : NuGet + VSBuild + WebApp.zip en staging
• [ ] Trigger auto vérifié par un push sur main (sans secret)
• [ ] Branche main (ou master documenté) ; aucun PAT versionné

Étape 8 — Vérification de fin de parcours

1. Pipeline YAML lié au repo (Azure Repos ou GitHub via chap. 2).
2. Run hello Succeeded sur ubuntu-latest.
3. Run multi-jobs avec les deux echo.
4. (Si .sln) build Windows NuGet + VSBuild.
5. Push sur la branche trigger → run auto ; historique Git sans secrets.

Nettoyage

• Gardez les pipelines hello / multi-jobs comme socle pédagogique du hub.
• Supprimez les runs ratés en masse seulement si le bruit gêne (l’historique aide à apprendre).
• Si un PAT a été collé par erreur : révoquez immédiatement ; retirez la ligne ; considérez l’historique Git compromis.
• Économisez le Free tier : évitez trigger trop large et les jobs Windows inutiles.
• Aucune ressource canadacentral à supprimer dans ce chapitre.

Lab bonus (8–12 min) — ubuntu vs windows

1. Branche feature : second job windows-latest avec pwsh: Write-Host "Hello from Windows".
2. Logs : Agent.OS / image (Microsoft-hosted).
3. Annulez le job Windows pour préserver les minutes ; remettez ubuntu-latest pour la suite.

Scénario terrain (débutant)

« L’équipe veut une vue d’ensemble Azure Pipelines (agent jetable, pool), un hello YAML, un multi-job, puis un build ASP.NET → WebApp.zip, trigger auto sur main. » → exemples 1–2, puis Windows si .sln Framework. Ensuite YAML, agents, CI, release — sans PAT.

Erreurs fréquentes

Symptôme	Cause	Correction
YAML mapping / indent (Example-2)	pool / jobs mal indentés (live cassé)	YAML corrigé étape 4
/bin/bash sur Windows	bash + windows-latest	ubuntu-latest pour bash ; pwsh sur Windows
Pipeline ne démarre pas au push	Trigger ≠ branche / pipeline non créé	Aligner trigger: - main + créer le pipeline
NuGet / VSBuild fail	Pas de .sln / mauvais $(solution)	Vérifier le glob ; template ASP.NET Framework
WebApp.zip introuvable	Args MSBuild incomplets	Garder DesktopBuildPackageLocation + staging
Parallel job / queue	Free tier saturé	Attendre, cancel runs, ou self-hosted
Secret / PAT dans les logs	echo d’un secret	Révoquer ; Variable groups / Key Vault
Image 404 dans un article	Asset distant mort	Couverture locale WebP uniquement

Quiz (5 questions)

1. Que fait principalement Azure Pipelines ? – A. Remplacer Azure Boards par Excel
– B. Fournir l’automation CI/CD (build, test, déploiement)
– C. Créer automatiquement un Resource Group canadacentral sans YAML

2. Après un build Microsoft-hosted, que devient la VM agent ? – A. Elle reste facturée comme VM Azure permanente dans votre abonnement
– B. Elle est jetée (environnement éphémère)
– C. Elle est convertie en App Service

3. Dans Example-2, pourquoi le YAML live d’origine échouait souvent ? – A. Parce que ubuntu-latest est interdit
– B. Structure jobs/steps/pool incorrecte (YAML cassé)
– C. Parce que bash est réservé à macOS

4. Quelle image convient au lab ASP.NET Framework + VSBuild de ce chapitre ? – A. windows-latest
– B. Uniquement macOS-latest
– C. Aucune image — classic editor obligatoire

5. Que se passe-t-il si vous poussez un commit sur la branche listée dans trigger ? – A. Rien — il faut toujours cliquer Save and Run
– B. Le pipeline est exécuté automatiquement
– C. Azure Repos est supprimé

Réponses : 1‑B · 2‑B · 3‑B · 4‑A · 5‑B

Pour aller plus loin

• Doc : Azure Pipelines, YAML schema, .NET, hosted agents
• Suite hub : YAML intro → agents hosted / self-hosted → CI build → release → pipeline GitHub

Maillage hub Azure Pipelines

← Hub / démarrage	Démarrer avec Azure DevOps
→ YAML approfondi	Azure Pipelines YAML : introduction
Agents	Microsoft-hosted · Self-hosted
CI / CD	CI build · Azure Release Pipeline
Aussi	Azure pipeline using GitHub

---

Retour parcours Azure DevOps — hub de la série et leçons sœurs.