Ein Buildserver in 10 Klicks

Automatisiertes Builden mit Hilfe eines Buildservers verbessert die Qualität der Software. Nachfolgend eine Anleitung zum Aufsetzen eines Build Jobs mit Hudson in 10 einfachen Schritten.

Automatisierte Builds

Wer kennt sie nicht, die klingenden Begriffe wie Continuous Integration, Nightly Builds oder Test Automation?

Build Tools wie Ant oder Maven in der Java Welt, make oder rake anderswo, sind bereits weit verbreitet. Diese kompilieren, testen und bündeln den nackten Code zu einem lauffähigen Programm. Doch oft endet dort bereits der Prozess eines automatisierten Builds, wo er eigentlich erst begonnen hat.

Die Rolle des Buildservers

Ein Buildserver übernimmt nun die Aufgabe, die erwähnten Build Scripts regelmässig, oder sogar nach jedem Check-in, auszuführen und damit die ständige Lauffähigkeit eines Systems zu überprüfen.

Während ein Entwickler den Code vielleicht nur kompiliert, durchläuft der Buildserver einen möglichst umfangreichen Test- und Analyseprozess. Allfällige Probleme werden rasch erkannt und können durch die Entwickler sofort behoben werden, ohne dass diese während dem Buildlauf in ihrer Arbeit blockiert werden.

Hudson

Mit Hudson existiert ein Open Source Buildserver, welcher kaum Wünsche offen lässt. Flexible Konfigurationsmöglichkeiten, verschiedenste Report und Analyse Tools, eine intuitive Oberfläche mit aussagekräftigen Hilfebuttons sowie unzählige Plugins sind alle unter einem Mantel vereint.

Ein Buildserver in 10 Klicks

Wie gradlinig die Konfiguration für einen Build Job abläuft, illustrieren wir mit folgender Anleitung. Als Vorbedingung setzen wir ein installiertes, aktuelles Java SDK voraus, sowie ein Software Projekt, welches bereits über ein Build Script verfügt und in einem Source Code Management System verwaltet wird.

1.

Laden Sie die aktuelle Hudson Version von http://hudson.gotdns.com/latest/hudson.war herunter.

2.

Setzen Sie die Umgebungsvariable ‘HUDSON_HOME’ auf das Verzeichnis, welches als Arbeitsverzeichnis für Hudson dienen soll. In diesem Verzeichnis werden die Konfiguration sowie die Workspaces für die verschiedenen Build Jobs abgelegt. Per Default verwendet Hudson das Verzeichnis ’~/.hudson’.

3.

In der Befehlszeile Ihrer Wahl ‘java -jar hudson.war’ ausführen oder die WAR Datei in Ihren bevorzugten Servlet Container deployen.

4.

Öffnen sie die Hudson Seite in Ihrem Browser über http://localhost:8080.

5.

Wählen Sie ‘Neuen Job anlegen’.

6.

Geben Sie einen aussagekräftigen Namen sowie den Job Typ an. Falls Sie ein Maven Projekt haben, wählen Sie ‘Maven 2 Projekt bauen’, sonst ist ’”Free Style”-Softwareprojekt bauen’ die erste Option.

7.

Sie befinden sich nun auf der Hauptkonfigurationsmaske für einen Build Job. Sämtliche Einstellungen können hier vorgenommen werden. Falls Sie bei einer Option unsicher über deren Verwendung sind, konsultieren Sie den blauen Hilfe Button an der rechten Seite. Eine ausführliche Beschreibung und allfällige Beispiele klären an dieser Stelle die meisten Fragen. Im Bereich ‘Source Code Management’ müssen Sie die URL zum Code Repository Ihres Projektes angeben. CVS und Subversion sind standardmässig vorhanden, weitere Tools können über Plugins hinzugefügt werden.

8.

Unter ‘Build Auslöser’ kann die gewünschte Build Häufigkeit gewählt werden. Unter anderem können Builds zu fest definierten Zeiten gestartet werden, oder aber bei Änderungen im Source Code Management System. Zur Syntax des
erforderlichen Zeitausdrucks gibt ebenfalls der Hilfebutton Auskunft.

9.

Beim ‘Build Verfahren’ das entsprechende Build Script und das zu buildende Target auswählen.

10.

Um über die jeweiligen Builds informiert zu werden, verwenden Sie unter ‘Build-Einstellungen’ die Option ‘E-Mail-Benachrichtigung’. So kann auf fehlerhafte Builds rasch reagiert werden. Ebenfalls nützlich ist die Option ‘Getrennte E-Mails an diejenigen Anwender senden, welche den Build fehlschlagen liessen’.

Fertig

Damit ist die Konfiguration eines ersten, grundlegenden Build Jobs abgeschlossen. Über das Hudson Webinterface kann nun der Buildstatus verfolgt werden. Die generierten (Test-)Reports sowie die Konsolenausgabe können eingesehen und zusätzliche Builds manuell gestartet werden.

Für neue Jobs kann der bestehende einfach kopiert werden, bei Bedarf lassen sich diese auch in Gruppen einteilen. Und sobald eine Meldung mit ‘Build Successful’ im Posteingang liegt, wissen die Entwickler, das ihre neusten Änderungen auch wirklich mit dem gesamten System verträglich sind.

Kommentare sind geschlossen.