25. April 2017

synTechTalk: Jenkins für Entwickler

synTechTalk: Jenkins für Entwickler (Bild: https://wiki.jenkins-ci.org/display/JENKINS/Logo / Creative Commons Attribution-ShareAlike 3.0 Unported License)

Jenkins ist ein hervorragendes Tool für DevOps, da es sowohl den Entwicklungsprozess unterstützen als auch automatische Deployments durchführen kann. In diesem Artikel möchten wir uns auf die Vorteile konzentrieren, die Jenkins im reinen Entwicklungsprozess bietet. Für die Durchführung der hier vorgestellten Demo benötigt man ungefähr 30 Minuten.

Inhaltsverzeichnis

  1. Installation
  2. Einrichtung
  3. Das erste Projekt
  4. Entwickler entlasten
  5. Beseitigung potentieller Fehlerquellen
  6. Unit-Tests
  7. Benachrichtigungen
  8. Fazit

1. Installation

  1. Downloade die neuste Version von Tomcat.
  2. Downloade die neuste Version von Jenkins.
  3. Deploye die jenkins.war im Tomcat und starte den Tomcat.

2. Einrichtung

Wenn Jenkins gestartet ist, empfehlen wir, ein Plugin zu installieren, das einem als Entwickler sonst fehlen könnte:

Wie der Name schon andeutet, fügt es Zeilennummern hinzu (z.B. bei der Konsolenausgabe). Dies ist insbesondere in der Teamarbeit praktisch. Mit dem Plugin können wir bei der Log-Analyse sicher sein, dass alle Beteiligten von der gleichen Zeile reden, ohne den Text direkt in ein anderes Tool kopieren zu müssen.

Außerdem gibt es diverse Plugin-Updates, die bei der Erstinbetriebnahme installiert werden sollten.

Während Jenkins sich installiert, haben wir Gelegenheit, schon einmal die Zugänge für Jenkins zu erstellen, sodass dieser mit den gleichen Services arbeiten kann wie der Entwickler.

  • Username + Password oder SSH-Schlüssel für git/svn hinterlegen bzw. freischalten
  • Maven’s settings.xml (Proxy, Repositories o.ä.) konfigurieren
  • Zugriff auf Repositories, Webserver und Datenbanken

3. Das erste Projekt

In der oberen linken Ecke kann ein neues Element angelegt werden.

Hier wählen wir unser Maven-Demo-Projekt aus.

Wer möchte, kann aber auch zwischen diversen anderen Projekt-Typen wählen.

Insbesondere das Pipeline-Projekt ermöglicht eine fast workflow-artige Hintereinanderschaltung von diversen Schritten unter Verwendung einer einfachen Textdatei. Diese Textdatei lässt sich ohne Probleme auch in git oder svn sichern/verwalten.

Schließlich wählen wir unser Version-Control-System aus, in dem unser Projekt liegt. Dazu konfigurieren wir unser Projekt so, dass es sogenannte Nightly-Builds erstellt.

Diese können wir im Bereich Build-Auslöser – Source Code Management System abfragen konfigurieren. Dabei wird eine sogenannte Chron-Syntax verwendet. Wir wählen hier „H 0 * * *“, was so viel bedeutet wie: jeden Tag zwischen 0:00:00 und 0:59:59 überprüfen wir, ob es eine neue Version in git/svn gibt und bauen entsprechend die Anwendung.

Für Maven geben wir zudem die Goals clean und package an, damit wir später die fertigen jars über die Weboberfläche herunterladen können.

Das war die Einrichtung des Projekts in Jenkins. Es bleibt lediglich, die Konfiguration zu testen und zu prüfen, ob das Build durchläuft. Natürlich könnten wir an dieser Stelle noch weitere Build-Schritte einfügen, wie z.B. ein Upload in eine Software-Repository oder ein Deployment auf einem Test-Server. Die Deployment-Features bringen vor allem den OPS- bzw. DevOps-Teams Vorteile. Das Bauen und Hochladen eines Projekts ist in vielen Unternehmen Aufgabe der Entwickler und lässt sich auch ohne Jenkins durchführen.

4. Entwickler entlasten

Gerade in größeren Projekten nimmt der komplette Kompilierungs- und Packungsprozess des Projekts (build-process) erhebliche CPU-Ressourcen in Anspruch. Partielle Builds gehen schneller, bergen aber das Risiko, dass irgendwo noch ein Stückchen alter Code in den Binärdateien lauert. Die Folge: Viel Spaß bei der Fehlersuche (und dabei, dem Kunden/Chef erklären zu müssen, warum ein Modul immer noch nicht funktioniert).

Hier zeigt sich ein großer Vorteil von Jenkins: Es bietet die Möglichkeit, den Build-Prozess (unbeaufsichtigt) auf einem Server durchzuführen und entlastet damit das System des Entwicklers. Hierdurch können wir als Entwickler entspannter und effektiver arbeiten.

5. Beseitigung potentieller Fehlerquellen

Teamwork heißt zudem, dass verschiedene Entwickler an verschiedenen Modulen arbeiten. Natürlich passieren dabei auch Fehler.

Ein Beispielszenario: Es ist Freitagabend kurz vor Feierabend und wir haben vor unserem Urlaub noch einen Bug behoben. Wir committen unsere Arbeit ins VCS, markieren die Aufgabe als erledigt und fahren mit guter Laune nach Hause. Montagmorgens möchte unser Kollege an einem anderen Modul arbeiten, das aufgrund des Bugs bisher nicht richtig lief. Er sieht, das Ticket ist geschlossen, lädt die neusten Updates für die benötigten Module herunter, startet die Anwendung und der Fehler ist immer noch da…

Das heißt: Der Bugfix wurde nicht ins Maven-Repository hochgeladen. Im besten Falle verliert der Kollege dabei die Zeit, die es dauert, das Projekt (aus dem VCS) auszuchecken und dann selbst das Build hochzuladen. Im schlimmsten Fall funktioniert es überhaupt nicht, sei es wegen eines anderen Betriebssystems, einer fehlenden speziellen Software oder auch nur wegen einer fehlenden Konfigurationsdatei. Dass unser Kollege sauer, oder zumindest genervt ist, ist hier verständlich.

Und nun sind wir bei den Nightly-/DEV-Builds: Statt es in die Verantwortung des Entwicklers zu geben, diese Builds durchzuführen und hochzuladen, schieben wir die Verantwortung auf Jenkins und lassen diesen diese Aufgaben automatisiert durchführen. So haben alle Teams Zugriff auf die aktuellsten Versionen der Bibliotheken.

6. Unit-Test

Jenkins hilft aber auch auf der Unit-Test-Seite weiter. Im Idealfall sollten die Tests immer grün sein, aber manchmal gibt es dann doch ein paar Tests, die nicht funktionieren. Jenkins bietet eine Übersicht, die angibt, bei welchem Build wie viele Tests erfolgreich waren bzw. fehlgeschlagen sind. Somit hat man auch im Nachhinein die Möglichkeit herauszufinden, seit wann ein Feature/Test defekt ist.

Außerdem können so Probleme erkannt werden, die durch Tests entstanden sind, die den Zustand des Entwicklerrechners voraussetzen. Dabei handelt es sich beispielsweise um eine bestimmte (abweichende) Softwareversion oder einen speziellen Eintrag mehr in der Datenbank, der z.B. durch Oberflächentests hervorgerufen wurde.

7. Benachrichtigungen

Da man nicht immer in die Oberfläche dieses Automatisierungstools schaut, bietet Jenkins Benachrichtigungen per E-Mail o.ä. an.  Diese informieren den Entwickler z.B. über fehlgeschlagene Tests oder eine neue Version der Bibliothek xy.

8. Fazit

Jenkins ist einfach zu bedienen. Vorteil ist, der Entwickler und sein Rechner werden entlastet. Zudem werden mögliche Fehlerquellen eliminiert oder zumindest reduziert. Jenkins bietet eine Build-Historie, die es ermöglicht herauszufinden, wann ein Fehler das erste Mal aufgetreten ist und kann Betroffene automatisch darüber informieren. Außerdem stellt es einen guten Einstieg in den Bereich DevOps dar.

Damit ist Jenkins ein sehr praktisches Tool, das vieles vereinfachen kann, wofür wir ein zweites System mit einer funktionierenden DEV-Umgebung für unsere Projekte einrichten müssen.

(Daniel Theuke)

In unserer Reihe synTechTalk geben unsere DEV und OPS Teams Einblicke in ihr Technologie- und Architektur- KnowHow zur Umsetzung erfolgreicher digitaler Geschäftsmodelle.

Keine Kommentare


Dein Kommentar:

* Pflichtfelder

Time limit is exhausted. Please reload CAPTCHA.