Continuous Integration mit Appveyor und .NET Core
Dieser Artikel bietet euch einen Schnelleinstieg in CI mit AppVeyor, sodass ihr sofort einen Buildserver in euer Open-Source-Projekt integrieren könnt..
Was ist AppVeyor
AppVeyor[1] ist ein Onlinedienst, welcher Continuous Integration anbietet. AppVeyor unterstützt verschiedene Anbieter wie GitHub, GitLab, VSTS und SVN. Für OpenSource-Projekte ist Appveyor kostenlos nutzbar.
Was ist Continuous Integration (CI)
CI ist recht umfangreich. Als Kurzversion lässt sagen, dass ein Service die Codebasis überwacht. Üblicherweise ist die Codebasis ein Git-Repository. Wird eine neue Version eingecheckt, wird der CI-Dienst aktiv. Der Dienst kann verschiedene Aktionen durchführen:
- Auschecken der aktuellsten Codeversion
- Kompilieren des Quellcodes
- Ausführen von Tests
- Auswerten der Ergebnisse
- Bei Fehlern eine Nachricht senden (E-Mail, SMS)
- Kompiliertes Ergebnis veröffentlichen (NuGet, FTP)
- Eigene Scripts aufrufen
- …
Buildserver sind (u.a. durch die eigenen Scripts) sehr mächtig. Primär soll dadurch sichergestellt werden, dass Fehler im Code oder fehlgeschlagene Tests sehr schnell erkannt werden. Vor allem wenn größere Teams an der gleichen Codebasis arbeiten können sich schnell Fehler einschleichen. Durch CI soll der Aufwand dadurch reduziert werden, das bestimmte Schritte konfiguriert werden und das Team sich auf die Entwicklung konzentrieren kann.
Weitere Infos lassen sich u.a. in Wikipedia[2] finden.
Projekt hinzufügen
Zu Beginn muss ein Account bei AppVeyor eingerichtet werden. Anschließend können wir, basierend auf den Anbietern das Projekt auswählen.
Neues Projekt anlegen
Auswahl des Hosters und Projekts
Sofern noch keine Verlinkung mit dem jeweiligen Hoster (z.B. Github) erfolgt ist, lässt sich diese mit einem Klick hinzufügen.
Konfiguration des Projekts
In den Einstellungen von Appveyor gibt es viele Möglichkeiten. Für ein MSBuild-Projekt kann es wichtig sein, die Version des Visual Studios festzulegen. Diese Einstellungen oder Umgebungsvariablen (für eigene Scripte) können unter Environment festgelegt werden.
Einstellungen für die Umgebung
Unter dem Menüpunkt Build gibt es verschiedene Möglichkeiten ein Projekt zu bauen. Hier wird
MSBuild, Script oder „Aus“ angeboten.
Wichtig ist hier „Script“ auszuwählen, wenn ein .NET-Core Projekt kompiliert werden soll. Da MSBuild
keine Core-Projekte bauen kann, müssen wir hier dotnet build aufrufen. Wenn eine bestimmte
Konfigurations kompiliert werden soll, wäre etwas wie dotnet build -c Release möglich.
Einstellungen für MSBuild
Angepasste Einstellungen für Script
Commit und automatische Ausführung
Ich habe ein einfaches Testprojekt erstellt und ein neues (leeres) Projekt gespeichert.
Commits des Projekts (in BitBucket)
Für das Testprojekt habe ich Bitbucket verwendet. In der Übersicht der Commits wird in der letzten Spalte der Status angezeigt. Ein paar Commits haben grüne Haken. Bei einem Commit habe ich absichtlich einen Fehler erzeugt. Hier wird, aufgrund der Integration von AppVeyor und BitBucket, der Fehler durch ein rotes Ausrufungszeichen angezeigt.
Ein Commit hat gar keinen Status. Das kommt daher, dass ich 2 Commits erzeugt habe. Ich habe allerdings nur 1x gepusht. Da AppVeyor nur auf push reagiert, wurde der letzte Stand kompiliert, welcher keinen Fehler mehr hatte.
In AppVeyor gibt es eine Konsolenausgabe.
Ausgabe der Konsole
In dieser kann detailliert nachgeschaut werden, was der Build-Prozess alles gemacht hat und welche
Ergebnisse es gab. Da wir hier nur dotnet build aufrufen und es sich um das klassische „Hallo
Welt“ Programm handelt, ist die Ausgabe recht übersichtlich.
Es kann allerdings vorkommen, dass eine fehlerhafte Konfiguration für einen Fehler sorgt und ein Commit dadurch mit einem Ausrufungszeichen markiert wird.
Fazit
Im Firmenumfeld habe ich fast immer mit einem Buildserver gearbeitet. Das automatische Kompilieren und die Auflistung der Ergebnisse (Erfolg oder Fehler) halte ich für sehr praktisch. Allerdings muss darauf geachtet werden, dass die Konfiguration vom Server korrekt ist, da dieser auch Fehler im Build erzeugen kann.
Dieser Artikel liefert einen ersten Einstieg. Aus diesem Grunde habe ich beispielsweise die Testausführung ausgelassen. Teilweise wird (je nach Unterstützung durch den Build-Server) ein Ticket angelegt oder eine E-Mail versendet, wenn ein Build (Kompilieren und Ausführen der Tests) fehlschlägt.
Bildquelle: Pixabay.com
