GitHub Actions vs GitLab CI für Backend, Web und Mobile

Womit Teams in Multi‑App‑CI kämpfen

Wenn ein Repo ein Backend, eine Web‑App und Mobile‑Apps baut, hört CI auf, nur „Tests ausführen“ zu sein. Es wird zur Verkehrssteuerung für verschiedene Toolchains, unterschiedliche Build‑Dauern und unterschiedliche Release‑Regeln.

Das häufigste Problem ist simpel: Eine kleine Änderung löst zu viel aus. Eine Doku‑Änderung startet iOS‑Signierung, oder ein Backend‑Tweak erzwingt einen vollständigen Web‑Rebuild, und plötzlich fühlt sich jeder Merge langsam und riskant an.

In Multi‑App‑Setups tauchen einige Probleme früh auf:

• Runner‑Drift: SDK‑Versionen unterscheiden sich zwischen Maschinen, deshalb verhalten sich Builds in CI und lokal unterschiedlich.
• Secret‑Sprawl: API‑Keys, Signaturzertifikate und Store‑Zugangsdaten werden über Jobs und Umgebungen dupliziert.
• Cache‑Verwirrung: Der falsche Cache‑Key erzeugt veraltete Builds, aber kein Cache macht alles quälend langsam.
• Gemischte Release‑Regeln: Backends wollen häufig deployen, Mobile‑Releases sind abgesichert und brauchen zusätzliche Checks.
• Pipeline‑Lesbarkeit: Die Konfiguration wächst zu einer Wand von Jobs, die niemand anfassen will.

Deshalb ist die Wahl zwischen GitHub Actions und GitLab CI in Monorepos wichtiger als in Ein‑App‑Projekten. Du brauchst klare Wege, Arbeit nach Pfad zu trennen, Artefakte sicher zu teilen und parallele Jobs daran zu hindern, sich gegenseitig ins Gehege zu kommen.

Ein praktischer Vergleich reduziert sich auf vier Dinge: Runner‑Setup und Skalierung, Secret‑Speicherung und ‑Scope, Caching und Artefakte sowie wie einfach es ist, „nur das zu bauen, was sich geändert hat“, ohne die Pipeline in eine fragile Regel‑Suppe zu verwandeln.

Es geht um Alltagstauglichkeit und Wartbarkeit, nicht darum, welche Plattform mehr Integrationen oder eine hübschere UI hat. Es ersetzt auch nicht Entscheidungen über deine Build‑Tools (Gradle, Xcode, Docker usw.). Es hilft dir, die CI zu wählen, die eine saubere Struktur leichter erhalten lässt.

Wie GitHub Actions und GitLab CI aufgebaut sind

Der größte Unterschied ist, wie jede Plattform Pipelines und Wiederverwendung organisiert — das spielt erst dann eine Rolle, wenn Backend, Web und Mobile Builds dasselbe Repo teilen.

GitHub Actions speichert Automatisierung in YAML‑Dateien unter ./github/workflows/. Workflows werden durch Events wie Pushes, Pull Requests, Zeitpläne oder manuelle Runs ausgelöst. GitLab CI zentriert sich um ./gitlab-ci.yml im Repo‑Root, mit optionalen Include‑Dateien; Pipelines laufen typischerweise bei Pushes, Merge Requests, Zeitplänen und manuellen Jobs.

GitLab ist um Stages gebaut. Du definierst Stages (build, test, deploy) und ordnest Jobs diesen Stages zu, die dann in Reihenfolge laufen. GitHub Actions basiert auf Workflows mit Jobs. Jobs laufen standardmäßig parallel; Abhängigkeiten fügst du hinzu, wenn etwas warten muss.

Wenn du dieselbe Logik über viele Targets laufen lassen willst, sind GitHubs Matrix‑Builds eine natürliche Lösung (iOS vs Android, mehrere Node‑Versionen). GitLab kann ähnliche Fan‑Outs mit parallelen Jobs und Variablen erreichen, aber oft musst du mehr selbst verknüpfen.

Wiederverwendung sieht ebenfalls anders aus. In GitHub setzen Teams oft auf wiederverwendbare Workflows und Composite‑Actions. In GitLab kommt Wiederverwendung häufig durch include, gemeinsame Templates und YAML‑Anchors/extends.

Approvals und geschützte Umgebungen unterscheiden sich auch. GitHub nutzt oft geschützte Environments mit erforderlichen Reviewern und Environment‑Secrets, sodass Produktion‑Deploys auf Genehmigung warten. GitLab kombiniert meist geschützte Branches/Tags, geschützte Environments und manuelle Jobs, sodass nur bestimmte Rollen deployen können.

Runner‑Setup und Jobausführung

Beim Runner‑Setup beginnen sich die beiden Plattformen im Alltag zu unterscheiden. Beide können Jobs auf Hosted Runners (du verwaltest die Maschine nicht) oder Self‑Hosted Runners (du besitzt Maschine, Updates und Sicherheit) ausführen. Hosted Runners sind einfacher zu starten; Self‑Hosted Runner werden oft für Geschwindigkeit, spezielle Tools oder Zugang zu internen Netzwerken benötigt.

Eine sinnvolle Aufteilung in vielen Teams ist: Linux‑Runner für Backend und Web, und macOS‑Runner nur wenn iOS nötig ist. Android läuft auf Linux, ist aber ressourcenhungrig, daher sind Runner‑Größe und Festplattenspeicher wichtig.

Hosted vs Self‑Hosted: Was du verwaltest

Hosted Runner sind gut, wenn du ein vorhersehbares Setup ohne Wartung willst. Self‑Hosted machen Sinn, wenn du spezifische Java/Xcode‑Versionen, schnellere Caches oder internen Netzwerkzugang brauchst.

Bei Self‑Hosted Runnern definiere früh Runner‑Rollen. Die meisten Repos kommen mit einer kleinen Auswahl gut zurecht: ein allgemeiner Linux‑Runner für Backend/Web, ein kräftigerer Linux‑Runner für Android, ein macOS‑Runner für iOS‑Packaging und ‑Signierung sowie ein separater Runner für Deploy‑Jobs mit engeren Berechtigungen.

Den richtigen Runner pro Job wählen

Beide Systeme erlauben, Runner gezielt anzusteuern (Labels in GitHub, Tags in GitLab). Benenne sie nach Workloads, z. B. linux-docker, android oder macos-xcode15.

Isolation ist eine häufige Ursache für flakige Builds. Verwaiste Dateien, korrupte geteilte Caches oder Tools, die "per Hand" auf Self‑Hosted Maschinen installiert wurden, schaffen zufällige Fehler. Saubere Arbeitsbereiche, gepinnte Tool‑Versionen und geplante Runner‑Aufräumjobs zahlen sich schnell aus.

Kapazität und Berechtigungen sind weitere wiederkehrende Schmerzpunkte, besonders bei macOS‑Verfügbarkeit und Kosten. Eine gute Standardregel: Build‑Runner dürfen bauen, Deploy‑Runner dürfen deployen, und Produktions‑Zugangsdaten sollten nur in so wenigen Jobs wie möglich verfügbar sein.

Secrets und Umgebungsvariablen

Secrets sind der Punkt, an dem Multi‑App CI‑Pipelines riskant werden. Die Grundlagen sind ähnlich (Secrets auf der Plattform speichern, zur Laufzeit injizieren), aber das Scoping fühlt sich unterschiedlich an.

GitHub Actions scoped Secrets typischerweise auf Repository‑ und Organisationsebene, mit einer zusätzlichen Environment‑Ebene. Diese Environment‑Ebene ist nützlich, wenn Produktion ein manuelles Gate und eigene Werte gegenüber Staging braucht.

GitLab CI verwendet CI/CD‑Variablen auf Projekt‑, Gruppen‑ oder Instance‑Ebene. Es unterstützt ebenfalls environment‑scoped Variablen und Schutzmechanismen wie "protected" (nur auf geschützten Branches/Tags verfügbar) und "masked" (in Logs verborgen). Diese Kontrollen sind hilfreich, wenn ein Monorepo mehrere Teams bedient.

Der häufigste Fehler ist unbeabsichtigte Offenlegung: Debug‑Output, fehlgeschlagene Befehle, die Variablen ausgeben, oder ein Artefakt, das versehentlich eine Config‑Datei enthält. Behandle Logs und Artefakte standardmäßig als teilbar.

In Backend + Web + Mobile Pipelines umfassen Secrets meist Cloud‑Credentials, Datenbank‑URLs und Drittanbieter‑API‑Keys, Signaturmaterial (iOS‑Zertifikate/Profiles, Android‑Keystore und Passwörter), Registry‑Tokens (npm, Maven, CocoaPods) und Automations‑Tokens (Email/SMS‑Provider, Chat‑Bots).

Bei mehreren Umgebungen (dev, staging, prod) halte Namenskonventionen konsistent und tausche Werte per Environment‑Scope statt Jobs zu kopieren. Das macht Rotation und Zugriffskontrolle überschaubar.

Ein paar Regeln verhindern die meisten Vorfälle:

• Bevorzuge kurzlebige Credentials (z. B. OIDC zu Cloud‑Providern) statt langlebiger Schlüssel, wenn möglich.
• Verwende Least Privilege: getrennte Deploy‑Identitäten für Backend, Web und Mobile.
• Maskiere Secrets und vermeide das Ausgeben von Umgebungsvariablen, auch bei Fehlern.
• Beschränke Produktions‑Secrets auf geschützte Branches/Tags und erforderliche Reviewer.
• Speichere niemals Secrets in Build‑Artefakten, nicht einmal temporär.

Ein einfaches, wirkungsvolles Beispiel: Mobile‑Jobs sollten Signatur‑Secrets nur bei getaggten Releases erhalten, während Backend‑Deploy‑Jobs bei Merges in main ein beschränktes Deploy‑Token nutzen. Das reduziert die Blast‑Radius, falls ein Job falsch konfiguriert ist.

Caching und Artefakte für schnellere Builds

Die meisten langsamen Pipelines sind aus einem langweiligen Grund langsam: Sie laden und bauen dieselben Dinge immer wieder. Caching vermeidet wiederholte Arbeit. Artefakte lösen ein anderes Problem: die exakten Outputs eines bestimmten Runs aufzubewahren.

Was du cachest, hängt von deinem Stack ab. Backends profitieren von Dependency‑ und Compiler‑Caches (z. B. Go‑Module‑Cache). Web‑Builds profitieren von Paketmanager‑Caches und Build‑Tool‑Caches. Mobile‑Builds benötigen oft Gradle plus Android‑SDK‑Caching auf Linux und CocoaPods oder Swift‑Package‑Manager Caches auf macOS. Sei vorsichtig mit aggressivem iOS‑Build‑Output‑Caching (z. B. DerivedData), wenn du die Trade‑offs nicht verstehst.

Beide Plattformen folgen dem gleichen Muster: Cache am Anfang des Jobs wiederherstellen, am Ende aktualisierten Cache speichern. Der Alltagunterschied ist die Kontrolle. GitLab macht Cache‑ und Artefaktverhalten explizit in einer Datei inklusive Ablaufzeiten. GitHub Actions nutzt oft separate Actions fürs Caching, was flexibel, aber leichter falsch zu konfigurieren ist.

Cache‑Keys sind in Monorepos wichtiger. Gute Keys ändern sich, wenn sich die Eingaben ändern, und bleiben sonst stabil. Lockfiles (go.sum, pnpm-lock.yaml, yarn.lock usw.) sollten den Key antreiben. Es hilft auch, einen Hash des spezifischen App‑Ordners aufzunehmen statt des ganzen Repos, und separate Caches pro App zu halten, damit eine Änderung nicht alles invalidiert.

Nutze Artefakte für die Liefergegenstände, die du von genau diesem Run behalten willst: Release‑Bundles, APK/IPA‑Outputs, Testreports, Coverage‑Dateien und Build‑Metadaten. Caches sind Geschwindigkeits‑Verbesserer; Artefakte sind Aufzeichnungen.

Wenn Builds weiterhin langsam sind, suche nach zu großen Caches, Keys, die sich bei jedem Lauf ändern (Timestamps, Commit‑SHAs) und gecachten Build‑Outputs, die auf verschiedenen Runnern nicht wiederverwendbar sind.

Monorepo‑Fit: mehrere Pipelines ohne Chaos

Ein Monorepo wird unordentlich, wenn jeder Push Backend‑Tests, Web‑Builds und Mobile‑Signierung startet, obwohl nur eine README geändert wurde. Das saubere Muster ist: erkennen, was sich geändert hat, und nur die relevanten Jobs ausführen.

In GitHub Actions bedeutet das oft getrennte Workflows pro App mit Pfadfiltern, damit jeder Workflow nur läuft, wenn Dateien in seinem Bereich geändert wurden. In GitLab CI heißt das meist eine Pipeline‑Datei mit rules:changes (oder Child Pipelines) zu verwenden, die Job‑Gruppen basierend auf Pfaden erstellt oder überspringt.

Gemeinsame Pakete sind der Punkt, an dem Vertrauen bricht. Wenn packages/auth sich ändert, müssen sowohl Backend als auch Web neu gebaut werden, auch wenn ihre Ordner unverändert blieben. Behandle gemeinsame Pfade als Trigger für mehrere Pipelines und halte Abhängigkeitsgrenzen klar.

Eine einfache Trigger‑Karte, die Überraschungen reduziert:

• Backend‑Jobs laufen bei Änderungen in backend/** oder packages/**.
• Web‑Jobs laufen bei Änderungen in web/** oder packages/**.
• Mobile‑Jobs laufen bei Änderungen in mobile/** oder packages/**.
• Doku‑Änderungen führen nur schnelle Checks aus (Formatierung, Rechtschreibprüfung).

Parallelisiere, was sicher ist (Unit‑Tests, Linting, Web‑Build). Serialisiere, was kontrolliert werden muss (Deployments, App‑Store‑Releases). Sowohl GitLabs needs als auch GitHubs Job‑Dependencies helfen, schnelle Checks früh laufen zu lassen und den Rest zu stoppen, wenn sie fehlschlagen.

Halte Mobile‑Signing vom Alltags‑CI isoliert. Lege Signatur‑Keys in eine dedizierte Environment mit manueller Genehmigung und führe Signatur nur bei getaggten Releases oder in geschützten Branches aus. Pull Requests können unge‑signte Apps für die Validierung bauen, ohne sensible Credentials offenzulegen.

Schritt für Schritt: eine saubere Pipeline für Backend, Web und Mobile

Eine saubere Multi‑App‑Pipeline beginnt mit einer Namensgebung, die die Absicht klar macht. Wähle ein Muster und bleibe dabei, damit Leute Logs überfliegen können und sofort sehen, was lief.

Ein Schema, das lesbar bleibt:

• Pipelines: pr-checks, main-build, release
• Environments: dev, staging, prod
• Artefakte: backend-api, web-bundle, mobile-debug, mobile-release

Von dort halte Jobs klein und promote nur, was frühere Checks bestanden hat:

1. PR‑Checks (jeder Pull Request): Führe schnelle Tests und Linting nur für die betroffenen Apps aus. Für das Backend baue ein deploybares Artefakt (Container‑Image oder Server‑Bundle) und speichere es, damit spätere Schritte nicht nochmal bauen müssen.

2. Web‑Build (PR + main): Baue die Web‑App als statisches Bundle. In PRs halte die Ausgabe als Artefakt (oder deploye in eine Preview‑Umgebung, falls vorhanden). Auf main erzeuge ein versioniertes Bundle für dev oder staging.

3. Mobile Debug Builds (nur PRs): Baue ein Debug‑APK/IPA ohne Release‑Signatur. Ziel ist schnelles Feedback und eine Datei, die Tester installieren können.

4. Release Builds (nur Tags): Wenn ein Tag wie v1.4.0 gepusht wird, führe vollständige Backend‑ und Web‑Builds sowie signierte Mobile‑Release‑Builds durch. Erzeuge store‑fertige Outputs und bewahre Release‑Notes neben den Artefakten auf.

5. Manuelle Genehmigungen: Platziere Genehmigungen zwischen staging und prod, nicht vor grundlegenden Tests. Entwickler können Builds starten, aber nur genehmigte Rollen sollten in Produktion deployen und Produktions‑Secrets sehen.

Häufige Fehler, die Zeit kosten

Teams verlieren oft Wochen an Workflow‑Gewohnheiten, die heimlich flakige Builds erzeugen.

Eine Falle ist zu starke Nutzung geteilter Runner. Wenn viele Projekte um denselben Pool konkurrieren, bekommst du zufällige Timeouts, langsame Jobs und Mobile‑Builds, die nur Spitzenstunden scheitern. Wenn Backend, Web und Mobile wichtig sind, isoliere schwere Jobs auf dedizierten Runnern (oder zumindest getrennten Queues) und mache Ressourcenlimits explizit.

Secrets sind ein weiterer Zeitfresser. Mobile Signatur‑Keys und Zertifikate werden leicht falsch gehandhabt. Ein häufiger Fehler ist, sie zu breit zu speichern (verfügbar für jeden Branch und Job) oder sie durch ausführliche Logs zu leaken. Halte Signaturmaterial auf geschützte Branches/Tags beschränkt und vermeide jeden Schritt, der geheime Werte ausgibt (auch base64‑Strings).

Caching kann nach hinten losgehen, wenn Teams riesige Verzeichnisse cachen oder Caches und Artefakte verwechseln. Cache nur stabile Eingaben. Bewahre Outputs, die du später brauchst, als Artefakte auf.

Schließlich verbraucht in Monorepos das Auslösen jeder Pipeline bei jeder Änderung Minuten und Geduld. Wenn jemand eine README ändert und du iOS, Android, Backend und Web rebuildest, hören Leute auf, CI zu vertrauen.

Eine kurze Checkliste hilft:

• Nutze pfadbasiertes Triggern, damit nur betroffene Apps laufen.
• Trenne Test‑Jobs von Deploy‑Jobs.
• Halte Signatur‑Keys für Release‑Workflows eingeschränkt.
• Cache kleine, stabile Eingaben, nicht ganze Build‑Ordner.
• Plane vorhersehbare Runner‑Kapazität für schwere Mobile‑Builds.

Schnelle Prüfungen, bevor du dich für eine Plattform entscheidest

Bevor du wählst, mach ein paar Checks, die widerspiegeln, wie ihr tatsächlich arbeitet. Sie retten dich davor, ein Tool zu wählen, das für eine App gut aussieht, aber schmerzhaft wird, sobald Mobile‑Builds, mehrere Umgebungen und Releases hinzukommen.

Konzentriere dich auf:

• Runner‑Plan: Hosted, Self‑Hosted oder gemischt. Mobile‑Builds treiben Teams oft zu einem Mix, weil iOS macOS braucht.
• Secrets‑Plan: Wo Secrets leben, wer sie lesen kann und wie Rotation funktioniert. Produktion sollte strenger sein als Staging.
• Cache‑Plan: Was du cachest, wo es gespeichert wird und wie Keys gebildet werden. Wenn der Key bei jedem Commit ändert, zahlst du ohne Speed‑Nutzen.
• Monorepo‑Plan: Pfadfilter und ein sauberer Weg, gemeinsame Schritte (Lint, Tests) zu teilen, ohne Copy‑Paste.
• Release‑Plan: Tags, Genehmigungen und Umgebungstrennung. Sei explizit, wer in Produktion promoten darf und welchen Nachweis sie brauchen.

Teste diese Antworten mit einem kleinen Szenario. In einem Monorepo mit einem Go‑Backend, einer Vue‑Web‑App und zwei Mobile‑Apps: Eine Doku‑Änderung sollte fast nichts anstoßen; eine Backend‑Änderung sollte Backend‑Tests und ein API‑Artefakt auslösen; eine Mobile‑UI‑Änderung sollte nur Android und iOS bauen.

Wenn du diesen Flow nicht auf einer Seite beschreiben kannst (Trigger, Caches, Secrets, Genehmigungen), mache eine einwöchige Pilotphase auf beiden Plattformen mit demselben Repo. Wähle das, das langweilig und vorhersehbar wirkt.

Beispiel: realistischer Monorepo‑Build‑ und Release‑Flow

Stell dir ein Repo mit drei Ordnern vor: backend/ (Go), web/ (Vue) und mobile/ (iOS und Android).

Im Alltag willst du schnelles Feedback. Bei Releases willst du vollständige Builds, Signierung und Publish‑Schritte.

Eine praktische Aufteilung:

• Feature‑Branches: Führe Lint & Unit‑Tests für die geänderten Teile aus, baue Backend und Web und optional ein Android‑Debug‑Build. iOS überspringen, außer es ist wirklich nötig.
• Release‑Tags: Führe alles aus, erstelle versionierte Artefakte, signiere Mobile‑Apps und pushe Images/Binaries in deinen Release‑Storage.

Die Runner‑Wahl verschiebt sich, sobald Mobile ins Spiel kommt. Go‑ und Vue‑Builds laufen problemlos auf Linux. iOS erfordert macOS‑Runner, was die Entscheidung oft stärker beeinflusst als alles andere. Wenn dein Team volle Kontrolle über Build‑Maschinen will, kann GitLab CI mit Self‑Hosted Runnern einfacher als Flotte zu betreiben sein. Wenn du weniger Ops‑Arbeit und schnelles Setup bevorzugst, sind GitHub Hosted Runner praktisch, aber macOS‑Minuten und Verfügbarkeit müssen geplant werden.

Caching spart echte Zeit, aber der beste Cache unterscheidet sich per App. Für Go: Module‑Downloads und Build‑Cache cachen. Für Vue: Paketmanager‑Store cachen und nur rebuilden, wenn Lockfiles ändern. Für Mobile: Gradle und Android‑SDK auf Linux cachen; CocoaPods oder SwiftPM auf macOS cachen; erwarte größere Caches und mehr Invalidierung.

Eine Entscheidungsregel: Wenn dein Code bereits auf einer Plattform gehostet ist, starte dort. Wechsel nur, wenn Runner (insbesondere macOS), Berechtigungen oder Compliance dich zwingen.

Nächste Schritte: wählen, standardisieren und sicher automatisieren

Wähle das Tool, das zu eurem Code und euren Leuten passt. Meist zeigt sich der Unterschied in täglicher Reibung: Reviews, Berechtigungen und wie schnell jemand einen broken Build diagnostiziert.

Starte einfach: eine Pipeline pro App (Backend, Web, Mobile). Sobald stabil, ziehe gemeinsame Schritte in wiederverwendbare Templates, um Copy‑Paste zu reduzieren ohne Ownership zu verwischen.

Schreibe Secret‑Scopes auf, wie du aufschreiben würdest, wer den Schlüssel zum Büro hat. Produktions‑Secrets sollten nicht von jedem Branch gelesen werden können. Setze eine Rotationserinnerung (vierteljährlich ist besser als nie) und vereinbare, wie Notfall‑Widerrufe funktionieren.

Wenn du mit einem No‑Code‑Generator arbeitest, der echten Quellcode erzeugt, behandle Generierung/Export als erstklassigen CI‑Schritt. Zum Beispiel generiert AppMaster (appmaster.io) Go‑Backends, Vue3‑Web‑Apps und Kotlin/SwiftUI‑Mobile‑Apps; deine Pipeline kann Code bei Änderung neu erzeugen und dann nur die betroffenen Ziele bauen.

Wenn du einen Flow hast, dem dein Team vertraut, mache ihn zum Standard für neue Repos und halte ihn langweilig: klare Trigger, vorhersehbare Runner, enge Secrets und Releases, die nur laufen, wenn du es wirklich willst.