Flutter App automatisch veröffentlichen: GitLab CI/CD für App Store und Play Store einrichten

Wer eine Flutter App entwickelt, kennt den klassischen Ablauf: lokal testen, Android Build erstellen, iOS Build erzeugen, Zertifikate prüfen, Version erhöhen, App Bundle hochladen, TestFlight öffnen, Google Play Console öffnen, Release Notes ergänzen, internen Test starten, später Production Release vorbereiten.

Bei kleinen Projekten funktioniert das noch irgendwie. Man klickt sich durch die Store-Oberflächen, kopiert Dateien hin und her und hofft, dass beim Upload nichts vergessen wurde. Doch sobald eine App wächst, mehrere Entwickler beteiligt sind oder regelmäßig neue Features veröffentlicht werden sollen, wird dieser manuelle Prozess schnell zum Risiko.

Genau hier kommt GitLab CI/CD ins Spiel.

Mit einer gut eingerichteten GitLab CI/CD Pipeline kannst du deine Flutter App automatisch testen, bauen und in den App Store sowie Play Store veröffentlichen lassen. Ein Merge in den main Branch kann zum Beispiel automatisch einen neuen Android Internal Release und einen neuen iOS TestFlight Build erzeugen. Ein Git Tag wie v1.2.0 kann anschließend einen kontrollierten Production Release auslösen.

Das Ergebnis: weniger manuelle Arbeit, weniger Fehler, nachvollziehbare Releases und ein Entwicklungsprozess, der auch dann noch funktioniert, wenn dein Projekt größer wird.

In diesem Artikel schauen wir uns an, was CI/CD bei Flutter Apps bedeutet, warum GitLab dafür eine starke Lösung ist, welche Vorteile automatische Releases bieten und welche Fragen dabei typischerweise auftauchen. Zum Schluss stelle ich dir eine Schritt-für-Schritt-Anleitung zur Verfügung, um Gitlab CI/CD für deine Flutter App einzurichten.

Was bedeutet CI/CD bei einer Flutter App?

CI/CD steht für Continuous Integration und Continuous Delivery beziehungsweise Continuous Deployment.

Bei einer Flutter App bedeutet das vereinfacht:

Continuous Integration:
Jede Änderung am Code wird automatisch geprüft. Dazu gehören zum Beispiel flutter analyze, Unit Tests, Widget Tests oder Golden Tests. Ziel ist es, Fehler früh zu erkennen, bevor sie in den Hauptbranch gelangen.

Continuous Delivery:
Nach erfolgreichen Tests wird automatisch ein veröffentlichbarer Build erzeugt. Bei Android ist das meistens ein .aab App Bundle. Bei iOS ist es eine .ipa Datei, die über App Store Connect verarbeitet wird.

Continuous Deployment:
Der Build wird anschließend automatisch an eine Zielumgebung ausgeliefert. Bei mobilen Apps sind das zum Beispiel Google Play Internal Testing, Closed Testing, Production, TestFlight oder der App Store.

Bei Webprojekten ist CI/CD inzwischen Standard. Bei mobilen Apps ist es oft etwas aufwendiger, weil Android und iOS eigene Signierungsmechanismen, Store-Richtlinien und Build-Umgebungen haben. Genau deshalb lohnt es sich aber besonders.

Warum ist CI/CD bei Flutter besonders interessant?

Flutter hat einen großen Vorteil: Du entwickelst eine App mit einer gemeinsamen Codebasis für mehrere Plattformen. Android und iOS entstehen also aus demselben Projekt. Das ist produktiv, aber es bringt auch eine Herausforderung mit sich, denn jeder Release betrifft meistens beide Stores.

Ohne CI/CD bedeutet das:

- Du baust Android lokal.
- Du baust iOS lokal.
- Du prüfst Signierung und Zertifikate.
- Du lädst die App manuell hoch.
- Du wiederholst ähnliche Schritte bei jedem Release.
- Du musst sicherstellen, dass beide Plattformen dieselbe Version haben.
- Du musst aufpassen, dass Build-Nummern korrekt hochgezählt werden.
- Du musst nachweisen können, welcher Code in welchem Store-Build gelandet ist.
- Du musst eventuell Konfigurationen anpassen.

Mit CI/CD wird daraus ein definierter Prozess.

Ein typischer Workflow kann so aussehen:

- Ein Entwickler erstellt einen Merge Request.
- GitLab startet automatisch Analyse und Tests.
- Wenn alles erfolgreich ist, kann der Merge in main erfolgen.
- Nach dem Merge baut GitLab automatisch Android und iOS.
- Android wird in den internen Testtrack hochgeladen.
- iOS wird zu TestFlight hochgeladen.
- Für den Production Release wird ein Git Tag erstellt.
- GitLab erzeugt daraus die Production Builds.
- Der finale Release wird kontrolliert manuell gestartet oder automatisch ausgeliefert.

Das sorgt dafür, dass dein Release-Prozess nicht mehr von lokalen Maschinen, vergessenen Klicks oder einzelnen Personen abhängt.

Was kann man mit GitLab CI/CD für Flutter Apps konkret erreichen?

Mit GitLab CI/CD kannst du deutlich mehr machen als nur einen Build starten.

Du kannst zum Beispiel festlegen, dass bei jedem Merge Request automatisch geprüft wird, ob der Code kompiliert, ob Tests bestehen und ob es Analysefehler gibt. Dadurch wird verhindert, dass fehlerhafte Änderungen überhaupt in den Hauptbranch gelangen.

Du kannst außerdem automatisiert App Bundles für Android erzeugen und direkt in die Google Play Console hochladen. So kann dein Team oder dein Kunde neue Versionen direkt über den internen Testtrack testen, ohne dass du manuell eine Datei exportieren und hochladen musst.

Für iOS kannst du automatisch eine IPA erstellen und zu TestFlight hochladen. Tester erhalten dadurch regelmäßig neue Versionen, ohne dass du Xcode öffnen und manuell archivieren musst.

Noch wichtiger wird es beim Skalieren: Du kannst verschiedene Release-Stufen einbauen. Zum Beispiel:

Merge Request: Nur Analyse und Tests
Merge in main: Automatischer Beta Release
Git Tag: Manuell freigegebener Production Release
Hotfix Branch: Separater Release für kritische Fehler
Protected Tags: Nur berechtigte Personen dürfen Production Releases auslösen

Damit wird aus einem improvisierten Veröffentlichungsprozess ein professioneller Software-Lifecycle.

Warum GitLab CI/CD statt lokaler Builds?

Lokale Builds haben einen entscheidenden Nachteil: Sie hängen von deiner Maschine ab.

Vielleicht hast du lokal eine andere Flutter-Version installiert. Vielleicht ist deine Java-Version anders. Vielleicht sind deine iOS-Zertifikate lokal korrekt, aber bei einem anderen Entwickler fehlen sie. Vielleicht funktioniert der Build nur auf deinem MacBook, aber niemand weiß genau, warum.

Eine GitLab CI/CD Pipeline schafft hier mehr Verlässlichkeit.

Die Pipeline dokumentiert den Build-Prozess in einer Datei: .gitlab-ci.yml. Dort steht genau, welche Befehle ausgeführt werden, welche Stages existieren und unter welchen Bedingungen Jobs starten.

Dadurch wird der Release-Prozess reproduzierbar.

Wenn ein Build fehlschlägt, sieht man im Pipeline-Log genau, an welcher Stelle es passiert ist. Wenn ein Release erfolgreich war, kann man später nachvollziehen, welcher Commit, welche Pipeline und welche Build-Nummer dazugehörten.

Das ist besonders wertvoll, wenn ein Projekt wächst oder mehrere Personen daran arbeiten.

Typischer Aufbau einer GitLab CI/CD Pipeline für Flutter Apps

Eine sinnvolle Pipeline für Flutter besteht meistens aus drei Stufen:

1. Test

In dieser Stage prüfst du, ob der Code grundsätzlich sauber ist. Dazu gehören zum Beispiel:

flutter pub get
flutter analyze
flutter test

Diese Stage sollte bei Merge Requests laufen. Ziel ist es, Fehler früh zu finden, bevor sie in den Hauptbranch gelangen.

2. Beta Release

Diese Stage läuft nach einem Merge in den main Branch. Hier werden echte Builds erzeugt und an Testumgebungen ausgeliefert.

Für Android kann das ein Upload in den Google Play Internal Track sein.
Für iOS kann das ein Upload zu TestFlight sein.

Dadurch bekommt dein Team nach jedem erfolgreichen Merge automatisch eine testbare App-Version.

3. Production Release

Diese Stage sollte bewusst kontrollierter ablaufen. Mobile Apps haben Store Reviews, Nutzerbewertungen und echte Auswirkungen auf bestehende Installationen. Deshalb ist es sinnvoll, Production Releases nicht bei jedem Merge automatisch auszulösen.

Ein guter Ansatz ist ein Git Tag:

v1.0.0
v1.0.1
v1.1.0

Sobald ein solcher Tag gepusht wird, erscheinen in GitLab Production Jobs. Diese können manuell gestartet werden. So kombinierst du Automatisierung mit Kontrolle.

Warum braucht man für iOS meistens einen macOS Runner?

Android Builds können in einem Linux Docker Container laufen. iOS Builds nicht.

Für iOS brauchst du Xcode und Xcode läuft nur auf macOS. Deshalb brauchst du entweder einen GitLab Hosted macOS Runner oder einen eigenen Mac als GitLab Runner.

Viele Teams nutzen dafür einen Mac mini, ein MacBook oder einen dedizierten Build-Mac. Dieser Runner wird bei GitLab registriert und bekommt einen Tag wie macos. In der .gitlab-ci.yml sagst du dann, dass iOS-Jobs nur auf Runnern mit diesem Tag laufen dürfen.

Das ist wichtig, weil sonst ein iOS-Job auf einem Linux Runner landen würde und dort gar nicht bauen kann.

Ein typischer iOS-Job läuft also auf einem macOS Runner, während Android und Tests auf normalen Docker Runnern laufen können.

Welche Rolle spielt fastlane?

GitLab CI/CD startet deine Jobs, aber GitLab selbst kennt nicht automatisch alle Details von App Store Connect, TestFlight, Google Play, iOS Signing und Store Uploads. Genau hier ist fastlane extrem hilfreich.

fastlane ist ein Automatisierungswerkzeug für mobile App Releases. Es kann unter anderem:

- Android App Bundles bauen
- AAB-Dateien in Google Play hochladen
- iOS Zertifikate und Provisioning Profiles verwalten
- IPA-Dateien zu TestFlight hochladen
- App Store Releases vorbereiten
- Build-Nummern setzen
- Release-Prozesse als wiederverwendbare Lanes definieren

In der Praxis ist GitLab CI/CD also die Pipeline-Plattform und fastlane das Werkzeug, das die mobilen Release-Schritte ausführt.

Das Zusammenspiel sieht so aus:

- GitLab startet den Job.
- Der Job installiert Abhängigkeiten.
- Fastlane führt die passende Lane aus.
- Flutter erzeugt den Build.
- Fastlane lädt den Build in den Store hoch.

Dadurch bleibt deine .gitlab-ci.yml übersichtlich und die komplexere Store-Logik liegt im Fastfile.

Kann man eine Flutter App direkt mit GitLab veröffentlichen, ohne fastlane?

Teilweise ja, aber in der Praxis ist fastlane meistens die bessere Lösung.

Du könntest theoretisch eigene Shell-Skripte schreiben, Android Builds erzeugen und APIs direkt ansprechen. Bei iOS wird es aber schnell kompliziert: App Store Connect API, Code Signing, Provisioning Profiles, Zertifikate, TestFlight Uploads und Exportoptionen müssen sauber zusammenspielen.

Fastlane löst viele dieser Probleme bereits. Es ist genau für mobile App Releases gemacht und wird in vielen professionellen Projekten eingesetzt.

Für Flutter Projekte ist deshalb ein realistischer Ansatz:

- GitLab CI/CD für Pipeline, Runner, Variablen und Trigger
- Fastlane für Android/iOS Build- und Store-Automatisierung
- Flutter CLI für die eigentlichen Builds

Was passiert bei einem automatischen Android Release?

Bei Android erzeugt Flutter normalerweise ein App Bundle:

flutter build appbundle --release

Dieses .aab wird dann über fastlane in die Google Play Console hochgeladen.

Dafür brauchst du:

- Eine App in der Google Play Console
- Die richtige Application ID
- Einen Upload Keystore
- Einen Service Account für die Google Play API
- Die passenden Rechte in der Play Console
- GitLab CI/CD Variablen für sensible Daten

Der Upload Keystore darf nicht einfach ins Repository gelegt werden. Stattdessen wird er typischerweise base64-kodiert als GitLab Variable gespeichert und während der Pipeline wieder als Datei erzeugt.

Auch Passwörter wie ANDROID_KEYSTORE_PASSWORD, ANDROID_KEY_PASSWORD und ANDROID_KEY_ALIAS gehören in GitLab CI/CD Variables, nicht in den Code.

Ein sauberer Android CI/CD Ablauf erzeugt also den Keystore zur Laufzeit, baut das App Bundle und lädt es anschließend in den gewünschten Track hoch.

Was passiert bei einem automatischen iOS Release?

iOS ist komplexer, weil Apple mit Zertifikaten und Provisioning Profiles arbeitet.

Für TestFlight und App Store brauchst du ein App Store Distribution Signing. Das bedeutet:

- Apple Distribution Certificate
- App Store Provisioning Profile
- App Store Connect API Key
- Korrekte Bundle ID
- Korrekte Team ID
- macOS Runner mit Xcode
- Flutter und CocoaPods
- Fastlane match oder ein anderer sauberer Signing-Prozess

In vielen Projekten nutzt man fastlane match. Dabei werden Zertifikate und Provisioning Profiles verschlüsselt in einem separaten privaten Git Repository gespeichert. Die CI lädt diese Signing-Dateien im readonly-Modus und kann damit reproduzierbar iOS Builds erzeugen.

Der Vorteil: Nicht jeder Entwickler muss manuell Zertifikate pflegen. Das Signing wird zentral verwaltet.

Gerade bei iOS ist es wichtig, nicht unkontrolliert neue Zertifikate zu erzeugen. Sonst entstehen schnell Fehler wie:

- Provisioning Profile enthält nicht das verwendete Signing Certificate.
- Private Key fehlt.
- Zertifikat ist lokal nicht verfügbar.
- Xcode verwendet Development Signing statt App Store Signing.
- Match-Repo und Apple Developer Portal sind nicht synchron.

Ein sauberer match-Workflow verhindert genau dieses Chaos.

Warum sollte man Secrets nicht ins Repository legen?

Eine CI/CD Pipeline braucht viele sensible Daten:

- Keystore-Dateien
- Store-Passwörter
- API Keys
- Service Account JSONs
- App Store Connect Private Keys
- Match Passwords
- Signing-Repositories
- Umgebungsvariablen wie .env

Diese Daten gehören nicht in Git.

Stattdessen nutzt man GitLab CI/CD Variables. Dort können Werte gespeichert und bei Bedarf als protected, masked oder hidden markiert werden.

Das hat mehrere Vorteile:

- Secrets landen nicht im Repository.
- Sie werden nicht versehentlich veröffentlicht.
- Sie können je nach Branch oder Tag geschützt werden.
- Sie lassen sich austauschen, ohne Code zu ändern.
- Die Pipeline bleibt flexibel.

Für skalierende Projekte ist das essenziell. Wenn später mehrere Apps, Teams oder Kundenprojekte betreut werden, brauchst du eine klare Trennung zwischen Code und geheimen Konfigurationen.

Wie funktioniert Versionierung in einer Flutter CI/CD Pipeline?

Mobile Apps brauchen zwei Arten von Versionsangaben.

Die sichtbare Version, zum Beispiel:

1.4.2

Und die interne Build-Nummer, zum Beispiel:

1040207

In Flutter kannst du diese Werte über die Build-Befehle setzen: --build-name für die sichtbare Version --build-number für die interne Build-Nummer.

Bei Android wird daraus versionName und versionCode.

Bei iOS wird daraus CFBundleShortVersionString und CFBundleVersion.

In einer CI/CD Pipeline kann man diese Werte automatisch erzeugen. Zum Beispiel aus der Pipeline-Nummer, einem Git Tag oder einem manuell gesetzten Offset.

Ein einfacher Ansatz ist:

- Build Number = GitLab Pipeline ID plus Offset
- Version Name = Basisversion plus Patch-Zähler

So kann aus einer Pipeline automatisch entstehen:

0.0.61+61
0.0.62+62
0.0.63+63

Das spart manuelle Arbeit und verhindert, dass App Store oder Play Store einen Build ablehnen, weil die Build-Nummer bereits verwendet wurde.

Warum sollte Production nicht immer automatisch veröffentlicht werden?

Automatisierung bedeutet nicht, dass jede Änderung sofort live gehen muss. Gerade bei mobilen Apps ist ein kontrollierter Production Release oft sinnvoller. Ein Merge in main kann automatisch TestFlight und Internal Testing auslösen. Der Production Release sollte aber häufig bewusst freigegeben werden. Dafür eignen sich Git Tags.

Beispiel:

v1.0.0
v1.0.1
v1.1.0

Eine Pipeline kann so konfiguriert werden, dass Production Jobs nur bei Tags erscheinen. Zusätzlich können diese Jobs manuell gestartet werden.

Das hat mehrere Vorteile:

- Nicht jeder Merge wird automatisch live.
- Production Releases sind bewusst und nachvollziehbar.
- Du kannst interne Tests vor dem finalen Release abwarten.
- Du kannst mit Protected Tags arbeiten.
- Du kannst Release Notes und Store Review bewusst vorbereiten.

Für professionelle Projekte ist das meist der beste Mittelweg: maximale Automatisierung für Tests und Beta Builds, aber bewusste Kontrolle bei Production.

Welche Vorteile hat GitLab CI/CD bei Flutter Projekten?

Der größte Vorteil ist nicht nur Zeitersparnis. Es geht vor allem um Prozessqualität.

1. Weniger manuelle Fehler

Manuelle Releases sind fehleranfällig. Schnell wird eine falsche Datei hochgeladen, eine Build-Nummer vergessen oder ein Schritt übersprungen. Eine Pipeline führt dieselben Schritte immer gleich aus.

2. Schnellere Testzyklen

Wenn nach jedem Merge automatisch ein TestFlight- oder Internal-Testing-Build entsteht, können Tester und Kunden viel schneller Feedback geben.

3. Bessere Nachvollziehbarkeit

Jeder Build ist mit einem Commit, einer Pipeline und einem Zeitpunkt verknüpft. Wenn später ein Fehler auftritt, kann man genau nachvollziehen, welcher Code ausgeliefert wurde.

4. Bessere Zusammenarbeit im Team

Bei mehreren Entwicklern ist es wichtig, dass Releases nicht nur auf dem Laptop einer Person funktionieren. CI/CD zentralisiert diesen Prozess.

5. Skalierbarkeit

Wenn dein Projekt wächst, brauchst du klare Prozesse. CI/CD schafft die Grundlage für größere Teams, mehrere Umgebungen, regelmäßige Releases und professionelle Qualitätssicherung.

6. Bessere Qualität vor dem Release

Automatische Tests und Analyse-Schritte verhindern, dass offensichtliche Fehler überhaupt in den Release-Prozess gelangen.

7. Automatisierbare Release-Strategien

Du kannst unterschiedliche Stufen definieren: Development, Beta, Internal Testing, Closed Testing, Production. Jede Stufe kann eigene Regeln und Freigaben haben.

Wie hilft CI/CD beim Skalieren eines Flutter Projekts?

Ein kleines App-Projekt kann mit manuellen Releases starten. Aber sobald das Projekt wächst, entstehen neue Anforderungen:

- Mehr Entwickler arbeiten gleichzeitig am Code.
- Features werden parallel entwickelt.
- Kunden oder Tester erwarten regelmäßige Builds.
- Fehler müssen schnell behoben werden.
- App Store und Play Store sollen sauber gepflegt werden.
- Builds müssen reproduzierbar sein.
- Sicherheitsdaten müssen geschützt werden.
- Release-Prozesse dürfen nicht von Einzelpersonen abhängen.

CI/CD löst genau diese Probleme. Ein skalierendes Projekt braucht wiederholbare Abläufe. Wenn jeder Release anders durchgeführt wird, entsteht Chaos. Wenn jeder Release denselben Pipeline-Prozess durchläuft, entsteht Struktur.

Außerdem ermöglicht CI/CD ein professionelleres Arbeiten mit Branches und Reviews. Ein Feature wird nicht einfach direkt veröffentlicht, sondern durchläuft Analyse, Tests, Review, Beta Build und erst danach Production.

Typische Fragen zu GitLab CI/CD mit Flutter

Kann GitLab CI/CD meine Flutter App automatisch in den App Store hochladen?

Ja. Dafür brauchst du einen macOS Runner, Xcode, einen App Store Connect API Key und ein korrekt eingerichtetes iOS Signing. In der Praxis wird häufig fastlane verwendet, um die IPA-Datei zu erzeugen und zu TestFlight oder App Store Connect hochzuladen.

Kann GitLab CI/CD meine Flutter App automatisch in den Play Store hochladen?

Ja. Android Builds können in einem Docker Runner erzeugt werden. Mit einem Google Play Service Account und fastlane kann das erzeugte App Bundle automatisch in einen Track wie Internal Testing, Closed Testing oder Production hochgeladen werden.

Brauche ich für Flutter CI/CD fastlane?

Nicht zwingend, aber in der Praxis ist fastlane sehr hilfreich. Es vereinfacht Store Uploads, iOS Signing, TestFlight Uploads und Android Releases deutlich. Ohne fastlane müsstest du viele Store-API-Schritte selbst skripten.

Warum brauche ich für iOS einen macOS Runner?

iOS Builds benötigen Xcode. Xcode läuft nur auf macOS. Deshalb kann ein iOS Build nicht einfach in einem normalen Linux Docker Container erstellt werden.

Kann Android auf einem normalen GitLab Runner gebaut werden?

Ja. Android Builds lassen sich normalerweise gut in Linux Docker Containern bauen. Deshalb kann man Android-Jobs oft auf GitLab Hosted Runners oder eigenen Linux Runnern ausführen.

Sollte ich bei jedem Merge direkt in Production veröffentlichen?

Meistens nein. Besser ist: Jeder Merge in main erzeugt automatisch Beta Builds für TestFlight und Internal Testing. Production Releases werden über Git Tags und manuelle Freigaben gesteuert.

Wie erhöhe ich automatisch die Build-Nummer?

Du kannst die Build-Nummer aus einer GitLab Pipeline-Variable wie der Pipeline-ID ableiten. Zusätzlich kann ein Offset gesetzt werden, wenn du bereits bestehende Build-Nummern im Store hast.

Wie erhöhe ich automatisch die sichtbare Versionsnummer?

Du kannst neben --build-number auch --build-name an den Flutter Build übergeben. Damit lässt sich zum Beispiel automatisch aus Pipeline-Daten eine Version wie 0.0.61 oder 1.2.3 erzeugen.

Was ist der Unterschied zwischen build-name und build-number?

build-name ist die sichtbare App-Version, zum Beispiel 1.0.3. build-number ist die interne Build-Nummer, die bei jedem Upload steigen muss.

Was ist fastlane match?

fastlane match verwaltet iOS Zertifikate und Provisioning Profiles zentral in einem verschlüsselten Repository. Dadurch kann die CI reproduzierbar iOS Builds signieren, ohne dass Zertifikate manuell auf jedem Rechner gepflegt werden müssen.

Warum sollte das match-Repository separat sein?

Das match-Repository enthält sensible Signing-Dateien. Es sollte deshalb getrennt vom App-Code liegen, privat sein und nur für berechtigte Personen oder Runner zugänglich sein.

Was passiert, wenn iOS Signing falsch eingerichtet ist?

Dann können Fehler auftreten wie fehlende Private Keys, falsche Provisioning Profiles, Development Signing statt App Store Signing oder nicht passende Zertifikate. Deshalb sollte iOS Signing sauber und zentral verwaltet werden.

Wo speichert man Keystore, API Keys und Passwörter?

In GitLab CI/CD Variables. Sensible Daten sollten niemals direkt ins Repository committed werden.

Was ist der Vorteil von Protected Branches und Protected Tags?

Damit kannst du steuern, wer Production Releases auslösen darf und welche Variablen nur in sicheren Kontexten verfügbar sind. Das schützt sensible Secrets und verhindert ungewollte Releases.

Was ist der Unterschied zwischen TestFlight und App Store Release?

TestFlight ist für Beta-Tests gedacht. Dort können interne oder externe Tester neue iOS Builds testen. Ein App Store Release geht an echte Nutzer und unterliegt dem finalen Review- und Veröffentlichungsprozess.

Was ist der Unterschied zwischen Internal Testing und Production bei Google Play?

Internal Testing ist ein Testtrack für eine begrenzte Testergruppe. Production ist der öffentliche Release für echte Nutzer im Play Store.

Häufige Fehler bei Flutter CI/CD Pipelines

Beim Einrichten einer Flutter CI/CD Pipeline treten oft ähnliche Probleme auf.

Flutter Version nicht fixiert

Wenn in der Pipeline immer stable verwendet wird, kann ein Flutter Update plötzlich Builds brechen. Für professionelle Projekte ist es oft sinnvoll, eine konkrete Flutter-Version zu verwenden.

Fehlende .env Datei

Wenn .env als Asset eingetragen ist, aber nicht im Repository liegt, schlägt der Build in der Pipeline fehl. Die Lösung ist, den Inhalt als GitLab Variable zu speichern und die Datei während der Pipeline zu erzeugen.

Falsche CocoaPods-Version

iOS Builds können fehlschlagen, wenn lokal oder in der CI unterschiedliche CocoaPods-Versionen verwendet werden. Deshalb ist es sinnvoll, CocoaPods über Bundler im Projekt zu verwalten.

iOS Signing-Chaos

Zu viele Zertifikate, falsche Provisioning Profiles oder ein nicht synchrones match-Repository führen schnell zu schwer verständlichen Fehlern. Hier hilft ein sauberer Reset und ein konsequenter match-Prozess.

Android JVM Target Mismatch

Manche Flutter Plugins verwenden unterschiedliche Java- oder Kotlin-Zielversionen. Dann kann der Android Release Build mit einem JVM Target Compatibility Fehler abbrechen. Hier müssen Gradle, Kotlin und Plugin-Versionen sauber zusammenspielen.

Build-Nummer bereits verwendet

App Store und Play Store akzeptieren keine bereits verwendeten Build-Nummern. Deshalb sollte die Pipeline die Build-Nummer automatisch erhöhen.

Secrets nicht verfügbar

Wenn GitLab Variablen als protected markiert sind, aber der Branch oder Tag nicht protected ist, kann die Pipeline die Secrets nicht nutzen. Das führt oft zu Fehlern, die auf den ersten Blick nicht wie Berechtigungsprobleme aussehen.

Für wen lohnt sich GitLab CI/CD bei Flutter Apps?

GitLab CI/CD lohnt sich besonders für:

- Startups mit wachsendem Produkt
- Freelancer mit mehreren Kundenprojekten
- Agenturen, die regelmäßig Apps veröffentlichen
- Teams mit mehreren Entwicklern
- Apps mit häufigen Updates
- Projekte mit Testern oder QA-Prozessen
- Apps mit Android- und iOS-Releases
- Produkte, die langfristig skalieren sollen

Wenn du nur einmal im Jahr eine kleine App aktualisierst, kann ein manueller Release ausreichen. Sobald du aber regelmäßig entwickelst, testest und veröffentlichst, spart CI/CD nicht nur Zeit, sondern erhöht die Qualität deines gesamten Prozesses.

Warum CI/CD auch für Kundenprojekte ein starkes Signal ist

Für Kunden ist CI/CD oft nicht direkt sichtbar. Aber sie spüren den Unterschied.

- Ein Kunde merkt, ob neue Testversionen schnell bereitstehen.
- Ein Kunde merkt, ob Releases chaotisch oder kontrolliert ablaufen.
- Ein Kunde merkt, ob Fehler nachvollziehbar analysiert werden können.
- Ein Kunde merkt, ob ein Entwickler professionell arbeitet oder jedes Mal improvisiert.

Eine GitLab CI/CD Pipeline zeigt: Dieses Projekt ist nicht nur programmiert, sondern professionell aufgestellt. Gerade für Agenturen und Freelancer ist das ein starkes Qualitätsmerkmal. Es zeigt, dass nicht nur Features gebaut werden, sondern auch der Release-Prozess, die Skalierbarkeit und die langfristige Wartbarkeit berücksichtigt werden.

Was sollte man vor der Einrichtung vorbereiten?

Bevor du eine Flutter CI/CD Pipeline einrichtest, solltest du einige Dinge klären:

- Wie lautet die Android Application ID?
- Wie lautet die iOS Bundle ID?
- Existiert die App bereits in Google Play Console und App Store Connect?
- Gibt es einen Android Upload Keystore?
- Gibt es einen Google Play Service Account?
- Gibt es einen App Store Connect API Key?
- Wie wird iOS Signing verwaltet?
- Gibt es einen macOS Runner?
- Welche Flutter-Version soll verwendet werden?
- Wie sollen Build- und Versionsnummern erzeugt werden?
- Welche Branches und Tags lösen Releases aus?
- Welche Secrets müssen geschützt werden?

Diese Vorbereitung spart später viel Zeit.

CI/CD ist kein Selbstzweck

Eine Pipeline einzurichten kostet am Anfang Zeit. Besonders bei iOS kann das Setup frustrierend sein. Zertifikate, Provisioning Profiles, Keychains und Runner sind nicht immer intuitiv. Aber der Aufwand lohnt sich. Denn danach läuft der Release-Prozess nicht mehr jedes Mal neu als manuelle Checkliste ab. Er ist definiert, versioniert und automatisiert. Das ist der entscheidende Unterschied: Du baust nicht nur eine App. Du baust ein System, mit dem diese App zuverlässig weiterentwickelt und veröffentlicht werden kann.

Fazit: GitLab CI/CD macht Flutter Releases professioneller

GitLab CI/CD kann deinen Flutter Release-Prozess massiv verbessern. Statt Android und iOS manuell zu bauen, Store Uploads per Hand auszuführen und bei jedem Release dieselben Schritte zu wiederholen, definierst du einen klaren automatisierten Ablauf und das bringt dir:

- schnellere Testversionen
- weniger manuelle Fehler
- bessere Nachvollziehbarkeit
- automatische Build- und Versionsnummern
- kontrollierte Production Releases
- saubere Trennung von Code und Secrets
- bessere Skalierbarkeit
- professionellere Zusammenarbeit im Team

Gerade wenn eine App langfristig wachsen soll, ist CI/CD kein Luxus, sondern eine wichtige Grundlage. Eine Flutter App zu entwickeln ist der erste Schritt. Sie zuverlässig zu testen, zu bauen und zu veröffentlichen ist der nächste. Mit GitLab CI/CD kannst du genau diesen nächsten Schritt professionell umsetzen.

PDF-Download: Schritt-für-Schritt Anleitung

Wenn du GitLab CI/CD für deine eigene Flutter App einrichten möchtest, brauchst du neben dem grundsätzlichen Verständnis auch eine konkrete technische Anleitung.

Deshalb findest du hier zusätzlich eine ausführliche Schritt-für-Schritt Anleitung als PDF. Darin wird praktisch erklärt, welche Einstellungen du in GitLab, fastlane, Google Play Console, App Store Connect und deinem Flutter Projekt vornehmen musst, um automatische Releases für Android und iOS einzurichten.