À la fin de ce tutoriel, vous maîtriserez une Azure DevOps CI/CD pipeline de bout en bout : bénéfices CI/CD, cas d’usage, architecture dataflow (Repos → CI → CD → App Service → Application Insights → Boards), processus de build, et étapes Build → Build Solution dans Visual Studio — sans secrets en clair, région lab Azure canadacentral.

Niveau : Débutant → intermédiaire · Temps estimé : 45–60 min · Versions testées : Azure DevOps Services (portail 2026), Azure Pipelines, Visual Studio 2022, Azure App Service · Dernière vérification : 2026-09-12

Slug live : azure-devops-cicd-pipeline · Série : Azure DevOps P4 (pipelines) · Post WP : #1041 · URL : https://devopelastichayway.com/azure-devops-cicd-pipeline/

Prérequis

• Organisation et projet Azure DevOps (ex. ado-lab) — hub Azure DevOps Tools utile
• Compte Microsoft / Entra ID avec MFA ; navigateur récent ; notions Git (commit, main)
• Optionnel : Visual Studio 2022 pour le lab Build Solution ; abonnement Azure pour App Service + Insights en canadacentral
• Droits Build Administrator ou Contributor sur le projet lab

Coût estimé : 0 € Free tier Azure DevOps (minutes hosted). Ressources Azure facturées à part en canadacentral. Aucun PAT ni connection string en clair dans Git ou le YAML.

Ce que nous allons construire

Azure DevOps CI/CD Pipeline (vue 2026)
  ├── Bénéfices CI/CD + cas d’usage
  ├── Dataflow : Repos → CI → CD → App Service → Insights → Boards
  ├── Build process (restore, compile, contrôles, artefact)
  ├── Visual Studio : Build → Build Solution
  └── Lab smoke YAML + checklist

(Schéma dataflow — image externe historique conservée si HTTP 200.)

Ce guide enrichit le post WordPress #1041 : thèmes bénéfices, use cases, dataflow, build process et Build Solution Visual Studio conservés, traduits et densifiés en français.

---

Étape 1 — Pourquoi une Azure DevOps CI/CD pipeline ?

Migrer vers des processus CI/CD modernes apporte des bénéfices pour builds, déploiements, tests et monitoring. Avec Azure DevOps (Pipelines, Repos, Boards, Test Plans) et des services Azure comme App Service et Application Insights, les équipes se concentrent sur le développement plutôt que sur la gestion manuelle de l’infrastructure de livraison.

Une Azure DevOps CI/CD pipeline typique enchaîne :

1. CI — à chaque push / PR : restore, compile, tests, artefact versionné.
2. CD — déploie l’artefact vers un environnement avec config spécifique (variables — pas de secrets en clair).
3. Observabilité — Application Insights mesure santé, perf et usage.
4. Boucle produit — Azure Boards priorise features et correctifs.

Sans CI/CD, chaque livraison reste fragile (build local, copie manuelle). Avec Azure Pipelines, le chemin commit → run vert devient répétable, auditable et rapide. Carte des services : Azure DevOps Tools.

Au quotidien, la pipeline réduit les allers-retours « ça marche chez moi » : chaque PR déclenche les mêmes contrôles, les échecs apparaissent en minutes, et le artefact validé devient la seule source déployable. Les équipes product et ops partagent le même run (logs, tests, durée) plutôt que des captures d’écran discordantes. C’est aussi un levier de conformité soft : qui a déployé quoi, quand, depuis quel commit — visible dans l’historique Azure Pipelines et les liens Boards.

Étape 2 — Cas d’usage potentiels

Envisagez Azure DevOps et le CI/CD pour :

• Accélérer le développement et le cycle de vie applicatif.
• Intégrer qualité et cohérence dans un build et une release automatisés.
• Augmenter stabilité et disponibilité (déploiements homogènes, rollback plus simple).
• Standardiser plusieurs repos sur un modèle Pipelines YAML versionné.
• Relier code et work items Boards (traçabilité commit ↔ story ↔ bug).
• Déployer vers App Service en canadacentral sans scripts non versionnés.

Lab conseillé : petite app web dans Azure Repos, CI qui publie un artefact, CD vers App Service lab, Insights branché, User Story Boards « Stabiliser la CI/CD pipeline ».

Étape 3 — Architecture dataflow (Repos → CI → CD → App Service → Insights → Boards)

Le flux du scénario :

1. Le développeur modifie le code source.
2. Le code (configs versionnées sans secrets) est commité dans Azure Repos.
3. La CI déclenche build et tests unitaires via Azure Pipelines (Test Plans pour le manuel si licence).
4. La CD déploie les artefacts avec des valeurs spécifiques à l’environnement.
5. Déploiement vers Azure App Service (canadacentral).
6. Application Insights collecte santé, performance et usage.
7. L’équipe surveille ces signaux (portail Azure / workbooks) — voir Azure Monitoring.
8. Le backlog Azure Boards priorise features et correctifs.

[Dev] → commit → Azure Repos → CI (build/tests) → artefact
      → CD (env + config) → App Service (canadacentral)
      → Application Insights → feedback → Azure Boards

Maillage : Azure Pipelines · Release Pipeline · exemple YAML.

Étape 4 — Le Build process

Le Build stage prend le code et le construit pour le tester. C’est le premier tronçon d’une Azure DevOps CI/CD pipeline : il automatise téléchargement des dépendances, installation des outils (SDK), compilation, contrôles qualité/sécurité de base, et publication d’un artefact immuable pour le CD.

Sans build automatisé, chaque machine locale diverge. La pipeline impose un contrat unique (vmImage, tasks). Préférez le YAML versionné (2026) — voir Azure Pipelines et exemple YAML. Pour le CD / environments : Release Pipeline.

# azure-pipelines.yml — CI smoke (illustratif, lab)
trigger:
  - main

pool:
  vmImage: ubuntu-latest

steps:
  - task: UseDotNet@2
    inputs:
      packageType: sdk
      version: "8.x"
    displayName: "Install .NET SDK"

  - script: |
      dotnet restore
      dotnet build --configuration Release --no-restore
      dotnet test --configuration Release --no-build --verbosity normal
    displayName: "Restore, build, test"

Aucun secret dans cet exemple. Adaptez chemins et PublishPipelineArtifact à votre solution.

Étape 5 — Build Solution dans Visual Studio

Thème historique du post #1041 — enrichi pour le lab local.

Comment builder le projet dans Visual Studio

1. Ouvrez le projet dans Visual Studio (ex. solution ASP.NET Core).
2. Dans l’explorateur de fichiers, le répertoire bin est vide (ou absent) avant le premier build.
3. Menu Build → Build Solution (Ctrl+Shift+B).
4. Après succès, bin (et souvent obj) contient exécutables / DLL (Debug ou Release).

Bonnes pratiques : aligner la configuration Debug/Release ; corriger localement avant push ; ne pas committer bin/ / obj/ ; secrets dans User Secrets / Key Vault / variables pipeline — jamais en clair sur main. Le build VS accélère le feedback ; la CI Azure DevOps garantit la reproductibilité équipe.

Étape 6 — App Service, Insights et Boards (vue d’ensemble)

1. App Service lab en canadacentral.
2. Service connection Azure DevOps → abonnement (OIDC préféré, pas de secret long terme).
3. Stage CD / environment déployant l’artefact (AzureWebApp@1 ou équivalent).
4. Activer Application Insights — Azure Monitoring.
5. Lier commits/builds aux work items Azure Boards (AB#123).

Même artefact pour tous les environnements ; config via variables ; pas de rebuild manuel sur l’agent CD.

Lab guidé — smoke CI et lecture dataflow

1. Repo ado-lab + YAML smoke (ou Starter pipeline).
2. Pipelines → New pipeline → Azure Repos Git → lancer un run sur main.
3. Annoter où se situe le run sur le dataflow (Repos → CI).
4. User Story Boards : « Étendre la CI vers CD App Service canadacentral ».
5. Bonus : Build Solution local, git push, comparer local vs cloud.

Succès : run CI vert · zéro secret dans les logs · work item lié · vocabulaire dataflow maîtrisé.

Erreurs courantes

Symptôme	Cause	Correction
Pipeline rouge au restore	SDK / lockfile manquant	Aligner UseDotNet / NodeTool ; committer les locks
App down après deploy	Settings / slot	App Settings via variables sécurisées
Insights vide	Instrumentation absente	Activer Insights sur App Service
Confusion CI / CD	Stage unique fourre-tout	Séparer build et deploy + environments
bin commité	.gitignore absent	Ignore .NET standard
Secret dans YAML	Copier-coller	Révoquer ; Variable Group / Key Vault / OIDC
VS OK, CI KO	Versions outils	Aligner SDK YAML ↔ machine locale

FAQ

CI et CD : deux pipelines ?

Pas obligatoire. Un YAML peut enchaîner stages CI puis CD. Séparez logiquement artefact CI et deploy CD ; approvals sur environments prod.

Visual Studio est-il obligatoire ?

Non. Utile en local ; la pipeline tourne sur agents hosted ou self-hosted. VS Code + CLI .NET suffisent souvent.

Quelle région Azure pour le lab ?

canadacentral pour App Service / Insights. ADO SaaS reste sur dev.azure.com (facture distincte).

YAML ou Release classique ?

YAML versionné recommandé en 2026. Les Release pipelines restent valides ; migrez progressivement.

Comment éviter les secrets dans le dataflow ?

Pas de secrets dans Repos ; variables secrètes / Key Vault ; OIDC ; jamais d’echo de PAT dans les logs.

Suite après ce tutoriel ?

Tools · Pipelines · Release · Monitoring · Boards · YAML.

Quiz (5 questions)

1. Dans le dataflow, qui reçoit en premier le commit ? – A. Application Insights
– B. Azure Repos
– C. Azure Boards uniquement
– D. App Service directement

2. Rôle principal du Build stage ? – A. Facturer App Service
– B. Compiler / tester et préparer un artefact
– C. Remplacer Boards
– D. Créer l’organisation

3. Quelle action Visual Studio remplit typiquement bin ? – A. Clone Git seul
– B. Build → Build Solution
– C. Créer un work item
– D. Ouvrir Insights

4. Où déployer l’artefact dans le scénario de référence ? – A. Uniquement le laptop
– B. Azure App Service (canadacentral)
– C. Uniquement Boards
– D. Dans le PAT

5. Application Insights sert surtout à… – A. Héberger le code
– B. Collecter santé, performance et usage
– C. Remplacer Git
– D. Générer des PAT Full access

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

Récapitulatif

Une Azure DevOps CI/CD pipeline relie Repos, build automatisé, déploiement App Service, télémétrie Insights et priorisation Boards. Vous avez vu bénéfices, cas d’usage, dataflow, build process et Build Solution Visual Studio. Suite : CD avec environments, monitoring et Boards sur le fil rouge lab canadacentral.

Maillage série Azure DevOps (menu + P4 pipelines)

← Hub outils	Azure DevOps Tools
→ Pipelines	Azure Pipelines · Release Pipeline
Observabilité	Azure Monitoring
Backlog	Azure Boards
YAML	Exemple pipeline YAML
Aussi P4	Agents, CI build, CD environnements, OIDC

---

Meta publication (Rank Math / SEO)

• Title SEO : Azure DevOps CI/CD Pipeline : dataflow et build (2026)
• Meta description (≤155) : Azure DevOps CI/CD pipeline FR : bénéfices, dataflow Repos→CI→CD→App Service→Insights→Boards, build Visual Studio. Lab canadacentral 2026.
• Focus keyword : azure devops ci/cd pipeline
• Focus secondaires : azure devops cicd pipeline, CI/CD Azure DevOps, App Service, Build Solution
• Image mise en avant : featured WP #4206 (HTTP 200) ; img dataflow blogger conservée (200)
• Catégorie : Azure DevOps · Slug : azure-devops-cicd-pipeline
• Canonical : /azure-devops-cicd-pipeline/ · Live : https://devopelastichayway.com/azure-devops-cicd-pipeline/
• Fusion : enrichit WP #1041 (thèmes EN conservés, FR enrichi).
• Publish : was HOLD — NOW GO LIVE (Maître 2026-09-12)