Continuous Integration mit Jenkins

Continuous integration (CI) ist ein Teil moderner Softwareentwicklung. Es stellt den Prozess des automatisierten Testens und Bauens einer Anwendung dar.

Jenkins ist ein webbasiertes Open Source CI Tool, das in Java geschrieben ist und unter Windows als Dienst läuft. Es hilft den Mitarbeitern der S&L BusinessSolutions aktuelle Versionen einer Anwendung zu veröffentlichen, indem es diese automatisiert baut oder in einer Testphase regelmäßig auf einer internen Testinstanz veröffentlicht.

 

Übersicht aller Projekte

In unserem Fall sehen wir nur das Projekt „Beispielprojekt“. Dieses Projekt ist ein sogenanntes „Free Style Softwareprojekt“, was bedeutet, dass wir alles selbst konfigurieren. Dieser Projekttyp ist für die meisten Projekte geeignet. Auf andere Projekttypen werden wir im Weiteren nicht eingehen, da diese meist sehr speziell sind.

 

Projekt Details

Auf der Detailseite sieht man die erste Besonderheit. Das Projekt kann nur mit Parametern gebaut werden (1). Das ist in der Standardkonfiguration von Jenkins so nicht vorgesehen und wird durch das Plugin „Conditional BuildStep“ ermöglicht.

Durch Plugins kann der Funktionsumfang von Jenkins erweitert werden, was das Tool sehr mächtig macht. Weiterhin kann man in der Detailansicht auf die Konfigurationsansicht navigieren (2) sowie den Build-Verlauf sehen (3).

Als Nächstes gehen wir auf die Konfiguration ein, also das eigentlich „Interessante“ an Jenkins.

 

Projektkonfiguration

Die Konfiguration eines Projektes beginnt mit der Konfiguration der Parameter. In dem Fall die gewünschte Umgebung und das Repository der Versionsverwaltung. Das Plugin bietet beim Bauen die verschiedenen Entwicklungszweige des Projektes in einem Dropdown an.

Hier sehen wir den vorher definierten Parameter, der durch den Text „${svnRepo}“ repräsentiert wird. Jenkins weist uns zudem darauf hin, dass die URL parametrisiert ist und er diese so nicht überprüfen kann. Da dieser Parameter jedoch eine Auswahl ist und diese direkt vom SVN Server bekommt, stellt dies kein Problem dar.

Danach folgen die Build-Auslöser, d.h. wann wird der Build automatisiert ausgeführt und die Buildumgebung. Die Umgebungseinstellungen steuern, was vor dem Build im Arbeitsbereich von Jenkins passieren soll. In diesem Projekt ist z.B. konfiguriert, dass der Arbeitsbereich vor dem Build gelöscht wird.

 

Buildvorgang des Projektes

Darauf folgt das Buildverfahren. Dieses besteht aus Steps, die verschiedene Aktionen durchführen, wie z.B. ein Batch Skript ausführen oder ein C# Projekt mit MSBuild bauen.  In unserem Fall werden zunächst die Nuget Pakete des Backendprojektes wiederhergestellt und danach mit MSBuild gebaut. Dafür muss vorher in den Einstellungen von Jenkins der Pfad zur MSBuild.exe gesetzt werden.

Da dieses Projekt im Frontend Angular benutzt wird, muss das Frontend ebenfalls gebaut werden.

Hierbei werden zuerst die Pakete für das Frontend mittels Yarn wiederhergestellt. Yarn ist ein Paketmanager, der genauso funktioniert wie NPM, nur das er die Pakete auf dem Server zwischenspeichert und schon einmal heruntergeladene Pakete nicht noch einmal herunterlädt. Danach wird das Projekt mittels der Angular CLI in einer produktiven Konfiguration gebaut.

 

Veröffentlichung des Projektes

Jetzt fehlt noch das Veröffentlichen des Projektes. Bei diesem Schritt kommt auch der oben definierte Parameter „Umgebung“ ins Spiel. Dieser entscheidet, wohin das Projekt veröffentlich wird. Das wird in diesem Fall für das Backend vom „Publish Profile“ durchgeführt, welches hier mit MSBuild ausgeführt wird. Danach wird mit dem Plugin „FileOperations“ das gebaute Angular Frontend in den entsprechenden Order kopiert. Das Kopieren des Backend übernimmt das „Publish Profile“.

Hiermit wäre der Buildvorgang abgeschlossen und nun folgen Post-Build-Aktionen, also was nach dem Build passieren soll.

 

Post-Build-Aktionen

Jenkins bietet hierfür diverse Möglichkeiten, die auch durch Plugins erweitert werden können. Denkbar wäre z.B. das eine E-Mail verschickt wird, wenn der Build fertig ist.

 

Starten eines Buildvorgangs

So viel zur Konfiguration eines Projektes. Aber wie starte ich den Build? Um den Build zu starten, klickt man auf die Schaltfläche „Bauen mit Parametern“. Das sieht dann wie folgt aus:

Beim Klick auf den Button „Build“, wird der Build mit den aktuell eingestellten Parametern gestartet.

Herauszufinden ob der Build erfolgreich war, ist zunächst relativ einfach, da Jenkins dies in der Übersicht anzeigt. Das hilft einem jedoch nicht, wenn Fehler auftreten. Deshalb kann man live den Konsolenoutput vom Build mitverfolgen. Dieser wird gespeichert und man kann sich das Log später nochmal anschauen. Um zu dieser Ansicht zu gelangen, klickt man im Menü zu dem Build auf Konsolenausgabe.

Hier sieht man gerade wie MSBuild das Backend Projekt erstellt.

 

Ergebnis eines Builds

Wenn der Build erfolgreich sieht das so aus:

Falls der Build nicht erfolgreich war dann wie folgt:

In dem Fall ist beim Build des Angular Projektes ein Fehler aufgetreten.

 

Wofür das alles? Unser Fazit

Natürlich stellt sich die Frage, warum man so etwas einsetzen sollte. Für uns eine einfache Frage, da das Tool

1. kostenlos ist
2. Fehler beim Veröffentlichen minimiert
3. Zeit einspart
4. nur einmalig je Projekt konfiguriert werden muss
5. und eine Veröffentlichung über alle Projektmitarbeiter hinweg vereinheitlicht.

Den 3. Punkt möchte wir mal genauer erläutern. Bei unseren Projekten dauert alleine der Build fast 10 Minuten.

 

Klingt erstmal nach nicht viel Zeit, jedoch muss man bedenken: Wir starten nur den Build! Sprich während Jenkins die Anwendung baut, können wir z.B. schon die Datenbank ausrollen. Normalerweise dauert ein Rollout ca. 20 – 30 Minuten (wenn alles glatt läuft), heißt also wir können die Zeit nutzen, um etwas anderes zu machen. Weiterhin wird man bei der Arbeit nicht unterbrochen und kann nahtlos an Projekten weiterarbeiten.

Haben wir Ihr Interesse geweckt? Sie möchten weitere Informationen? Dann sprechen Sie uns gerne an!