Personnaliser votre pipeline

Azure DevOps Services | Azure DevOps Server 2022 | Azure DevOps Server 2019

Il s’agit d’un guide pas à pas sur les façons courantes de personnaliser votre pipeline.

Prérequis

Suivez les instructions fournies dans Créer votre premier pipeline pour créer un pipeline opérationnel.

Comprendre le fichier azure-pipelines.yml

Un pipeline est défini avec un fichier YAML dans votre dépôt. En règle générale, ce fichier est nommé azure-pipelines.yml et se trouve à la racine de votre dépôt.

Accédez à la page Pipelines dans Azure Pipelines, sélectionnez le pipeline que vous avez créé, puis choisissez Modifier dans le menu contextuel du pipeline pour ouvrir l’éditeur YAML pour le pipeline.

Remarque

Pour obtenir des instructions afin de voir et gérer vos pipelines dans le portail Azure DevOps, consultez Afficher et gérer les pipelines.

Examinez le contenu du fichier YAML.

 trigger:
 - main

 pool:
   vmImage: 'ubuntu-latest'

 steps:
 - task: Maven@4
   inputs:
     mavenPomFile: 'pom.xml'
     mavenOptions: '-Xmx3072m'
     javaHomeOption: 'JDKVersion'
     jdkVersionOption: '1.11'
     jdkArchitectureOption: 'x64'
     publishJUnitResults: false
     testResultsFiles: '**/surefire-reports/TEST-*.xml'
     goals: 'package'

Notes

Le contenu de votre fichier YAML peut être différent selon l’exemple de dépôt avec lequel vous avez démarré ou les mises à niveau effectuées dans Azure Pipelines.

Ce pipeline s’exécute chaque fois que votre équipe pousse un changement sur la branche primaire de votre dépôt ou crée une demande de tirage. Il s’exécute sur une machine Linux hébergée par Microsoft. Le processus de pipeline a une seule étape, qui est l’exécution de la tâche Maven.

Changer la plateforme de génération

Vous pouvez générer votre projet sur des agents hébergés par Microsoft qui ont déjà des SDK et des outils pour différents langages de développement. Vous pouvez également utiliser des agents auto-hébergés avec les outils spécifiques dont vous avez besoin.

• Accédez à l’éditeur de votre pipeline en sélectionnant l’action Modifier le pipeline sur la build, ou en sélectionnant Modifier dans la page principale du pipeline.

• Actuellement, le pipeline s’exécute sur un agent Linux :

  pool:
    vmImage: "ubuntu-latest"
  

• Pour choisir une autre plateforme, comme Windows ou Mac, changez la valeur vmImage :

  pool:
    vmImage: "windows-latest"
  

  pool:
    vmImage: "macos-latest"
  

• Sélectionnez Enregistrer, puis confirmez les changements pour voir votre pipeline s’exécuter sur une autre plateforme.

Ajouter des étapes

Vous pouvez ajouter d’autres scripts ou tâches comme étapes de votre pipeline. Une tâche est un script pré-empaqueté. Vous pouvez utiliser des tâches pour générer, tester, publier ou déployer votre application. Pour Java, la tâche Maven que nous avons utilisée gère les tests et la publication des résultats. Toutefois, vous pouvez également utiliser une tâche pour publier les résultats de la couverture du code.

• Ouvrez l’éditeur YAML pour votre pipeline.

• Ajoutez l’extrait de code suivant à la fin de votre fichier YAML.

  - task: PublishCodeCoverageResults@1
    inputs:
      codeCoverageTool: "JaCoCo"
      summaryFileLocation: "$(System.DefaultWorkingDirectory)/**/site/jacoco/jacoco.xml"
      reportDirectory: "$(System.DefaultWorkingDirectory)/**/site/jacoco"
      failIfCoverageEmpty: true
  

• Sélectionnez Enregistrer pour confirmer les changements.

• Vous pouvez voir les résultats de votre test et de la couverture du code en sélectionnant votre build et en accédant aux onglets Test et Couverture.

Générer sur plusieurs plateformes

Vous pouvez générer et tester votre projet sur plusieurs plateformes. Pour ce faire, vous pouvez utiliser strategy et matrix. Vous pouvez utiliser des variables pour placer facilement les données dans différentes parties d’un pipeline. Pour cet exemple, nous utilisons une variable pour passer le nom de l’image que nous voulons utiliser.

• Dans votre fichier azure-pipelines.yml, remplacez ce contenu :

  pool:
    vmImage: "ubuntu-latest"
  

  par le contenu suivant :

  strategy:
    matrix:
      linux:
        imageName: "ubuntu-latest"
      mac:
        imageName: "macOS-latest"
      windows:
        imageName: "windows-latest"
    maxParallel: 3
  
  pool:
    vmImage: $(imageName)
  

• Sélectionnez Enregistrer, puis confirmez les changements pour voir votre build exécuter jusqu’à trois travaux sur trois plateformes différentes.

Chaque agent peut exécuter un seul travail à la fois. Pour exécuter plusieurs travaux en parallèle, vous devez configurer plusieurs agents. Vous avez également besoin d’un nombre suffisant de travaux parallèles.

Générer avec plusieurs versions

Pour générer un projet avec différentes versions de ce langage, vous pouvez utiliser une matrix de versions et une variable. Dans cette étape, vous pouvez générer le projet Java avec deux versions différentes de Java sur une même plateforme ou exécuter différentes versions de Java sur différentes plateformes.

Notes

Vous ne pouvez pas utiliser strategy plusieurs fois dans un contexte.

• Si vous voulez générer sur une seule plateforme et plusieurs versions, ajoutez la matrice suivante à votre fichier azure-pipelines.yml avant la tâche Maven et après vmImage.

  strategy:
    matrix:
      jdk10:
        jdkVersion: "1.10"
      jdk11:
        jdkVersion: "1.11"
    maxParallel: 2
  

• Remplacez ensuite cette ligne dans votre tâche Maven :

  jdkVersionOption: "1.11"
  

  par cette ligne :

  jdkVersionOption: $(jdkVersion)
  

• Veillez à rétablir la variable $(imageName) sur la plateforme de votre choix.

• Si vous voulez générer sur plusieurs plateformes et versions, remplacez l’intégralité du contenu de votre fichier azure-pipelines.yml avant la tâche de publication par l’extrait de code suivant :

  trigger:
  - main
  
  strategy:
    matrix:
      jdk10_linux:
        imageName: "ubuntu-latest"
        jdkVersion: "1.10"
      jdk11_windows:
        imageName: "windows-latest"
        jdkVersion: "1.11"
    maxParallel: 2
  
  pool:
    vmImage: $(imageName)
  
  steps:
  - task: Maven@4
    inputs:
      mavenPomFile: "pom.xml"
      mavenOptions: "-Xmx3072m"
      javaHomeOption: "JDKVersion"
      jdkVersionOption: $(jdkVersion)
      jdkArchitectureOption: "x64"
      publishJUnitResults: true
      testResultsFiles: "**/TEST-*.xml"
      goals: "package"
  

• Sélectionnez Enregistrer, puis confirmez les changements pour voir votre build exécuter deux travaux sur deux plateformes et SDK différents.

Personnaliser les déclencheurs CI

Les déclencheurs de pipeline entraînent l’exécution d’un pipeline. Vous pouvez utiliser trigger: pour provoquer l’exécution d’un pipeline chaque fois que vous poussez une mise à jour sur une branche. Les pipelines YAML sont configurés par défaut avec un déclencheur CI sur votre branche par défaut (qui est généralement main). Vous pouvez configurer des déclencheurs pour des branches spécifiques ou pour la validation des demandes de tirage. Pour un déclencheur de validation de demande de tirage, remplacez simplement l’étape trigger: par pr: comme indiqué dans les deux exemples ci-dessous. Par défaut, le pipeline s’exécute pour chaque changement de demande de tirage.

• Si vous voulez configurer des déclencheurs, ajoutez un des extraits de code suivants au début de votre fichier azure-pipelines.yml.

  trigger:
    - main
    - releases/*
  

  pr:
    - main
    - releases/*
  

  Vous pouvez spécifier le nom complet de la branche (par exemple, main) ou un caractère générique avec le préfixe correspondant (par exemple, releases/*).

Paramètres du pipeline

Vous pouvez voir et configurer les paramètres du pipeline dans le menu Autres actions dans la page de détails du pipeline.

• Gérer la sécurité - Gérer la sécurité
• Renommer/déplacer : modifiez le nom et l’emplacement du dossier de votre pipeline.
• Badge d’état - Ajouter un badge d’état à votre dépôt
• Supprimer : supprime le pipeline, y compris toutes les builds et les artefacts associés.
• Exécutions planifiées - Vue Exécutions planifiées

Choisissez Paramètres pour configurer les paramètres de pipeline suivants.

Dans le volet Paramètres du pipeline, vous pouvez configurer les paramètres suivants.

• Traitement des nouvelles demandes d’exécution : vous pouvez empêcher les nouvelles exécutions de démarrer sur votre pipeline.

  • Par défaut, le traitement des nouvelles demandes d’exécution est Activé. Ce paramètre permet le traitement standard de tous les types de déclencheur, y compris les exécutions manuelles.
  • Les pipelines en pause autorisent le traitement des demandes d’exécution, mais ces demandes sont mises en file d’attente sans réellement démarrer. Quand le traitement des nouvelles demandes est activé, le traitement de l’exécution reprend à partir de la première demande dans la file d’attente.
  • Les pipelines désactivés empêchent les utilisateurs de démarrer de nouvelles exécutions. Tous les déclencheurs sont également désactivés quand ce paramètre est appliqué. Toutes les stratégies de build qui utilisent un pipeline désactivé affichent le message « Impossible de mettre en file d’attente le build » en regard de la stratégie de build dans la fenêtre de vue d’ensemble de la demande de tirage et l’état de la stratégie de build est « Arrêté ».

• Chemin du fichier YAML : si vous devez indiquer à votre pipeline d’utiliser un autre fichier YAML, vous pouvez spécifier le chemin de ce fichier. Ce paramètre peut également être utile si vous devez déplacer/renommer votre fichier YAML.

• Lier automatiquement les éléments de travail inclus dans cette exécution : les changements associés à une exécution de pipeline donnée peuvent avoir des éléments de travail associés. Sélectionnez cette option pour lier ces éléments de travail à l’exécution. Quand Lier automatiquement les éléments de travail inclus dans cette exécution est sélectionné, vous devez spécifier une branche spécifique, ou * pour toutes les branches, ce qui est la valeur par défaut. Si vous spécifiez une branche, les éléments de travail sont uniquement associés aux exécutions de cette branche. Si vous spécifiez *, les éléments de travail sont associés pour toutes les exécutions.

  

  • Pour recevoir des notifications en cas d’échec de vos exécutions, consultez comment Gérer les notifications d’une équipe

Gérer la sécurité

Vous pouvez configurer la sécurité des pipelines au niveau d’un projet à partir des autres actions sur la page d’arrivée des pipelines et au niveau d’un pipeline sur la page de détails du pipeline.

Pour prendre en charge la sécurité des opérations de votre pipeline, vous pouvez ajouter des utilisateurs à un groupe de sécurité intégré, définir des autorisations individuelles pour un utilisateur ou un groupe, ou ajouter des utilisateurs à des rôles prédéfinis. Vous pouvez gérer la sécurité d’Azure Pipelines dans le portail web, à partir du contexte utilisateur ou administrateur. Pour plus d’informations sur la configuration de la sécurité des pipelines, consultez Autorisations de pipeline et rôles de sécurité.

Créer un élément de travail en cas d’échec

Les pipelines YAML n’ont pas le paramètre Créer un élément de travail en cas d’échec comme les pipelines de build classiques. Les pipelines de build classiques sont monophases, et Créer un élément de travail en cas d’échec s’applique à l’ensemble du pipeline. Les pipelines YAML peuvent être multiphases et un paramètre au niveau du pipeline peut ne pas être approprié. Pour implémenter Créer un élément de travail en cas d’échec dans un pipeline YAML, vous pouvez utiliser des méthodes comme l’appel de l’API REST Éléments de travail - Créer ou la commande Azure DevOps CLI az boards work-item create au point souhaité dans votre pipeline.

L’exemple précédent a deux travaux. Le premier travail représente le travail du pipeline, mais en cas d’échec, le deuxième travail s’exécute et crée un bogue dans le même projet que le pipeline.

# When manually running the pipeline, you can select whether it
# succeeds or fails.
parameters:
- name: succeed
  displayName: Succeed or fail
  type: boolean
  default: false

trigger:
- main

pool:
  vmImage: ubuntu-latest

jobs:
- job: Work
  steps:
  - script: echo Hello, world!
    displayName: 'Run a one-line script'

  # This malformed command causes the job to fail
  # Only run this command if the succeed variable is set to false
  - script: git clone malformed input
    condition: eq(${{ parameters.succeed }}, false)

# This job creates a work item, and only runs if the previous job failed
- job: ErrorHandler
  dependsOn: Work
  condition: failed()
  steps: 
  - bash: |
      az boards work-item create \
        --title "Build $(build.buildNumber) failed" \
        --type bug \
        --org $(System.TeamFoundationCollectionUri) \
        --project $(System.TeamProject)
    env: 
      AZURE_DEVOPS_EXT_PAT: $(System.AccessToken)
    displayName: 'Create work item on failure'

Notes

Azure Boards vous permet de configurer le suivi des éléments de travail en utilisant plusieurs processus différents, comme Agile ou Basic. Chaque processus a des types d’élément de travail différents, et les types d’élément de travail ne sont pas tous disponibles dans chaque processus. Pour obtenir la liste des types d’élément de travail pris en charge par chaque processus, consultez Types d’élément de travail (WIT).

L’exemple précédent utilise des paramètres de runtime pour configurer si le pipeline réussit ou échoue. Quand vous exécutez manuellement le pipeline, vous pouvez définir la valeur du paramètre succeed. La deuxième étape script du premier travail du pipeline évalue le paramètre succeed et s’exécute seulement si succeed est défini sur false.

Le deuxième travail du pipeline dépend du premier travail et ne s’exécute qu’en cas d’échec du premier travail. Le deuxième travail utilise la commande Azure DevOps CLI az boards work-item create pour créer un bogue. Pour plus d’informations sur l’exécution des commandes CLI Azure DevOps à partir d’un pipeline, consultez Exécuter des commandes dans un pipeline YAML.

Cet exemple utilise deux travaux, mais cette même approche peut être utilisée sur plusieurs phases.

Notes

Vous pouvez également utiliser une extension de la Place de marché de type Créer un bogue en cas d’échec de la mise en production, qui prend en charge les pipelines YAML multiphases.

Étapes suivantes

Vous avez appris les principes de base de la personnalisation de votre pipeline. Ensuite, nous vous recommandons de voir comment personnaliser un pipeline pour le langage que vous utilisez :

• .NET Core
• Containers
• Go
• Java
• Node.JS
• Python

Sinon, pour convertir votre pipeline CI en pipeline CI/CD, ajoutez un travail de déploiement avec des étapes pour déployer votre application dans un environnement.

Pour en savoir plus sur les rubriques de ce guide, consultez Travaux, Tâches, Catalogue de tâches, Variables, Déclencheurs ou Résolution des problèmes.

Pour savoir ce que vous pouvez faire d’autre dans les pipelines YAML, consultez Informations de référence sur le schéma YAML.