Ein neuer Stern am Himmel der Buildsysteme

Ab in das Repository

Das Ende eines erfolgreichen Buildprozesses stellt oft der Upload des erzeugten Artefaktes in das Repository dar. Hier ist zu unterscheiden zwischen dem lokalen Repository auf dem Buildrechner und dem globalen Repository, aus dem sich das ganze Team bedienen kann. Die Installation in das lokale Repository erfolgt dabei über den Task install:

buildr install

Um das installierte Artefakt wieder aus dem lokalen Repository zu löschen, hilft der Task uninstall:

buildr uninstall

Eine Installation in einen zentralen Server ist über upload möglich:

buildr upload

Hierfür muss dieser aber definiert werden:

repositories.release_to = "sftp://user:secrect@repo/share"

Diese Definition ist auch in einzelnen Schritten möglich:

repositories.release_to[:username] = "user"
repositories.release_to[:password] = "secret"
repositories.release_to[:url] = "sftp://repo/share"

In der eingesetzten Version von buildr (1.2.10) wird nur das SFTP-Protokoll unterstützt. Hier hat buildr in Bezug auf Maven 2 sicherlich noch Nachholbedarf, denn in Maven 2 existiert z.B. eine Möglichkeit zum Upload der Artefakte über webdav.

Stabilität und Sicherheit für den Buildprozess

Zur Steigerung der Qualität des Builds stellt buildr eine eingebaute Möglichkeit zur Verfügung. Es können so genannte Checks definiert werden. Nachfolgend ist z.B. die Prüfung dargestellt, ob im erzeugten war-Archiv auch eine web.xml im Verzeichnis WEB-INF vorhanden ist:

check package(:war), "should contain a web.xml" do
  it.should contain("WEB-INF/web.xml")
end

Beim Scheitern dieser Prüfung wird auch der Buildprozess scheitern. Bei größeren Buildskripts sind solche Checks sicherlich sehr sinnvoll, um den Buildprozess auch wartbar zu halten.

Umstieg möglich?

Neuland ist Neuland. An dieser Tatsache kann auch der sanfteste Weg nichts ändern, und so gestaltet es sich auch mit buildr. Der einfachste Weg zu buildr ist sicherlich von Maven 2 bzw. von Projekten, die mit einer Maven-2-Verzeichnisstruktur aufwarten können. Ein Umstieg von einer anderen Struktur ist vergleichbar mit dem Aufwand bei einem Umstieg von ANT zu Maven 2, d.h. der Umstieg ist sicherlich machbar. Da ein Buildprozess häufig aber auch mit einem Buildserver (Stichwort: Continuous Integration) verbunden ist, muss auch dieser Zweig weiterhin ausgefüllt werden. Die Beantwortung dieser Frage wird für viele sicherlich zentral sein, um die Frage nach einem Umstieg beantworten zu können. Ein Umstieg ist möglich, muss aber in der jeweiligen Projektsituation individuell bewertet werden. Ein erster Eindruck von buildr in einem größeren Projekt kann das Projekt Apache Ode geben.

buildr: Ist das ein gangbarer Weg?

buildr ist mit Sicherheit ein Buildsystem, welches einem Projekt hilft, die alltäglichen Aufgaben im Buildprozess zu bewältigen. Die Neuerung für Java-Entwickler, dass hier mit Buildskripten hantiert werden muss, die auf Ruby basieren, ist eigentlich kein großes Hindernis, denn einerseits werden hier nur sehr geringe Ruby-Kenntnisse erwartet und andererseits steht das gute Tutorial von buildr mit Rat und Tat zur Seite. Und Ruby allein sollte hier wirklich nicht abschrecken, sondern eher als Einladung, auch diese Welt kennenzulernen. In der Java-Welt steht täglich neue Technologie vor der Haustür, somit ist Ruby auch willkommen.

Da aber professionelle Softwareentwicklung mehr als aus einem compile – test – package (welches wirklich gut mit buildr bewerkstelligt werden kann) besteht, müssen auch die Aufgaben danach zufriedenstellend gelöst werden. Hier ist vor allem der Blick auf die bereits genannte Continuous Integration gerichtet. Projekte, die darauf angewiesen sind, benötigen hier die Antwort. Vorhandene Projekte, die bereits in einen funktionsfähigen Buildprozess eingebettet sind, haben mit Sicherheit nicht die Not, auf einen neuen Prozess umzusteigen. Aber bei neuen Projekten sollte man im Hinterkopf haben, dass hier ein Kandidat aus dem Ruby-Lager existiert, der einige interessante Lösungsansätze bietet. Beim direkten Vergleich mit Maven 2 sind noch folgende Punkte zu nennen, die eventuell gegen buildr den Ausschlag geben könnten:

  • Es existiert noch kein Plug-in für Eclipse oder IntelliJ IDEA.
  • Für Maven 2 und ANT existieren bereits viele Plug-ins und Tasks. Hier kann buildr noch nicht mithalten.
  • buildr hat keine eingebaute Unterstützung von Source-Code-Management-Systemen (es besteht aber die Möglichkeit, dies zu skripten, z.B. für Subversion mittels SVN-Kommando).
  • buildr bietet keine Alternative zur Projektseite von Maven 2.

Das endgültige Fazit fällt somit sicherlich uneinheitlich aus. Einerseits gefällt die Variante, aufgrund von Ruby-basierten Skripts Möglichkeiten zu haben, die Maven 2 nicht bietet. Andererseits werden einige doch Dinge vermissen, die essenziell für den Projektalltag in Java-Projekten sind. Da buildr aber doch noch eher in den Kinderschuhen steckt, werden einige Mankos in Zukunft beseitigt werden. Ein Blick lohnt sich allemal und bei Projekten, die auf Maven 2 basieren, ist ein Testlauf sehr einfach möglich und kann auch in einer ruhigen Minute schnell durchgeführt werden. Diese Chance hat buildr mehr als verdient und sie sollte auch gewährt werden. Für Interessierte sind folgende Quellen noch empfehlenswert: From Maven to Buildr, Buildr or when Ruby is faster than Java und build tools: buildr.

Markus Stäuble ist Senior Software Engineer bei namics (deutschland) GmbH, einem führenden IT- und Web-Dienstleister. Schwerpunkt in der täglichen Arbeit ist neben der Projektleitung und dem Coaching die Architektur von Java-EE-Anwendungen und deren Qualitätssicherung. Darüber hinaus ist er freier Autor von Fachartikeln. Kontakt: fb[at]staeuble.de.
Kommentare

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.