Wir setzen schon seit langem erfolgreich Jenkins ein, allerdings war unsere benutzte Jenkins-Umgebung veraltet. Jenkins selber und die Slaves liefen noch mit JDK6 und die Jenkins-Version war 1.456. Also „sehr“ alt. Schon das Einspielen neuer Plugins war im Prinzip unmöglich, weil diese in der Regel auf Java7 basierten. Mengenmäßig haben wir 20 Jenkins Slaves mit 27 Projekten und 200 Jobs. Die Projekte sind in unterschiedlichen Zuständen (gerade erst aufgesetzt, mitten in der Entwicklung, kurz vor der Release oder Wartungsmodus). Der normale Projektablauf sollte durch die Umstellung nicht behindert werden.

Wir haben uns entschieden, keine schleichende Migration zu machen, sondern komplett auf eine neue Jenkins-Version zu setzen und dabei gleich die JDK Version zu aktualisieren.

Dabei gibt es zwei Möglichkeiten: Man stellt den Server um und betet. Oder man setzt einen neuen Master auf und lässt die Jobs sukzessive umziehen. Wir haben uns für die zweite Methode entschieden. Dabei wird zunächst der alte Master dupliziert. Auf der Kopie werden Jenkins und JDK aktualisiert und dieser wird der neue Master. Alle Slaves werden erstmal auf dem neuen Master deaktiviert. Dann wird nacheinander ein Slave nach dem anderen auf dem neuen Master aktiviert und auf dem alten deaktiviert. Zusätzlich wird vor dem Umschalten des Slaves auf den neuen Master (per rsync) die aktuelle  Buildhistorie aller Jobs des Slave auf dem neuen Master aktualisiert.  Dabei sind folgende Probleme aufgetretenn:

1. Der parallele Betrieb von zwei Mastern (unterschiedlicher Versionen) auf dem selben Slave funktioniert nicht. Der neue Master aktualisiert auf dem Slave die jar-Dateien und damit läuft dann der alte Master nicht mehr. Daher ist es wichtig, Slaves auf dem alten Master zu deaktivieren.
2. Die eingerichteten Benutzer bekommen neue API-Token (siehe https://wiki.jenkins-ci.org/display/JENKINS/Authenticating+scripted+clients). Wenn also externe script-gesteuerte Zugriffe auf den Jenkins passieren, die diese Token verwenden  (z. B. SCM-Manager), dann müssen diese angepasst werden.

Schritte

Die Systemlandschaft besteht aus einem Master und einem guten Dutzend Slaves (RedHat, Windows, Ubuntu) sowie Crowd als Authentisierungssystem. Der Master steuert die Slaves per ssh.

Master installieren

1. Java8 installieren (hier am Beispiel Ubuntu):

   apt-get install software-properties-common add-apt-repository     ppa:webupd8team/java aptitude update aptitude install oracle-java8-installer

2. Jenkins installieren. Wir empfehlen die LTS-Version (http://jenkins-ci.org/#stable). Dabei gibt es verschiedene Varianten. Wichtig ist: Wenn man noch Projekte mit JDK6 hat, darf man keine Version über 1.612 installieren (siehe https://issues.jenkins-ci.org/browse/JENKINS-29004).
   1. Über die Pakteverwaltung (hier am Beispiel Ubuntu):
      1. Jenkins-Quellen hinzufügen via

         wget -q -O - https://jenkins-ci.org/debian/jenkins-ci.org.key | apt-key add - sh -c 'echo deb http://pkg.jenkins-ci.org/debian binary/ > /etc/apt/sources.list.d/jenkins.list' aptitude update

      2. Mit aptitude safe-upgrade den Jenkins aktualisieren. Hierbei bietet es sich an, mit aptitude den hold-status des Jenkins zu setzen.
   2. Direkt von der Hersteller-Seite herunterladen und installieren.
3. Jenkins (neu) starten

Authentisierung aktualisieren

1. Crowd Plugin (nicht Crowd2!) herunterladen

   cd /opt/jenkins/plugins rm -rf crowd* curl -OL http://updates.jenkins-ci.org/latest/crowd.hpi

2. Bug https://issues.jenkins-ci.org/browse/JENKINS-17288 fixen

   mv /var/run/jenkins/war/WEB-INF/lib/spring-context-support-2.5.6.SEC03.jar /var/run/jenkins/war/WEB-INF/lib/spring-context-support-2.5.6.SEC03.jar.orig

3. Konfiguration in config.xml anpassen

   <securityRealm class="com.ds.tools.hudson.crowd.CrowdSecurityRealm" plugin="crowd@1.2">   <url>http://XXXX/crowd/services</url>   <applicationName>XXXXX</applicationName>   <applicationPassword>XXXXXX</applicationPassword> </securityRealm>

Sonstiges Aufräumarbeiten

1. Plugins aktualisieren
2. „Tabbar für Ansichten“ auf „Default Views Tabbar“ umschalten
3. Unter „Jenkins verwalten“/“Globale Sicherheit konfigurieren“ den Punkt „Enable Slave → Master Access Control“ einschalten und „allow all /.*“ als File Access Rules setzen.
4. Unter „Jenkins/Zugangsdaten“ globale Zugangsdaten System: Den internen Nutzer mit Passwort hinterlegen.

Fazit

Der Umzug betraf 27 Projekte mit insgesamt 200 Jobs. Durch die gewählte Methode konnte jedes Projekt selber entscheiden, wann es auf den neuen Jenkins umzog.  Bei bestehenden Problemem gab es einen einfachen Fallback, indem der Slave aufgeräumt und einfach wieder auf dem alten Master aktiviert wurde.