À la fin de ce guide, vous saurez ce qu’est une Azure Release Pipeline, comment enchaîner artifacts → stages → deployments, quand utiliser les approvals et gates, et comment migrer mentalement du classic Release vers le YAML multi-stage avec Environments — lab App Service en région canadacentral, sans secrets en clair.

Niveau : Intermédiaire · Temps estimé : 45–60 min · Versions testées : Azure DevOps Services (portail 2026), classic Releases + YAML Pipelines · Dernière vérification : 2026-09-12

Slug : azure-release-pipeline · Série : Azure DevOps (menu) · Post WP : #1075 · Mot-clé SEO : azure release pipeline

Prérequis

• Organisation Azure DevOps Services + projet lab (ex. ado-lab) avec droits Project Administrator (Environments / checks)
• Un pipeline CI qui publie un artefact (ex. drop) — voir CI build
• Optionnel pour le lab Azure : abonnement + App Service Linux en canadacentral, service connection OIDC (pas de secret client long terme)
• Navigateur récent, MFA ; aucun PAT en clair dans Git

Coût estimé : 0 € sur Free tier ADO pour le parcours classic + YAML simulé. Les App Service réels facturent à part (région lab canadacentral).

Ce que nous allons construire

Azure Release Pipeline (carte 2026)
  ├── Classic Release UI
  │     artifacts → stages → pre/post approvals → gates → agents
  ├── YAML multi-stage (recommandé)
  │     stages + deployment jobs + Environments + checks
  ├── Lab CD
  │     Build → Dev → Staging → Production (+ approval)
  └── Mapping classic ↔ YAML + troubleshooting

Ce hub enrichit le post WordPress #1075 : on conserve le parcours de leçons ci-dessous, puis on densifie la théorie, le lab et le SEO FR.

Parcours de leçons (conservé)

1. Overview — Azure Release Pipelines : fonctionnement d’une release (approvals, agent, download artifacts, tasks, logs).
2. Azure Release pipeline with WebApp and Approval Gates : flux build → dev → staging → production pour une Web App, avec approvals et gates.

Hub série : Retour parcours Azure DevOps.

Étape 1 — Qu’est-ce qu’une Azure Release Pipeline ?

Une Azure Release Pipeline orchestre la livraison continue (CD) : elle prend un artifact produit par le CI (build), le déploie sur un ou plusieurs stages (Dev, QA, Prod), avec des barrières humaines (approvals) et automatiques (gates / checks).

Deux surfaces coexistent en 2026 :

Dans les deux cas, l’idée est la même : promouvoir la même build versionnée, pas « rebuild en prod ».

Étape 2 — Comment fonctionne une release (classic)

À chaque déploiement vers un stage, Azure Pipelines enchaîne typiquement :

1. Pre-deployment approval — si requis, notification aux approvers avant de démarrer.
2. Queue deployment job — planification sur un agent (même famille que le CI).
3. Agent selection — agent hosted ou self-hosted selon la définition.
4. Download artifacts — récupération des artefacts déclarés (Azure Pipelines, Jenkins, etc.).
5. Run deployment tasks — tâches du job (Web App, slots, scripts, smoke).
6. Progress logs — journaux détaillés remontés dans ADO.
7. Post-deployment approval — optionnel avant le stage suivant.

Vous définissez : artifacts (composants déployables), stages, jobs/tasks, variables, triggers (après CI réussi, manuel, schedule).

Exemple de topologie classique : Dev → (QA1 ∥ QA2) → Production ring 1 → ring 2. Chaque ring peut représenter plusieurs instances géographiques du même site.

Étape 3 — YAML : Environments, deployment jobs, checks

En YAML, la maison des approvals/gates s’appelle Environment :

• Environment = cible logique (lab-dev, lab-staging, lab-prod) + historique des déploiements.
• deployment job (deployment: + environment:) = job lié à un Environment (déclenche les checks).
• Checks = Approvals, Business hours, Branch control, Query Azure Monitor alerts, Invoke REST API / Azure Function, Required template, Evaluate artifact, Exclusive lock.

Création rapide (portail) :

1. Pipelines → Environments → New environment → lab-dev (Resource: None).
2. Répétez lab-staging, lab-prod.
3. Sur lab-prod → ⋮ → Approvals and checks → Approvals (vous-même en lab ; en entreprise : groupe Release Managers, Requester should not approve).
4. Option lab : Business hours (ex. lun–ven 09:00–16:00 America/Toronto) + Branch control refs/heads/main.

Ne confondez pas Environment Pipelines avec un Resource Group Azure : ici c’est l’objet ADO.

Étape 4 — Lab CD minimal (CI → Staging avec approval)

Évoluez un azure-pipelines.yml (illustratif, aucun secret) :

# azure-pipelines.yml — lab Azure Release / CD — PAS de secrets
trigger:
  - main

variables:
  buildConfiguration: Release

stages:
  - stage: Build
    displayName: CI Build
    jobs:
      - job: CI
        pool:
          vmImage: ubuntu-latest
        steps:
          - script: echo "build + tests ici (voir tuto CI)"
            displayName: Placeholder CI
          - task: PublishPipelineArtifact@1
            inputs:
              targetPath: "$(Build.SourcesDirectory)"
              artifact: drop

  - stage: DeployStaging
    displayName: CD lab-staging
    dependsOn: Build
    condition: and(succeeded(), eq(variables['Build.SourceBranch'], 'refs/heads/main'))
    jobs:
      - deployment: DeployLabStaging
        displayName: Deploy to lab-staging
        environment: lab-staging
        pool:
          vmImage: ubuntu-latest
        strategy:
          runOnce:
            deploy:
              steps:
                - download: current
                  artifact: drop
                - script: echo "Deploy simulé depuis $(Pipeline.Workspace)/drop"
                  displayName: Simulated deploy

Ajoutez un check Approvals sur lab-staging pour voir le statut Waiting for approval. Pour un vrai App Service : tâche AzureWebApp@1 + service connection OIDC, apps en canadacentral. Pattern prod : déployer sur un slot puis swap (rollback = re-swap).

Étape 5 — Web App, slots et gates (fil rouge)

Le parcours complet (détail dans la leçon WebApp + Approval Gates) :

Gates utiles en 2026 : Query Azure Monitor alerts (bloque si Sev0–Sev2 sur le staging), Invoke REST API (Sonar / synthétique), Business hours. Combinez jugement humain (approval) et données (gate).

Rollback rapide après swap : az webapp deployment slot swap (re-swap) ou rejouer le stage Production d’un run antérieur (même artefact, toujours sous approval).

Étape 6 — Mapping classic Release → YAML

Chemin classic encore utile pour la maintenance : Pipelines → Releases → Edit → icône personne avant un stage → Pre-deployment conditions. Microsoft n’a pas annoncé de date de retrait, mais templates, checks avancés et validation YAML n’évoluent que côté YAML.

Étape 7 — Agents, variables et secrets

• Agents Microsoft-hosted (ubuntu-latest) : Free tier, cold start possible — voir Microsoft-hosted agents.
• Agents self-hosted : pools privés, demands, systemd — voir Self-hosted agents.
• Secrets : variable groups + Azure Key Vault ; service connections OIDC pour Azure. Jamais de PAT ni connection string en clair dans le YAML.

Scénario terrain (débutant → prod)

Vous publiez une API ASP.NET Core. Le lundi, le stage Dev reçoit chaque merge sur main sans friction. Le mardi, Staging smoke-teste /healthz et un product owner valide la démo. Le mercredi, un release manager Approuve Production pendant les business hours ; le job déploie sur le slot blue, le swap bascule le trafic, et une alerte Monitor Sev1 sur le staging aurait bloqué le check. Jeudi, un bug UX force un re-swap en deux minutes — même artefact, zéro rebuild. Ce scénario est exactement ce que couvrent classic Releases et YAML Environments : promouvoir une build connue, avec barrières humaines et automatiques.

Checklist anti-régression CD

1. Artefact nommé stable (drop) publié uniquement si les tests CI sont verts.
2. Environment lab-prod avec Approvals + Branch control main.
3. Smoke HTTP après chaque deploy (Dev/Staging/slot).
4. Aucun secret dans le YAML ; OIDC pour Azure ; région lab canadacentral.
5. Runbook rollback (re-swap ou re-run stage) documenté dans le README du repo.

Erreurs fréquentes

Quiz (5 questions)

1. En 2026, pour un nouveau projet CD Azure DevOps, que recommande-t-on en priorité ?
– A. Uniquement classic Releases
– B. YAML multi-stage + Environments
– C. TFVC obligatoire
– D. Déployer sans artefact

2. Quel objet YAML déclenche les Approvals / gates ?
– A. Un simple script
– B. Un deployment job lié à un Environment
– C. Un board Kanban
– D. Un feed Artifacts

3. À quoi sert surtout une gate Query Azure Monitor alerts ?
– A. Remplacer Git
– B. Bloquer le déploiement si des alertes critiques sont actives
– C. Créer le Resource Group
– D. Générer un PAT

4. Le swap de slots App Service permet surtout…
– A. D’éviter le CI
– B. Une bascule rapide et un rollback par re-swap
– C. De supprimer les approvals
– D. De facturer ADO

5. Classic Release et YAML…
– A. Sont incompatibles à jamais
– B. Partagent les idées artifacts / stages / approvals, avec mapping clair
– C. Exigent tous les deux TFVC
– D. Interdisent les agents hosted

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

FAQ

Azure Release Pipeline = pipeline YAML CI ?

Non. Le CI construit et teste ; la Release / CD promouvoir l’artefact vers des environnements avec contrôles. En YAML, CI et CD vivent souvent dans le même fichier multi-stage.

Faut-il migrer tout classic demain ?

Pas forcément en une nuit. Gelé côté features, le classic reste maintenu. Tout nouveau flux : YAML + Environments. Migrez stage par stage en vous appuyant sur le tableau de mapping.

Quelle région lab Azure utiliser ?

Pour App Service / ressources de lab sur ce site : canadacentral. Les agents Microsoft-hosted ne sont pas des VM dans votre abonnement.

Où approfondir CI, CD et App Service ?

• Overview Release Pipelines
• WebApp + Approval Gates
• CD : environnements et approvals
• CI build
• Déployer App Service
• Azure DevOps Tools

Pour aller plus loin

• Doc Microsoft : Release pipelines, Environments, Approvals and checks
• Hub : Parcours Azure DevOps

Meta SEO (Rank Math)

• Title : Azure Release Pipeline : stages, approvals et CD (2026)
• Description : Azure Release Pipeline en FR : classic vs YAML, stages, artifacts, approvals, gates Environments, lab App Service canadacentral. Guide CD 2026.
• Focus keyword : azure release pipeline

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