Utiliser le SDK .NET dans les environnements d’intégration continue (CI)
Cet article explique comment utiliser le kit SDK .NET et ses outils sur un serveur de builds. L’ensemble d’outils .NET fonctionne à la fois de manière interactive, où un développeur tape des commandes à une invite de commandes, et de manière automatique, où un serveur d’intégration continue (CI) exécute un script de build. Les commandes, les options, les entrées et les sorties sont identiques, et les seuls éléments que vous fournissez sont un moyen d’acquérir les outils et un système pour générer votre application. Cet article se concentre sur les scénarios d’acquisition d’outils pour l’intégration continue (CI). Il contient des recommandations sur la façon de concevoir et de structurer vos scripts de build.
Options d’installation pour les serveurs de builds avec intégration continue
Si vous utilisez GitHub, l’installation est simple. Vous pouvez vous appuyer sur GitHub Actions pour installer le kit SDK .NET dans votre workflow. La méthode recommandée pour installer le kit SDK .NET dans un workflow consiste à utiliser l’action actions/setup-net-core-sdk. Pour plus d’informations, consultez l’action Configurer le kit SDK .NET Core sur la Place de marché GitHub. Pour obtenir des exemples d’utilisation, consultez Démarrage rapide : Créer un workflow GitHub de validation de build.
Programmes d’installation natifs
Les programmes d’installation natifs sont disponibles pour macOS, Linux et Windows. Les programmes d’installation requièrent un accès administrateur (sudo) au serveur de builds. L’avantage d’utiliser un programme d’installation natif est qu’il installe toutes les dépendances natives requises pour l’exécution des outils. Les programmes d’installation natifs fournissent également une installation du kit SDK à l’échelle du système.
Les utilisateurs de macOS doivent utiliser les programmes d’installation PKG. Sous Linux, vous pouvez utiliser un gestionnaire de package basé sur les flux, tel que apt-get pour Ubuntu, yum pour CentOS Stream, ou utiliser directement les packages DEB ou RPM. Sous Windows, utilisez le programme d’installation MSI.
Les fichiers binaires stables les plus récents se trouvent sous Téléchargements .NET. Si vous souhaitez utiliser les derniers outils en préversion (potentiellement instables), utilisez les liens fournis dans le dépôt GitHub dotnet/installer. Pour les distributions Linux, des archives tar.gz (également appelées tarballs) sont disponibles. Utilisez les scripts d’installation contenus dans les archives pour installer .NET.
Script de programme d’installation
L’utilisation du script d’installation permet une installation non administrative sur votre serveur de builds, ainsi qu’une automatisation facile pour obtenir les outils. Le script se charge de télécharger les outils et de les extraire dans un emplacement par défaut ou spécifié. Vous pouvez également spécifier la version des outils que vous souhaitez installer et si vous voulez installer le kit SDK complet ou uniquement le runtime partagé.
Le script d’installation est automatisé pour s’exécuter au début de la génération afin de récupérer et d’installer la version nécessaire du kit SDK. La version souhaitée est la version du kit SDK dont vos projets ont besoin pour être générés. Le script vous permet d’installer le kit SDK dans un répertoire local sur le serveur, d’exécuter les outils à partir de l’emplacement d’installation, puis de nettoyer (ou de laisser le service d’intégration continue nettoyer) une fois la génération terminée. Cela fournit à l’ensemble de votre processus de génération l’encapsulation et l’isolation requises. La documentation de référence sur le script d’installation est disponible dans l’article dotnet-install.
Notes
Azure DevOps Services
Lorsque vous utilisez le script d’installation, les dépendances natives ne sont pas installées automatiquement. Vous devez installer les dépendances natives si le système d’exploitation ne les possède pas. Pour plus d’informations, consultez Installer .NET sur Windows, Linux et macOS.
Exemples de configuration de l’intégration continue
Cette section décrit une configuration manuelle à l’aide d’un script PowerShell ou bash. Elle décrit également des solutions CI SaaS (software as a service). Les solutions d’intégration continue SaaS traitées sont CI Travis, AppVeyor et Azure Pipelines. Pour GitHub Actions, consultez GitHub Actions et .NET
Configuration manuelle
Chaque service SaaS dispose de ses propres méthodes pour la création et la configuration d’un processus de génération. Si vous utilisez une autre solution SaaS que celles qui sont listées, ou si vous avez besoin d’une personnalisation qui va au-delà de la prise en charge prédéfinie, vous devez effectuer au moins une configuration manuelle.
En règle générale, une configuration manuelle vous oblige à acquérir une version des outils (ou les versions les plus récentes des outils générées de nuit) et à exécuter votre script de build. Vous pouvez utiliser un script PowerShell ou bash pour orchestrer les commandes .NET ou vous pouvez utiliser un fichier projet qui décrit le processus de génération. La section sur l’orchestration fournit plus de détails sur ces options.
Après avoir créé un script qui exécute une configuration manuelle du serveur de builds CI, utilisez-le sur votre machine de développement afin de générer votre code localement à des fins de test. Après avoir confirmé que le script s’exécute correctement localement, déployez-le sur votre serveur de builds CI. Un script PowerShell relativement simple illustre comment obtenir le kit SDK .NET et l’installer sur un serveur de builds Windows :
Vous fournissez l’implémentation pour votre processus de génération à la fin du script. Le script acquiert les outils, puis exécute votre processus de génération.
$ErrorActionPreference="Stop"
$ProgressPreference="SilentlyContinue"
# $LocalDotnet is the path to the locally-installed SDK to ensure the
# correct version of the tools are executed.
$LocalDotnet=""
# $InstallDir and $CliVersion variables can come from options to the
# script.
$InstallDir = "./cli-tools"
$CliVersion = "6.0.7"
# Test the path provided by $InstallDir to confirm it exists. If it
# does, it's removed. This is not strictly required, but it's a
# good way to reset the environment.
if (Test-Path $InstallDir)
{
rm -Recurse $InstallDir
}
New-Item -Type "directory" -Path $InstallDir
Write-Host "Downloading the CLI installer..."
# Use the Invoke-WebRequest PowerShell cmdlet to obtain the
# installation script and save it into the installation directory.
Invoke-WebRequest `
-Uri "https://dot.net/v1/dotnet-install.ps1" `
-OutFile "$InstallDir/dotnet-install.ps1"
Write-Host "Installing the CLI requested version ($CliVersion) ..."
# Install the SDK of the version specified in $CliVersion into the
# specified location ($InstallDir).
& $InstallDir/dotnet-install.ps1 -Version $CliVersion `
-InstallDir $InstallDir
Write-Host "Downloading and installation of the SDK is complete."
# $LocalDotnet holds the path to dotnet.exe for future use by the
# script.
$LocalDotnet = "$InstallDir/dotnet"
# Run the build process now. Implement your build script here.
Travis CI
Vous pouvez configurer CI Travis pour installer le SDK .NET à l’aide du langage csharp et de la clé dotnet. Pour plus d’informations, consultez les documents officiels sur CI Travis sous Building a C#, F#, or Visual Basic Project (Générer un projet C#, F# ou Visual Basic). Remarque : lorsque vous accédez aux informations sur CI Travis, l’identificateur de langage language: csharp entretenu par la communauté fonctionne pour tous les langages .NET, notamment F# et Mono.
Travis CI exécute les travaux macOS et Linux dans une matrice de build, où vous spécifiez une combinaison de runtime, d’environnement et d’exclusions/inclusions pour couvrir les combinaisons de build de votre application. Pour plus d’informations, consultez l’article Personnalisation de la build dans la documentation CI Travis. Les outils MSBuild incluent les runtimes LTS et STS dans le package. Ainsi, en installant le kit SDK, vous disposez de tout ce dont vous avez besoin pour effectuer des builds.
AppVeyor
AppVeyor installe le kit SDK .NET 6 avec l’image de travail de build Visual Studio 2022. D’autres images de build avec différentes versions du SDK .NET sont disponibles. Pour plus d’informations, consultez l’article Build worker images dans la documentation AppVeyor.
Les fichiers binaires du kit SDK .NET sont téléchargés et décompressés dans un sous-répertoire à l’aide du script d’installation, puis ils sont ajoutés à la variable d’environnement PATH. Ajoutez une matrice de builds pour exécuter des tests d’intégration avec plusieurs versions du SDK .NET :
environment:
matrix:
- CLI_VERSION: 6.0.7
- CLI_VERSION: Latest
Azure DevOps Services
Configurez Azure DevOps Services pour générer des projets .NET à l’aide de l’une des approches suivantes :
- Exécutez le script à partir de l’étape de configuration manuelle en utilisant vos commandes.
- Créez une build composée de plusieurs tâches de build intégrées Azure DevOps Services qui sont configurées pour utiliser les outils .NET.
Les deux solutions sont valides. À l’aide d’un script de configuration manuelle, vous contrôlez la version des outils que vous recevez, car vous les téléchargez dans le cadre de la génération. La build est exécutée à partir d’un script que vous devez créer. Cet article couvre uniquement l’option manuelle. Pour plus d’informations sur la composition d’une build avec les tâches de génération Azure DevOps Services, consultez la documentation Azure Pipelines.
Pour utiliser un script de configuration manuelle dans Azure DevOps Services, créez une nouvelle définition de build et spécifiez le script à exécuter pour l’étape de génération. Cette opération est possible grâce à l’interface utilisateur Azure DevOps Services :
Commencez par créer une nouvelle définition de build. Lorsque vous atteignez l’écran qui vous permet de définir le type de build que vous souhaitez créer, sélectionnez l’option Empty (Vide).
Après avoir configuré le référentiel à générer, vous êtes dirigé vers les définitions de la build. Sélectionnez Ajouter une étape de build :
Le catalogue de tâches s’affiche. Le catalogue contient les tâches que vous utilisez dans la build. Étant donné que vous avez un script, sélectionnez le bouton Ajouter pour PowerShell : exécuter un script PowerShell.
Configurez l’étape de build. Ajoutez le script à partir du référentiel que vous générez :
Orchestration de la build
La majeure partie de ce document explique comment acquérir les outils .NET et configurer divers services CI, sans fournir d’informations sur la façon d’orchestrer, ou de générer réellement, votre code avec .NET. Les choix sur la façon de structurer le processus de génération dépendent de nombreux facteurs qui ne peuvent pas être traités ici d’une manière générale. Pour plus d’informations sur l’orchestration de vos builds avec chaque technologie, explorez les ressources et les exemples fournis dans la documentation de CI Travis, AppVeyor et Azure Pipelines.
L’utilisation directe de MSBuild ou l’utilisation des commandes de ligne de commande .NET constituent les deux méthodes générales que vous utilisez afin de structurer le processus de génération pour le code .NET à l’aide des outils .NET. La méthode que vous choisissez dépend de votre niveau d’assurance et des compromis en matière de complexité. MSBuild vous permet d’exprimer votre processus de génération sous la forme de tâches et de cibles, mais vous devez vous familiariser avec la syntaxe de fichier projet MSBuild complexe. L’utilisation des outils de ligne de commande .NET est peut-être plus simple, mais vous devez écrire une logique d’orchestration dans un langage de script comme bash ou PowerShell.
Conseil
Vous devez affecter à la propriété MSBuild true la valeur ContinuousIntegrationBuild. Cette propriété active les paramètres qui s’appliquent uniquement aux builds officielles, par opposition aux builds de développement local.
