Mobile Continuous Deployment mit Bitrise

Der agile Gedanke hat das grundlegende Vorgehen in der Softwareentwicklung verändert. Durch iterative Vorgehensmodelle wie Scrum oder Kanban hat sich der Umgang mit Features oder Resultaten verändert. Der Entwicklungsprozess durchläuft in relativ kurzen Zyklen immer wieder die gleichen „Checkpoints“ und man kommt häufiger an den Punkt, die Fortschritte veröffentlichen oder deployen zu müssen. Der Anspruch hat sich gewandelt: Von einzelnen punktuellen Veröffentlichungen im Projektverlauf hin zu regelmäßigen Integrationen in Systemlandschaften.

Der klassische Ansatz, teils kritische Deployments und Integrationen in vielen Schritten manuell durchzuführen, ist nicht mehr wirtschaftlich und darüber hinaus auch noch fehleranfällig. Hier wird der Bedarf nach Automatisierung sichtbar – „Software für die Software“. 

In unserem Native-Mobile-Projekt für eine große Hotelkette arbeiten wir nach Kanban und haben auch hier diese Anforderung gesehen. Daher setzen wir in unserem Team, wie andere Projektteams auch, ein automatisiertes Build-System ein.

Bitrise

Für dieses Projekt nutzen wir die Build-Plattform Bitrise. Dabei handelt es sich um ein SaaS-Tool, bei dem Mayflower einen bezahlten Account hat. Die Besonderheit solcher Tools ist, dass sie den Prozess und die vielen manuellen Schritte des Bauens einer App vollständig automatisieren. Das ist in unserem Projekt u. a. Code-Kompilierung, Code-Signierung, Einstellungen für den nächsten Build und AppStore-Handling. In anderen Projekten und in anderen Tech-Stacks sind es ggf. noch andere Schritte, wie Testing oder weitere operative Aktionen.

Durch diese Automatisierung wird der Buildvorgang reproduzierbar, zuverlässiger, stabiler und sicherer. Darüberhinaus wird der Entwicklerrechner durch den Buildvorgang nicht blockiert, da sich ein dedizierter Server um diese Aufgabe kümmert. Dadurch kann der Entwickler sofort weiterarbeiten während gebaut wird.

Buildstrecken

In diesem Account haben wir vier sog. Buildstrecken konfiguriert: DevAlpha und Production – jeweils für iOS und Android. Sie haben den Zweck, ausführbare App-Pakete („Buildartefakte“) bestimmter Codestände zu erzeugen. Die erwähnten Varianten unterscheiden sich folgendermaßen:

Artefakte

Die fertigen Buildartefakte, werden unter iOS und Android unterschiedlich gehandhabt. Bei Letzterem ist der Prozess einfacher gehalten, da hier Apps aus jeder beliebigen Quelle installiert werden können. Dabei entsteht am Ende der beiden Android-Buildstrecken jeweils eine APK-Datei, die von einem Bitrise-eigenem Storage heruntergeladen werden kann.

Bei iOS hingegen gibt es stärkere Restriktionen. iOS-Apps dürfen bei unserem Verteilungsverfahren nur über TestFlight verteilt werden. Aus diesem Grund müssen am Ende der iOS-Buildstrecken die resultierenden IPA-Dateien zusätzlich noch in TestFlight im Apple-App-Store hochgeladen werden. Hierfür müssen noch einige zusätzliche Einstellungen und Zugangsdaten in Bitrise hinterlegt sein.

Für den Kundenkomfort gibt es dann in Bitrise und für iOS in TestFlight noch Möglichkeiten, Notifications einzustellen. Zusätzlich zu normalen Mails kann Bitrise sogar auch über andere Kanäle, wie z. B. Slack, Benachrichtigungen verschicken. Auf diese Notifications kann der Kunde jederzeit asynchron reagieren und sich die Artefakte selbstständig herunterladen und auf seine Testgeräte installieren.

Ergänzend sei gesagt, dass es bei iOS zwar auch noch eine alternative Möglichkeit gibt, so wie bei Android, direkt zu verteilen. Dazu müssen jedoch alle Testgeräte einzeln registriert und dieses Register verwaltet werden.

Trigger

Es gibt bestimmte Git-Aktionen, die bestimmte Buildstrecken aktivieren, sodass Builds vollautomatisch aus der alltäglichen Arbeit entstehen. So lösen Git-Pushes oder Git-Merges auf unseren Development-Branch Builds unserer Testversion DevAlpha aus. Hingegen lösen Git-Tags mit einem bestimmten Namen, die bei uns releasefähige Codestände markieren, Builds der Produktivversion aus.

Lediglich die Versionsnummern muss man noch manuell definieren, da sie sich aus dem spezifischen Projektverlauf errechnen. Weitere manuelle Schritte sind nicht nötig – die Buildstrecken erledigen auch ganz spezielle Aktivitäten vollautomatisch. Die finale Freigabe, damit eine deployte Live-Version nach dem TestFlight dann auch allen Endnutzern zur Verfügung gestellt wird, führt der Kunde durch.

Continuous Deployment FTW!

Abschließend kann man sagen, dass initial zwar ein zusätzlicher Aufwand für die Einrichtung der Buildstrecken erforderlich ist, sich dieser jedoch sehr schnell amortisiert und als klares Win-Win entpuppt.

Die Automatisierung manueller Prozesse im operativen Bereich ist in agilen Projekten mit iterativen Vorgehensmodellen unentbehrlich geworden. Und das ist auch gut so. Denn davon profitiert nicht nur der einzelne Entwickler, der von wiederkehrenden Aufgaben befreit wurde, sondern auch das gesamte Projekt, da manueller Arbeitsaufwand wegfällt und bestimmte Schritte hierdurch sicherer ablaufen.

Und schließlich ist der Fortschritt auch für den Kunden sichtbarer und der Business-Value schneller zugänglich.