Événements
Créer des applications intelligentes
17 mars, 23 h - 21 mars, 23 h
Rejoignez la série de rencontres pour créer des solutions IA évolutives basées sur des cas d’usage réels avec d’autres développeurs et experts.
S’inscrire maintenantCe navigateur n’est plus pris en charge.
Effectuez une mise à niveau vers Microsoft Edge pour tirer parti des dernières fonctionnalités, des mises à jour de sécurité et du support technique.
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.
Suivez les instructions fournies dans Créer votre premier pipeline pour créer un pipeline opérationnel.
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.
Notes
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.
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.
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.
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.
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.
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/*
).
Vous pouvez afficher et configurer les paramètres du pipeline à partir du menu Autres actions de la page de détails du pipeline.
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.
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.
Vous pouvez configurer la sécurité des pipelines au niveau d'un projet à partir de la page Plus d'actions de la page de destination des pipelines, et au niveau d'un pipeline sur la page des 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é.
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.
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 mettre en œuvre Créer un élément de travail en cas d'échec dans un pipeline YAML, vous pouvez utiliser l'appel API REST Éléments de travail - Créer à l'endroit 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: |
curl \
-X POST \
-H 'Authorization: Basic $(System.AccessToken)' \
-H 'Content-Type: application/json-patch+json' \
-d '[
{
"op": "add",
"path": "/fields/System.Title",
"from": null,
"value": "git clone failed"
}
]' \
"$(System.CollectionUri)$(System.TeamProject)/_apis//wit/workitems/$Bug?api-version=7.1-preview.3
"
env:
SYSTEM_ACCESSTOKEN: $(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 API az boards work-item create pour créer un bogue.
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.
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 :
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.
Événements
Créer des applications intelligentes
17 mars, 23 h - 21 mars, 23 h
Rejoignez la série de rencontres pour créer des solutions IA évolutives basées sur des cas d’usage réels avec d’autres développeurs et experts.
S’inscrire maintenantEntrainement
Module
Créer un pipeline de build avec Azure Pipelines - Training
Configurez un pipeline d’intégration continue (CI) qui automatise le processus de génération de votre application.
Certification
Microsoft Certified : DevOps Engineer Expert - Certifications
Cette certification mesure votre capacité à réaliser les tâches techniques suivantes : Concevoir et implémenter des processus et des communications, concevoir et implémenter une stratégie de contrôle de code source, concevoir et implémenter des pipelines de build et de mise en production, développer un plan de sécurité et de conformité et implémenter une stratégie d’instrumentation.
Documentation
Guide de l’éditeur de pipeline YAML - Azure Pipelines
Découvrez comment créer et modifier des pipelines avec l’éditeur de pipeline YAML.
Documentation Azure Pipelines - Azure DevOps
Configurez et gérez l’intégration continue et la livraison continue (CI/CD) pour l’application et la plateforme de votre choix.
YAML et pipelines classiques - Azure Pipelines
Découvrez les bases d'Azure Pipelines et explorez les différentes fonctionnalités disponibles pour les pipelines YAML et Classic.