Monorepo vs Polyrepo: Web, Mobile und Backend synchron halten

Das eigentliche Problem: Änderungen über drei Codebasen ausliefern

Teams streiten nicht wegen Git-Philosophie über Monorepo vs Polyrepo. Sie streiten, weil eine kleine Produktänderung in drei getrennte Änderungen für Web, Mobile und Backend ausartet und dabei etwas kaputtgeht.

Was zuerst kaputtgeht, ist selten die UI. Meist ist es der unsichtbare Klebstoff: ein API-Vertrag wurde geändert, ohne dass eine passende Anpassung erfolgte, eine geteilte Bibliothek wurde an einer Stelle aktualisiert, an einer anderen nicht, oder die Build-Pipeline braucht plötzlich einen neuen Schritt. Wenn ein Teil früher ausgeliefert wird als die anderen, merken Nutzer das als Fehler wie „der Button ist im Web da, aber die Mobile-App sagt nicht unterstützt“ oder „die App lädt ewig, weil sich die Backend-Antwort geändert hat."

Web, Mobile und Backend laufen außerdem mit unterschiedlichen Release-Uhren. Web kann oft mehrmals am Tag liefern. Backend kann häufig deployen, braucht aber eine vorsichtige Rollout-Strategie. Mobile ist am langsamsten, weil App-Store-Review und Nutzer-Updates real Zeit kosten. Eine „einfache“ Änderung wie das Umbenennen eines Felds kann dich dazu zwingen, dich nach der langsamsten Spur zu richten, selbst wenn nur ein Bildschirm das neue Feld braucht.

Du zahlst wahrscheinlich eine Art Repo-Koordinations-Steuer, wenn diese Probleme häufiger auftreten:

• Breaking-API-Änderungen werden erst nach dem Merge entdeckt.
• Versionen stimmen nur mit manuellen Erinnerungen und Tabellen überein.
• Ein Feature braucht mehrere koordinierte Pull Requests, die aufeinander warten.
• CI ist langsam, weil es viel mehr baut und testet als nötig.
• Rollbacks sind riskant, weil unklar ist, welcher Commit zu welchem Release gehört.

Teamgröße und Produktreife beeinflussen die richtige Antwort. Früh gewinnen die meisten Teams, indem sie Koordination günstig und Sichtbarkeit hoch halten, auch wenn es etwas chaotisch ist. Mit Wachstum werden Grenzen wichtiger — aber nur, wenn Schnittstellen stabil und Verantwortlichkeiten klar sind.

Wenn jede sinnvolle Änderung an drei Orten landen muss, wirst du diese Steuer auf die eine oder andere Weise zahlen. Die Repo-Strategie bestimmt hauptsächlich, wie du sie zahlen willst.

Monorepo und Polyrepo einfach erklärt

Ein Repo ist einfach der Ort, an dem dein Code lebt — inklusive Historie. Bei Web, Mobile und Backend ist die Wahl klar: alles zusammenhalten oder aufteilen.

Ein Monorepo ist ein einziges Repository, das mehrere Apps und oft auch geteilten Code enthält. Web, iOS/Android, Backend-Services und Shared-Libraries liegen nebeneinander.

Ein Polyrepo ist das Gegenteil: jede App (und manchmal jeder Service) hat ein eigenes Repository. Gemeinsamer Code wird dann meist als Paket ausgelagert oder Teams kopieren kleine Teile bei Bedarf.

Im Alltag fühlt sich ein Monorepo oft so an: Code teilen ist einfach, Änderungen über Apps hinweg können in einem Pull Request passieren und Regeln sind konsistent. Der Nachteil ist sozial: Ownership kann verschwimmen, wenn man keine klaren Grenzen setzt, und repo-weite Prüfungen können streng wirken.

Polyrepos fühlen sich meist so an: Teams bewegen sich unabhängig, Repos bleiben fokussiert und Zugriffsregeln sind einfacher. Der Nachteil ist Koordination: Code teilen braucht Planung, und cross-app Änderungen werden oft zu mehreren Pull Requests mit genauer Timings-Planung.

Viele Teams landen in einer Mischung: Apps in separaten Repos, gemeinsame Verträge an einem Ort; oder ein Monorepo mit starken Grenzen, sodass jedes Team größtenteils im eigenen Bereich bleibt.

Wenn du eine Plattform nutzt, die Backend, Web und Mobile aus einer einzigen Quelle erzeugt, reduzierst du Drift, weil Verträge und Logik zusammen leben. AppMaster (appmaster.io) zum Beispiel generiert produktionsreife Backend-, Web- und native Mobile-Apps aus einem Modell. Das beseitigt nicht die Release-Realitäten (Mobile bleibt langsamer), kann aber viel „haben wir alle drei aktualisiert?“-Aufwand sparen.

Abhängigkeitsmanagement: Gemeinsamen Code sicher halten

Geteilter Code kostet Teams Zeit — unabhängig vom Repo-Layout. Eine kleine Änderung in einer Shared-Library oder einem API-Vertrag kann Web-Builds, Mobile-Releases und Backend-Deploys auf unterschiedliche Weise brechen.

Wenn du Bibliotheken teilst (UI-Komponenten, Validierungsregeln, Auth-Helfer), entscheidest du dich zwischen einer Version für alle oder mehreren Versionen über die Zeit.

• Eine gemeinsame Version ist einfacher und vermeidet Überraschungen „funktioniert in meinem Branch".
• Mehrere Versionen lassen Teams in ihrem Tempo bewegen, schaffen aber Unordnung und erschweren Security-Fixes.

API-Clients und Schemas verdienen besondere Sorgfalt. Manuelle Updates sind langsam und fehleranfällig. Besser ist: behandel das API-Schema als Quelle der Wahrheit und generiere Clients daraus, diese entweder einchecken oder in CI erzeugen. Ziel ist schnell zu scheitern: Wenn das Backend ein Pflichtfeld hinzufügt, sollte der Mobile-Client im Build fehlschlagen und nicht drei Tage später in QA.

Breaking Changes breiten sich aus, wenn Verhalten ohne sicheren Übergang geändert wird. Bevorzuge additive Änderungen (neue Felder, neue Endpunkte) und depreziere später. Wenn du etwas brechen musst, nutze versionierte Endpunkte oder ein kurzes Kompatibilitätsfenster.

Konkretes Beispiel: Das Backend benennt status zu state um. Wenn Web heute aktualisiert, Mobile aber erst in einer Woche liefern kann, muss das Backend beide Felder für diese Woche akzeptieren oder einen Adapter ausrollen, der altes Feld auf das neue mappt.

Ein paar Regeln, die Abhängigkeits-Updates langweilig (im guten Sinne) halten:

• Aktualisiere nach einem Rhythmus. Kleine wöchentliche Updates sind besser als große vierteljährliche.
• Erfordere explizite Zustimmung für breaking changes und eine kurze Migrationsnotiz.
• Automatisiere Prüfungen: Dependency-Bumps, Client-Generierung und einfache Vertrags-Tests.
• Definiere „done“ als „Web-, Mobile- und Backend-Builds sind grün“, nicht nur „mein Repo ist grün".

Generierter Code kann Drift reduzieren, ersetzt aber keine Disziplin. Du brauchst weiterhin einen Vertrag, klare Deprecations und vorhersagbare Updates.

Release-Koordination: Web, Mobile und Backend in Einklang bringen

Release-Koordination ist der Punkt, an dem Repo-Strategie praktisch wird. Wenn das Backend ein API-Feld umbenennt, kann die Web-App meist am selben Tag aktualisiert werden. Mobile-Apps sind anders: App-Store-Review und Nutzer-Updates können eine kleine Abweichung in eine Woche voller Support-Tickets verwandeln.

Das praktische Ziel ist einfach: Eine Nutzeraktion sollte funktionieren, egal welcher Teil zuerst updated wurde. Das heißt, plane für gemischte Versionen, statt perfekte Synchronisation zu erwarten.

Versionsmuster, die Teams tatsächlich nutzen

Die meisten Teams finden sich in einer dieser Ansätze wieder:

1. Ein gemeinsamer Release-Zug: Web, Mobile und Backend werden als eine versionierte Einheit ausgeliefert.

2. Pro-Service-Versionierung mit Kompatibilitätsregeln: Jede App/Service hat eigene Versionen, und das Backend unterstützt einen definierten Bereich von Client-Versionen.

Ein gemeinsamer Release-Zug wirkt ordentlich, bricht aber oft bei Mobile-Verzögerungen zusammen. Pro-Service-Versionen sind auf dem Papier unordentlicher, passen dafür zur Realität. Wenn du pro Service gehst, schreib eine Regel auf und setze sie durch: welche Backend-Versionen welche Mobile-Versionen wie lange unterstützen.

Mobile-Verzögerungen beeinflussen auch Hotfixes. Backend-Hotfixes gehen schnell raus; Mobile-Hotfixes erreichen Nutzer vielleicht erst nach Tagen. Bevorzuge serverseitige Fixes, die alte Mobile-Builds weiterhin funktionsfähig halten. Wenn der Client geändert werden muss, nutze Feature-Flags und entferne alte Felder erst, wenn die meisten Nutzer aktualisiert haben.

Beispiel: Du fügst „Lieferinstruktionen" zur Bestellung hinzu. Das Backend nimmt ein neues optionales Feld an, Web zeigt es sofort, Mobile kommt im nächsten Sprint. Wenn das Backend alte Requests akzeptiert und das Feld optional lässt, funktioniert alles weiter, während Mobile nachzieht.

Wer besitzt den Release-Kalender

Koordination scheitert, wenn „alle es besitzen" — dann besitzt es niemand. Der Owner kann ein Tech Lead, Release Manager oder ein Product Manager mit Engineering-Unterstützung sein. Aufgabe ist, Überraschungen zu verhindern, indem Release-Erwartungen sichtbar und konsistent gehalten werden.

Er braucht keinen komplexen Prozess. Sondern ein paar wiederholbare Gewohnheiten: ein einfacher Release-Kalender mit Cutoffs und Freeze-Fenstern, ein schneller cross-team Check vor API-Änderungen und ein klarer Plan für den Fall, dass Mobile verzögert ist (Backend zurückhalten vs Kompatibilität behalten).

Wenn dein Workflow Backend, Web und Mobile aus einem Modell erzeugt, brauchst du trotzdem einen Release-Owner. Du wirst seltener „haben wir alle drei Orte aktualisiert?“-Momente haben, aber das Mobile-Timing bleibt bestehen.

CI-Zeit unter Kontrolle halten

CI wird langsam aus denselben Gründen: Du baust zu viel, installierst Abhängigkeiten wiederholt und führst jede Änderung gegen die gesamte Test-Suite.

Häufige Zeitfresser sind komplette Builds bei kleinen Änderungen, fehlende Caches, Tests, die alles laufen lassen, und serielle Jobs, die parallel laufen könnten.

Beginne mit Verbesserungen, die überall helfen:

• Cache Abhängigkeitsdownloads und Build-Artefakte.
• Führe Lint, Unit-Tests und Builds parallel aus, wo möglich.
• Trenne schnelle Checks (bei jedem Commit) von langsameren Checks (Main-Branch, Nightly oder vor Releases).

Monorepo-Taktiken, die helfen

Monorepos werden schmerzhaft, wenn jeder Commit eine "build the world"-Pipeline auslöst. Die Lösung ist, nur das zu bauen und zu testen, was von der Änderung betroffen ist.

Nutze Pfadfilter und ein affected-only-Vorgehen: Wenn du mobile UI-Code geändert hast, baue nicht die Backend-Images. Wenn eine Shared-Library geändert wurde, baue und teste nur die Apps, die davon abhängen. Viele Teams formalisieren das mit einem einfachen Abhängigkeitsgraphen, damit CI entscheiden kann statt zu raten.

Polyrepo-Taktiken, die Drift verhindern

Polyrepos können schnell sein, weil jedes Repo kleiner ist, aber sie verschwenden oft Zeit durch Duplikation und inkonsistente Tooling.

Halte ein gemeinsames Set an CI-Templates (gleiche Schritte, gleiche Caches, gleiche Konventionen), damit nicht jedes Repo die Pipeline neu erfindet. Pin Toolchains (Runtime-Versionen, Build-Tools, Linter), um Überraschungen "funktioniert in einem Repo" zu vermeiden. Wenn Dependency-Downloads der Flaschenhals sind, richte geteilte Caches oder interne Mirrors ein.

Konkretes Beispiel: Ein Feature fügt ein neues Feld status hinzu. Backend ändert sich, Web zeigt es, Mobile zeigt es. In einem Monorepo sollte CI Backend-Tests und nur die Web- und Mobile-Teile ausführen, die den API-Client nutzen. In einer Polyrepo-Umgebung sollte jedes Repo schnelle Checks laufen lassen und eine separate Integrationspipeline prüfen, ob die drei Releases zusammenpassen.

Wenn du Quellcode exportierst und eigene CI ausführst, gilt dieselbe Regel: Baue nur, was sich geändert hat, nutze Caches aggressiv und reserviere langsame Checks für Zeiten, in denen sie echten Mehrwert bringen.

Schritt für Schritt: Eine Repo-Strategie wählen, die zu deinem Team passt

Die Entscheidung fällt leichter, wenn du vom Alltag aus startest statt von Ideologie.

1) Schreib auf, was zusammen geändert werden muss

Wähle 5–10 kürzliche Features und notiere, was synchron laufen musste. Markiere, ob jedes UI-Bildschirme, API-Endpunkte, Datentabellen, Auth-Regeln oder Validierungen betroffen hat. Wenn die meisten Features koordinierte Änderungen in allen drei Bereichen brauchen, wird eine Aufteilung schmerzhaft sein, außer dein Release-Prozess ist sehr diszipliniert.

2) Verfolge gemeinsamen Code und Entscheidungen

Geteilter Code ist nicht nur Bibliotheken — es sind Verträge (API-Schemas), UI-Patterns und Geschäftsregeln. Notiere, wo diese heute liegen, wer sie ändert und wie Änderungen genehmigt werden. Wenn Teile zwischen Repos kopiert werden, ist das ein Zeichen, dass du engere Kontrolle brauchst — entweder durch ein Monorepo oder strikte Versionierungsregeln.

3) Definiere Grenzen und Owner

Entscheide, was die Einheiten sind (Apps, Services, Libraries) und weise jeweils einen Owner zu. Grenzen sind wichtiger als das Repo-Layout. Ohne Owner wird ein Monorepo laut; ohne Owner wird ein Polyrepo unverbunden.

Wenn du eine einfache Checkliste willst: ein Repo oder Ordner pro deployable Service/App, ein Ort für gemeinsame Verträge, ein Ort für wirklich geteilte UI-Komponenten, eine klare Regel, wo Geschäftslogik lebt, und ein dokumentierter Owner für jedes Stück.

4) Wähle ein Release-Modell, dem ihr folgen könnt

Wenn Mobile-Deploys hinterherhinken, brauchst du einen Kompatibilitätsplan (versionierte APIs, rückwärtskompatible Felder oder eine definierte Support-Zeit). Wenn wirklich alles zusammen ausgeliefert werden muss, kann ein Release-Train funktionieren — erhöht aber die Koordination.

Halte Branching-Regeln langweilig: kurzlebige Branches, kleine Merges und ein klarer Hotfix-Pfad.

5) Entwerfe CI um die häufigen Änderungen herum

Entwerfe CI nicht für den schlimmstmöglichen Fall am ersten Tag. Entwirf sie für das, was die Leute jeden Tag tun.

Wenn die meisten Commits nur Web-UI betreffen, führe standardmäßig Web-Lint und Unit-Tests aus und laufe vollständige End-to-End-Tests nur nach Zeitplan oder vor Releases. Wenn API-Drift die meisten Vorfälle verursacht, investiere zuerst in Contract-Tests und Client-Generierung.

Beispiel: Ein Feature, das Web, Mobile und Backend berührt

Stell dir ein kleines Team vor, das drei Dinge baut: ein Kundenportal (Web), eine Feld-App (Mobile) und eine API (Backend). Die Aufgabe: ein neues Feld „Service status" zu Jobs hinzufügen und überall anzeigen.

Die Änderung klingt klein, ist aber ein Koordinationstest. Backend fügt das Feld hinzu und aktualisiert Validierung und Antworten. Web zeigt es und aktualisiert Filter. Mobile muss es offline anzeigen, synchronisieren und Randfälle behandeln.

Das eigentliche Problem: Die API-Änderung ist breaking. Der Feldname ändert sich von status zu service_status, und alte Clients crashen, wenn sie es nicht handhaben.

Was ein Monorepo verändert

Hier wirkt ein Monorepo oft ruhiger. Backend-, Web- und Mobile-Updates können in einem Pull Request landen (oder in einem koordinierten Satz von Commits). CI kann betroffene Tests laufen lassen, und du kannst einen Release taggen, der alle drei Updates enthält.

Das Hauptrisiko ist sozial, nicht technisch: Ein Repo macht es leicht, einen breaking change schnell zu mergen, daher müssen Review-Regeln stark sein.

Was ein Polyrepo verändert

Mit separaten Repos leben Apps nach ihrem eigenen Zeitplan. Backend könnte zuerst deployen, und Web sowie Mobile hetzen hinterher. Wenn Mobile-App-Updates App-Store-Review brauchen, kann die „Reparatur" Tage dauern, obwohl der Code klein ist.

Teams lösen das meist mit mehr Struktur: versionierte Endpunkte, rückwärtskompatible Antworten, längere Deprecation-Phasen und klarere Rollout-Schritte. Es funktioniert, ist aber ein andauernder Aufwand.

Wenn du nach Beweisen entscheidest, schau dir die letzten Monate an:

• Kommen Vorfälle oft durch nicht übereinstimmende Versionen? Dann bevorzuge engere Koordination.
• Sind Releases häufig und zeitkritisch (besonders Mobile)? Dann vermeide breaking changes oder zentralisiere sie.
• Arbeiten Teams unabhängig und greifen selten dieselben Features an? Dann könnte der Overhead eines Polyrepos es wert sein.

Häufige Fehler und Fallstricke

Die meisten Teams scheitern nicht, weil sie die „falsche" Repo-Struktur wählen. Sie scheitern, weil Alltagsgewohnheiten langsam Reibung aufbauen, bis jede Änderung riskant wirkt.

Shared Code wird Müllhalde

Eine Shared-Library ist verlockend: Helfer, Typen, UI-Stücke, „temporäre" Workarounds. Bald wird es der Ort, an dem alter Code versteckt wird, und niemand weiß, was sicher zu ändern ist.

Halte Shared-Code klein und strikt. „Shared" sollte bedeuten: von vielen Teams genutzt, sorgfältig geprüft und mit Absicht geändert.

Enge Kopplung durch versteckte Annahmen

Auch in separaten Repos entsteht enge Kopplung — sie verlagert sich in Annahmen: Datumsformate, Enum-Werte, Berechtigungsregeln und „dieses Feld ist immer vorhanden".

Beispiel: Mobile behandelt status = 2 als „Approved", Web als „Confirmed", Backend ändert die Enum-Reihenfolge — und alles bricht so, dass es zufällig wirkt.

Vermeide das durch dokumentierte Verträge (was ein Feld bedeutet, welche Werte erlaubt sind) und behandle sie wie Produktregeln, nicht als Trivia.

Unklare Ownership

Wenn jeder alles ändern kann, werden Reviews oberflächlich und Fehler schlüpfen durch. Wenn niemand verantwortlich ist, liegen Bugs wochenlang herum.

Definiere Owner für Web, Mobile, Backend und Shared-Module. Ownership blockiert nicht Beiträge — sie sorgt dafür, dass Änderungen die richtigen Augen bekommen.

CI wächst ohne Beschneidung

CI startet klein, dann fügt jeder Vorfall einen neuen Job „nur zur Sicherheit" hinzu. Monate später ist es langsam und teuer, und Leute meiden es.

Eine einfache Regel hilft: Jeder CI-Job braucht einen klaren Zweck und einen Owner; er sollte entfernt werden, wenn er keine echten Probleme mehr findet.

Warnsignale für Aufräumbedarf sind doppelte Tests über Jobs hinweg, Jobs, die tagelang rot bleiben, „schnelle Änderungen", die länger zur Verifikation brauchen als zum Bauen, und Pipelines, die Mobile-Builds bei reinen Backend-Änderungen triggern.

Release-Koordination beruht auf tribal knowledge

Wenn Releases davon abhängen, dass eine Person die richtige Reihenfolge und geheime Fallstricke kennt, lieferst du langsamer und brichst öfter.

Schreibe Release-Schritte auf, mache sie wiederholbar und automatisiere langweilige Prüfungen. Selbst wenn dein Tooling konsistente Backends und Clients erzeugt, brauchst du klare Release-Regeln.

Schnelle Checks, bevor du dich für Monorepo oder Polyrepo entscheidest

Bevor du Repos neu organisierst, überprüfe, wie dein Team heute liefert. Ziel ist nicht perfekte Struktur, sondern weniger Überraschungen, wenn eine Änderung Web, Mobile und Backend berührt.

Stelle fünf Fragen:

• Unabhängiges Ausliefern: Kannst du einen Backend-Fix ausliefern, ohne am selben Tag ein Mobile-Update zu erzwingen?
• API-Change-Regeln: Habt ihr einen schriftlichen Vertrag für Deprecations und wie lange altes Verhalten unterstützt wird?
• Shared-Code-Disziplin: Werden Shared-Libraries (UI-Komponenten, API-Clients, Geschäftsregeln) konsistent geprüft und versioniert?
• CI, das Relevantes läuft: Kann CI erkennen, was sich geändert hat, und nur betroffene Builds/Tests ausführen?
• Eine Release-Übersicht: Gibt es einen Ort, an dem man sieht, was über Web, Mobile und Backend rausgeht, mit Ownern und Daten?

Ein einfaches Beispiel: Ein neues Feld „address" wird zur Checkout-API hinzugefügt. Wenn das Backend zuerst deployed, sollte die alte Mobile-App weiter funktionieren. Das heißt meist: die API akzeptiert sowohl altes als auch neues Payload für eine Weile, und Client-Updates sind optional, nicht zwingend.

Nächste Schritte: Koordinationsaufwand reduzieren und mit Zuversicht liefern

Das Ziel ist nicht das „richtige" Repo-Layout, sondern weniger Übergaben, weniger Überraschungen und weniger „welche Version läuft gerade?"-Momente.

Schreibe eine kurze Entscheidungsaufzeichnung: Warum ihr den aktuellen Ansatz gewählt habt, was ihr verbessern wollt und welche Kompromisse ihr akzeptiert. Überprüft das alle 6–12 Monate oder früher, wenn Teamgröße oder Release-Takt sich ändern.

Bevor du Dateien verschiebst, wähle die kleinste Änderung, die echten Schmerz nimmt:

• Führe Versionierungsregeln für Shared-Pakete ein und befolge sie.
• Definiere API-Verträge und prüfe sie mit Contract-Tests in CI.
• Einigt euch auf eine gemeinsame Release-Checklist für Web, Mobile und Backend.
• Nutze Preview-Umgebungen für Änderungen, die mehrere Teile berühren.
• Setze CI-Zeitbudgets (z. B.: PR-Checks unter 15 Minuten).

Wenn Kopplung zwischen Codebasen der echte Engpass ist, kann es mehr bringen, die Anzahl der Orte zu reduzieren, die sich ändern müssen, als nur das Repo-Layout zu wechseln. Manche Teams tun das, indem sie mehr Logik und Datenmodellierung in eine einzige Quelle der Wahrheit verschieben.

Wenn du diesen Ansatz erkunden willst: AppMaster (appmaster.io) ist gebaut, um Backend-Services, Web-Apps und native Mobile-Apps mit gemeinsamen Datenmodellen und Geschäftslogik zu generieren. Ein risikoarmer Weg, es zu evaluieren, ist ein kleines internes Tool zuerst zu bauen und dann zu entscheiden, basierend auf wie viel Koordinationsarbeit dadurch entfällt.

Der sichere Weg ist bewusst unspektakulär: Dokumentiere die Entscheidung, reduziere Kopplung, automatisiere Prüfungen und ändere die Repo-Struktur nur, wenn die Zahlen zeigen, dass es hilft.