Azure DevOps: Azure Pipeline Using GitHub

À 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

Prérequis

• Démarrer avec Azure DevOps : organisation, projet ado-lab (Private)
• Repo Git dans Azure Repos (ou GitHub / Bitbucket — connecteur possible) avec branche main (ex-master sur anciens labs)
• Droits Build Administrator ou Project Administrator (lab) pour Create Pipeline
• Compte MFA ; navigateur récent
• Pour l’exemple ASP.NET : solution .sln ciblant le .NET Framework (template portail « ASP.NET Core (.NET Framework) ») — sinon suivez les exemples 1 et 2 seulement
• Budget : minutes Microsoft-hosted du Free tier ADO (quelques runs consomment quelques minutes)

Coût estimé : 0 € hors quota Free (souvent 1 800 min/mois Microsoft-hosted pour org Free — chiffres indicatifs 2026, vérifiez le portail). Aucune ressource Azure canadacentral créée 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 à remplacer par une image locale Excalidraw / draw.io, alt : « Azure Pipelines : agent pool Microsoft-hosted, jobs YAML et build ASP.NET vers WebApp.zip ».)

Ce chapitre est la vue d’ensemble du hub mega-menu Azure Pipelines. Le YAML détaillé continue dans azure-pipelines-yaml-intro ; les agents dans Microsoft-hosted et self-hosted ; le CI build dans ci-build ; la release dans azure-release-pipeline ; le cas GitHub dans azure-devops-azure-pipeline-2.

Étape 1 — Azure Pipeline = automation CI/CD

Azure Pipelines est le service Azure DevOps qui fournit l’automation CI/CD : compiler, tester, empaqueter, puis déployer vers des environnements. Historiquement « Build & Release » (VSTS), le produit unifié s’appelle aujourd’hui Azure Pipelines.

Deux façons de définir un pipeline :

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

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.

Concepts à ancrer dès maintenant :

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. pool « 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 machine virtuelle (que vous ne voyez pas dans le portail Azure VMs de votre abonnement).
2. L’agent clone / récupère le code depuis Azure Repos (aussi GitHub, Bitbucket, etc. selon la connexion).
3. Les jobs et steps s’exécutent sur cette VM (Windows, Linux ou macOS selon l’image).
4. Une fois le build terminé (succès ou échec), la VM est jetée : environnement intermédiaire, pas une machine permanente à administrer.

Cette VM est un agent, membre d’un agent pool. Le type d’agent dépend de l’image / du pool choisi dans le YAML (vmImage) ou dans la définition classic.

Types d’agents (aperçu hub)

Type	Qui gère	Lab typique
Microsoft-hosted	Microsoft (images ubuntu-latest, windows-latest, macOS-latest)	Exemples 1–2 et ASP.NET de ce chapitre
Self-hosted	Vous (VM, PC, scale set)	Quand minutes Free insuffisantes ou outils custom — voir agents self-hosted

Détail des pools et images : agents Microsoft-hosted. Pour la CI réelle (tests, artefacts) : ci-build.

Rappel région : toute ressource Azure (App Service, RG, ACR…) 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 : créer un pipeline minimal avec pool ubuntu-latest et un step bash qui affiche un message — équivalent modernisé du live « Azure Basic Pipeline Code ».

1. Projet ado-lab → Pipelines → Pipelines → Create Pipeline (ou New pipeline).
2. Where is your code? → Azure Repos Git (si le code est dans Azure Repos ; sinon GitHub / Bitbucket).
3. Sélectionnez le repository où se trouve le code.
4. Configure : choisissez un starter ou Existing Azure Pipelines YAML file si le fichier existe déjà. Pour ce lab, remplacez l’aperçu par le YAML ci-dessous.
5. Save and run → branche main (ou master sur un repo legacy) → 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 (fond live enrichi) :

1. pool.vmImage: ubuntu-latest : l’agent Linux Microsoft-hosted du pool Azure Pipelines.
2. steps / bash : tâche exécutée sur la VM ; un job implicite encapsule les steps si vous ne déclarez pas jobs:.
3. Save and Run enregistre souvent le YAML dans le repo et lance le premier run.
4. Branche cible : préférez main en 2026 ; si votre lab est encore sur master, alignez trigger et la branche du run.
5. Aucun PAT, connection string ou mot de passe dans le fichier.

Après le run : ouvrez le job → logs → message Azure Basic Pipeline Code. Statut attendu : Succeeded.

Suite YAML structurée (artefacts, PublishPipelineArtifact, checklist) : azure-pipelines-yaml-intro.

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

Même parcours Create Pipeline → Azure Repo, mais avec plusieurs jobs. Le YAML live historique était cassé (indentation / clé pool absente / second job sans steps correctement rattachés). Voici la version corrigée et exécutable :

# 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"

Comportement :

• Chaque job obtient typiquement sa propre VM Microsoft-hosted (éphémère), sauf stratégie de dépendances avancée.
• timeoutInMinutes: 10 limite la durée du premier job (bonne hygiène Free tier).
• Les 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

Scénario live modernisé : build d’une app ASP.NET Core ciblant le .NET Framework sur agent Windows, avec variables, restore NuGet et packaging IIS (WebApp.zip).

1. Pipelines → New Pipeline.
2. Sélectionnez l’Azure Repo qui contient le code ASP.NET Core (.NET Framework).
3. Choisissez le template / plateforme ASP.NET Core (.NET Framework) si proposé, puis alignez le YAML sur l’exemple ci-dessous (corrigé : trigger, pool, variables, inputs des tâches).
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)"

Lecture des tâches (fond live clarifié) :

Tâche	Rôle
NuGetToolInstaller@1	Tâche intégrée : télécharger / préparer NuGet sur la VM Windows
NuGetCommand@2	Restore NuGet de la solution ($(solution))
VSBuild@1	Build MSBuild ; args WebPublish → WebApp.zip dans $(build.artifactStagingDirectory)

Notes lab :

• Image windows-latest : nécessaire pour MSBuild / scénario .NET Framework classique de cet exemple.
• Variables solution, buildPlatform, buildConfiguration : réutilisées dans les inputs — pas de secrets.
• Le zip est un artefact de staging ; pour le publier durablement, ajoutez ensuite PublishBuildArtifacts / PublishPipelineArtifact (voir ci-build).
• Déploiement App Service / gates : azure-release-pipeline. Connexion GitHub au lieu d’Azure Repos : azure-devops-azure-pipeline-2.

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

Note (live préservé) : dès que le pipeline est créé avec un trigger sur main (ou master), tout changement poussé sur cette branche relance automatiquement le pipeline. C’est le cœur de la CI : plus besoin de cliquer Save and Run à chaque commit.

Bonnes pratiques hub :

• Limitez le trigger aux branches utiles (main) pour économiser les minutes Free.
• Pour valider une PR avant merge : ajoutez pr: + Build validation (détail dans yaml-intro).
• Run manuel : Run pipeline dans le portail — utile sans nouveau commit.
• Ne mettez jamais de PAT dans un echo ou une variable non secrète.

Étape 7 — Checklist qualité (hub)

• [ ] Vous savez expliquer : CI/CD, VM agent éphémère, pool, types d’agents
• [ ] Example-1 : run Succeeded avec echo "Azure Basic Pipeline Code"
• [ ] Example-2 : deux jobs Firstjob / Secondjob verts (YAML corrigé)
• [ ] (Option) ASP.NET : restore NuGet + VSBuild + présence de WebApp.zip en staging
• [ ] Trigger auto vérifié par un push sur main (sans secret dans le YAML)
• [ ] Branche alignée main (ou master documenté)
• [ ] Aucun PAT / secret versionné

Étape 8 — Vérification de fin de parcours

1. Au moins un pipeline YAML lié au repo Azure Repos (ou GitHub via le chapitre 2).
2. Un run hello Succeeded sur ubuntu-latest.
3. Un run multi-jobs avec les deux messages d’echo.
4. (Si code ASP.NET présent) build Windows avec NuGet + VSBuild.
5. Un push sur la branche trigger a bien démarré un run automatique.
6. Historique Git du YAML 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) — comparer ubuntu vs windows (info agent)

1. Sur une branche feature, dupliquez Example-1 avec un second job windows-latest qui exécute pwsh: Write-Host "Hello from Windows".
2. Observez dans les logs Agent.OS / nom d’image (introspection détaillée : agents Microsoft-hosted).
3. Annulez le job Windows si vous voulez préserver les minutes Free.
4. Remettez un seul job ubuntu-latest pour la suite du parcours hub.

Toujours canadacentral pour les ressources Azure des chapitres déploiement — ce lab bonus n’en crée aucune.

Scénario terrain (débutant)

« L’équipe découvre Azure Pipelines dans le mega-menu : ils veulent une vue d’ensemble (agent jetable, pool), un hello YAML, un multi-job, puis un build ASP.NET qui produit WebApp.zip, avec trigger auto sur main. » → suivez les exemples 1–2, puis l’exemple Windows si le repo a une .sln Framework. Ensuite YAML approfondi, agents, CI build, release — sans coller de PAT.

Erreurs fréquentes

Symptôme	Cause	Correction
YAML mapping / indent error (Example-2)	pool / jobs mal indentés (live cassé)	Utiliser le YAML corrigé de l’étape 4
/bin/bash sur Windows	bash + windows-latest	ubuntu-latest pour bash ; pwsh/script sur Windows
Pipeline ne démarre pas au push	Trigger ≠ branche poussée / 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 / mauvais staging	Garder DesktopBuildPackageLocation + $(build.artifactStagingDirectory)
Parallel job / queue	Free tier saturé (multi-jobs)	Attendre, cancel runs inutiles, ou self-hosted
Secret / PAT dans les logs	echo d’un secret	Révoquer ; Variable groups / Key Vault — jamais en clair
Image 404 dans un article	Asset distant mort	Couverture locale WebP uniquement (pas d’img 404)

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 officielle : Azure Pipelines, YAML schema, .NET Core / Framework, Microsoft-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