De .NET SDK gebruiken in CI-omgevingen (continue integratie)
In dit artikel wordt beschreven hoe u de .NET SDK en de bijbehorende hulpprogramma's op een buildserver gebruikt. De .NET-toolset werkt zowel interactief, waarbij een ontwikkelaar opdrachten typt bij een opdrachtprompt en automatisch, waarbij een CI-server (continue integratie) een buildscript uitvoert. De opdrachten, opties, invoer en uitvoer zijn hetzelfde en de enige dingen die u opgeeft, zijn een manier om de hulpprogramma's en een systeem te verkrijgen om uw app te bouwen. Dit artikel is gericht op scenario's voor het verkrijgen van hulpprogramma's voor CI met aanbevelingen voor het ontwerpen en structuren van uw buildscripts.
Installatieopties voor CI-buildservers
Als u GitHub gebruikt, is de installatie eenvoudig. U kunt vertrouwen op GitHub Actions om de .NET SDK in uw werkstroom te installeren. De aanbevolen manier om de .NET SDK in een werkstroom te installeren, is met de actions/setup-net-core-sdk actie. Zie de actie .NET Core SDK instellen in de GitHub Marketplace voor meer informatie. Zie Quickstart: Een GitHub-werkstroom voor buildvalidatie maken voor voorbeelden van hoe dit werkt.
Systeemeigen installatieprogramma's
Systeemeigen installatieprogramma's zijn beschikbaar voor macOS, Linux en Windows. Voor de installatieprogramma's is beheerderstoegang (sudo) tot de buildserver vereist. Het voordeel van het gebruik van een systeemeigen installatieprogramma is dat alle systeemeigen afhankelijkheden worden geïnstalleerd die nodig zijn om de hulpprogramma's uit te voeren. Systeemeigen installatieprogramma's bieden ook een systeembrede installatie van de SDK.
macOS-gebruikers moeten de PKG-installatieprogramma's gebruiken. In Linux is er een keuze uit het gebruik van een feedgebaseerde pakketbeheerder, zoals apt-get voor Ubuntu of yum voor CentOS, of het gebruik van de pakketten zelf, DEB of RPM. Gebruik in Windows het MSI-installatieprogramma.
De meest recente stabiele binaire bestanden vindt u op .NET-downloads. Als u de meest recente (en mogelijk instabiele) hulpprogramma's voor voorlopige versies wilt gebruiken, gebruikt u de koppelingen in de GitHub-opslagplaats dotnet/installer. Voor Linux-distributies zijn archieven (ook wel bekend als tarballs) beschikbaar. Gebruik de installatiescripts tar.gz in de archieven om .NET te installeren.
Installatiescript
Met behulp van het installatiescript kunt u niet-beheerders installeren op uw buildserver en eenvoudige automatisering voor het verkrijgen van de hulpprogramma's. Het script zorgt ervoor dat de hulpprogramma's worden gedownload en geëxtraheerd naar een standaardlocatie of opgegeven locatie voor gebruik. U kunt ook een versie opgeven van de hulpprogramma's die u wilt installeren en of u de volledige SDK of alleen de gedeelde runtime wilt installeren.
Het installatiescript wordt automatisch uitgevoerd aan het begin van de build om de gewenste versie van de SDK op te halen en te installeren. De gewenste versie is elke versie van de SDK die uw projecten nodig hebben om te bouwen. Met het script kunt u de SDK installeren in een lokale map op de server, de hulpprogramma's uitvoeren vanaf de geïnstalleerde locatie en vervolgens opschonen (of de CI-service laten opschonen) na de build. Dit biedt inkapseling en isolatie voor uw hele buildproces. De naslaginformatie over het installatiescript vindt u in het dotnet-install-artikel .
Notitie
Azure DevOps Services
Wanneer u het installatiescript gebruikt, worden systeemeigen afhankelijkheden niet automatisch geïnstalleerd. U moet de systeemeigen afhankelijkheden installeren als het besturingssysteem deze niet heeft. Zie .NET-afhankelijkheden en -vereisten voor meer informatie.
Voorbeelden van CI-installatie
In deze sectie wordt een handmatige installatie beschreven met behulp van een PowerShell- of bash-script, samen met beschrijvingen van SaaS-CI-oplossingen (Software as a Service). De behandelde SaaS CI-oplossingen zijn Travis CI, AppVeyor en Azure Pipelines. Zie GitHub Actions en .NET voor GitHub Actions
Handmatige installatie
Elke SaaS-service heeft zijn methoden voor het maken en configureren van een buildproces. Als u een andere SaaS-oplossing gebruikt dan die welke worden vermeld of aanpassingen nodig hebt buiten de vooraf verpakte ondersteuning, moet u ten minste een handmatige configuratie uitvoeren.
Over het algemeen moet u voor een handmatige installatie een versie van de hulpprogramma's (of de meest recente nachtversies van de hulpprogramma's) verkrijgen en uw buildscript uitvoeren. U kunt een PowerShell- of bash-script gebruiken om de .NET-opdrachten in te delen of een projectbestand te gebruiken dat het buildproces beschrijft. In de indelingssectie vindt u meer informatie over deze opties.
Nadat u een script hebt gemaakt dat een handmatige INSTALLATIE van de CI-buildserver uitvoert, gebruikt u dit op uw ontwikkelcomputer om uw code lokaal te bouwen voor testdoeleinden. Nadat u hebt bevestigd dat het script goed lokaal wordt uitgevoerd, implementeert u het op uw CI-buildserver. Een relatief eenvoudig PowerShell-script laat zien hoe u de .NET SDK kunt verkrijgen en installeren op een Windows-buildserver:
U geeft de implementatie voor uw buildproces aan het einde van het script op. Het script verkrijgt de hulpprogramma's en voert vervolgens uw buildproces uit.
$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
U kunt Travis CI configureren om de .NET SDK te installeren met behulp van de csharp taal en de dotnet sleutel. Zie de officiële Travis CI-documenten over het bouwen van een C#, F# of Visual Basic Project voor meer informatie. Houd er rekening mee dat u toegang krijgt tot de Travis CI-gegevens die door de community worden onderhouden language: csharp voor alle .NET-talen, waaronder F#en Mono.
Travis CI voert zowel macOS- als Linux-taken uit in een buildmatrix, waarbij u een combinatie van runtime, omgeving en uitsluitingen/insluitingen opgeeft om de buildcombinaties voor uw app te behandelen. Zie het artikel Build aanpassen in de Travis CI-documentatie voor meer informatie. De op MSBuild gebaseerde hulpprogramma's omvatten de langetermijnondersteuning (LTS) en STS-runtimes (Standard-Term Support) in het pakket; Dus door de SDK te installeren, ontvangt u alles wat u nodig hebt om te bouwen.
AppVeyor
AppVeyor installeert de .NET 6 SDK met de installatiekopie van de Visual Studio 2022 build worker. Andere build-installatiekopieën met verschillende versies van de .NET SDK zijn beschikbaar. Zie het artikel build worker images in de AppVeyor docs voor meer informatie.
De binaire .NET SDK-bestanden worden gedownload en uitgepakt in een submap met behulp van het installatiescript en vervolgens worden ze toegevoegd aan de PATH omgevingsvariabele. Voeg een buildmatrix toe om integratietests uit te voeren met meerdere versies van de .NET SDK:
environment:
matrix:
- CLI_VERSION: 6.0.7
- CLI_VERSION: Latest
Azure DevOps Services
Configureer Azure DevOps Services om .NET-projecten te bouwen met behulp van een van deze methoden:
- Voer het script uit vanuit de handmatige installatiestap met behulp van uw opdrachten.
- Maak een build die bestaat uit verschillende ingebouwde buildtaken van Azure DevOps Services die zijn geconfigureerd voor het gebruik van .NET-hulpprogramma's.
Beide oplossingen zijn geldig. Met behulp van een handmatig installatiescript bepaalt u de versie van de hulpprogramma's die u ontvangt, omdat u deze downloadt als onderdeel van de build. De build wordt uitgevoerd vanuit een script dat u moet maken. In dit artikel wordt alleen de handmatige optie behandeld. Zie de documentatie voor Azure Pipelines voor meer informatie over het opstellen van een build met Azure DevOps Services-buildtaken.
Als u een handmatig installatiescript wilt gebruiken in Azure DevOps Services, maakt u een nieuwe builddefinitie en geeft u het script op dat moet worden uitgevoerd voor de buildstap. Dit wordt bereikt met behulp van de gebruikersinterface van Azure DevOps Services:
Begin met het maken van een nieuwe builddefinitie. Zodra u bij het scherm bent dat u een optie biedt om te definiëren welk type build u wilt maken, selecteert u de optie Leeg .
Nadat u de opslagplaats hebt geconfigureerd om te bouwen, wordt u omgeleid naar de builddefinities. Selecteer Build-stap toevoegen:
U krijgt de taakcatalogus te zien. De catalogus bevat taken die u in de build gebruikt. Omdat u een script hebt, selecteert u de knop Toevoegen voor PowerShell: Voer een PowerShell-script uit.
Configureer de buildstap. Voeg het script toe vanuit de opslagplaats die u bouwt:
De build organiseren
In het meeste van dit document wordt beschreven hoe u de .NET-hulpprogramma's verkrijgt en verschillende CI-services configureert zonder informatie te verstrekken over hoe u uw code kunt organiseren, of daadwerkelijk bouwt met .NET. De keuzes voor het structuren van het buildproces zijn afhankelijk van veel factoren die hier niet op een algemene manier kunnen worden behandeld. Bekijk de resources en voorbeelden in de documentatiesets van Travis CI, AppVeyor en Azure Pipelines voor meer informatie over het organiseren van uw builds met elke technologie.
Twee algemene benaderingen die u neemt bij het structureren van het buildproces voor .NET-code met behulp van de .NET-hulpprogramma's, gebruiken MSBuild rechtstreeks of met behulp van de .NET-opdrachtregelopdrachten. Welke benadering u moet nemen, wordt bepaald door uw comfortniveau met de benaderingen en afwegingen in complexiteit. MSBuild biedt u de mogelijkheid om uw buildproces uit te drukken als taken en doelen, maar het wordt geleverd met de toegevoegde complexiteit van het leren van de syntaxis van het MSBuild-projectbestand. Het gebruik van de .NET-opdrachtregelprogramma's is misschien eenvoudiger, maar hiervoor moet u indelingslogica schrijven in een scripttaal zoals bash of PowerShell.
Tip
Eén MSBuild-eigenschap waarop u wilt instellen true , is ContinuousIntegrationBuild. Met deze eigenschap kunt u instellingen inschakelen die alleen van toepassing zijn op officiële builds in plaats van lokale ontwikkelings builds.
Zie ook
Feedback
Binnenkort beschikbaar: In de loop van 2024 zullen we GitHub-problemen geleidelijk uitfaseren als het feedbackmechanisme voor inhoud en deze vervangen door een nieuw feedbacksysteem. Zie voor meer informatie: https://aka.ms/ContentUserFeedback.
Feedback verzenden en weergeven voor