Partager via

Générer, tester et déployer des applications .NET Core

  • Article

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 :

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

  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

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.

  1. Dans un navigateur, rendez-vous sur dev.azure.com et connectez-vous.
  2. Sélectionnez votre organisation.
  3. Créez un nouveau projet en sélectionnant Nouveau projet ou Créer un projet si c’est le premier projet dans l’organisation.
  4. Entrez un Nom de projet.
  5. Choisissez la Visibilité de votre projet.
  6. Sélectionnez Créer.
  1. Dans un navigateur, rendez-vous sur votre serveur Azure DevOps.
  2. Sélectionnez votre collection.
  3. Créez un nouveau projet en sélectionnant Nouveau projet ou Créer un projet si c’est le premier projet dans la collection.
  4. Entrez un Nom de projet.
  5. Choisissez la Visibilité de votre projet.
  6. Sélectionnez Créer.
  1. Dans une fenêtre de navigateur, connectez-vous à votre serveur Azure DevOps et sélectionnez votre collection.
  2. Sélectionnez Nouveau projet.
  3. Entrer un nom de projet.
  4. Si vous le souhaitez, entrez une description.
  5. 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

  1. Connectez-vous à votre organisation Azure DevOps et accédez à votre projet.

  2. Accédez à Pipelines, puis sélectionnez Nouveau pipeline ou Création d’un pipeline si vous créez votre premier pipeline.

  3. Effectuez les étapes de l’Assistant en sélectionnant d’abord GitHub comme emplacement du code source.

  4. Vous serez peut-être redirigé vers GitHub pour vous connecter. Si c’est le cas, entrez vos informations d’identification GitHub.

  5. Quand la liste des dépôts s’affiche, sélectionnez le vôtre.

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

  1. Quand l’onglet Configurer apparaît, sélectionnez Afficher plus et choisissez le modèle de pipeline ASP.NET Core dans la liste.

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

  1. Lorsque vous êtes prêt, sélectionnez Enregistrer et exécuter.

    Bouton Enregistrer et exécuter dans un nouveau pipeline YAML

  2. Facultativement, vous pouvez modifier le message de validation.

  3. Validez le nouveau fichier azure-pipelines.yml dans votre référentiel en sélectionnant Sauvegarder et exécuter.

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

  1. Allez dans votre projet et sélectionnez Pipelines.
  2. Sélectionnez Créer un pipeline ou Nouveau pipeline si vous créez le premier pipeline pour ce projet.
Sélectionnez votre source

  1. Sélectionnez votre référentiel source. Pour cet exemple, utilisez GitHub Enterprise Server.

    1. Saisissez l’URL de votre compte GitHub. Par exemple : https://github.com/<username>.
    2. Saisissez votre jeton d’accès personnel pour votre compte GitHub.
    3. Saisissez un nom de connexion de service. Par exemple : my-github.
    4. Sélectionnez Créer.

  2. Sélectionnez votre référentiel GitHub.

Configurer votre pipeline

  1. Sur l’onglet Configurer, sélectionnez Afficher plus et choisissez le modèle de pipeline ASP.NET Core dans la liste.

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

  1. Cliquez sur Enregistrer.

    Capture d’écran montrant le bouton Enregistrer et exécuter dans un nouveau pipeline YAML.

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

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

  1. Sélectionnez Enregistrer et exécuter.

    Capture d’écran montrant le bouton Enregistrer et exécuter dans un nouveau pipeline YAML.

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

  1. Allez à la position dans le fichier YAML où vous souhaitez insérer la tâche.

  2. Sélectionnez .NET Core dans le catalogue de tâches.

  3. Sélectionnez la commande restore dans la liste déroulante Commande.

  4. Dans le champ Chemin d’accès au(x) projet(s), entrez le chemin d’accès vers vos fichiers .csproj.

  5. Sélectionnez Ajouter.

  6. 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 :

  1. Allez à la position dans le fichier YAML où vous souhaitez insérer la tâche.

  2. Sélectionnez .NET Core dans le catalogue de tâches.

  3. Sélectionnez la commande build dans la liste déroulante Command.

  4. Dans le champ Chemin d’accès au(x) projet(s), entrez le chemin d’accès vers vos fichiers .csproj.

  5. Sélectionnez Ajouter.

  6. 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 :

  1. Allez à la position dans le fichier YAML où vous souhaitez insérer la tâche.

  2. Sélectionnez la Ligne de Commande dans le catalogue de tâches.

  3. Ajoutez éventuellement un Nom d’Affichage.

  4. Saisissez la commande dotnet build avec des paramètres. Par exemple : dotnet build --configuration $(buildConfiguration).

  5. Saisissez le chemin d’accès vers le fichier .csproj en tant que répertoire de travail.

  6. Sélectionnez Ajouter.

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

  1. Allez à la position dans le fichier YAML où vous souhaitez insérer la tâche.

  2. Sélectionnez .NET Core dans le catalogue de tâches.

  3. Sélectionnez la commande que vous souhaitez exécuter.

  4. Configurez toutes les options nécessaires.

  5. Sélectionnez Ajouter.

  6. 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 :

  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

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 :

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.

Questions fréquentes (FAQ)

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