Effiziente OTA-Distribution mit GitLab Pages: Unsere Lösung für iOS, Android, Windows und Web

Einführung: Warum wir OTA-Distribution brauchen

In modernen Softwareprojekten ist eine reibungslose Bereitstellung von App-Builds für Tester:innen, Stakeholder oder Kund:innen ein entscheidender Erfolgsfaktor. Besonders bei mobilen Anwendungen für iOS und Android sowie Desktop-Apps für Windows kann es schnell umständlich werden, Builds manuell per USB oder über Drittanbieterdienste zu verteilen.

Ein beliebter Dienst für Over-The-Air (OTA) Distribution war bisher AppCenter. Da dieser jedoch eingestellt wird, haben wir bei Hybrid Heroes eine eigene Lösung implementiert: eine vollständig in GitLab Pages integrierte OTA-Distribution, die für alle relevanten Plattformen funktioniert – iOS, Android, Windows und Web. Dabei nutzen wir die bestehenden CI/CD-Pipelines und ermöglichen es, Builds bequem per QR-Code oder Direktlink zu installieren

Die Idee hinter unserer Lösung

Unsere Lösung basiert auf der GitLab-eigenen Möglichkeit, über GitLab Pages statische Inhalte zu hosten. In Kombination mit unserer Build-Pipeline erzeugen wir für jede Plattform automatisch eine OTA-Downloadseite, die abhängig vom Gerät unterschiedlich aussieht:

• Auf dem Desktop sieht man QR-Codes sowie Download-Buttons für ZIP-Dateien mit allen relevanten Builds.
• Auf dem Mobilgerät wird direkt ein Installations-Button für den passenden Build angezeigt.

Die Seiten sind öffentlich erreichbar (ohne GitLab-Login), sodass sie auch mit externen Stakeholdern oder Testpersonen geteilt werden können. Dabei nutzen wir die Flexibilität von GitLab Pages, um gezielt zwischen Merge Requests und der Hauptentwicklungsbranche (main/master) zu unterscheiden.

So funktioniert es im Detail

Plattformübergreifende URL-Struktur

Für jede Plattform (iOS, Android, Windows, Web) wird ein spezifischer OTA-Pfad generiert. Die URL-Struktur folgt einem klaren Schema:

• Merge Requests:
  https://<team>.gitlab.io/<projekt>/preview-<merge_request_id>--<plattform>-testing
• Branch Builds (z. B. main):
  https://<team>.gitlab.io/<projekt>/preview-main--<plattform>-testing

So entstehen eindeutige, nachvollziehbare Links, die sich konsistent teilen lassen – sowohl während der Entwicklung als auch nach dem Merge.

Device-abhängige Darstellung

Die OTA-Seiten passen sich dynamisch an das verwendete Gerät an:

• Wird die Seite am Desktop geöffnet, erscheinen QR-Codes (z. B. zur Installation auf iOS) und Buttons zum Herunterladen von ZIP-Archiven mit mehreren App-Varianten.
• Wird sie direkt am Smartphone geöffnet, gibt es einen einzelnen Download-Button für die passende Datei (z. B. .apk für Android oder .ipa für iOS).

Technischer Überblick: Was passiert in der CI-Pipeline?

Für jede Plattform wird eine eigene Pipeline definiert, die neben dem eigentlichen Build-Prozess auch die notwendigen HTML-Vorlagen generiert und alles per GitLab Pages deployt.

iOS (mit Fastlane)

• Die build_preview-Lane in Fastlane erzeugt eine ad-hoc-signierte .ipa-Datei.
• Zusätzlich wird eine HTML-Datei mit Icons und Metadaten generiert.
• Die fertigen Builds werden in einer preview-Struktur abgelegt und als GitLab Pages veröffentlicht.

Wichtig: iOS OTA benötigt ein Manifest zur Installation über den Safari-Browser – dies wird automatisch eingebunden.

Android (mit und ohne Fastlane)

• Für Android werden .apk- und .aab-Dateien für verschiedene Umgebungen gebaut (z. B. prod, staging).
• Per Fastlane oder Ruby-Script wird ein HTML-Template ausgefüllt.
• Auch hier entstehen ZIP-Dateien und eine saubere, mobile-freundliche OTA-Website.

Windows (z. B. mit Electron)

• Für Windows-Projekte (wie die PHYWE measureAPP) werden .exe-Dateien erzeugt und signiert.
• Die fertige Datei wird als ZIP verpackt und mit einer Landing Page über GitLab Pages veröffentlicht.
• Der Prozess läuft in einer PowerShell-Shell auf einer Windows-Runner-Maschine.

Web (z. B. mit Expo)

• Auch Web-Anwendungen profitieren von dieser Struktur.
• Nach jedem Commit auf einen Merge Request oder main wird automatisch eine Version der App als statische Seite deployt.
• Damit auch Assets korrekt ausgeliefert werden, muss die baseUrl in der App-Konfiguration exakt zur GitLab Pages-URL passen – insbesondere darf sie nicht mit einer Zahl beginnen (das führte bei Android sonst zu Build-Fehlern).

Lessons Learned

Im Laufe der Umsetzung haben wir einige wichtige Erkenntnisse gesammelt:

• GitLab Pages akzeptiert nur bestimmte Variablen im path_prefix. Eigene Variablen aus Jobs oder dynamische Konstrukte wie || oder && funktionieren nicht.
• Die Nutzung von CI_MERGE_REQUEST_IID ist ideal, da sie in Merge Requests immer verfügbar ist – im Gegensatz zu CI_COMMIT_BRANCH, das nur in Branch-Pipelines verfügbar ist.
• Länge zählt: Variablen wie CI_COMMIT_REF_SLUG können zu lange URLs erzeugen, was zu 404-Fehlern führt.
• Bei Web-Apps muss der baseUrl-Wert mit dem path_prefix übereinstimmen, und mit einem Buchstaben beginnen.

Fazit

Mit unserer GitLab Pages-basierten OTA-Lösung haben wir ein flexibles, zukunftssicheres System geschaffen, das den Wegfall von AppCenter nicht nur kompensiert, sondern deutlich komfortabler ist.

• Alle Builds an einem Ort
• Automatische Verteilung über Merge Requests oder Main-Branch
• Plattform- und gerätespezifische Darstellung
• Keine externen Tools notwendig

Gerade in Teams mit mehreren Plattformen und paralleler Entwicklung erleichtert dieses Setup die tägliche Arbeit erheblich – sowohl für Entwickler:innen als auch für QA, Projektleitung und Kund:innen.