Schlagwort-Archive: jenkins

Android Open Source Release Management Continuous Delivery

Release Management ist ein wichtiges Mittel um effizient der Nutzerschaft neue Versionen einer Software bereitzustellen. Ein Artefakt muss aus einem bestimmten Stand der Quellen erzeugt und in einem geeigneten Repository bereitgestellt werden. Normalerweise wird das Release mit einer informativen Release Note bestückt. Im Fall von Open Source Software gibt es zusätzliche Anforderungen, wie zum Beispiel eine Referenz auf den verwendeten Stand der Quellen und eine Dokumentation.

Ein gutes Release Management erlaubt es, jederzeit ein funktionierendes Artefakt veröffentlichen zu können. Ein solcher Aufbau soll im folgenden für Android  Apps unter Verwendung von Git als Versionsverwaltungssystem, Jenkins als Build Server, Javadoc als Dokumentationswerkzeug und Fdroid als Markplatz zur Veröffentlichung der Apps beschrieben werden.

Unterschiedliche Zielgruppen

Wir unterscheiden in unserem Fall zwischen zwei Gruppen von Nutzern, denen jeweils in unterschiedlichen Zyklen Updates bereitgestellt werden sollen.

Entwickler sollen immer mit dem neuesten Stand einer App und der dazugehörigen Dokumentation versorgt werden. Auf diese Weise kann innerhalb des Entwicklerteams jeder den aktuellen Stand einer App installieren und testen. Dabei muss nicht jeder Stand zwangsläufig ein komplett fertiggestelltes Feature enthalten.
Die Endanwender wiederum sollen nur in den Genuss von ausgewählten Versionen einer App kommen, in der sich mindestens eine spürbare Änderung im Vergleich zur Vorversion befindet.
Im folgenden verwenden wir die Begriffe Release und Dev um die beiden Zielgruppen auseinanderzuhalten.

Unterschiedliche Orte für Fdroid und Javadoc

Um Artefakte und Dokumentation für beide Zielgruppen zu trennen legen wir je ein Fdroid Repository und einen Ort für das Javadoc an. Um sie in Jenkins Jobs einfacher ansprechen zu können, legen wir die Orte in Umgebungsvariablen ab. Die folgenden Variablen werden in der weiteren Beschreibung verwendet:

  • FDROID_REPO_DEV
  • FDROID_REPO_RELEASE
  • JAVADOC_DEV
  • JAVADOC_RELEASE
Dev Konfiguration

Um die Konfiguration möglichst simpel zu halten, verwenden wir pro App einen Jenkins Job der auf jeden push in das Git Repositories reagiert. Im Abstand von wenigen Minuten fragt Jenkins das Git Repository ab und startet folgenden Gradle Aufruf.

  • clean assembleRelease  leert das build Verzeichnis und kompiliert das apk File
  • publishFdroid -Pfdroid=${FDROID_REPO_DEV} -Ppatch=${BUILD_NUMBER} veröffentlicht die App Fdroid Dev Repo und verwendet für den dritten Teil der Versionsnummer die Nummer des Builds
  • publishJavadocRelease -Pjavadoc=${JAVADOC_DEV}  erstellt die Javadoc Dokumentation in einem dafür vorgesehenen Verzeichnis

Als Post Build Action werden die folgenden beiden Artefakte archiviert. Diese werden benötigt um zu einen beliebigen Zeitpunkt einen Stand in das Fdroid Release Repository zu veröffentlichen.

  • app/build/outputs/apk/app-release.apk
  • gradle.properties

Zum einen handelt es sich dabei um das apk File selbst und zum anderen um eine Properties Datei, die weitere Informationen über die App enthält.

Die Werte werden unter anderem verwendet, um die Metadaten des Fdroid Repisitories zu füllen. Bei Bedarf kann die Liste natürlich um weitere Einträge erweitert werden. Wie oben beschrieben wird die Patch Version durch den Parameter patch  von außen gesetzt. Für das Setzen der Versionsanteile Major und Minor ist der Entwickler verantwortlich.

Release Konfiguration

Für die Realisierung der Release Konfiguration verwenden wir das Promoted Builds Plugin. Die Promotion soll nur manuell ausgelöst werden.

Die Release Notes können für die Veröffentlichung im Dev Repo direkt aus jeder Git Commit Message des Commits gezogen werden, der den Build getriggert hat (mehr dazu weiter unten). Für die Release Notes des Release Repos ist das nicht der Fall, da davon auszugehen ist, dass zur Fertigstellung eines Features mehrere Commits getätigt wurden. Aus diesem Grund fügen wir der Promotion den Textparameter RELEASE_MESSAGE hinzu. Auf diese Weise kann ein sprechender, für den Endanwender gedachter Text für das Release angegeben werden.

Da die Promotion zeitlich verzögert also auch erst nach weiteren Commits stattfinden kann, ist der Zustand des Workspace nicht stabil.
Daher müssen im ersten Build Step der Promotion die veröffentlichten Artefakte des ursprünglichen Builds wieder zurück in Workspace kopiert werden. Dafür verwenden wir das Copy Artifacts Plugin. Als Jobname wird der Name des Jobs angegeben dessen App veröffentlicht werden soll, als die Nummer des spezifischen Builds die Variable ${PROMOTED_NUMBER} . Auf die Weise ist sichergestellt, dass genau die Version der App verwendet wird, die zuvor beim automatischen Build erstellt wurde. Gleiches gilt auch für die Metadaten.

Der zweite Build Step der Promotion ist ein Gradle Aufruf, der sich nur minimal von dem des Dev Builds unterscheidet. Die Tasks clean  und assembleRelease entfallen, da das Artefakt schon vorhanden ist. Die Verzeichnisse für das Fdroid Repository und die Dokumentation werden mit den entsprechenden Umgebungsvariablen für die Variante Release angegeben. Zu beachten ist die Verwendung des Parameters message , der den Wert des Jenkins Text Parameters übergeben bekommt.

 Gradle Tasks

Im folgenden wollen wir näher die verwendeten Gradle Tasks und deren Konfiguration eingehen. Wie zuvor erwähnt wir beim Gradle Aufruf die Versionskompente patch von außen gesetzt.

Fdroid

Die Variable fdroidDir beschreibt das Verzeichnis des Fdroid Repositories. Sie muss beim Aufruf gesetzt werden, da sonst sämtlich Fdroid bezogene Tasks übersprungen werden.

Die Variable fdroidMessage kann durch den Parameter message beim Aufruf gesetzt werden, was wie schon erwähnt in unserer Konfiguration bei der Promotion genutzt wird. Sollte message nicht von außen gesetzt werden, wird die Commit Message des letzten Commits verwendet.

  • tidy  entfernt ein Artefakt selben Names aus dem Fdroid Repository
  • copy  kopiert das gebaute apk File in das Fdroid Repository und benennt es enstprechend der Versionsnummer um
  • writeMetadata  beschreibt die Metadata Datei der App. Dabei werden die Werte aus gradle.properties verwendet
  • updateMetadata  aktualisiert die Metadaten
  • publishFdroid  aktualisiert das Fdroid Repository

Javadoc

Die Variable javadocDir beschreibt das Verzeichnis, in das die Javadoc Dokumentation kompiliert werden soll. Das Verzeichnis kann beim Gradle Aufruf durch den Parameter javadoc überschrieben werden. Wird dieser Parameter nicht verwendet, landet das kompilierte Javadoc unterhalb des Projektverzeichnisses.

Er wird pro Build Variante ein Gradle Task in der Form publishJavadoc  erstellt, sodass ein möglicher Aufruf gradle publishJavadocRelease -Pjavadoc=/my/javadoc/dir  lauten könnte.

Fazit

Die Erstellung eines ausgeklügelten Build und Release Mechanismus erfordert meist einen hohen Aufwand, bis sämtliche Schritte funktionieren und alle Rädchen ineinander greifen. Jedoch lassen sich auf diese Weise zeitaufwändige Schritte automatisieren, und neue Versionen per Knopfdruck veröffentlichen. Erfahrungsgemäß lohnt sich die Einrichtung eines Release Mechanismus schon bei wenigen Projekten innerhalb von kürzester Zeit.

Volle Fahrt voraus Interoberlin

Der Frühjahrsputz trägt Früchte : unsere Android Apps sind jetzt mit Javadoc Dokumentationen ausgestattet. Der Blog wird immer internationaler, bis nächste Woche sollten auch die restlichen Posts eine englische Übersetzung bekommen. Unser Fdroid Repo hat jetzt eine neue URL

Ebenfalls bis nächste Woche wollen wir unser Release Management überarbeiten. Basierend auf unserem Build Server Jenkins wollen wir dann präzise bestimmen können, welche Commits zu einem Release werden. Die genaue Konfiguration werden wir beschreiben, sobald sie fertig ist.

Zwischendurch waren wir zu zwei spannenden Sessions im Baumhaus Berlin um zusammen mit Lukas und Oscar das neue Design der Website des Open Space voranzutreiben.

Programmieren im Huddle und das Problem des Versionsmanagements

Ein wirklich präzises Versionsmanagement war an dieser Stelle übrigens nicht möglich, da fast gleichzeitig mehrere Personen an mehreren Dateien des Themes gearbeitet haben. Dabei jede Änderung zu versionieren hätte einen gewaltigen Overhead bedeutet.

Um das versehentliche Überschreiben von Dateien zu verhindern, an denen zwei Entwickler zur gleichen Zeit arbeiten, war in diesem Fall eine ständige Absprache notwendig, die aber nach einer Einspielzeit so gut wie automatisch erfolgte. Wirklich versioniert haben wir die Änderungen nur durch das tägliche Backup der WordPress Instanz.

Git // Klaus #tt Session 2013/09/12

Die Umstellung von SVN auf Git geht voran. Nachdem wir letzte Woche das Webfrontend Klaus installiert haben, ist heute die Integration unserer Git Repos in Jenkins dran. Anschließend soll der Kreis wieder geschlossen werden, indem die von Jenkins gebauten Artefakte in unser fdroid Repo gestellt werden sollen – natürlich auch per Knopfdruck in Jenkins, versteht sich.

Neben infrastrukturellen Themen haben wir uns mit der Ablauffähigkeit einer App auf Android Gingerbread beschäftigt. Zur Zeit versuchen wir bei der Entwicklung abwärtskompatibel bis Android SDK Version 8 zu sein und verzichten dabei auf einige Features von Icecream Sandwich und Jelly Bean.

Trotzdem ist es auf unserem Gingerbread gerät zum Absturz der App gekommen. Nach ein wenig USB Debugging mit adb und Catlog kam heraus dass die Methode LinearLayout.setBackground(Drawable d) nicht gefunden werden konnte. Das ist insofern verwunderlich, als dass wir die App für SDK Version 8 kompilieren konnten. Wir werden das Problem weiter untersuchen und halten euch auf dem Laufenden.

Tools : Build Automatisierung mit Jenkins #tt Session 2013/06/27

In dieser Woche haben wir eine Pause von unserem Modellboot Projekt eingelegt. Teilweise war dies der Tatsache geschuldet, dass die Fernbedienung explodiert ist…

Stattdessen haben wir uns auf unsere Build Prozesse konzentriert, speziell auf das Deployment von Android Apps. Aus diesem Grund haben wir auf unserem Server ein eigenes fdroid Repository installiert, in dem wir unsere Apps veröffentlichen wollen.

Android App Deployment Automatisierung

Jedes Mal wenn ein Entwickler Änderungen an einer App mit einem push auf den Server schiebt, wird ein Job im Jenkins Build System gestartet, der die App aus den aktuellen Quellen baut. Anschließend wir die apk Datei ins fdroid Repository kopiert und veröffentlicht.