Générer, tester et déployer des applications .NET Core
Azure DevOps Services | Azure DevOps Server 2022 | Azure DevOps Server 2019
Utilisez Azure Pipeline pour construire, tester et déployer automatiquement vos projets .NET Core. Cet article explique comment effectuer les tâches suivantes :
- Configurez votre environnement de construction avec des agents auto-hébergés.
- Restaurez les dépendances, construisez votre projet et testez avec la tâche .NET Core (DotNetCoreCLI@2) ou un script.
- Testez votre code et utilisez la tâche publish code coverage pour publier les résultats de la couverture de code.
- Packagez et livrez votre résultat de build sur :
- votre pipeline.
- un flux NuGet.
- un fichier
.zip
pour déployer une application web sur Azure.
- Configurez votre environnement de build avec des agents hébergés par Microsoft ou auto-hébergés.
- Restaurez les dépendances, construisez votre projet et testez avec la tâche .NET Core (DotNetCoreCLI@2) ou un script.
- Testez votre code et utilisez la tâche publish code coverage pour publier les résultats de la couverture de code.
- Packagez et livrez votre résultat de build sur :
- votre pipeline.
- un flux NuGet.
- un fichier
.zip
pour déployer une application web sur Azure.
Remarque
Pour obtenir de l’aide sur les projets .NET Framework, consultez Créer des applications ASP.NET avec .NET Framework.
Prérequis
- Un compte GitHub dans lequel vous pouvez créer un référentiel. Créez-en un gratuitement.
- Une organisation et un projet Azure DevOps. Créez-en un gratuitement.
- Possibilité d’exécuter des pipelines sur des agents hébergés par Microsoft. Vous pouvez acheter un travail parallèle ou demander un niveau gratuit.
- Un compte GitHub dans lequel vous pouvez créer un référentiel. Créez-en un gratuitement.
- Une collection Azure DevOps.
- La capacité de faire fonctionner des pipelines sur un agent auto-hébergé avec Docker installé et en cours d’exécution sur l’hôte de l’agent.
Créer votre premier pipeline
Vous débutez avec Azure Pipelines ? Si c’est le cas, nous vous recommandons d’abord d’essayer la section suivante.
Créer un projet .NET
Si vous n’avez pas de projet .NET à utiliser, créez-en un nouveau sur votre système local. Commencez par installer la dernière version du SDK .NET 8.0 .
Ouvrez une fenêtre de terminal.
Créer un répertoire de projet et y accéder.
Créez une nouvelle application web .NET 8.
dotnet new webapp -f net8.0
À partir de la même session de terminal, exécutez l’application localement à l’aide de la commande
dotnet run
depuis votre répertoire de projet.dotnet run
Une fois l’application démarrée, appuyez sur Ctrl-C pour l’arrêter.
Créez un référentiel git et connectez-le à GitHub
À partir du répertoire du projet, créez un dépôt Git local et commitez le code de l’application dans la branche primaire.
Connectez votre référentiel Git local à un référentiel GitHub.
Créer un projet DevOps
Connectez-vous à Azure Pipelines. Une fois que vous êtes connecté, votre navigateur accède à https://dev.azure.com/my-organization-name
et affiche votre tableau de bord Azure DevOps.
- Dans un navigateur, rendez-vous sur dev.azure.com et connectez-vous.
- Sélectionnez votre organisation.
- Créez un nouveau projet en sélectionnant Nouveau projet ou Créer un projet si c’est le premier projet dans l’organisation.
- Entrez un Nom de projet.
- Choisissez la Visibilité de votre projet.
- Sélectionnez Créer.
- Dans un navigateur, rendez-vous sur votre serveur Azure DevOps.
- Sélectionnez votre collection.
- Créez un nouveau projet en sélectionnant Nouveau projet ou Créer un projet si c’est le premier projet dans la collection.
- Entrez un Nom de projet.
- Choisissez la Visibilité de votre projet.
- Sélectionnez Créer.
- Dans une fenêtre de navigateur, connectez-vous à votre serveur Azure DevOps et sélectionnez votre collection.
- Sélectionnez Nouveau projet.
- Entrer un nom de projet.
- Si vous le souhaitez, entrez une description.
- Sélectionnez Créer.
Configurez votre environnement de build
Vos builds s’exécutent sur des agents auto-hébergés. Assurez-vous d’avoir la version nécessaire du SDK et du runtime .NET Core installés sur les agents. Vous pouvez construire vos projets .NET Core en utilisant le SDK et le runtime .NET Core sur Windows, Linux, macOS et Docker.
Vous pouvez installer une version spécifique du SDK .NET en ajoutant la tâche UseDotNet@2 dans votre fichier YAML de pipeline ou ajouter la tâche à votre pipeline en utilisant l’éditeur classique.
Exemple de snippet YAML :
steps:
- task: UseDotNet@2
inputs:
version: '8.x'
Vos builds fonctionnent sur des agents hébergés par Microsoft. Vous pouvez construire vos projets .NET Core en utilisant le SDK et le runtime .NET Core sur Windows, Linux et macOS.
Alternativement, vous pouvez utiliser un agent auto-hébergé. Avec un agent auto-hébergé, vous pouvez utiliser des SDKs en avant-première ou privés non officiellement supportés par les services Azure DevOps et exécuter des builds incrémentiels.
Créer votre pipeline
Vous pouvez utiliser l’éditeur de pipeline YAML ou l’éditeur classique pour créer votre pipeline. Pour utiliser l’éditeur classique, sélectionnez Utiliser l’éditeur classique.
Créez un nouveau pipeline et sélectionnez votre source
Connectez-vous à votre organisation Azure DevOps et accédez à votre projet.
Accédez à Pipelines, puis sélectionnez Nouveau pipeline ou Création d’un pipeline si vous créez votre premier pipeline.
Effectuez les étapes de l’Assistant en sélectionnant d’abord GitHub comme emplacement du code source.
Vous serez peut-être redirigé vers GitHub pour vous connecter. Si c’est le cas, entrez vos informations d’identification GitHub.
Quand la liste des dépôts s’affiche, sélectionnez le vôtre.
Vous serez peut-être redirigé vers GitHub pour pouvoir installer l’application Azure Pipelines. Si c’est le cas, sélectionnez Approuver et installer.
Configurer votre pipeline
Quand l’onglet Configurer apparaît, sélectionnez Afficher plus et choisissez le modèle de pipeline ASP.NET Core dans la liste.
Examinez votre nouveau pipeline pour voir ce que fait le YAML.
Vous pouvez personnaliser le fichier YAML selon vos besoins. Par exemple, vous pouvez spécifier le pool d’agents ou ajouter une tâche pour installer un SDK .NET différent.
Sauvegardez et exécutez votre pipeline
Lorsque vous êtes prêt, sélectionnez Enregistrer et exécuter.
Facultativement, vous pouvez modifier le message de validation.
Validez le nouveau fichier azure-pipelines.yml dans votre référentiel en sélectionnant Sauvegarder et exécuter.
Pour voir votre pipeline en action, sélectionnez le travail dans la section Travaux.
Créez et exécutez votre pipeline.
Vous pouvez créer un pipeline en utilisant l’éditeur de pipeline YAML ou l’éditeur classique.
- Allez dans votre projet et sélectionnez Pipelines.
- Sélectionnez Créer un pipeline ou Nouveau pipeline si vous créez le premier pipeline pour ce projet.
Sélectionnez votre source
Sélectionnez votre référentiel source. Pour cet exemple, utilisez GitHub Enterprise Server.
- Saisissez l’URL de votre compte GitHub. Par exemple :
https://github.com/<username>
. - Saisissez votre jeton d’accès personnel pour votre compte GitHub.
- Saisissez un nom de connexion de service. Par exemple :
my-github
. - Sélectionnez Créer.
- Saisissez l’URL de votre compte GitHub. Par exemple :
Sélectionnez votre référentiel GitHub.
Configurer votre pipeline
Sur l’onglet Configurer, sélectionnez Afficher plus et choisissez le modèle de pipeline ASP.NET Core dans la liste.
Examinez votre nouveau pipeline pour voir ce que fait le YAML.
Vous pouvez personnaliser le fichier YAML selon vos besoins. Par exemple, vous pouvez ajouter des tâches pour installer un SDK .NET ou pour tester et publier votre projet.
Sauvegardez et exécutez votre pipeline
Cliquez sur Enregistrer.
Pour valider le fichier YAML de votre pipeline dans votre référentiel, modifiez le message de commit selon vos besoins et sélectionnez Enregistrer.
Sélectionnez Exécuter pour exécuter votre pipeline.
Pour voir les journaux de construction pendant l’exécution de votre pipeline, sélectionnez le numéro de build en haut de la page.
Sélectionnez Enregistrer et exécuter.
Pour valider le nouveau fichier azure-pipelines.yml dans votre référentiel, modifiez le message de commit selon vos besoins et sélectionnez Enregistrer et exécuter.
Pour voir votre pipeline en action, sélectionnez le travail dans la section Travaux.
Vous disposez maintenant d’un pipeline de travail prêt à être personnalisé ! Lisez la suite pour apprendre certaines des façons les plus utilisées pour personnaliser votre pipeline.
Environnement de génération
Azure Pipelines utilise des agents auto-hébergés pour construire vos projets .NET Core. Assurez-vous d’avoir la version nécessaire du SDK et du runtime .NET Core installés sur les agents. Vous pouvez construire vos projets .NET Core en utilisant le SDK et le runtime .NET Core sur Windows, Linux, macOS et Docker.
Par exemple, pour sélectionner un pool et des capacités d’agent dans le fichier YAML du pipeline :
Vous pouvez sélectionner le pool d’agents et l’agent pour votre travail de build. Les agents sont spécifiés en fonction de leurs capacités.
pool:
name: myPrivateAgents
demands:
- agent.os -equals Darwin
- anotherCapability -equals somethingElse
Vous pouvez installer une version spécifique du SDK .NET en ajoutant la tâche UseDotNet@2 dans votre pipeline. Gardez à l’esprit que pour les agents qui fonctionnent sur des systèmes physiques, l’installation de SDK et d’outils via votre pipeline modifie l’environnement de build sur l’hôte de l’agent.
Pour installer un SDK plus récent, définissez performMultiLevelLookup
sur true
dans l’extrait de code suivant :
steps:
- task: UseDotNet@2
displayName: 'Install .NET Core SDK'
inputs:
version: 8.x
performMultiLevelLookup: true
includePreviewVersions: true # Required for preview versions
Vous pouvez utiliser Azure Pipelines pour construire vos projets .NET Core sur Windows, Linux ou macOS sans avoir besoin de configurer une infrastructure.
Par exemple, Ubuntu est défini ici dans le fichier YAML du pipeline.
pool:
vmImage: 'ubuntu-latest'
Voir Agents hébergés par Microsoft pour une liste complète des images et des exemples de configuration supplémentaires.
Les agents hébergés par Microsoft dans Azure Pipelines incluent plusieurs versions préinstallées des SDK .NET Core pris en charge. Les agents hébergés par Microsoft n’incluent pas certaines des anciennes versions du SDK .NET Core. Ils n’incluent généralement pas les préversions. Si vous avez besoin de ces versions du SDK sur des agents hébergés par Microsoft, installez-les en utilisant la tâche UseDotNet@2.
Par exemple, pour installer le SDK 5.0.x, ajoutez l’extrait de code suivant :
steps:
- task: UseDotNet@2
inputs:
version: '5.x'
Les agents Windows incluent déjà un runtime .NET Core. Pour installer un SDK plus récent, définissez performMultiLevelLookup
sur true
dans l’extrait de code suivant :
steps:
- task: UseDotNet@2
displayName: 'Install .NET Core SDK'
inputs:
version: 8.x
performMultiLevelLookup: true
includePreviewVersions: true # Required for preview versions
Conseil
Pour économiser le coût d’exécution du programme d’installation de l’outil, vous pouvez configurer un agent linux, macOS ou Windows auto-hébergé. Vous pouvez également utiliser des agents auto-hébergés pour gagner du temps si vous disposez d’un dépôt volumineux ou si vous exécutez des builds incrémentielles. Un agent auto-hébergé peut également vous aider à utiliser les SDK en avant-première ou privés qui ne sont pas officiellement pris en charge par Azure DevOps ou qui sont uniquement disponibles dans vos environnements d’entreprise ou locaux.
Restaurer les dépendances
NuGet est un moyen populaire de dépendre du code que vous ne générez pas. Vous pouvez télécharger des packages NuGet et des outils spécifiques au projet spécifiés dans le fichier projet en exécutant la commande dotnet restore
via la tâche .NET Core ou directement dans un script dans votre pipeline. Pour plus d’informations, veuillez consulter la section .NET Core task (DotNetCoreCLI@2).
Vous pouvez télécharger des packages NuGet à partir d’Azure Artifacts, de NuGet.org ou d’un autre dépôt NuGet externe ou interne. La tâche .NET Core est particulièrement utile pour restaurer des packages à partir de flux NuGet authentifiés. Si votre flux se trouve dans le même projet que votre pipeline, vous n’avez pas besoin de vous authentifier.
Ce pipeline utilise un flux d’artefacts Azure pour dotnet restore
dans la tâche DotNetCoreCLI@2.
trigger:
- main
pool:
vmImage: 'windows-latest'
steps:
- task: UseDotNet@2
displayName: 'Install .NET Core SDK'
inputs:
version: 8.x
performMultiLevelLookup: true
includePreviewVersions: true # Required for preview versions
variables:
buildConfiguration: 'Release'
steps:
- task: DotNetCoreCLI@2
inputs:
command: 'restore'
feedsToUse: 'select'
vstsFeed: 'my-vsts-feed' # A series of numbers and letters
- task: DotNetCoreCLI@2
inputs:
command: 'build'
arguments: '--configuration $(buildConfiguration)'
displayName: 'dotnet build $(buildConfiguration)'
La commande dotnet restore
utilise le NuGet.exe
empaqueté avec le SDK .NET Core et ne peut restaurer que les paquets spécifiés dans les fichiers de projet .NET Core .csproj
.
Si vous avez également un projet Microsoft .NET Framework dans votre solution ou si vous utilisez package.json
pour spécifier vos dépendances, utilisez la tâche NuGet pour restaurer ces dépendances.
- task: NuGetCommand@2
inputs:
command: 'restore'
restoreSolution: '**/*.sln'
feedsToUse: 'select'
Dans la version 2.0 du SDK .NET Core et les versions ultérieures, les paquets sont restaurés automatiquement lors de l’exécution de commandes telles que dotnet build
. Cependant, vous devrez toujours utiliser la tâche .NET Core pour restaurer les paquets si vous utilisez un flux authentifié.
Vos builds peuvent échouer en raison de problèmes de connexion lors de la restauration des paquets depuis NuGet.org. Vous pouvez utiliser Azure Artifacts avec des sources en amont pour mettre en cache les paquets. Les informations d’identification du pipeline sont utilisées automatiquement lorsqu’il se connecte à Azure Artifacts. Ces informations d’identification sont généralement dérivées du compte de service de build de collection de projets. Pour en savoir plus sur l’utilisation d’Azure Artifacts pour mettre en cache vos paquets NuGet, veuillez consulter la section Connect to Azure Artifact feeds.
Pour spécifier un référentiel NuGet, placez l’URL dans un fichier NuGet.config
dans votre référentiel. Si votre flux est authentifié, gérez ses informations d’identification en créant une connexion de service NuGet sous l’onglet Services sous Paramètres du projet.
Lorsque vous utilisez des agents hébergés par Microsoft, vous obtenez une nouvelle machine à chaque fois que vous exécutez une build, ce qui restaure les paquets à chaque exécution. La restauration peut prendre beaucoup de temps. Pour atténuer les problèmes, vous pouvez utiliser Azure Artifacts ou un agent auto-hébergé avec l’avantage d’utiliser le cache de package.
Pour plus d’informations sur les connexions au service NuGet, consultez Publier dans les flux NuGet.
Restaurez les paquets depuis un flux externe
Procédez comme suit pour restaurer des packages à partir d’un flux externe.
Vous pouvez ajouter la commande de restauration à votre pipeline en utilisant l’éditeur de pipeline YAML en insérant directement l’extrait de code suivant dans votre fichier azure-pipelines.yml
ou en utilisant l’assistant de tâche pour ajouter la tâche .NET Core.
# do this before your build tasks
steps:
- task: DotNetCoreCLI@2
displayName: Restore
inputs:
command: restore
projects: '**/*.csproj'
feedsToUse: config
nugetConfigPath: NuGet.config # Relative to root of the repository
externalFeedCredentials: <Name of the NuGet service connection>
Remplacez <l’espace réservé> par le nom de votre connexion de service.
Pour utiliser l’assistant de tâche :
Pour ajouter une tâche de build en utilisant l’assistant de tâche, suivez les étapes suivantes :
Allez à la position dans le fichier YAML où vous souhaitez insérer la tâche.
Sélectionnez .NET Core dans le catalogue de tâches.
Sélectionnez la commande restore dans la liste déroulante Commande.
Dans le champ Chemin d’accès au(x) projet(s), entrez le chemin d’accès vers vos fichiers
.csproj
.Sélectionnez Ajouter.
Sélectionnez Sauvegarder pour valider le changement.
Remarque
Vérifiez que le flux personnalisé est spécifié dans votre fichier NuGet.config
et que les informations d’identification sont spécifiées dans la connexion au service NuGet.
Générer votre projet
Construisez vos projets .NET Core en exécutant la commande dotnet build
. Vous pouvez ajouter la commande à votre pipeline en tant que script de ligne de commande ou en utilisant la tâche .NET Core.
Build .NET Core en utilisant la tâche .NET Core
Exemple YAML pour construire en utilisant la tâche DotNetCoreCLI@2 :
steps:
- task: DotNetCoreCLI@2
displayName: Build
inputs:
command: build
projects: '**/*.csproj'
arguments: '--configuration $(buildConfiguration)' # Update this to match your needs
Vous pouvez ajouter une tâche de build en utilisant l’éditeur de pipeline YAML en éditant directement le fichier ou en ajoutant la tâche .NET Core en utilisant l’assistant de tâche.
Pour ajouter une tâche de build en utilisant l’assistant de tâche, suivez les étapes suivantes :
Allez à la position dans le fichier YAML où vous souhaitez insérer la tâche.
Sélectionnez .NET Core dans le catalogue de tâches.
Sélectionnez la commande build dans la liste déroulante Command.
Dans le champ Chemin d’accès au(x) projet(s), entrez le chemin d’accès vers vos fichiers
.csproj
.Sélectionnez Ajouter.
Sélectionnez Sauvegarder pour valider le changement.
Build .NET Core en utilisant un script de ligne de commande
Exemple YAML pour construire en utilisant le script dotnet build
:
steps:
- script: dotnet build --configuration $(buildConfiguration)
displayName: 'dotnet build $(buildConfiguration)'
Vous pouvez ajouter une tâche de build en utilisant l’éditeur de pipeline YAML en éditant directement le fichier ou en ajoutant la tâche Ligne de Commande.
Utilisez les étapes suivantes pour ajouter la tâche Ligne de Commande :
Allez à la position dans le fichier YAML où vous souhaitez insérer la tâche.
Sélectionnez la Ligne de Commande dans le catalogue de tâches.
Ajoutez éventuellement un Nom d’Affichage.
Saisissez la commande
dotnet build
avec des paramètres. Par exemple :dotnet build --configuration $(buildConfiguration)
.Saisissez le chemin d’accès vers le fichier
.csproj
en tant que répertoire de travail.Sélectionnez Ajouter.
Sélectionnez Sauvegarder pour valider le changement.
Ajoutez des commandes SDK .NET à votre pipeline
Vous pouvez ajouter des commandes SDK .NET à votre projet en script ou en utilisant la tâche .NET Core. La tâche .NET Core (DotNetCoreCLI@2) vous permet d’ajouter facilement des commandes CLI dotnet à votre pipeline. Vous pouvez ajouter des tâches .NET Core en modifiant votre fichier YAML ou en utilisant l’éditeur classique.
Ajouter une commande CLI .NET en utilisant la tâche .NET Core
Pour ajouter une commande CLI .NET Core en utilisant l’éditeur de pipeline YAML, suivez les étapes suivantes :
Allez à la position dans le fichier YAML où vous souhaitez insérer la tâche.
Sélectionnez .NET Core dans le catalogue de tâches.
Sélectionnez la commande que vous souhaitez exécuter.
Configurez toutes les options nécessaires.
Sélectionnez Ajouter.
Sélectionnez Sauvegarder pour valider le changement.
Ajouter une commande CLI .NET Core en utilisant un script
Vous pouvez ajouter des commandes CLI .NET Core en tant que script
dans votre fichier azure-pipelines.yml
.
Exemple :
steps:
# ...
- script: dotnet test <test-project>
Installer un outil
Pour installer un outil global .NET Core comme dotnetsay dans votre build s’exécutant sur Windows, procédez comme suit :
- Ajoutez la tâche .NET Core et définissez les propriétés suivantes :
- Commande : personnalisée.
- Chemin d’accès aux projets : laissez vide.
- Commande personnalisée : outil.
- Arguments :
install -g dotnetsay
.
- Commande : personnalisée.
- Pour exécuter l’outil, ajoutez une Ligne de commande et définissez les propriétés suivantes :
- Script :
dotnetsay
.
- Script :
Exécutez vos tests.
Lorsque vous avez des projets de test dans votre dépôt, vous pouvez utiliser la tâche .NET Core pour exécuter des tests unitaires en utilisant des cadres de test comme MSTest, xUnit et NUnit. Le projet de test doit référencer Microsoft.NET.Test.SDK version 15.8.0 ou ultérieure. Les résultats des tests sont automatiquement publiés sur le service. Ces résultats sont disponibles dans le résumé de la build et peuvent être utilisés pour résoudre les échecs de tests et l’analyse du minutage des tests.
Vous pouvez ajouter une tâche de test à votre pipeline en utilisant la tâche DotNetCoreCLI@2 ou ajouter l’extrait de code suivant à votre fichier azure-pipelines.yml
:
steps:
# ...
# do this after other tasks such as building
- task: DotNetCoreCLI@2
inputs:
command: test
projects: '**/*Tests/*.csproj'
arguments: '--configuration $(buildConfiguration)'
Lors de l’utilisation de l’éditeur de tâches .NET Core, paramétrez Commande sur test et Chemin d’accès vers les projets doit se référer aux projets de test dans votre solution.
Alternativement, vous pouvez exécuter la commande dotnet test
avec un journal spécifique, puis utiliser la tâche Publier les résultats des tests :
steps:
# ...
# do this after your tests have run
- script: dotnet test <test-project> --logger trx
- task: PublishTestResults@2
condition: succeededOrFailed()
inputs:
testRunner: VSTest
testResultsFiles: '**/*.trx'
Collecter la couverture du code
Lorsque vous construisez sur la plate-forme Windows, les métriques de couverture de code peuvent être collectées en utilisant le collecteur de données de couverture intégré. Le projet de test doit référencer Microsoft.NET.Test.SDK version 15.8.0 ou ultérieure.
Lorsque vous utilisez la tâche .NET Core pour exécuter des tests, les données de couverture sont automatiquement publiées sur le serveur. Le fichier .coverage
peut être téléchargé à partir du résumé de la construction pour visualisation dans Visual Studio.
Ajoutez l’extrait de code suivant à votre fichier azure-pipelines.yml
:
steps:
# ...
# do this after other tasks such as building
- task: DotNetCoreCLI@2
inputs:
command: test
projects: '**/*Tests/*.csproj'
arguments: '--configuration $(buildConfiguration) --collect "Code coverage"'
Pour ajouter la tâche .NET Core via l’éditeur de tâches :
Ajoutez la tâche .NET Core à votre travail de build et définissez les propriétés suivantes :
- Commande : test.
- Chemin d’accès aux projets : doit faire référence aux projets de test dans votre solution.
- Arguments :
--configuration $(BuildConfiguration) --collect "Code coverage"
.
Vérifiez que l’option Publier les résultats des tests reste sélectionnée.
Si vous choisissez d’exécuter la commande dotnet test
, spécifiez l’enregistreur des résultats des tests et les options de couverture. Ensuite, utilisez la tâche Publier les résultats des tests :
steps:
# ...
# do this after your tests have run
- script: dotnet test <test-project> --logger trx --collect "Code coverage"
- task: PublishTestResults@2
inputs:
testRunner: VSTest
testResultsFiles: '**/*.trx'
Collecter des métriques de couverture du code avec Coverlet
Si vous générez sur Linux ou macOS, vous pouvez utiliser Coverlet ou un outil similaire pour collecter des métriques de couverture du code.
Vous pouvez publier les résultats de la couverture de code sur le serveur avec la tâche Publier les résultats de la couverture de code (PublishCodeCoverageResults@1). L’outil de couverture doit être configuré pour générer des résultats dans le format de couverture Cobertura ou JaCoCo.
Pour exécuter des tests et publier la couverture du code avec Coverlet, effectuez les tâches suivantes :
Ajoutez une référence au package NuGet
coverlet.collector
.Ajoutez l’extrait de code suivant à votre fichier
azure-pipelines.yml
:- task: UseDotNet@2 inputs: version: '8.x' includePreviewVersions: true # Required for preview versions - task: DotNetCoreCLI@2 displayName: 'dotnet build' inputs: command: 'build' configuration: $(buildConfiguration) - task: DotNetCoreCLI@2 displayName: 'dotnet test' inputs: command: 'test' arguments: '--configuration $(buildConfiguration) --collect:"XPlat Code Coverage" -- DataCollectionRunSettings.DataCollectors.DataCollector.Configuration.Format=cobertura' publishTestResults: true projects: 'MyTestLibrary' # update with your test project directory - task: PublishCodeCoverageResults@1 displayName: 'Publish code coverage report' inputs: codeCoverageTool: 'Cobertura' summaryFileLocation: '$(Agent.TempDirectory)/**/coverage.cobertura.xml'
Empaqueter et remettre votre code
Vous pouvez publier vos artefacts de build en :
- Publiant sur Azure Pipelines.
- Publiant des paquets sur Azure Artifacts.
- Créant un paquet NuGet et le publiant sur votre flux NuGet.
- Création d’une archive .zip pour déployer votre application web.
Publier des artefacts sur Azure Pipelines
Pour publier la sortie de votre build .NET build dans votre pipeline, effectuez les tâches suivantes :
- Exécutez
dotnet publish --output $(Build.ArtifactStagingDirectory)
sur le CLI .NET ou ajoutez la tâche DotNetCoreCLI@2 avec la commande de publication. - Publiez l’artefact en utilisant la tâche Publier des artefacts de pipeline.
Ajoutez l’extrait de code suivant à votre fichier azure-pipelines.yml
:
steps:
- task: DotNetCoreCLI@2
inputs:
command: publish
publishWebProjects: True
arguments: '--configuration $(BuildConfiguration) --output $(Build.ArtifactStagingDirectory)'
zipAfterPublish: True
# this code takes all the files in $(Build.ArtifactStagingDirectory) and uploads them as an artifact of your build.
- task: PublishPipelineArtifact@1
inputs:
targetPath: '$(Build.ArtifactStagingDirectory)'
artifactName: 'myWebsite'
Remarque
La tâche DotNetCoreCLI@2 a une entrée publishWebProjects
qui est réglée par défaut sur true. Cette tâche publie tous les projets web dans votre dépôt par défaut. Vous trouverez plus d’aide et d’informations dans la tâche open source sur GitHub.
Pour copier plus de fichiers vers le répertoire de build avant la publication, utilisez la tâche Copier des fichiers (CopyFile@2).
Pour publier la sortie de votre build .NET build dans votre pipeline, effectuez les tâches suivantes :
- Exécutez
dotnet publish --output $(Build.ArtifactStagingDirectory)
sur CLI ou ajoutez la tâche DotNetCoreCLI@2 avec la commande de publication. - Publiez l’artefact en utilisant la tâche Publier l’artefact de build (PublishBuildArtifacts@1).
Ajoutez l’extrait de code suivant à votre fichier azure-pipelines.yml
pour publier vos artefacts de build sous forme de fichier .zip :
steps:
- task: DotNetCoreCLI@2
inputs:
command: publish
publishWebProjects: True
arguments: '--configuration $(BuildConfiguration) --output $(Build.ArtifactStagingDirectory)'
zipAfterPublish: True
# this code takes all the files in $(Build.ArtifactStagingDirectory) and uploads them as an artifact of your build.
- task: PublishBuildArtifacts@1
inputs:
PathtoPublish: '$(Build.ArtifactStagingDirectory)'
ArtifactName: 'drop'
Pour plus d’informations, veuillez consulter la section Publier et télécharger des artefacts de build.
Publier sur un flux NuGet
Pour créer un package NuGet et le publier sur votre flux NuGet, ajoutez l’extrait de code suivant :
steps:
# ...
# do this near the end of your pipeline in most cases
- script: dotnet pack /p:PackageVersion=$(version) # define version variable elsewhere in your pipeline
- task: NuGetAuthenticate@1
inputs:
nuGetServiceConnections: '<Name of the NuGet service connection>'
- task: NuGetCommand@2
inputs:
command: push
nuGetFeedType: external
publishFeedCredentials: '<Name of the NuGet service connection>'
versioningScheme: byEnvVar
versionEnvVar: version
Remarque
La tâche NuGetAuthenticate@1 ne prend pas en charge l’authentification par clé API NuGet. Si vous utilisez une clé API NuGet, utilisez la tâche NuGetCommand@2 avec l’entrée command
réglée sur push
avec l’argument --api-key. Par exemple : dotnet nuget push --api-key $(NuGetApiKey)
.
Pour plus d’informations sur le contrôle de version et la publication de packages NuGet, consultez Publier dans les flux NuGet.
Publiez un package NuGet sur Azure Artifacts
Vous pouvez publier vos packages NuGet sur votre flux Azure Artifacts en utilisant NuGetCommand@2 pour pousser vers votre flux Azure Artifact. Par exemple, consultez la section Publier des packages NuGet avec Azure Pipelines.
Déployer une application web
Pour créer une archive de fichier .zip prête à être publiée sur une application web, ajoutez l’extrait de code suivant :
steps:
# ...
# do this after you've built your app, near the end of your pipeline in most cases
# for example, you do this before you deploy to an Azure web app on Windows
- task: DotNetCoreCLI@2
inputs:
command: publish
publishWebProjects: True
arguments: '--configuration $(BuildConfiguration) --output $(Build.ArtifactStagingDirectory)'
zipAfterPublish: True
Pour publier cette archive dans une application web, consultez Déploiement d’applications web Azure.
Générer et envoyer une image au registre de conteneurs
Vous pouvez également construire une image pour votre application et la pousser vers un registre de conteneurs.
Publiez des symboles
Vous pouvez utiliser la tâche PublishSymbols@2 pour publier des symboles sur un serveur de symboles Azure Artifacts ou un partage de fichiers.
Par exemple, pour publier des symboles dans un partage de fichiers, ajoutez le morceau de code suivant à votre fichier azure-pipelines.yml
:
- task: PublishSymbols@2
inputs:
SymbolsFolder: '$(Build.SourcesDirectory)'
SearchPattern: '**/bin/**/*.pdb'
IndexSources: true
PublishSymbols: true
SymbolServerType: 'FileShare'
SymbolsPath: '\\server\shareName'
Lorsque vous utilisez l’éditeur classique, sélectionnez les sources d’index publient des symboles à partir du catalogue de tâches à ajouter à votre pipeline.
Pour plus d’informations, veuillez consulter la section Publier des symboles.
Résolution des problèmes
Si vous pouvez créer votre projet sur votre machine de développement, mais que vous rencontrez des difficultés pour le créer sur Azure Pipelines, explorez les causes potentielles et les actions correctives suivantes :
- Les versions préliminaires du SDK .NET Core ne sont pas installées sur les agents hébergés par Microsoft. Après la sortie d’une nouvelle version du SDK .NET Core, cela peut prendre quelques semaines pour être déployé dans tous les centres de données Azure Pipelines. Vous n’avez pas besoin d’attendre la fin de ce déploiement. Vous pouvez utiliser la tâche Utiliser .NET Core pour installer la version du SDK .NET Core que vous souhaitez sur les agents hébergés par Microsoft.
Vérifiez les versions et le runtime du SDK .NET Core sur votre ordinateur de développement et assurez-vous qu’ils correspondent à l’agent. Vous pouvez inclure un script de ligne de commande
dotnet --version
dans votre pipeline pour imprimer la version du SDK .NET Core. Utilisez le programme d’installation de l’outil .NET Core pour déployer la même version sur l’agent, ou mettez à jour vos projets et votre ordinateur de développement vers la version la plus récente du SDK .NET Core.Vous utilisez peut-être une logique dans l’IDE Visual Studio qui n’est pas encodée dans votre pipeline. Azure Pipelines exécute chacune des commandes que vous spécifiez dans les tâches l’une après l’autre dans un nouveau processus. Examinez les journaux de la build des pipelines pour voir les commandes exactes exécutées dans le cadre de la build. Répétez les mêmes commandes dans le même ordre sur votre ordinateur de développement pour localiser le problème.
Si vous disposez d’une solution mixte qui inclut certains projets .NET Core et certains projets .NET Framework, vous devez également utiliser la tâche NuGet pour restaurer les packages spécifiés dans les fichiers
packages.config
. Ajoutez la tâche MSBuild ou Visual Studio Build pour générer les projets .NET Framework.Vos builds peuvent échouer de manière intermittente lors de la restauration des packages : soit NuGet.org a des problèmes, soit il y a des problèmes de réseau entre le centre de données Azure et NuGet.org. Vous pouvez explorer si l’utilisation d’Azure Artifacts avec NuGet.org comme source en amont améliore la fiabilité de vos builds, car cela n’est pas sous notre contrôle.
Occasionnellement, lorsqu’une nouvelle version du SDK .NET Core ou de Visual Studio est déployée, votre build pourrait échouer. Par exemple, une version ou une fonctionnalité plus récente de l’outil NuGet livrée avec le SDK pourrait casser votre build. Pour isoler ce problème, utilisez la tâche du programme d’installation de l’outil .NET Core pour spécifier la version du kit SDK .NET Core utilisée dans votre build.
Forum aux questions
Q : Où puis-je en savoir plus sur Azure Artifacts ?
R : Gestion des packages dans Azure Artifacts
Q : où puis-je en savoir plus sur les commandes .NET Core ?
Q : Où puis-je en savoir plus sur l’exécution de tests dans ma solution ?
R : Tests unitaires dans les projets .NET Core