Was sich ändert, wenn Sie eine mobile App ausliefern
Wenn Sie jahrelang Webanwendungen ausgeliefert haben, fühlt sich die mobile Auslieferung an wie der Eintritt in eine andere Welt. Bei einer Webanwendung bauen Sie, laden auf einen Server hoch, und fertig. Benutzer aktualisieren ihren Browser und sehen die neueste Version. Sie kontrollieren alles: den Server, die Infrastruktur, den Zeitpunkt der Veröffentlichung.
Mobile Apps funktionieren nicht so. Und die Unterschiede sind so tiefgreifend, dass sich Ihre gesamte CI/CD-Pipeline ändern muss.
Die App lebt auf einem fremden Gerät
Der erste und grundlegendste Unterschied ist der Ort, an dem die Anwendung tatsächlich läuft. Eine mobile App lebt nicht auf einem Server, den Sie verwalten. Sie lebt auf einem Gerät in der Tasche eines anderen. Sie können keine Dateien auf einem Server austauschen. Sie können keinen Hotfix einspielen, der sofort wirkt.
Jedes Mal, wenn Sie eine neue Version ausliefern wollen, müssen Sie die Anwendung neu bauen, digital signieren und an einen App Store übermitteln. Dann muss der Benutzer das Update selbst herunterladen und installieren. Manche Benutzer aktualisieren sofort. Andere ignorieren die Benachrichtigung wochenlang. Einige werden nie aktualisieren.
Das ändert, wie Sie über Auslieferung denken. Sie können nicht davon ausgehen, dass alle die neueste Version haben. Sie können keinen kritischen Fehler beheben und ihn innerhalb von Minuten an alle Benutzer ausliefern. Die Kontrolle, die Sie bei der Webauslieferung hatten, ist weg.
Zwei Plattformen, zwei Build-Systeme
Mobile Auslieferung bedeutet den Umgang mit mehreren Build-Systemen. Android verwendet Gradle. iOS verwendet Xcode. Jedes hat seine eigenen Regeln für SDK-Versionen, Abhängigkeiten und Ausgabeformate. Sie können keine Android-App auf macOS bauen und an iOS-Benutzer ausliefern oder umgekehrt.
Ihre Pipeline muss zwei separate Build-Pfade verarbeiten. Sie können parallel oder sequenziell laufen, je nach Einrichtung, aber sie sind niemals gleich. Die Build-Konfiguration für Android lebt in Gradle-Dateien. Die Build-Konfiguration für iOS lebt in Xcode-Projektdateien und -Schemas. Die Abhängigkeiten werden unterschiedlich verwaltet. Der Signierungsprozess ist völlig anders.
Wenn Sie beide Plattformen unterstützen, wird Ihre CI/CD-Pipeline effektiv zu zwei Pipelines, die sich etwas Test- und Benachrichtigungslogik teilen, aber beim Build-Schritt auseinandergehen.
Signierung ist nicht optional
Bevor eine mobile App auf dem Gerät eines Benutzers installiert werden kann, muss sie digital signiert werden. Diese Signatur beweist, dass die App von Ihnen stammt, nicht von jemandem, der sich als Sie ausgibt. Android verwendet eine Keystore-Datei. iOS verwendet Zertifikate und Provisioning-Profile.
Dies sind geheime Dateien. Wenn sie durchsickern, kann jemand anderes Apps veröffentlichen, die wie Ihre aussehen. Wenn Sie sie verlieren, können Sie nie wieder ein Update für Ihre bestehende App im Play Store oder App Store veröffentlichen. Es gibt keine Wiederherstellung. Sie müssten ein neues App-Listing erstellen und alle Ihre bestehenden Benutzer verlieren.
In Ihrer Pipeline müssen diese Dateien sicher gespeichert werden. Hartcodieren Sie sie niemals in Ihrem Repository. Committen Sie sie niemals in die Versionskontrolle. Verwenden Sie einen Secrets-Manager, verschlüsselten Speicher in Ihrem CI-System oder einen dedizierten Signierungsdienst. Die Pipeline sollte nur während des Signierungsschritts auf diese Dateien zugreifen und sonst nirgendwo.
Der Store kontrolliert Ihren Veröffentlichungszeitpunkt
Sie können nicht einfach eine APK- oder IPA-Datei an Benutzer senden. Die App muss durch einen App Store gehen. Google Play Store und Apple App Store haben beide Überprüfungsprozesse. Google Play überprüft normalerweise innerhalb von Stunden. Apples Überprüfung kann länger dauern und ist oft strenger.
Das bedeutet, dass die Zeit zwischen dem Ende Ihres Builds und dem Zeitpunkt, an dem Benutzer die neue Version verwenden, nicht unter Ihrer Kontrolle steht. Ein Dritter entscheidet, wann Ihre App live geht. Wenn sie Ihre Einreichung ablehnen, müssen Sie das Problem beheben, neu bauen und erneut einreichen. Die Uhr beginnt von vorne.
Dies betrifft auch Ihre Rollback-Strategie. Im Web bedeutet Rollback, die vorherige Version bereitzustellen. Auf Mobilgeräten können Sie Benutzer nicht zwingen, zurückzukehren. Benutzer, die bereits aktualisiert haben, bleiben auf der fehlerhaften Version, bis Sie einen Fix ausliefern. Und dieser Fix muss erneut durch die Überprüfung.
Gestaffelte Rollouts werden unerlässlich
Da Sie nicht einfach zurückrollen können, müssen Sie vorsichtig sein, wie Sie veröffentlichen. Sowohl Android als auch iOS unterstützen schrittweise Rollouts. Android nennt es gestaffelten Rollout. iOS nennt es phasenweise Veröffentlichung.
Die Idee ist einfach: Sie veröffentlichen die neue Version zuerst für einen kleinen Prozentsatz der Benutzer. Vielleicht 1 % oder 5 %. Sie überwachen Absturzberichte, Fehlerraten und Benutzerfeedback. Wenn alles gut aussieht, erweitern Sie den Rollout auf 10 %, dann 25 %, dann 50 %, dann 100 %. Wenn etwas schiefgeht, pausieren Sie den Rollout. Nur die kleine Gruppe von Benutzern, die das Update bereits erhalten haben, ist betroffen.
Dies ist für ernsthafte mobile Auslieferung nicht optional. Es ist der primäre Weg, um Risiken zu reduzieren, wenn Sie nicht sofort zurückrollen können.
Was das für Ihre Pipeline bedeutet
All diese Unterschiede summieren sich zu einer CI/CD-Pipeline, die sich stark von einer Web-Pipeline unterscheidet. Ihre mobile Pipeline muss Folgendes handhaben:
Das folgende Flussdiagramm zeigt die beiden Pfade nebeneinander und hebt hervor, wo mobile zusätzliche Hürden hinzufügt.
- Plattformspezifische Builds mit unterschiedlichen Toolchains
- Sichere Signierung mit Geheimnissen, die niemals durchsickern dürfen
- Upload zu App Stores mit automatisierter Einreichung
- Gestaffelte Rollout-Strategien, die pausiert oder erweitert werden können
Sie müssen auch anders über Tests nachdenken. Emulatoren und Simulatoren können viele Probleme erkennen, aber sie sind nicht perfekt. Manche Fehler treten nur auf echten Geräten mit bestimmter Hardware, Sensoren oder Netzwerkbedingungen auf. Ihre Pipeline sollte sowohl automatisierte Tests auf virtuellen Geräten als auch einen Prozess für Tests auf physischen Geräten vor der vollständigen Veröffentlichung umfassen.
Eine kurze Checkliste für mobile CI/CD
- Signierungsschlüssel und Zertifikate in einem sicheren Secrets-Manager speichern, nicht im Repository
- Separate Build-Jobs für Android und iOS mit ihren jeweiligen Toolchains einrichten
- Upload zu Google Play Console und App Store Connect automatisieren
- Gestaffelten Rollout oder phasenweise Veröffentlichung in der Pipeline implementieren
- Absturzberichterstattung und Überwachung hinzufügen, die während des schrittweisen Rollouts Warnungen auslösen
- Sowohl auf Emulatoren als auch auf echten Geräten testen, bevor der Veröffentlichungsprozentsatz erweitert wird
Das Fazit
Mobile Auslieferung ist nicht Webauslieferung mit einem anderen Build-Schritt. Die App lebt auf Geräten, die Sie nicht kontrollieren. Der Store kontrolliert Ihren Veröffentlichungszeitpunkt. Rollback ist kein Knopf, den Sie drücken. Ihre CI/CD-Pipeline muss diese Realitäten von Anfang an berücksichtigen. Für die Plattform bauen, sicher signieren, schrittweise veröffentlichen und unermüdlich überwachen. Das ist der einzige Weg, mobile Apps auszuliefern, ohne mit einem Produktionsvorfall aufzuwachen, den Sie erst im nächsten Überprüfungszyklus beheben können.