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.

Schreibe einen Kommentar

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

Bitte die Buchstaben des captcha Bildes im Eingabefeld eintippen

Please type the characters of this captcha image in the input box