Kürzlich habe ich ein Tutorial darüber erstellt, wie Sie Travis CI als Tool zum automatischen Testen Ihres Codes verwenden, den Sie gerade in den Zweig master gepusht haben oder zu pushen versucht haben. Lassen Sie es kompilieren und testen und berichten Sie schließlich über den Status dieser Änderung.

Aber wir können es weiter besser machen, zum Beispiel möchte ich die Kernbibliothek, die im letzten Tutorial erstellt wurde, mit dem Feed NuGet öffentlich machen, damit jeder die Bedienung in seinen Bibliotheken vereinfachen kann!

Aber wie? Wie kompilieren, testen und veröffentlichen wir dieses Paket dann im Feed, damit jeder es in seinen Projekten herunterladen kann?

Nun, das ist dieses Tutorial für 😁!

Was ist neu?

Es gibt fast keine Änderungen am Code. Die Dinge, die wir ändern müssen, sind das Packen, die Veröffentlichung und dann die Art und Weise, wie wir es automatisieren können.

.NET Core-CLI

Wir werden die [.NET Core CLI](https://docs.microsoft.com/en-gb/dotnet/core/tools/?tabs=netcore2x verwenden, die wir im vorherigen Tutorial mit Befehlen wie dotnet restore, dotnet build und dotnet test verwendet haben.

Jetzt werden wir einen neuen Befehlssatz verwenden!

dotnet nuget

Sie können die Dokumentation für diesen Satz von Tools gleich [hier](https://docs.microsoft.com/en-gb/nuget/reference/dotnet-commands einsehen, aber eine kurze Erklärung:

dotnet nuget ist eine Reihe wesentlicher Tools, die das Installieren, Wiederherstellen, Entfernen und Veröffentlichen von Paketen umfassen.

NuGet-Feed

NuGet ist der Paketmanager für .NET. Die NuGet-Clienttools bieten die Möglichkeit, Pakete zu produzieren und zu nutzen. Die NuGet-Galerie ist das zentrale Paket-Repository, das von allen Paketautoren und -konsumenten verwendet wird.

NuGet ist kostenlos, Sie können sich also anmelden, Ihren API-Schlüssel abholen und mit dem Hochladen von Paketen beginnen. Sie werden hochgeladen, überprüft und dann für jeder aufgelistet.

Holen Sie sich den API-Schlüssel

Um Ihr Paket hochzuladen, benötigen Sie nach der Anmeldung Ihren API-Schlüssel. Gehen Sie also zur [API-Schlüsselseite](https://www.nuget.org/account/apikeys und erstellen Sie einen neuen.

Beachten Sie, dass der API-Schlüssel eine Ablauffrist von 365 Tagen hat.

Kopieren Sie dann Ihren Schlüssel und speichern Sie ihn wie auf der Seite beschrieben irgendwo. Sie können ihn dann nicht mehr sehen, und wenn Sie ihn nicht gespeichert haben, müssen Sie ihn neu generieren.

NuGet-Paket generieren

Nachdem wir nun den Schlüssel API haben, besteht unser nächster Schritt darin, das NuGet-Paket aus der Lösung zu generieren. Öffnen Sie also die Lösung dort, wo Sie Ihre Klassenbibliothek haben.

Ich werde die Lösung aus meinem [letzten Tutorial](https://emimontesdeoca.github.io/2020/ci-dotnet-core-and-travis-ci/ verwenden, die eine .NET Core-Bibliotheksklasse namens CalculatorCLI.Core enthält.

Gehen Sie nun zu den Projekteigenschaften und dann zu Paket. Dort werden viele Informationen zum Paket angezeigt, z. B. die Paketversion, Autoren, Beschreibungen und mehr.

Als nächstes müssen Sie dies ausfüllen. Sie müssen nicht wirklich alles ausfüllen, aber die wichtigen und obligatorischen sind Package id, Package version, Authors und Description. Auch wenn Sie versuchen, die Datei selbst hochzuladen, werden Sie nach License gefragt. Wir müssen sie ebenfalls hinzufügen.

Anschließend können Sie speichern, mit der rechten Maustaste in das Projekt klicken und Pack auswählen.

1>------ Build started: Project: CalculatorCLI.Core, Configuration: Debug Any CPU ------
1>CalculatorCLI.Core -> D:\Development\Personal\CalculatorCLI-demo\CalculatorCLI\CalculatorCLI.Core\bin\Debug\netstandard2.1\CalculatorCLI.Core.dll
1>Successfully created package 'D:\Development\Personal\CalculatorCLI-demo\CalculatorCLI\CalculatorCLI.Core\bin\Debug\CalculatorCLI.Core.1.0.0.1.nupkg'.
========== Build: 1 succeeded, 0 failed, 0 up-to-date, 0 skipped ==========

Die Ausgabe zeigt, dass, wenn alles in Ordnung ist, Successfully created package gedruckt wird.

Mit dotnet

Wie im vorherigen Tutorial haben wir verschiedene Befehle verwendet, um die Lösung zu erstellen und zu testen. Jetzt werden wir weitere Befehle zum Packen und Veröffentlichen der Pakete hinzufügen.

Diese Befehle sind:

1. dotnet pack -c <configuration>
2. dotnet nuget push <package> <k <apikey> -s <source>

Bereitstellungsskripte

Da wir die Art und Weise, wie der Build aussehen wird, ändern werden, wäre es meiner Meinung nach die beste Idee, unterschiedliche Dateien zu haben, von denen jede je nach Umgebung eine Build-Definition enthält.

Erstellen wir also einen Ordner namens scripts mit drei bash-Skripten im Stammverzeichnis des Repositorys.

scripts\compile.sh

#!/bin/sh

echo "Restoring..."
dotnet restore ".\CalculatorCLI\CalculatorCLI.sln"   

echo "Building..."
dotnet build ".\CalculatorCLI\CalculatorCLI.sln" -c Release

scripts\test.sh

#!/bin/sh

echo "Testing..."
dotnet test ".\CalculatorCLI\CalculatorCLI.sln" -c Release -v n

scripts\push.sh

#!/bin/sh

echo "Packing..."
dotnet pack ./CalculatorCLI/CalculatorCLI.Core/CalculatorCLI.Core.csproj -c Release

echo "Pushing..."
dotnet nuget push ./CalculatorCLI/CalculatorCLI.Core/bin/Release/*.nupkg -s "https://nuget.org" -k $NUGET_API_KEY

Verbesserung der Datei .travis.yml.

Nachdem wir nun den Quellcode aktualisiert haben, kennen wir die Befehle, die wir verwenden müssen, und müssen unsere kontinuierliche Bereitstellung mit kontinuierlicher Integration integrieren. Damit müssen wir eigentlich nichts weiter tun als programmieren, testen, überprüfen und pushen.

Was wir jetzt mit der Datei .travis.yml tun werden, ist Folgendes:

1. Verschiedene stages hinzufügen
2. Jeder stage hängt vom Zweig ab
3. Wenn Ihr Build auf Master basiert, bedeutet dies, dass das Paket aktualisiert werden muss. Daher werden wir unser Paket an die NuGet-Feeds übertragen
4. Wenn es sich bei Ihrem Build um eine Pull-Anfrage handelt, prüfen wir immer noch, ob der Build kompiliert werden kann, und testen ihn, veröffentlichen ihn jedoch nicht.

Stufen

Aus ihrer Dokumentation:

Sie können Builds, Phasen und Jobs herausfiltern und ablehnen, indem Sie Bedingungen in Ihrer Build-Konfiguration (Ihrer .travis.yml-Datei) angeben.

Weitere Informationen zu TravisCI stages finden Sie auf ihrer Dokumentationsseite.

Also werden wir die Datei ändern und die Stufen hinzufügen, was am Ende so aussieht:

language:
    csharp
sudo: required
mono: none 
dotnet: 3.0

os:
  - linux
    
jobs:
  include:
    - stage: compile
      script: bash scripts/compile.sh

    - stage: test
      script: bash scripts/test.sh

    - stage: deploy-prod
      if: branch = master AND type = push
      name: "Deploy to NuGet"
      script: bash scripts/push.sh

Wie Sie sehen können, haben wir drei verschiedene Stufen compile, test und push, wobei die letzte nur ausgeführt wird, wenn die branch master ist und es sich nicht um eine pull request handelt, sondern nur um eine push.

Wenn Sie das nicht verstehen, schauen Sie einfach in der Dokumentation nach und es wird ganz einfach erklärt.

Vor diesem Hintergrund werden alle pull request nichts an den NuGet-Feed weiterleiten.

Den API-Schlüssel als Umgebungsvariable festlegen

Gehen Sie zu den Einstellungen Ihres Repository-Builds und fügen Sie eine neue Umgebungsvariable mit dem Namen NUGET_API_KEY hinzu, wobei der Wert der kopierte API-Schlüssel von der NuGet-Seite ist.

Erstellen Sie ein pull request

Nachdem wir nun alles eingerichtet haben, ist es an der Zeit, einen pull request zu erstellen und zu prüfen, ob die Kompilierung für diesen Pull-Request den letzten stage ignoriert.

Überprüfen Sie die Builds

Sobald Sie die Pull-Anfrage stellen, wird ein Build im TravisCI-Dashboard in die Warteschlange gestellt, und wie Sie sehen, haben wir dort zwei verschiedene Builds und nicht drei.

Akzeptieren wir nun den pull request und überprüfen wir den Build erneut, um festzustellen, dass wir jetzt drei statt zwei Jobs haben.

Und sobald Sie sehen, dass der Build in die Warteschlange gestellt wird, können Sie die drei Jobs einschließlich des Deploy-prod am Ende sehen.

Sobald der gesamte Build abgeschlossen ist, können Sie in den Protokollen sehen, dass das Paket an die Quellen übertragen wurde.

Und natürlich können Sie es auf der NuGet-Seite sehen

Das ist es

In diesem Tutorial haben wir erfahren, wie wir unsere NuGet-Paketzustellung automatisieren können. Wir haben einige Tools wie TravisCI, stages und dotnet nuget verwendet.

Meiner Meinung nach, auch wenn die ordnungsgemäße Einrichtung einige Zeit in Anspruch nehmen würde und in manchen Fällen viel zu komplex sein könnte. Es lohnt sich, Zeit in diese Art von Techniken zu investieren, um alles perfekt und automatisiert zu machen.

Den Quellcode mit der Datei .travis.yml finden Sie direkt hier. Wenn Sie Fragen haben, können Sie mich gerne auf meinem Twitter kontaktieren!