Azure DevOps : Boards, Repos, Pipelines et Bicep

Azure DevOps Services est la plateforme SaaS Microsoft pour planifier, versionner, construire, tester et livrer du logiciel — accessible via https://dev.azure.com/<org>. Elle ne doit pas être confondue avec Azure DevOps Server (on‑premises) : ce hub et le parcours P4 ciblent exclusivement le SaaS, le Free tier et un lab Azure en région canadacentral.

Cette page est le hub pilier de la série Azure DevOps sur DevOps Elastic Hayway. Elle enrichit le fil de certification AZ‑400, les méthodologies SDLC et le vocabulaire Agile, puis enchaîne organisation, projets, Entra ID, Boards, Repos, Pipelines YAML, agents, releases et Azure Monitor — avec Bicep prioritaire sur ARM.

Les cinq piliers d’Azure DevOps Services

Dans une organisation ADO, un projet Agile + Git expose cinq services. Quatre sont au cœur du Free tier pour apprendre ; le cinquième (Test Plans) est souvent hors périmètre des labs débutants.

• Boards — work items, backlogs, sprints, tableaux Kanban et liens commit ↔ item
• Repos — Git (évitez TFVC pour les labs modernes), branches, pull requests et politiques
• Pipelines — CI/CD en YAML (et classic), agents Microsoft‑hosted ou self‑hosted
• Artifacts — feeds NuGet, npm, Maven ou universels pour industrialiser les packages
• Test Plans — tests manuels et plans structurés (souvent hors Free de base)

Côté abonnement Azure (distinct d’ADO) : App Service, Container Apps, Monitor, et surtout Bicep pour l’infrastructure as code. Le YAML des pipelines reste dans Git ; les secrets vivent dans Variable Groups / Key Vault ; les déploiements Azure passent par des service connections OIDC plutôt que des secrets longue durée.

Architecture en une minute : org → projet → OIDC

L’identité (compte Microsoft ou Entra ID avec MFA) porte l’organisation. L’organisation gère billing, users et policies. Le projet contient backlog, repos et pipelines. Les service connections OIDC / Workload Identity Federation relient le projet à Azure sans coller un secret dans le YAML.

Entra ID / Microsoft (MFA)
  └── Organisation ADO
        └── Projet (Agile, Git)
              ├── Boards · Repos · Pipelines · Artifacts
              └── Service connections (OIDC → Azure)

Prérequis et Free tier

• Compte Microsoft ou Entra ID avec MFA (et Conditional Access si disponible)
• Navigateur + terminal ; bases Git / YAML utiles mais pas obligatoires au départ
• Budget : Free tier ADO pour org, Boards, Repos et un volume raisonnable de minutes hosted
• Ressources Azure à part en canadacentral + alertes budgétaires — le compute Azure n’est pas « gratuit parce que Free ADO »

Quick start (10 minutes)

1. Activez la MFA sur le compte d’identité avant de créer quoi que ce soit.
2. Ouvrez dev.azure.com → Create organization (nom stable, difficile à renommer ensuite).
3. New project ado-lab : Private · Git · process Agile.
4. Vérifiez Boards, Repos, Pipelines et Artifacts dans le menu latéral.
5. Option CLI (placeholders seulement, aucun secret) :

az extension add --name azure-devops
az devops configure --defaults organization=https://dev.azure.com/<ORG> project=ado-lab
az devops project list -o table

Si vous créez un PAT pour le lab Git/CLI : durée courte, scopes minimaux, stockage hors dépôt — jamais en clair dans un commit. Pour déployer vers Azure, préférez OIDC.

Parcours d’apprentissage (leçons live)

Le parcours ci‑dessous reprend la grille menu déjà publiée. Labels en français ; chemins inchangés. Suivez l’ordre certification → organisation → Boards → Repos/Pipelines → releases → Monitor.

Certification, méthodologie et vocabulaire

Cartographie AZ‑400, introduction ADO, SDLC et vocabulaire Agile — le contexte avant de cliquer dans le portail.

1. Détails certification Azure DevOps (AZ‑400)
2. Certification Azure DevOps — vue d’ensemble
3. Introduction à Azure DevOps
4. Méthodologies SDLC
5. Azure DevOps — de quoi s’agit‑il
6. Outils Azure DevOps
7. Terminologie Agile

Organisation, projets et identité

Process templates, configuration d’organisation, projets, Microsoft Entra ID (ex‑Azure AD), utilisateurs, permissions et équipes — le socle sécurité avant le premier pipeline.

1. Processus de projet Azure
2. Organisation et sa configuration
3. Projets Azure
4. Azure Active Directory (Microsoft Entra ID)
5. Ajouter des utilisateurs Azure AD
6. Ajouter des utilisateurs et définir les permissions
7. Équipes de projet

Azure Boards

Backlogs, sprints et suivi des work items. Les labs Boards et Sprint montrent le flux réel dans un projet Agile.

1. Azure Boards
2. Lab Azure Boards
3. Lab Sprint Azure

Repos et Pipelines

Cœur de la livraison : Azure Repos et Git, pipelines classic et YAML, CI/CD depuis GitHub, agents Microsoft‑hosted versus self‑hosted (leçon self‑hosted très détaillée), intégration Jenkins, et templates ARM — pivot vers Bicep pour les nouveaux labs.

1. Azure Repos
2. Concepts de pipeline CI/CD
3. Azure Pipelines
4. Azure Pipeline avec GitHub
5. Agents Microsoft‑hosted
6. Agents self‑hosted
7. Jenkins avec Azure Repos
8. Templates ARM (pivot Bicep)

Pipelines de release

Releases, vues d’ensemble et scénario Web App avec portes d’approbation — le passage CI → CD avec gouvernance humaine.

1. Pipeline de release Azure
2. Pipelines de release — vue d’ensemble
3. Release avec Web App et portes d’approbation

Azure Monitor

Clôture observabilité : métriques, journaux d’activité et alertes. Les captures suivent le portail Azure actuel ; lorsque Microsoft a renommé un service, les deux noms sont donnés dans les leçons.

1. Monitoring Azure
2. Azure Monitor — vue d’ensemble
3. Métriques Monitor
4. Journaux d’activité
5. Alertes Monitor

Chaîne DevOps et Bicep

Le fil maillé typique : Repos → Pipelines YAML → image Docker → déploiement App Service / ACA / Kubernetes via OIDC → Bicep pour le socle infra → Azure Monitor. Sur ce site, Bicep passe avant ARM JSON pour les nouveaux labs ; la leçon ARM reste le pont pour lire l’existant.

# azure-pipelines.yml (extrait — aucun secret)
trigger: [main]
pool: { vmImage: ubuntu-latest }
steps:
  - script: echo "build + test ici"
    displayName: CI
  # Deploy Azure : service connection OIDC + tâches Azure*@*
  # Secrets : Variable group / Key Vault — jamais commités

Bonnes pratiques jour 1

• MFA + Conditional Access ; projet Private ; process Agile
• Pipelines YAML versionnés dans Git ; démarrer en Microsoft‑hosted (ubuntu-latest)
• Secrets : Variable groups + Key Vault ; OIDC vers Azure plutôt que PAT longue durée
• Bicep > ARM pour le nouveau code ; branch policies + PR sur main ; lier les work items aux commits
• Lab Azure : région canadacentral + alertes budget avant le premier déploiement coûteux

Commandes du quotidien

Une fois l’extension Azure CLI installée, ces commandes (placeholders) couvrent le quotidien lab. Portail utile : User settings → PAT · Project settings → Service connections · Pipelines → Environments.

az devops configure --defaults organization=https://dev.azure.com/<ORG> project=<PROJECT>
az devops project list -o table
az repos list -o table
az pipelines list -o table
az boards work-item show --id <ID> -o jsonc

Pour qui (et pour quoi)

• Débutants DevOps / cloud qui veulent un fil rouge FR autour d’Azure plutôt qu’une playlist dispersée de captures d’écran
• Développeurs qui doivent brancher un backlog, un dépôt Git et un pipeline YAML vers App Service ou Container Apps
• Ops / SRE qui industrialisent agents, OIDC, Bicep et Monitor sans inventer une usine à gaz le premier jour

Vous n’avez pas besoin d’un abonnement Azure payant pour découvrir Boards et Repos. Le Free tier ADO suffit pour créer l’org, le projet et les premiers pipelines hosted. Dès que vous déployez du compute, passez en lab jetable canadacentral avec alertes budgétaires — snapshot mental : tout ce qui tourne hors Free ADO peut facturer.

Services SaaS ≠ Azure DevOps Server

Beaucoup de tutoriels mélangent encore les deux mondes. Azure DevOps Services est multi‑tenant, mis à jour par Microsoft, URL dev.azure.com. Azure DevOps Server s’installe dans votre datacenter, suit un calendrier de versions et sort du scope de ce hub. Si votre employeur impose le Server, les concepts Boards / Repos / Pipelines restent proches, mais l’identité, le networking et le patching sont différents — ne copiez pas les captures SaaS telles quelles.

Sur Services, l’organisation est l’unité de facturation et de gouvernance. Un projet isole backlog, repos et pipelines. Plusieurs équipes peuvent partager un projet via Area Paths et Iteration Paths. Les permissions se gèrent au niveau org, projet, repo et pipeline : commencez restrictif (projet Private), ajoutez des groupes Entra, évitez les comptes personnels « admin forever ».

Boards, Repos, Pipelines, Bicep — ce que chaque carte signifie

Boards n’est pas un tableau Kanban cosmétique : c’est le système de work items (Epic, Feature, User Story, Task, Bug selon le process) qui trace la valeur. Lier un commit ou une PR à un work item transforme le sprint en preuve d’audit. Les labs Boards et Sprint montrent le flux réel : backlog → sprint board → done, avec capacité et burndown.

Repos impose Git pour les labs modernes. Branch policies sur main (reviewers, build validation, work item linked) évitent le « push direct en prod ». Les PR sont le point de contrôle qualité avant le YAML. Si vous venez de GitHub, le modèle mental est familier ; les permissions et les service hooks diffèrent légèrement.

Pipelines : préférez le YAML versionné dans le dépôt. Microsoft‑hosted (ubuntu-latest) pour démarrer vite ; self‑hosted quand vous avez besoin d’outils privés, d’accès réseau restreint ou de caches lourds. La leçon self‑hosted du site est volontairement détaillée — c’est souvent là que les labs « cassent » en entreprise. Classic releases restent utiles pour comprendre les stages et approval gates, même si le futur du code de pipeline est YAML.

Bicep compile vers ARM mais se lit comme un langage déclaratif moderne. Pour un lab App Service ou Container Apps, écrivez Bicep, validez en what‑if, déployez depuis un pipeline avec OIDC. Gardez la leçon ARM comme décryptage des templates exportés du portail. Terraform reste un voisin (voir le hub Terraform) ; ici le fil rouge Microsoft reste Bicep.

Agents hosted vs self‑hosted

Les agents Microsoft‑hosted sont jetables, patchés par Microsoft, idéaux pour CI Linux standard. Limites : minutes Free, software préinstallé, pas d’accès à votre VNet privée sans relais. Les agents self‑hosted tournent sur votre VM/scale set : vous contrôlez images, caches Docker, connectivité on‑prem et secrets via le pool. Coût : vous patchez, vous sécurisez, vous surveillez. Commencez hosted ; basculez self‑hosted seulement quand un besoin concret apparaît (outil propriétaire, peering réseau, performances).

Observabilité et clôture Monitor

Un pipeline vert ne prouve pas que l’app survit la nuit. Azure Monitor relie métriques, activity logs et alertes. Dans le parcours, vous apprenez à lire les signaux après un déploiement Web App, à distinguer un échec d’infra d’un bug applicatif, et à poser des alertes actionnables plutôt qu’une pluie de mails. Combinez avec le hub Monitoring & Observability pour élargir hors Azure.

Maillage avec le reste du site

ADO n’existe pas en vase clos. Versionnez avec les réflexes du hub Git, packaginez avec Docker, orchestrez si besoin avec Kubernetes, automatisez la config avec Ansible, comparez le cloud avec AWS, et renforcez le socle OS via Linux. Le hub CI/CD & Jenkins reste pertinent pour les équipes mixtes Jenkins + Azure Repos.

FAQ

Azure DevOps ou GitHub Actions ?

Choisissez ADO quand Boards + Repos + Pipelines + Artifacts doivent coexister et que la cible principale est Azure. Preférez Actions si le code vit déjà sur GitHub — vous pouvez toujours brancher un pipeline ADO sur un dépôt GitHub (voir la leçon pipeline + GitHub).

Faut‑il apprendre ARM avant Bicep ?

Non — Bicep d’abord. ARM reste utile pour lire les exports et l’existant : commencez par Templates ARM comme pont, puis écrivez le nouveau code en Bicep.

Le Free tier suffit‑il pour apprendre ?

Oui pour créer une org, Boards, Repos et un volume raisonnable de minutes d’agents hosted. Le compute Azure (VM, App Service, etc.) facture l’abonnement Azure séparément : posez des alertes budgétaires en canadacentral.

PAT ou OIDC ?

PAT pour lab Git/CLI : courte durée, scopes minimaux, hors dépôt. Pour déployer vers Azure depuis un pipeline : OIDC / Workload Identity. Évitez les secrets longue durée dans le YAML.

Par où commencer concrètement ?

Hub → Organisation → Boards → Repos → Pipelines. Avant ADO si besoin : intro SDLC / DevOps.

Points clés

• ADO Services = Boards + Repos + Pipelines + Artifacts (+ Test Plans selon licence)
• MFA avant l’org ; Free tier pour démarrer ; lab Azure en canadacentral
• Ordre recommandé : fondations → Boards/Repos → YAML → agents → CI/CD → OIDC → Bicep → deploy → Monitor
• Bicep > ARM · OIDC > secrets longs · YAML > UI seule pour le code de pipeline

Commencer maintenant

1. Créer l’org + projet ado-lab (Private, Git, Agile)
2. Suivre Organisation et configuration
3. Enchaîner Boards puis Pipelines
4. Revenir à ce hub : https://devopelastichayway.com/azure-devops/

Autres parcours