Continuous Integration für iOS Projekte mit Jenkins

1 Kommentar

In unseren Projekten verwenden wir einen zentralen Jenkins Continuous Integration Server mit dem wir nach jedem check in Vorgang automatische Builds aller unserer Module durchführen. Der Status der Builds wird ständig auf Bildschirmen in den Büros und neben der Kaffeemaschine angezeigt. Damit haben wir Transparenz über alle unsere Module.
Alle Module? – Na ja, zumindest über alle Java und Android Anwendungen, die sich auf dem unter Linux laufenden Jenkins kompilieren lassen. Doch was ist mit den iOS Applikationen? – Da sich iOS Anwendungen leider nicht so einfach auf einem Linux basiertem System erstellen lassen, haben diese sich lange Zeit der Transparenz entzogen. Doch damit ist jetzt Schluss! Dieser Artikel beschreibt Schritt für Schritt, wie der Build von iOS Anwendungen durch eine zentralen Jenkins Instanz gesteuert werden kann.

Definition eines neuen iOS Slaves auf dem Jenkins Master

Da der Jenkins Master unter Linux nicht in der Lage ist iOS Projekte zu kompilieren, ist es erforderlich einen Slave einzurichten, der unter MacOS läuft und für alle iOS Builds verwendet wird. Dazu wird auf dem Jenkins Master unter „Manage Jenkins/Manage Nodes“ mit „New Node“ ein neuer Knoten vom Typ „Dumb Slave“ hinzugefügt:

Anschließend können die Details des neuen Slaves bearbeitet werden:

Die folgenden Angaben müssen gemacht werden:

  • Name
    Der eindeutige Name des neuen Knotens. Es ist zu empfehlen, hier keine Leerzeichen zu verwenden
  • # of executors
    Die Anzahl der Build Prozessoren, die der Slave zur Verfügung stellt
  • Remote FS root
    Das Verzeichnis auf dem MacOS Node unter dem temporäre Dateien und workspaces abgelegt werden. Relative Pfade werden unterhalb des Verzeichnisses angelegt  von dem aus die Client Software gestartet wurde.
  • Launch Method
    Die Methode, die zum Start des Slaves verwendet wird. Hier sollte „Launch slave agents via Web Start“ ausgewählt werden. Dabei baut der Slave eine Verbindung zum Master auf und startet per Java Web Start den Client Prozess. Der Vorteil ist, dass die IP-Adresse des Client Nodes nicht bekannt sein muss und demnach auch Clients mit dynamischen IP-Adressen als Slaves verwendet werden können

Da der Slave später in der Lage sein muss auf das Source Code Repository zuzugreifen, ist es sinnvoll die dazu notwendigen Umgebungsvariablen und Pfade zu den benötigten Tools in den „Node Properties“ zu konfigurieren. Diese Einstellungen hängen jeweils von den Gegebenheiten des Slaves und dem verwendeten Versionsverwaltungssystem ab:

Erstellen eines iOS Jobs auf dem Jenkins Master

Bevor auf dem Jenkins Master ein neuer Job für einen iOS Build angelegt werden kann, muss zunächst das „XCode Integration Plugin“  installiert und der Jenkins Server neu gestartet werden.
Anschließend kann ein neuer Jenkins Job als „Free Style Software Projekt“ erstellt werden:

Für alle iOS Projekte ist es wichtig anzugeben, dass die Builds immer auf dem zuvor eingerichteten iOS-Slave ausgeführt werden. Dazu die Option „Restrict where this project can be run“ setzen und als „Label Expression“ den Namen des Nodes eingeben, der auf einem Mac läuft.

Anschließend in den Eigenschaften des Jobs wie gewohnt die Optionen zum Source Code Management konfigurieren.

Der eigentliche Build der iOS Software wird dann als Build Step hinzugefügt. Durch die Installation des XCode Integration Plugin steht in der Auswahlliste unter „Add build step“ die zusätzliche Option „XCode“ zur Verfügung, die dazu verwendet wird.

Für einen einfachen Xcode Build mit nur einem Projekt müssen lediglich die folgenden Angaben gemacht werden:

 

  • Configuration
    Der Name der in Xcode definierten Build Konfiguration die verwendet werden soll. Diese kann aus den vorhandenen Build Konfigurationen in Xcode ausgelesen werden
  • Xcode Projekt Directory
    Der Pfad zum Verzeichnis indem sich die „.xcodeproj“ Projektdatei befindet. Dieser Pfad ist relativ zu dem aus dem SCM ausgecheckten Projektverzeichnis anzugeben:

Desweiteren ist es sinnvoll die Option Unlock Keychain zu wählen und die zu verwendenden Keychain zu konfigurieren:

Für komplexere Projekte mit mehreren Modulen, die innerhalb eines Workspace organisiert sind, ist es notwendig den Xcode Workspace File und das zu verwendende Schema anzugeben. Die verfügbaren Schemata können mit dem Befehl

/usr/bin/xcodebuild -workspace yourworkspacefile.xcworkspace -list

in einem Terminalfenster auf dem Mac ermittelt werden.  Alle zur Konfiguration verfügbaren Optionen sind auf der Wiki Seite des Xcode Plugin beschrieben.

Vorbereitung des Jenkins Slave auf einem Mac

Als Jenkins Slave dient ein Mac mit installiertem Xcode und einer aktuellen Java Runtime. Die für einen Jenkins Slave Node benötigte Software kann sehr einfach von dem Jenkins Master heruntergeladen werden. Mit einem Aufruf der URL:

http:/jenkins_master_url/jnlpJars/slave.jar

über den Browser oder z.B. wget in der Kommandozeile erhält man die benötigte Software und kann sie in einem beliebigen Verzeichnis speichern.

Starten des Jenkins Slave und Verbindungsaufbau zum Master

Die zuvor heruntergeladene Datei slave.jar stellt die gesamte Funktionalität zur Verfügung, die ein Jenkins Slave benötigt. Beim Start eines Slave Node wird die jnlp URL des Masters übergeben, sodass der Slave eine Verbindung aufbauen und sich bei dem Master registrieren kann. Der Slave mit dem Namen iOS-Slave wird beispeilsweise mit folgendem Kommando gestartet:

java -jar slave.jar -jnlpUrl http://jenkins_master_url/computer/iOS-Slave/slave-agent.jnlp

Wurde der Slave auf dem Master nicht iOS-Slave genannt muss der Wert des Paramters jnlpUrl dementsprechend angepasst werden. Die zu verwendende jnlpUrl kann auf dem Master untern den Eigenschaften des Nodes ausgelesen werden (unter „Manage Jenkins/Manage Nodes/iOS-Slave“). Ist der Start des Nodes erfolgreich verlaufen, wird auf der Übersichtsseite im Master der Status „Connected via JNLP agent“ gemeldet:

Der iOS Build Job kann nun wie jeder andere Jenkins Job behandelt werden. Ebenso ist es möglich die beim Build entstandenen Artefakte herunterzuladen und auf dem Master zu archivieren. Außerdem kann der Job natürlich in die verschiedenen Views aufgenommen werden, sodass unser Statusmonitor in der Küche ab sofort auch grüne iOS Projekte anzeigt.

Lars Rückemann

Lars Rückemann leitet die Niederlassung Solingen der codecentric AG. In seiner fast 20-jährigen IT-Laufbahn hat er in den Rollen Softwareentwickler, Architekt, Solution Engineer und Agile Coach in verschiedenen Branchen und mit unterschiedlichen Technologien Erfahrungen sammeln können. Aktueller Schwerpunkt seiner Arbeit ist es, Unternehmen beim Setup agiler Softwareentwicklungsprojekte zu unterstützen. Dabei liegt sein Fokus sowohl im Bereich der Backlog-Erstellung als auch darauf, Software-Entwicklungs-Praktiken und Continuous Delivery in den Teams zu etablieren.

Share on FacebookGoogle+Share on LinkedInTweet about this on TwitterShare on RedditDigg thisShare on StumbleUpon

Artikel von Lars Rückemann

Agile Management

Planlos agil

Java 8 first steps with Lambdas and Streams

Weitere Inhalte zu Continuous Delivery

Kommentare

    Kommentieren

    Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.