Comprendre Azure DevOps et créer un pipeline CI/CD

OryStack > Blog > DevOps > Comprendre Azure DevOps et créer un pipeline CI/CD

Azure DevOps est bien plus qu’un simple outil de déploiement. C’est une plateforme complète qui couvre l’ensemble du cycle de vie d’un projet logiciel — de la gestion des tâches au déploiement automatisé en production. Dans cet article, on décortique ses composants principaux et on construit pas à pas un pipeline CI/CD concret.

1. Qu’est-ce qu’Azure DevOps ?

Azure DevOps est une suite de services cloud proposée par Microsoft, conçue pour accompagner les équipes de développement tout au long du cycle de vie d’une application. Elle s’adresse aussi bien aux petites équipes qu’aux grandes organisations, et s’intègre nativement avec l’écosystème Azure, mais reste compatible avec n’importe quel cloud ou environnement on-premise.

Contrairement à des outils mono-usage, Azure DevOps centralise dans une seule interface la planification, le code, les tests, la livraison et la surveillance. C’est ce qu’on appelle une plateforme ALM (Application Lifecycle Management).

Note : Azure DevOps est disponible en version cloud sur azure.microsoft.com/devops et en version on-premise sous le nom Azure DevOps Server — anciennement Team Foundation Server (TFS).

2. Les cinq composants clés

Azure Boards

Un outil de gestion de projet agile intégré. Il permet de créer des backlogs, des sprints, des épopées et des user stories. On y retrouve des tableaux Kanban, des burndown charts et des rapports de vélocité — le tout lié directement aux commits et pull requests.

Azure Repos

Un service d’hébergement de code source compatible Git et TFVC (Team Foundation Version Control). Il propose du versioning, des revues de code, des politiques de branches (protections, approbations obligatoires) et s’intègre avec GitHub.

Azure Pipelines

Le cœur du sujet de cet article. C’est le moteur CI/CD d’Azure DevOps. Il permet de créer des pipelines de build et de déploiement pour n’importe quel langage (Node.js, Python, .NET, Java, Flutter…) et n’importe quelle cible de déploiement (Azure, AWS, GCP, Kubernetes, on-premise).

Azure Test Plans

Un outil de gestion des tests manuels et exploratoires. Il permet de créer des plans de test, d’associer des cas de test à des user stories, et de suivre les résultats dans le temps.

Azure Artifacts

Un registre de packages privé compatible npm, NuGet, Maven, Python et Cargo. Utile pour partager des bibliothèques internes entre projets sans passer par des registres publics.

3. CI/CD : les concepts fondamentaux

Avant de créer un pipeline, clarifions les termes.

Intégration continue (CI)

La CI consiste à automatiser la vérification du code à chaque push. Dès qu’un développeur envoie du code sur le dépôt, un pipeline se déclenche : il compile l’application, exécute les tests unitaires et génère un artefact (binaire, image Docker, bundle…). L’objectif est de détecter les régressions au plus tôt.

Déploiement continu (CD)

Le CD prend l’artefact produit par la CI et le déploie automatiquement vers un ou plusieurs environnements (staging, production). On distingue la Continuous Delivery – le déploiement en production nécessite une validation manuelle – de la Continuous Deployment – tout est automatique, sans intervention humaine.

Flux typique d’un pipeline CI/CD :

Code Push → Build → Tests → Staging → Production
  (Git)    (Compile) (Unit/E2E) (Deploy)  (Release)

4. Créer son premier pipeline

Azure Pipelines se configure via un fichier YAML versionné directement dans le dépôt. C’est l’approche recommandée : le pipeline fait partie du code, il est reviewé comme n’importe quelle modification.

Prérequis

  • Un compte Azure DevOps (gratuit pour les projets publics, 5 utilisateurs gratuits pour les projets privés)
  • Un dépôt Azure Repos ou GitHub connecté
  • Un projet créé dans l’organisation Azure DevOps

Créer le pipeline depuis l’interface

Dans Azure DevOps, accéder à Pipelines → New pipeline. Sélectionner la source du code (Azure Repos Git, GitHub, Bitbucket…), puis choisir le dépôt. Azure propose ensuite des templates selon la stack détectée, ou l’option Starter pipeline pour partir de zéro.

5. Structure du fichier YAML

Voici la structure d’un pipeline CI complet pour une application Node.js :

# azure-pipelines.yml

trigger:
  branches:
    include:
      - main
      - develop

pool:
  vmImage: 'ubuntu-latest'

variables:
  nodeVersion: '20.x'

stages:
  - stage: Build
    displayName: 'Build & Test'
    jobs:
      - job: BuildJob
        displayName: 'Install, Build, Test'
        steps:
          - task: NodeTool@0
            inputs:
              versionSpec: $(nodeVersion)
            displayName: 'Use Node.js $(nodeVersion)'

          - script: npm ci
            displayName: 'Install dependencies'

          - script: npm run build
            displayName: 'Build application'

          - script: npm test -- --coverage
            displayName: 'Run unit tests'

          - task: PublishTestResults@2
            inputs:
              testResultsFormat: 'JUnit'
              testResultsFiles: '**/test-results.xml'
            displayName: 'Publish test results'

          - task: PublishBuildArtifacts@1
            inputs:
              pathToPublish: '$(Build.ArtifactStagingDirectory)'
              artifactName: 'drop'
            displayName: 'Publish build artifact'

Anatomie du fichier

  • trigger — définit les branches qui déclenchent le pipeline automatiquement.
  • pool — l’agent d’exécution. ubuntu-latest est le plus courant ; on peut aussi utiliser windows-latest ou macos-latest, ou un agent self-hosted.
  • variables — centralise les valeurs réutilisables dans le pipeline.
  • stages — structure le pipeline en grandes étapes logiques (Build, Test, Deploy…).
  • jobs — les unités de travail exécutées en parallèle ou en séquence à l’intérieur d’un stage.
  • steps — les actions concrètes : scripts shell, tâches Azure prédéfinies (NodeTool, PublishTestResults, etc.).

6. Déploiement continu vers Azure App Service

On étend le pipeline avec un stage de déploiement. L’exemple ci-dessous déploie sur un Azure App Service (Linux) après validation du build.

# azure-pipelines.yml — stage Deploy

  - stage: Deploy
    displayName: 'Deploy to Staging'
    dependsOn: Build
    condition: succeeded()
    jobs:
      - deployment: DeployStaging
        displayName: 'Deploy to App Service'
        environment: 'staging'
        pool:
          vmImage: 'ubuntu-latest'
        strategy:
          runOnce:
            deploy:
              steps:
                - task: AzureWebApp@1
                  inputs:
                    azureSubscription: 'OryStack-ServiceConnection'
                    appType: 'webAppLinux'
                    appName: 'orystack-app-staging'
                    package: '$(Pipeline.Workspace)/drop/**/*.zip'
                    runtimeStack: 'NODE|20-lts'
                  displayName: 'Deploy to Azure App Service'

Service Connection : pour que le pipeline puisse déployer sur Azure, il faut créer une Service Connection dans les paramètres du projet (Project Settings → Service connections). Elle représente une identité avec les droits nécessaires sur l’abonnement Azure cible.

Gestion des environnements

Azure DevOps permet de définir des Environments (Pipelines → Environments) avec des règles d’approbation. Par exemple : le déploiement en production nécessite la validation manuelle d’un tech lead avant de s’exécuter. C’est la frontière entre Continuous Delivery et Continuous Deployment.

7. Bonnes pratiques

Séparer CI et CD

Pour les projets complexes, il est courant d’avoir deux fichiers YAML distincts : un pour le pipeline de build (CI) déclenché à chaque push, et un pour le pipeline de release (CD) déclenché manuellement ou sur un tag Git.

Utiliser des variable groups

Les secrets (tokens, clés API, chaînes de connexion) ne doivent jamais apparaître en clair dans le YAML. Azure DevOps propose les Variable Groups — avec intégration Azure Key Vault — pour centraliser et sécuriser ces valeurs.

Mettre en cache les dépendances

La tâche Cache@2 permet de mettre en cache le dossier node_modules ou .gradle entre les runs. Sur un projet de taille moyenne, cela peut réduire le temps de build de 40 à 60 %.

Définir des politiques de branches

Dans Azure Repos, activer les Branch Policies sur main : exiger une pull request, bloquer le merge si le pipeline CI échoue, et imposer au moins une approbation. C’est la combinaison qui garantit une base de code stable.

Monitorer les runs

Azure DevOps conserve l’historique des runs avec les logs complets, les durées et les artefacts. Configurer des alertes email ou Teams en cas d’échec permet de réagir rapidement sans surveiller en permanence.

En résumé

Azure DevOps offre un écosystème complet pour industrialiser le développement logiciel. Azure Pipelines, au cœur du dispositif, permet de passer d’un simple script de build à un pipeline multi-environnements avec approbations, gestion des secrets et déploiements automatisés — le tout versionné en YAML.

Chez OryStack, on intègre Azure Pipelines dans les projets où l’hébergement Azure est déjà en place, ou quand l’équipe cliente utilise déjà l’écosystème Microsoft. Pour les projets indépendants du cloud, on s’appuie sur GitHub Actions ou GitLab CI selon le contexte.

Équipe technique OryStack · contact@orystack.com

Tags:

Leave A Comment

All fields marked with an asterisk (*) are required