Konsistente Continuous Delivery für iOS - So haben wir den Prozess vereinfacht

Seit ich 2015 mit der professionellen Entwicklung von iOS-Apps begonnen habe, hat sich das Tooling für unsere Projekte wesentlich weiterentwickelt. Damals, als Junior-Entwickler, wurde mir die zeitaufwändige Aufgabe übertragen, nach der Fertigstellung der Projekte, diese in die App Stores hochzuladen. Wer damit Erfahrung hat, kann sich vorstellen, dass diese Aufgabe mit der wachsenden Anzahl von Projekten schnell ziemlich mühsam wurde. Ich begann also, nach einer besseren Lösung zu suchen.

Im Laufe der Jahre sind wir von der manuellen Erstellung und dem Export zu einer vollautomatischen Bereitstellung unserer Projekte übergegangen. In diesem Blog möchte ich die Geschichte der Entwicklung von Continuous Delivery bei Apps with love aufrollen. Ich werde die verschiedenen Tools in der Reihenfolge erkunden, in der wir angefangen haben, sie zu nutzen. Jede Technik baut auf der vorhergehenden auf und bringt neue Vorteile mit sich, so dass die Entwicklung nahtlos verläuft und das Setup im Laufe der Zeit schrittweise verbessert werden konnte.

Wer noch nicht weiss, was Continuous Integration und Continuous Delivery - kurz CI/CD - ist und warum man es verwenden sollte, sollte sich so bald wie möglich darüber informieren! Ein gutes Setup spart enorm viel Zeit und Frustration.

Als kurzen Überblick können wir unsere Fortschritte im Laufe der Jahre in drei Teile unterteilen:

• Builds vereinfachen

• Builds und Tests automatisieren

• Standardisierung über alle Projekte hinweg

Beginnen wir mit dem ersten Teil: Vereinfachung der Builds. Unser Tool der Wahl dafür ist Fastlane. Das vielleicht am weitesten verbreitete Build-Scripting-Tool für iOS, hat Entwickler*innen im Apple-Ökosystem Tausende von Stunden und einiges an Kopfzerbrechen erspart. Mit Fastlane kannst du “Lanes” erstellen, d. h. eine Reihe von Anweisungen, die ausgeführt werden sollen. Es sind viele Aktionen verfügbar, die zum Testen, Erstellen und Hochladen deiner Projekte verwendet werden können.

Building mit Fastlane

Wir haben 2015 begonnen, Fastlane zu nutzen. Es half uns, das Exportieren von .ipa-Dateien aus unseren Xcode-Projekten zu vereinfachen. Wir richteten in jedem Projekt ein sogenanntes Gymfile ein. Damit teilt man Fastlane mit, welches Schema verwendet werden soll, wie es exportiert werden soll und welche anderen Konfigurationen gegebenenfalls erforderlich sind. Die Verwendung von ˋgymˋ bedeutete, dass wir uns nicht mehr durch Xcode klicken mussten, um Builds zu exportieren. Stattdessen konnten wir es vom Terminal aus tun, was oft ein paar Minuten sparte und weniger fehleranfällig war, da die Anforderungen bereits im Gymfile definiert waren.

Code Signing mit Match

iOS-Entwickler*innen können sich sicherlich alle noch an den Moment erinnern, als sie ihre allererste App fertig entwickelt haben. Dann kommt der Teil der Veröffentlichung und der Kampf mit dem Code Signing fängt an. Das ist oft ziemlich nervig, vor allem wenn man Zertifikate und Profile manuell im Apple Developer Portal erstellen muss. Wenn man diesen Aufwand mit verscheidensten App Store-Teams und dutzenden Projekten multipliziert, wird es schnell zu einem riesigen Aufwand, den Überblick zu behalten.

Wir haben damit begonnen, die Generierung von Code Signing Assets mit ˋfastlane sighˋ zu automatisieren. Dadurch werden die erforderlichen Signing-Assets generiert, heruntergeladen und auf dem Rechner des*der Entwickler*in installiert, bevor die App gebuildet wird. In ähnlicher Weise hat Xcode vor einigen Jahren begonnen, Automated Provisioning zu unterstützen. Beide haben jedoch einen grossen Nachteil: Zusammenarbeit im Team wird nicht wirklich unterstützt.

Ein wichtiger Grund, warum bei uns früher nur eine Person für die Erstellung und Bereitstellung unserer Projekte verantwortlich war, war die Tatsache, dass die gemeinsame Nutzung von Zertifikaten und Bereitstellungsprofilen auf verschiedenen Rechnern ein grosses Problem darstellte.

Eine Zeit lang haben wir unsere Profile und Zertifikate im Drive auf unserem Google Workspace gespeichert. Aber wenn ein*e Entwickler*in vergass, diese hochzuladen oder sie einfach nicht finden konnte, erstellte die Person oft einfach ein neues Zertifikat und Profil. Dadurch wurden bestenfalls die Arbeitsabläufe anderer Entwickler*innen und schlimmstenfalls die an die Kund*innen gelieferten Builds unterbrochen. Ausserdem ist diese "Lösung" aus Sicherheitsgründen natürlich alles andere als optimal, aber hey, so wurde es damals halt gemacht.

Die Rettung kam in Form eines neuen Fastlane-Tools namens “Match”. Es nimmt die Signing Assets (Zertifikate und Profile) und synchronisiert sie über ein verschlüsseltes Git-Repository. Wir haben begonnen Match in alle unsere Projekte einzubauen und bis heute erweist es sich als enorme Zeitersparnis und als grundlegender Baustein unseres CI-Systems.

Wir verwenden ein einziges Repo für Match, mit einem separaten Branch für jedes App Store Team. Wir verwenden ein einziges Repo, weil wir für die verschiedenen Teams keinen Zugriff auf bestimmte Bereiche benötigen. Aber wenn das Szenario dies erfordert, funktioniert Match auch mit verschiedenen Repos oder sogar S3-Buckets.

Builds für mehrere Umgebungen

Bei praktisch jedem professionellen Projekt wirst du mit der Notwendigkeit konfrontiert, verschiedene Versionen deiner Builds zu erstellen. Vielleicht hast du verschiedene Staging- und Produktionsumgebungen oder Debug-Feature-Flags für Entwickler-Builds. Oder möglicherweise willst du Builds aus dem Dev-Branch an die Entwickler*innen oder an die Qualitätssicherung ausliefern, aber auch Builds aus dem Main Branch an deine Kund*innen.

Angesichts dieser Herausforderung mussten wir die Speicherung unserer Build-Konfigurationen in Gymfile, Matchfile und so weiter überdenken. Wir haben also bald alle unsere Konfigurationen in .env-Dateien verschoben und die anderen Dateien so geändert, dass sie einfach aus dem Environment gelesen werden. Das Erstellen des richtigen Builds ist jetzt nur noch eine Frage der Angabe des richtigen Environments:

Deployment mit Updraft

Viele Teams verwenden TestFlight, um Vorproduktions-Builds zu verteilen und für bestimmte Testszenarien (IAP ist eines davon) ist dies die einzige zuverlässige Option. Für die meisten unserer Projekte bevorzugen wir jedoch die gemeinsame Nutzung von Builds mit unserem eigenen Tool Updraft, das eine einfache Verteilung per E-Mail, Slack und MS Teams ermöglicht, ohne dass Testgeräte vorher registriert werden müssen. Und weil wir Updraft ständig benutzen, haben wir unsere eigene Fastlane-Aktion entwickelt, welche die mit ˋgymˋ exportierte .ipa-Datei abruft und sie sofort über Updraft an die Tester*innen weitergibt. Du kannst Updraft unter getupdraft.com ausprobieren - es ist kostenlos und funktioniert auch für Android-Projekte.

Weitere Tipps und Tricks

Wir haben auch mit anderen Fastlane-Aktionen herum experimentiert, um unsere Prozesse zu verbessern. Im Folgenden einige der Dinge, die wir mit Fastlane durchführen:

• Linting mit Swiftlint

• Ausführen von Tests und Sammeln von Coverage Reports

• Aktualisieren von Cocoapods vor dem Builden

• Hochladen von DSYM Dateien zu Firebase Crashlytics

• Inkrementieren der Build-Nummer

• Registrierung neuer Testgeräte

Wie man sehen kann, ist Fastlane unglaublich vielseitig und definitiv etwas, mit dem jede*r iOS-Entwickler*in umgehen können sollte.

Die Geschichte geht weiter…

Natürlich gibt es noch viel mehr zu erzählen zu Continuous Delivery. Zum Beispiel wie wir schneller Feedback erhalten und sicherstellen, dass unsere Tester*innen und Kund*innen immer Zugang zu aktuellen Builds haben, während wir unseren Entwickler*innen einen weiteren manuellen Schritt zugunsten der Automatisierung abnehmen. Mehr dazu ein andermal. In der Zwischenzeit: Danke fürs Lesen, ich hoffe, es war interessant. Und bei Fragen oder Anregungen stehe ich gerne zur Verfügung!

Bonus

Gerne teilen wir hier ein vollständiges Fastlane-Setup. Wir hoffen das gibt einen Überblick darüber, wie alles zusammenpasst: Hier geht's zu Github.