Aus Hudson wird Jenkins – umsteigen oder abwarten?

Keine Zeit? Hier die Kurzversion in 30 Sekunden.

• Nach dem Streit mit Oracle um den Namen „Hudson“ hat die Community Ende Januar 2011 für die Umbenennung in Jenkins gestimmt.
• Hudson gibt es bei Oracle weiter, Jenkins ist der Fork der bisherigen Entwickler.
• Der Umstieg ist praktisch ein Tausch der WAR-Datei, Jobs, Konfiguration und Plugins bleiben erhalten.
• Statt HUDSON_HOME gilt jetzt JENKINS_HOME, ein vorhandenes altes Verzeichnis wird weiter genutzt.
• Mein Eindruck: Wer produktiv Builds fährt, sollte lieber früher als später auf Jenkins gehen. Vorher Backup, dann geht es schnell.

Wer einen Hudson-Server laufen hat, hat in den letzten Wochen sicher die Meldungen gelesen: Hudson heißt jetzt Jenkins. Ganz so einfach ist die Geschichte aber nicht, deshalb hier kurz, was passiert ist und was ihr tun müsst.

Was war los?

Nach der Übernahme von Sun durch Oracle gab es Streit um den Namen. Oracle wollte die Marke „Hudson“ für sich beanspruchen, die Entwickler um den Projektgründer wollten das nicht einfach hinnehmen. Am Ende hat die Community Ende Januar 2011 abgestimmt und sich für den neuen Namen Jenkins entschieden. Seitdem gibt es zwei Linien: Jenkins als Weiterentwicklung der Community und Hudson, das bei Oracle weiterläuft. Technisch ist das anfangs derselbe Code, die beiden werden sich aber vermutlich auseinanderentwickeln. Wie sich das bei den Plugins auswirkt, muss man beobachten.

Ich bin kein Jurist und will die Namensfrage auch nicht bewerten. Für mich als Anwender zählt: Wo passiert die Entwicklung, und wo kommen die Plugins her? Im Moment sieht es so aus, als säßen die meisten aktiven Entwickler bei Jenkins.

Der Umstieg

Hudson und Jenkins sind eine einzelne WAR-Datei. Wer Hudson in einem Servlet-Container wie Tomcat betreibt, tauscht die hudson.war gegen die jenkins.war aus, startet neu, fertig. Wer es ausprobieren will, ohne irgendetwas zu installieren:

java -jar jenkins.war --httpPort=8080

Das startet den integrierten Jetty-Server, und Jenkins ist unter http://localhost:8080 erreichbar. Die Daten liegen im Home-Verzeichnis. Statt der Umgebungsvariable HUDSON_HOME gilt jetzt JENKINS_HOME:

export JENKINS_HOME=/var/lib/jenkins
java -jar jenkins.war

Hattet ihr schon ein Hudson-Verzeichnis (bei vielen ist das ~/.hudson), wird das alte Verzeichnis weiter benutzt, eure Jobs, die Konfiguration und die installierten Plugins sind also einfach da. Trotzdem gilt wie immer vor einem Update: Verzeichnis sichern, also schlicht kopieren. Das Zurückgehen ist dann nur ein WAR-Tausch.

Ein kleines Beispiel zum Ausprobieren

Zum Testen taugt ein Maven-Job. Unter „Neuen Job anlegen“ wählt ihr „Maven 2/3-Projekt bauen“, tragt unter Quellcode-Management euer Subversion-Repository ein und bei „Goals“ einfach clean install. Im Abschnitt „Build auslösen“ könnt ihr „SCM abfragen“ mit /5 * * * eintragen, dann prüft Jenkins alle fünf Minuten, ob es neue Commits gibt, und baut bei Änderungen. Wer lieber ein Shell-Skript nimmt, nimmt „Freestyle-Projekt“ und schreibt den Aufruf in den Schritt „Shell ausführen“. Die JUnit-Testergebnisse zeigt Jenkins als Trend an, das ist für mich nach wie vor der größte Nutzen, weil man kaputte Tests sofort sieht.

Umsteigen oder abwarten?

Meine Meinung: umsteigen, nur nicht blind. Bei einem Rechner, der nur Hobbyprojekte baut, lohnt sich Abwarten sowieso nicht, da kann man in Ruhe testen. Wer produktiv baut, sollte sich Zeit für einen Probelauf nehmen: Backup ziehen, auf einer Kopie des Verzeichnisses starten, einmal alle Jobs durchlaufen lassen und die Plugins prüfen. Läuft alles, spricht aus meiner Sicht nichts dagegen, denn die Entwicklung der Plugins scheint eher bei Jenkins stattzufinden.

Wie sieht es bei euch aus, habt ihr schon gewechselt oder bleibt ihr erst mal bei Hudson? Schreibt es gern in die Kommentare.

Beitragsbild: eigene Collage mit Logos von Wikimedia Commons (Jenkins-Logo: The Jenkins project, CC BY-SA 3.0); die Marken gehören ihren Inhabern. Die Collage steht ebenfalls unter CC BY-SA 3.0.