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 :

Prérequis

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 .

1. Ouvrez une fenêtre de terminal.

2. Créer un répertoire de projet et y accéder.

3. Créez une nouvelle application web .NET 8.

   dotnet new webapp -f net8.0
   

4. À 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
   

5. 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

1. À 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.

2. Connectez votre référentiel Git local à un référentiel GitHub.

Créer un projet DevOps

Configurez votre environnement de build

steps:
- task: UseDotNet@2
  inputs:
    version: '8.x'

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.

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

pool:
  name: myPrivateAgents
  demands:
  - agent.os -equals Darwin
  - anotherCapability -equals somethingElse

steps:
- task: UseDotNet@2
  displayName: 'Install .NET Core SDK'
  inputs:
    version: 8.x
    performMultiLevelLookup: true
    includePreviewVersions: true # Required for preview versions

pool:
  vmImage: 'ubuntu-latest' 

steps:
- task: UseDotNet@2
  inputs:
    version: '5.x'

steps:
- task: UseDotNet@2
  displayName: 'Install .NET Core SDK'
  inputs:
    version: 8.x
    performMultiLevelLookup: true
    includePreviewVersions: true # Required for preview versions

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.

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.

# 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>

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

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)'

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

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 :

1. 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.
2. Pour exécuter l’outil, ajoutez une Ligne de commande et définissez les propriétés suivantes :
   • Script : dotnetsay.

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 :

1. Ajoutez la tâche .NET Core à votre travail de build et définissez les propriétés suivantes :

   1. Commande : test.
   2. Chemin d’accès aux projets : doit faire référence aux projets de test dans votre solution.
   3. Arguments : --configuration $(BuildConfiguration) --collect "Code coverage".

2. 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

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'

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'

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

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 :

• 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 ?

R : Outils CLI .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

Q : Où puis-je en savoir plus sur les tâches ?

R : Tâches de build et de mise en production