Primär werden Buildserver zum automatisierten Erstellen und Veröffentlichen von Projekten genutzt. Ihr könnt allerdings auch wiederholende Cronjobs einrichten.
Mit Shared Libraries lassen sich die Funktionen von Jenkins einfach erweitern. In diesem Artikel zeige ich euch, wie ihr eine Shared Library erstellen, einbinden und aufrufen könnt.
Nach einiger Zeit ist mir aufgefallen, dass ein .NET Buildprozess auf Jenkins erheblich länger dauert als normal. Dieser Artikel zeigt euch eine mögliche Lösung.
Symptome Ich habe die Beobachtung gemacht, dass die Projekte anstatt ca. 4 Minuten plötzlich 15-20 Minuten gebraucht haben. Auch andere Projekte, die in 2-3 Minuten normalerweise beendet wurden, hatten eine Ausführungszeit von 10-15 Minuten.
Der Log sah bei allen Projekten ähnlich aus: Erst wurde das Projekt in der üblichen Zeit erstellt.
Nachdem wir Jenkins installiert und grundlegend eingerichtet haben, kümmern wir uns nun um die Erstellung eines Build-Jobs.
Am einfachsten richten wir uns zuerst den Job mit einem Jenkinsfile ein. Diese Datei beschreibt den Prozess, wie das Projekt korrekt erstellt wird. Da diese Datei ebenfalls im Git-Repository abgelegt wird, kann jeder Entwickler das Skript anpassen, sofern es nötig ist und Änderungen nachverfolgen.
Die Ordnerstruktur des Beispielprojekts
Um den Prozess exemplarisch zu zeigen, habe ich ein einfaches Repository vorbereitet.
Nachdem Jenkins installiert wurde, sollten wir das Programm auf dem aktuellen Stand halten. Dieser Artikel zeigt euch, wie das geht.
Meine aktuelle Version ist 2.164.3. Nachdem ihr euch angemeldet habt, wird euch die Version unten rechts in der Ecke angezeigt. Neue Versionen oder Updates für Plugins zeigt euch die Weboberfläche mit einem großen roten Hinweis an.
Startseite von Jenkins
Die Installation legt die .war-Datei automatisch unter /usr/share/jenkins ab. Den Pfad könnt ihr euch auch unter Jenkins Konfigurieren > Systeminformationen anzeigen lassen.
Dieser Artikel zeigt euch, wie ihr Jenkins auf eurem Linux installiert und einrichtet. Nachdem wir allgemein über Buildserver gesprochen haben, richten wir uns nun selbst einen ein.
Vorbereitung der Linuxumgebung Hierfür habe ich mir eine neue virtuelle Maschine erstellt und verwende Debian 9 als Betriebssystem. Ich habe mit apt-get update und apt-get upgrade das System aktualisiert jedoch keine weiteren Änderungen durchgeführt. Es handelt sich hierbei um ein ganz frisches System. Mit SSH habe ich mich am System angemeldet und arbeite via Konsole.
Ein Buildserver ist praktisch im Alltag. Doch was macht ihn aus und welche Vorteile werden geboten? In diesem Artikel gebe ich einen ersten Einblick.
Einleitung zu Buildservern Ein Buildserver ist, wie der Name schon sagt, ein Server, welcher dazu da ist, etwas zu bauen. In der Regel wird unter „bauen“ das Erstellen bzw. Kompilieren von Programmcode verstanden. Das Ergebnis kann anschließend weiterverarbeitet werden.
In der einfachsten Variante besteht ein Buildserver aus einem Skript, das regelmäßig ausgeführt wird.
In diesem Artikel möchte ich euch mein Projekt „NugetWrapper“ vorstellen. Hintergrund des Programmes ist das NuGet-Plugin von Jenkins. Es fehlen leider ein paar Funktionen im Plugin bzw. Nuget, um den Buildprozess zu verbessernF.
Das Wichtigste vorab: Ihr findet die Links zu den Projekten am Ende des Artikels.
Hintergrund Es gibt ein Jenkins-Plugin , um nach erfolgreichem Kompilieren die NuGet-Pakete auf einem NuGet-Server zu veröffentlichen. Das Einrichten ist sehr schnell erledigt.
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.