Als Entwickler kann es mühsam sein, eine neue Version für eine iOS-App im App Store zu veröffentlichen. Sie müssen den richtigen Commit auswählen, den Code überprüfen, einen Build erstellen, archivieren, exportieren und das Archiv in den App Store von Apple hochladen. Angenommen, Sie müssen das 8-mal für die gleiche App mit einem anderen Brand wiederholen. Nun stellen Sie sich vor, all das mit nur einem Mausklick zu bewerkstelligen.
Bei Smartfactory nutzen wir fastlane bereits seit einiger Zeit für die kontinuierliche Integration unserer iOS Apps. In erster Linie für die Durchführung automatisierter Tests und die Erstellung von Testbuilds für unsere Kunden. Um eine neue Version der App in Apples App Store einzustellen, war die Unsicherheit jeweils gross. Sind die richtigen Zertifikate installiert? Wie war noch mal das Passwort? Welches Konto soll verwendet werden? Also, weshalb nicht auch diesen "letzten" Schritt automatisieren?
Die Funktionalität besteht schon seit längerem in den "fastlane Tools" mit "deliver" oder auch "pilot" für die TestFlight builds. Wir mussten nur das sogenannte Fastfile erweitern. Aber um eine App hochzuladen, braucht es zuerst eine IPA. Für die IPA, muss man die App kompilieren und archivieren. Und das funktioniert nur, wenn die richtigen Zertifikate und "Provisioning Profiles" installiert sind.
Wir haben mal angefangen und eine zusätzliche "lane" hinzugefügt, um einen App Store-Build der App zu erstellen. Damit wir auch die richtigen "Provisioning Profile" haben, weisen wir die "lane" zuerst an, diese von Apple's Entwickler Portal herunterzuladen. Dies bewerkstelligen wir mit "sigh". Hier ist ein Beispiel:
"sigh" lädt sich die Provisioning Profiles herunter und installiert sie auf Ihr System - in unserem Fall den Integrationsserver für iOS builds. Auf Ihren Wunsch kann "sigh" das Provisioning Profil neu generieren.
Sind die korrekten Profile installiert, muss die App erstellt werden. Dies hat im Grunde ein ähnlicher Mechanismus wie für unsere Testversionen, einfach mit anderen Zertifikaten. Das Tool der Wahl ist "gym".
Mit "gym" lässt sich auch noch einiges für den Build-Prozess überschreiben. Dies könnte das Spezifizieren von Profilen und Zertifikaten sein oder die explizite Auswahl des SDK oder der Toolchain sein. In der Regel stellen wir das alles schon im Projekt korrekt ein.
Nun zum letzten Schritt, das Hochladen. Normalerweise laden wir eine neue Version in ITC (iTunes Connect) hoch und stellen via TestFlight eine Testversion für das finale Testing zur Verfügung. Dazu nutzen wir "pilot" anstelle von "deliver". Somit haben wir auch im ITC-Prozess noch ein wenig die Zügel in der Hand. Mit "deliver" lassen sich auch Android Apps in den Play Store laden, wobei "pilot" nur im Ökosystem von Apple funktioniert. Auf der anderen Seite kann mit "pilot" auch das Beta-Testing verwaltet werden. Zur Zeit benutzen wir nur die Funktion des Uploads.
Wir haben die Profile, die App erstellt und hochgeladen. Was fehlt noch? Irgendwas muss noch fastlane anstossen um alles in Gang zu bringen. Bei Smartfactory benutzen wir gitlab zusammen mit dem Continuous Integration (CI) Modul für die Integration und das Deployment. Der Entwicklungszweig ist bei uns develop und der Release-Zweig master. Wir haben gitlab-CI auch so konfiguriert, dass ein Upload zu ITC nur auf Wunsch und nur vom master-Zweig möglich ist. Wenn wir also eine neue Version veröffentlichen wollen, "mergen" wir den develop in den master-branch und nachdem der Releasezweig aktualisiert worden ist, können wir auf unserem gitlab Server den Knopf für den Upload betätigen.
Dies hat uns nicht nur viel Zeit und Mühe beim Kompilieren von Hand und dem anschliessenden Hochladen erspart, sondern es erspart uns auch die lokale Verwaltung der Zertifikate und Profile auf unseren Entwicklungsservern.
Links: