À la fin de ce tutoriel, vous aurez cartographié Azure DevOps sur le cycle de vie applicatif (SDLC), distingué Services (cloud) et Server (on-prem), créé une organisation et un projet lab ContosoApp / ado-lab, initialisé un dépôt Azure Repos, puis posé un premier pipeline Azure Pipelines (build Docker) et une piste de déploiement continu avec gates — le fil Lesson 3 / 31.

Niveau : Débutant · Temps estimé : 50–70 min · Versions testées : Azure DevOps Services (portail 2026) · Azure CLI 2.60+ · Git 2.x · Dernière vérification : 2026-09-12

Slug : sdlc-methodologies-2 · Série : Azure DevOps Lesson 3 / 31 · Région lab Azure : canadacentral (ressources Azure des tutos suivants)

Prérequis

• Compte Microsoft pouvant créer une organisation sur dev.azure.com
• Azure CLI 2.60+ avec l’extension azure-devops (az extension add --name azure-devops)
• Git installé localement ; notions YAML et conteneurs (niveau découverte)
• Optionnel : abonnement Azure lab (ACR / AKS) pour les étapes build & release — sinon suivez en lecture seule
• Contexte méthodologies : Introduction SDLC et DevOps et Processus de projet Azure

Coût estimé : 0 € sur le Free tier Azure DevOps (jusqu’à 5 utilisateurs Basic). Les minutes d’agents Microsoft-hosted et les ressources Azure (ACR, AKS) restent hors Free pur — budgétez le lab.

Checklist Lesson 3 : org + projet · Git main · azure-pipelines.yml · vue Boards / Pipelines · liens sœurs CI/CD.

Introduction — Azure DevOps et le cycle de vie applicatif

Azure DevOps Server est un produit Microsoft qui fournit le contrôle de version, le reporting, la gestion des exigences, la gestion de projet, les builds automatisés, les tests et la gestion des releases. Il couvre l’ensemble du cycle de vie applicatif et active les capacités DevOps. En 2026, cette plate-forme unifie toujours planification, code, CI, qualité et livraison.

La plupart des labs utilisent Azure DevOps Services (SaaS sur dev.azure.com), frère cloud d’Azure DevOps Server (ex-TFS, on-prem / IaaS). Les cinq services — Azure Boards, Azure Repos, Azure Pipelines, Azure Test Plans, Azure Artifacts — mappent le SDLC : exigences, code, build/CI, test, release.

Ce chapitre remplace le stub EN trop court par un parcours FR : Services vs Server, puis org/projet → Git → build Docker → piste CD. Les sœurs couvrent process (Basic, Agile, Scrum, CMMI), agents et multi-stage.

Azure DevOps Services vs Azure DevOps Server

Pour Lesson 3, créez une org Services. Server garde le même modèle mental (projets, Git, builds) avec l’ops d’infra en plus. Les commandes az devops ici ciblent Services.

Les cinq services Azure DevOps et le mapping SDLC

Pensez « une plate-forme, cinq leviers » : vous ne changez pas d’outil à chaque phase du SDLC, vous changez d’onglet. C’est l’avantage pédagogique d’Azure DevOps pour un lab débutant en région canadacentral : le même projet porte backlog, Git et pipelines.

1. Azure Boards — backlog, work items, sprints, tableaux Kanban : phase exigences / planification du SDLC. Voir Azure Boards.
2. Azure Repos — Git (ou TFVC legacy) : phase conception / implémentation. Voir Azure Repos.
3. Azure Pipelines — CI/CD YAML ou classic : phases build, test automatisé, release. Voir pipeline CI/CD et release.
4. Azure Test Plans — plans de test manuels / exploratoires : phase validation qualité.
5. Azure Artifacts — feeds NuGet, npm, Maven, Universal : phase gestion des binaires entre build et deploy.

Ensemble : plate-forme SDLC du besoin à l’artefact déployable. Agents hosted ou self-hosted ; Free tier = minutes limitées — Microsoft-hosted · self-hosted.

Méthodologies : Waterfall, Agile, DevOps et process Azure

Le SDLC n’impose pas une seule méthode. Waterfall enchaîne les phases (spécifications → design → code → test → release) avec des cycles longs. Agile / Scrum misent sur des itérations courtes (Boards + pipelines fréquents). DevOps relie dev et ops via automatisation (Pipelines) et feedback rapide — cœur de cette série.

Le process template (Basic, Agile, Scrum, CMMI) structure les work items à la création du projet (souvent Agile ou Basic en lab). Voir Introduction SDLC et DevOps, Processus de projet Azure et Organisation et configuration.

Ce que nous allons construire

dev.azure.com
  └── Organisation lab
        └── Projet ContosoApp (ou ado-lab)
              ├── Azure Boards (backlog minimal)
              ├── Azure Repos (Git, branche main)
              ├── Azure Pipelines (YAML build Docker@2 → ACR)
              └── Piste CD (multi-stage / gates → lien release)
Région lab Azure : canadacentral (ACR / AKS optionnels)

(Schéma conceptuel — aucune image embarquée dans cet article.)

Étape 1 — Créer l’organisation et le projet ContosoApp / ado-lab

Sans organisation ni projet, Boards / Repos / Pipelines restent inaccessibles : cette étape ouvre le conteneur SDLC. Comptez 5–10 minutes si le compte Microsoft est déjà prêt.

1. Ouvrez https://dev.azure.com/ avec votre compte lab.
2. Créez une organisation si besoin (nom unique, région proche de vos users).
3. Créez un projet : nom ContosoApp (ou ado-lab pour rester aligné sur la série), visibilité Private, version control Git, process Agile (ou Basic).
4. Configurez le contexte CLI :

az devops configure --defaults organization=https://dev.azure.com/yourorg project=ContosoApp
az devops project show --project ContosoApp

La première commande fixe le contexte ; la seconde vérifie le projet. Remplacez yourorg / ContosoApp. Extension manquante : az extension add --name azure-devops (PAT via AZURE_DEVOPS_EXT_PAT, jamais dans Git).

ContosoApp vs ado-lab : le stub EN utilisait ContosoApp ; la série préfère souvent ado-lab. Un seul nom par lab. Vérifiez Overview → Repos / Boards / Pipelines. Suite : Organisation et configuration.

Étape 2 — Initialiser Azure Repos (Git) : clone, commit, push main

1. Dans le projet : Repos → initialisez le dépôt (README optionnel) si vide.
2. Clonez en HTTPS (ou SSH si clé déposée) :

git clone https://dev.azure.com/yourorg/ContosoApp/_git/ContosoApp
cd ContosoApp
echo "# ContosoApp" > README.md
git add README.md
git commit -m "chore: commit initial README"
git branch -M main
git push -u origin main

Azure Repos suit main. Activez des branch policies (reviewers, build validation) sans bloquer le lab solo trop tôt. Ajoutez un Dockerfile (racine ou src/) ; aucun secret en commit. Voir Azure Repos.

Étape 3 — Premier pipeline YAML : build Docker (illustration SDLC « build »)

1. Pipelines → Create Pipeline → Azure Repos Git → sélectionnez le dépôt.
2. Choisissez le starter YAML, puis adaptez pour un build/push d’image (illustration de la phase build du SDLC) :

trigger:
  - main

pool:
  vmImage: ubuntu-latest

steps:
  - task: Docker@2
    displayName: Build and push
    inputs:
      containerRegistry: 'ACRConnection'
      repository: 'contosoapp'
      command: 'buildAndPush'
      Dockerfile: '**/Dockerfile'
      tags: |
        $(Build.BuildId)

3. Créez la service connection ACR ACRConnection (lab canadacentral), ou limitez-vous à un docker build sur l’agent pour un premier run vert.
4. Sauvez sur main et lancez : checkout → Docker@2 → push.

Chaque commit produit un artefact (Build.BuildId) — phase build du SDLC. Agents : Microsoft-hosted. Suite CI/CD : pipeline CI/CD.

Étape 4 — Release / CD : multi-stage YAML, gates et liens sœurs

Le stub historique utilisait un release classic + kubectl apply vers AKS. En 2026, préférez un multi-stage YAML (build → deploy) avec environments et approval gates, tout en gardant l’idée « CD après CI ».

1. Stage Deploy consommant l’image, Environment lab-aks (ou Web App).
2. Check d’approbation manuelle avant prod-like.
3. Classic Release possible : artifact → stage → kubectl / App Service — Azure Release Pipeline.

Sans kubeconfig, kubectl « hang » souvent. Détails : release · CI/CD. Objectif Lesson 3 : placer la release dans le SDLC, pas forcément provisionner AKS.

Erreurs fréquentes (à enrichir, pas à ignorer)

Pour aller plus loin

• Qualité & sécu dans le pipeline : SonarQube / SonarCloud, Snyk (scans dépendances) en jobs séparés après le build
• Variable groups liés à Azure Key Vault pour les secrets de deploy (jamais en clair dans le YAML)
• YAML multi-stage avec templates réutilisables, environments et gates d’approbation
• Intégration Azure Boards ↔ GitHub lorsque le code vit sur GitHub mais le suivi reste dans Boards
• Agents : Microsoft-hosted · self-hosted Ubuntu
• Process & org : processus projet · organisation

Conclusion

Carte SDLC Azure DevOps : Boards (planifier), Repos (versionner), Pipelines (build/deploy), Test Plans et Artifacts (qualité/packages). Services pour le lab cloud ; Server on-prem. Projet ContosoApp / ado-lab + Git + YAML Docker = socle des leçons agents, CI/CD et releases.

FAQ

1. Combien d’utilisateurs sont gratuits sur Azure DevOps Services ?
Le Free tier inclut typiquement 5 utilisateurs Basic (Repos, Pipelines, Boards selon offre en vigueur). Au-delà, des licences Basic additionnelles s’appliquent. Les Stakeholders ont un accès limité gratuit plus large. Vérifiez Organization settings → Billing.

2. Puis-je utiliser un agent self-hosted Ubuntu 24.04 ?
Oui. Installez l’agent officiel sur une VM Ubuntu 24.04 lab, enregistrez-le dans un pool, et pointez pool: name: MonPool. Utile si les minutes Microsoft-hosted sont épuisées ou si vous avez besoin d’outils custom. Voir self-hosted agents.

3. Comment gérer l’infra Azure (ACR, AKS) avec Terraform dans ce parcours ?
Provisionnez le RG canadacentral, ACR et AKS via Terraform (state distant sécurisé), puis consommez les sorties dans les service connections Pipelines. Ne stockez pas les secrets Terraform dans le dépôt ADO.

4. Comment migrer d’Azure DevOps Server vers Services ?
Microsoft documente des outils de migration (base, identities, historisation Git). Planifiez Entra ID, recréation des service connections, et bascule DNS/bookmarks. Testez d’abord sur une collection non critique.

5. Que configurent les branch policies sur main ?
Elles imposent reviewers, validation build, suppression des pushes directs, etc. C’est un levier SDLC majeur pour protéger la branche de production. En lab solo, activez au minimum une build validation une fois le pipeline vert. Documentez la politique dans le README du dépôt pour l’équipe.

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

• Introduction SDLC et DevOps
• Processus de projet Azure
• Organisation et configuration
• Azure Repos
• Azure Boards
• Pipeline CI/CD
• Azure Release Pipeline
• Agents Microsoft-hosted
• Agents self-hosted