So richten Sie CI/CD und automatisierte Tests für ein React SPA Monorepo ein

Die meisten Teams bekommen die Monorepo-Struktur am ersten Tag richtig hin und kämpfen dann die nächsten sechs Monate mit dem Release-Prozess. Ein sauberes Workspace-Layout schützt Sie nicht vor fehlerhaften Merges, verschwendeten CI-Minuten durch den Rebuild unveränderter Apps oder Produktions-Deploys, die die Verifizierung überspringen. Was wirklich zählt, ist das Monorepo in ein zuverlässiges Release-System mit automatisierter Validierung, umgebungsbewussten Deploy-Regeln und wiederholbaren End-to-End-Tests zu verwandeln.

Dieses Tutorial ist der praktische Begleiter zu React SPA Monorepo CI/CD: So automatisieren Sie Tests und deployen nur, was sich geändert hat. Es führt durch die vollständige Pipeline des react-spa-monorepo-cicd-Repositorys: wie Pull Requests validiert werden, wie Checks nach dem Merge auf Staging und Main erneut laufen, wie nur geänderte Apps deployt werden und wie Playwright E2E-Tests und Post-Deploy-Health-Checks fehlerhafte Releases reduzieren. Am Ende haben Sie einen funktionierenden CI/CD-Ablauf vom Feature-Branch bis zur Produktion, mit jedem Gate dokumentiert.

Bevor Sie beginnen, klonen Sie das Repo:

git clone https://github.com/InkByteStudio/react-spa-monorepo-cicd.git
cd react-spa-monorepo-cicd

Schritt 1: Den React SPA Monorepo CI/CD-Ablauf abbilden

Bevor Sie eine Konfiguration anfassen, verstehen Sie den vollständigen Release-Pfad. Die Kernidee dieses Repositorys ist nicht „mehrere Apps in einem Ordner”. Es ist „mehrere Apps mit einem kontrollierten Pfad von der Code-Änderung bis zum Deploy”. Die Pipeline erkennt Änderungen, führt Validierungs-Gates aus, führt E2E-Tests aus, deployt nur geänderte Apps und schließt mit einem Health-Check ab.

Trigger-Punkte verstehen

Die Pipeline hat drei Haupteinstiegspunkte, jeweils mit einem bestimmten Zweck:

1. Pull Request auf Main oder Staging — validiert die vorgeschlagene Änderung während des Code-Reviews
2. Push auf Staging — re-validiert das Merge-Ergebnis und deployt in die Staging-Umgebung
3. Push auf Main — re-validiert erneut und deployt in die Produktion

Tests laufen absichtlich nach dem Merge erneut. Ein Pull Request validiert den Branch isoliert, aber der gemergte Zustand kann sich durch Konflikte oder gleichzeitige Änderungen anderer Contributor unterscheiden. Post-Merge-Validierung auf Staging oder Main stellt sicher, dass der exakt gemergte Code noch jedes Gate besteht, bevor etwas deployt wird.

Dem Branch-Promotionsmodell folgen

Das Repository erzwingt einen linearen Promotionspfad:

1. An einem Feature-Branch arbeiten
2. Einen Pull Request öffnen — CI validiert Formatierung, Linting, Typen, Unit-Tests, Build, Security-Audit und E2E
3. In staging mergen für ein Pre-Production-Deploy
4. Das Staging-Deployment manuell oder mit automatisierten Smoke-Tests verifizieren
5. staging in main mergen für das Produktions-Deploy
6. Post-Deploy-Health-Checks bestätigen, dass das Release live und gesund ist

Verstehen, warum selektive Deploys wichtig sind

Das Monorepo enthält drei deploybare Ziele: eine statische Marketing-Hauptseite, eine Admin-SPA und eine Portal-SPA. Ohne Änderungserkennung würde jeder Push alle drei neu bauen und deployen, selbst wenn sich nur eine Datei geändert hat. Dieses Repository nutzt intelligente Änderungserkennung, sodass ein Commit, der apps/admin-spa/ berührt, nur den Build und das Deploy der Admin-SPA auslöst. Änderungen unter packages/, das gemeinsamen Code enthält, lösen Rebuilds für beide SPA-Apps aus, da sie diese Abhängigkeiten teilen. Die Hauptseite ist unabhängig.

Sie sollten jetzt verstehen, wann diese Pipeline Code validiert, wann sie deployt und warum sie Checks nach dem Merge erneut ausführt.

Schritt 2: Die vollständige Validierungs-Pipeline lokal ausführen

Der schnellste Weg, eine CI/CD-Pipeline zu verstehen, ist sie auf Ihrem eigenen Rechner auszuführen, bevor Sie einen Branch pushen. Das hält Feedback-Schleifen kurz und verhindert verschwendete CI-Minuten für Commits, die nie bestanden hätten.

Erforderliche Tools installieren

Bestätigen Sie, dass Sie die dokumentierten Voraussetzungen haben:

node -v    # Sollte v22.x ausgeben
pnpm -v    # Sollte 10.x oder neuer ausgeben
docker -v  # Sollte Docker version 27.x oder neuer ausgeben

Dann installieren Sie die Abhängigkeiten:

corepack enable
pnpm install

Lokale Pipeline ausführen

Das Repository stellt einen einzelnen Befehl bereit, der den vollständigen CI-Validierungsablauf reproduziert:

bash scripts/run-all.sh

Dieses Skript führt jede Validierungsstufe der Reihe nach aus und gibt am Ende eine Zusammenfassung mit Bestanden/Nicht-bestanden aus. Es ist das Nächste an einem lokalen Preflight-Check. Wenn dieser Befehl besteht, können Sie relativ sicher sein, dass auch CI bestehen wird.

Validierungskategorien verstehen

Die Pipeline erzwingt sieben Kategorien von Prüfungen, in dieser Reihenfolge:

1. Format-Check — Prettier stellt konsistenten Code-Stil sicher
2. Lint — ESLint erkennt Code-Qualitätsprobleme und potenzielle Bugs
3. Type-Check — Der TypeScript-Compiler verifiziert Typkorrektheit über alle Packages hinweg
4. Unit-Tests — Vitest führt schnelle, isolierte Komponenten- und Utility-Tests aus
5. Build — Vite kompiliert jede App zu produktionsreifen statischen Assets
6. Security-Audit — Abhängigkeits-Schwachstellen-Scanning markiert bekannte CVEs
7. E2E-Tests — Playwright führt Browser-Level-Tests gegen die gebauten Apps aus

Führen Sie den vollständigen Befehl erfolgreich aus, bevor Sie fortfahren. Sie sollten jetzt eine lokale Möglichkeit haben, die gleichen Prüfungskategorien zu reproduzieren, die der CI-Server durchsetzt.

Schritt 3: Automatisierte Test-Gates konfigurieren

Dieser Schritt ist das Herzstück der Pipeline. Das Ziel ist nicht nur, Jobs zu haben, die laufen, sondern zu verstehen, warum sie in dieser Reihenfolge angeordnet sind und wovor jedes Gate schützt.

Gates nach Zweck organisieren

Denken Sie an die sieben Validierungs-Gates als Testleiter mit vier Stufen:

Schnelle Feedback-Gates erkennen triviale Probleme in Sekunden:

pnpm format:check    # Prettier-Formatierung
pnpm lint            # ESLint-Code-Qualitaet
pnpm typecheck       # TypeScript-Compiler

Vertrauens-Gates verifizieren, dass der Code funktioniert und gültige Ausgabe produziert:

pnpm test                # Unit-Tests via Vitest
pnpm build:admin-spa     # Admin-SPA bauen
pnpm build:portal-spa    # Portal-SPA bauen
pnpm build:main-site     # Hauptseite bauen

Sicherheits-Gates prüfen auf bekannte Schwachstellen (siehe CI/CD-Pipeline mit Sigstore, SLSA und SBOMs härten für weitergehende Artefakt-Signierung und Provenance):

pnpm audit    # Abhängigkeits-Sicherheitsscan

Release-Gates validieren das deployte Artefakt in einer realistischen Umgebung:

pnpm test:e2e    # Playwright-Browser-Tests

Die Reihenfolge ist wichtig. Format- und Lint-Checks kosten fast nichts in der Ausführung. Wenn sie fehlschlagen, gibt es keinen Grund, Zeit mit dem Build von drei Apps und dem Start eines Docker-Stacks für E2E zu verbringen. Scheitern Sie früh bei günstigen Checks, damit Sie nur Ressourcen für teure Checks aufwenden, wenn die Grundlagen bereits sauber sind.

Lokale Befehle auf CI-Jobs abbilden

Jeder der obigen Befehle bildet sich direkt auf einen Job im CI-Workflow ab. Wenn Sie .github/workflows/validate-and-deploy.yml oder .gitlab-ci.yml lesen, werden Sie die gleichen Skripte in der gleichen Reihenfolge sehen. Diese Übereinstimmung zwischen lokalem und CI-Verhalten ist beabsichtigt — sie bedeutet, dass ein lokales Bestehen ein zuverlässiger Prädiktor für ein CI-Bestehen ist.

Wissen, dass lokale Commits ebenfalls geprüft werden

Das Repository erzwingt Conventional Commits durch commitlint und führt lint-staged über Husky Pre-Commit-Hooks aus. Jeder lokale Commit führt automatisch Prettier und ESLint auf gestageten Dateien aus, bevor der Commit erstellt wird. Das bedeutet, dass Formatierungs- und Lint-Probleme erkannt werden, bevor Code überhaupt gepusht wird, was Rauschen in CI reduziert.

Verstehen, warum E2E nach dem Build kommt

E2E-Tests brauchen gebaute Artefakte, gegen die sie testen können. Sie laufen nicht gegen einen Entwicklungsserver, weil Dev-Server sich anders verhalten als Produktions-Builds — sie verwenden Hot Module Replacement, überspringen bestimmte Optimierungen und liefern Assets anders aus. E2E gegen tatsächlichen Build-Output auszuführen fängt Probleme ab, die nur unter produktionsähnlichen Bedingungen auftreten.

Sie sollten jetzt eine klare Testleiter haben: statische Checks zuerst, Build-Validierung als Zweites und Browser-Level-Tests, nachdem deploybare Artefakte existieren.

Schritt 4: Playwright E2E-Tests in einer produktionsähnlichen Umgebung ausführen

E2E-Tests sind die letzte Vertrauensschicht vor dem Deploy. Dieser Schritt behandelt die exakte Abfolge, um sie lokal auszuführen, damit Sie Fehler reproduzieren und debuggen können, ohne auf CI zu warten.

Zuerst die SPAs bauen

Playwright-Tests benötigen Produktions-Build-Output. Bauen Sie beide SPAs, bevor Sie die Testumgebung starten:

pnpm build:admin-spa
pnpm build:portal-spa

Testumgebung starten

Das Repository verwendet Docker Compose mit nginx, um die gebauten Apps in einer Topologie bereitzustellen, die das Produktions-Deployment spiegelt:

docker compose -f docker/docker-compose.yml up -d

Dies startet einen nginx-Container, der die Admin-SPA und Portal-SPA auf den gleichen Pfaden bereitstellt, die sie in der Produktion belegen werden. Das bedeutet, Route-Boundaries, Asset-Pfade und Cross-App-Navigation verhalten sich alle so, wie sie es nach einem echten Deploy tun werden.

In CI verwendet die Pipeline docker/docker-compose.ci.yml als Override, der die Port-Exposition entfernt und ein isoliertes Bridge-Netzwerk erstellt. Das verhindert Port-Konflikte auf gemeinsam genutzten Runnern bei gleicher nginx-Topologie. Sie benötigen den CI-Override nicht beim lokalen Ausführen.

Playwright ausführen

Mit dem laufenden Docker-Stack führen Sie die E2E-Suite aus:

pnpm test:e2e

Das e2e/-Verzeichnis enthält Playwright-Tests, die abdecken:

• App-Laden — jede deployte SPA rendert ihre Root-Komponente
• Route-Boundaries — Client-seitiges Routing funktioniert innerhalb jeder App
• Content-Rendering — Dashboard-Elemente wie Statistik-Karten, Überschriften und Seiteninhalt werden korrekt angezeigt
• Cross-App-Navigation — Links zwischen Admin- und Portal-SPA werden ohne Fehler aufgelöst
• Visuelle Regression — Screenshots werden mit Baselines verglichen, um unbeabsichtigte UI-Änderungen zu erkennen
• Accessibility — axe-core-Checks markieren WCAG 2.0/2.1 AA-Verstöße vor dem Deploy

Sauber herunterfahren

Nach Abschluss der Tests stoppen Sie den Docker-Stack:

docker compose -f docker/docker-compose.yml down

Sie sollten jetzt in der Lage sein, die gleiche Art von Browser-Level-Validierung auszuführen, die die Pipeline vor einem Deploy verwendet.

Schritt 5: Änderungserkennung hinzufügen, damit nur betroffene Apps deployt werden

Selektives Deployment ist einer der größten praktischen Vorteile eines gut strukturierten Monorepos. Ohne es baut und deployt jeder Push alles neu, was Rechenleistung verschwendet, Feedback verlangsamt und den Blast-Radius jedes Releases vergrößert.

Das Deployment-Entscheidungsmodell verstehen

Das Repository bildet Dateiänderungen mit einfachen Regeln auf Deploy-Ziele ab:

Geänderter Pfad	Was wird deployt
apps/main-site/	Nur die Hauptseite
apps/admin-spa/	Nur die Admin-SPA
apps/portal-spa/	Nur die Portal-SPA
packages/	Beide SPAs (gemeinsame Abhängigkeit)
docs/ oder nur Markdown	Minimal validieren, Deploy überspringen

Änderungen in packages/ lösen beide SPA-Deploys aus, weil diese Packages gemeinsame Abhängigkeiten sind. Ein Bug in gemeinsam genutztem Code könnte jeden Consumer betreffen, daher müssen beide neu gebaut und getestet werden. Die Hauptseite hängt nicht von den gemeinsamen Packages ab und ist daher nicht betroffen.

Das Pivot-Skript kennen

Das Repository enthält scripts/changed-files.sh, das der Entscheidungspunkt sowohl für selektive Validierung als auch für selektives Deployment ist. Der CI-Workflow ruft dieses Skript auf, um zu bestimmen, welche Apps vom aktuellen Commit-Bereich betroffen sind, und führt dann bedingt nur die relevanten Build-, Test- und Deploy-Jobs aus.

Sie müssen dieses Skript nicht ändern, um dem Tutorial zu folgen, aber zu verstehen, dass es existiert — und dass es die einzige Wahrheitsquelle für „was hat sich geändert” ist — ist wichtig für spätere Erweiterungen der Pipeline.

Den Business Case erkennen

Selektive Deploy-Logik beeinflusst direkt drei Dinge, die Teams wichtig sind:

• CI-Kosten — eine App statt drei zu bauen und zu deployen reduziert die Rechenzeit entsprechend
• Feedback-Geschwindigkeit — eine gezielte Pipeline wird schneller fertig, was schnellere Code-Review-Zyklen bedeutet
• Release-Risiko — nur die geänderte App zu deployen reduziert die Angriffsfläche für Regressionen in nicht verwandtem Code

Sie sollten jetzt verstehen, wie dieses Repo vermeidet, bei jeder Änderung alles zu deployen.

Schritt 6: Staging- und Produktions-Release-Regeln konfigurieren

Dieser Schritt zeigt, wie die gleiche Pipeline-Logik je nach Branch, der den Push erhalten hat, unterschiedliches Deployment-Verhalten erzeugt. Kein Anwendungscode ändert sich zwischen den Umgebungen — nur der Build-Modus, die Secrets und das Deploy-Ziel unterscheiden sich.

Die Umgebungstrennung verstehen

Das Repository trennt Umgebungen nach Branch:

• staging-Branch — baut im Staging-Modus, verwendet Staging-Secrets, deployt auf den Staging-Server
• main-Branch — baut im Produktionsmodus, verwendet Produktions-Secrets, deployt auf den Produktionsserver

Umgebungsspezifische Builds verwenden

Die Build-Skripte akzeptieren ein Umgebungsargument, das auf einen Vite-Modus abgebildet wird:

bash scripts/build-spa.sh admin-spa staging
bash scripts/build-spa.sh admin-spa production

Jeder Modus kann seine eigenen Umgebungsvariablen (API-Endpunkte, Feature-Flags, Analytics-Keys) über .env.staging- und .env.production-Dateien definieren. Der CI-Workflow übergibt den korrekten Modus automatisch basierend auf dem Branch, der die Pipeline ausgelöst hat.

Erforderliche Secrets konfigurieren

Sowohl GitHub Actions als auch GitLab CI benötigen die folgenden Secrets, pro Umgebung konfiguriert:

Secret	Zweck
SSH_PRIVATE_KEY	Authentifizierung für rsync-über-SSH-Deployment
DEPLOY_HOST	Hostname oder IP des Zielservers
DEPLOY_PORT	SSH-Port (normalerweise 22)
DEPLOY_USER	SSH-Benutzer auf dem Zielserver
DEPLOY_MAIN_SITE_PATH	Remote-Pfad für die Hauptseite (z.B. /var/www/html)
DEPLOY_ADMIN_SPA_PATH	Remote-Pfad für die Admin-SPA (z.B. /var/www/html/admin)
DEPLOY_PORTAL_SPA_PATH	Remote-Pfad für die Portal-SPA (z.B. /var/www/html/portal)

Konfigurieren Sie separate Werte für Staging und Produktion, damit jede Umgebung auf ihren eigenen Server oder ihr eigenes Verzeichnis deployt.

Genehmigungs-Gates einrichten

Für GitHub Actions verwenden Sie GitHub Environments zur Steuerung des Deployment-Verhaltens:

• Staging-Umgebung — konfigurieren Sie automatisches Deploy nach bestandener Validierung. Keine manuelle Genehmigung erforderlich, da Staging ein Pre-Production-Verifizierungsschritt ist, kein kundenseitiges Release.
• Produktions-Umgebung — konfigurieren Sie mit erforderlichen Reviewern. Nach bestandener Validierung pausiert der Deploy-Job und wartet auf die Freigabe durch ein autorisiertes Teammitglied in der Actions-UI.

Sie sollten jetzt sehen, wie die gleiche Pipeline-Logik sich je nach Branch unterschiedlich verhält, ohne Anwendungscode zu ändern.

Schritt 7: Deployen, verifizieren und Rollback vorbereiten

Das Deployment ist nicht abgeschlossen, wenn Dateien erfolgreich übertragen wurden. Es ist abgeschlossen, wenn die Ziel-App korrekt antwortet und Sie einen getesteten Pfad zurück zur vorherigen Version haben, falls etwas schiefgeht.

Das Deploy-Ziel-Modell verstehen

Das Repository deployt jede App auf einen eigenen Pfad auf dem Zielserver mit rsync über SSH:

DEPLOY_MAIN_SITE_PATH=/var/www/html
DEPLOY_ADMIN_SPA_PATH=/var/www/html/admin
DEPLOY_PORTAL_SPA_PATH=/var/www/html/portal

Jedes Deploy-Skript überträgt nur den Build-Output für die jeweilige App. Die anderen Apps auf dem Server bleiben unberührt, weshalb selektives Deployment sicher ist — das Deployen der Admin-SPA riskiert nicht, die Dateien der Portal-SPA zu überschreiben.

Dry-Run-Modus vor dem Deploy nutzen

Die Deploy-Skripte unterstützen ein Dry-Run-Flag, das genau zeigt, was rsync übertragen würde, ohne den Remote-Server tatsächlich zu ändern:

DRY_RUN=true bash scripts/deploy-spa.sh admin-spa

Nutzen Sie dies, um die Deploy-Absicht zu überprüfen, bevor Sie die Dateiübertragung erlauben, insbesondere beim ersten Konfigurieren eines neuen Zielpfads oder Servers.

Den Rollback-Pfad kennen

Das Repository erstellt vor jedem Deployment Backups mit Zeitstempel. Wenn ein Deploy ein Problem einführt, führen Sie ein Rollback auf die vorherige Version durch:

bash scripts/rollback-spa.sh admin-spa

Dies stellt das letzte Backup für die angegebene App wieder her. Rollback ist Teil des CI/CD-Designs, kein Last-Minute-Notfall-Skript. Die Tatsache, dass das Repo es standardmäßig enthält, bedeutet, dass das Team Rollbacks erwartet und sie zu einer Ein-Befehl-Operation gemacht hat.

Mit Post-Deploy-Health-Checks verifizieren

Nach jedem Deployment führt die Pipeline einen Health-Check gegen die deployte URL durch, um zu bestätigen, dass die App antwortet. Eine erfolgreiche Dateiübertragung garantiert keine funktionierende App — die Server-Konfiguration könnte falsch sein, die Umgebungsvariablen könnten fehlen oder der Build könnte im falschen Modus erstellt worden sein.

Health-Checks schließen den Kreis. Wenn der Check fehlschlägt, meldet die Pipeline einen Fehler, obwohl das Deploy selbst erfolgreich war, was dem Team ein sofortiges Signal gibt, zu untersuchen und möglicherweise ein Rollback durchzuführen.

Sie sollten jetzt den vollständigen Lebenszyklus verstehen: deployen, verifizieren und bei Bedarf wiederherstellen.

Häufige Einrichtungsprobleme

Docker-basierte E2E-Tests schlagen lokal fehl

Symptom: Playwright startet nicht sauber, oder Tests können die Apps nicht erreichen.

Wahrscheinliche Ursache: Docker läuft nicht, der nginx-Test-Stack ist nicht gestartet, oder die SPAs wurden nicht vorher gebaut.

Lösung: Führen Sie die dokumentierte Reihenfolge erneut aus: Bauen Sie die SPAs mit pnpm build:admin-spa und pnpm build:portal-spa, starten Sie Docker Compose mit docker compose -f docker/docker-compose.yml up -d, führen Sie pnpm test:e2e aus und fahren Sie dann den Stack mit docker compose -f docker/docker-compose.yml down herunter.

Eine Änderung an einem gemeinsamen Package hat den erwarteten SPA-Rebuild nicht ausgelöst

Symptom: Ein Package-Update besteht die Validierung, aber eine der SPAs wurde nicht neu gebaut oder deployt.

Wahrscheinliche Ursache: Die Änderungserkennungsregeln berücksichtigen packages/ nicht korrekt.

Lösung: Verifizieren Sie, dass Ihre Pipeline packages/-Änderungen auf beide SPAs abbildet. Das Skript scripts/changed-files.sh sollte jede Dateiänderung unter packages/ als Auswirkung auf sowohl apps/admin-spa/ als auch apps/portal-spa/ behandeln. Prüfen Sie die Skript-Logik und die bedingten Job-Trigger des CI-Workflows.

Produktions-Deploy startet nie, obwohl CI bestanden hat

Symptom: Die Validierung wird erfolgreich abgeschlossen, aber der Produktions-Deploy-Job bleibt blockiert.

Wahrscheinliche Ursache: GitHub Environment Protection Rules erfordern eine Reviewer-Genehmigung.

Lösung: Prüfen Sie die konfigurierte Produktionsumgebung in Ihren Repository-Einstellungen unter Settings > Environments > production. Genehmigen Sie das ausstehende Deployment in der Actions-UI. Wenn niemand im Team die Genehmigungsberechtigung hat, aktualisieren Sie die Liste der erforderlichen Reviewer der Umgebung.

Deployment ist erfolgreich, aber die App ist im Browser defekt

Symptom: Dateien wurden erfolgreich übertragen, aber die deployte App lädt nicht oder verhält sich falsch.

Wahrscheinliche Ursache: Falscher Umgebungsmodus (Staging-Build in Produktion deployt), falscher Zielpfad oder veraltete Server-Konfiguration, wie eine nginx-Config, die die index.html der SPA nicht für Client-seitige Routen ausliefert.

Lösung: Bestätigen Sie das Branch-zu-Umgebung-Mapping im CI-Workflow. Verifizieren Sie, dass scripts/build-spa.sh das korrekte Modus-Argument erhalten hat. Prüfen Sie, ob die Deploy-Pfade mit der nginx-Konfiguration auf dem Server übereinstimmen. Nutzen Sie den Health-Check- und Rollback-Ablauf zur Wiederherstellung, während Sie untersuchen.

Die Pipeline ist zu langsam nach dem Hinzufügen weiterer Apps

Symptom: CI-Zeiten steigen, wenn das Monorepo über drei oder vier Apps hinauswächst.

Wahrscheinliche Ursache: Selektive Validierung oder selektives Deployment wird nicht aggressiv genug angewendet. Neue Apps sind möglicherweise nicht in die Änderungserkennungslogik eingebunden, was dazu führt, dass die Pipeline alles neu baut.

Lösung: Erweitern Sie scripts/changed-files.sh, um das Verzeichnis der neuen App einzuschließen. Bilden Sie den neuen Pfad auf eigene Build- und Deploy-Jobs im CI-Workflow ab. Das bestehende Modell skaliert gut, solange jede App ihren eigenen bedingten Pfad hat — der Schlüssel ist, die Änderungserkennung zentral im Pipeline-Design zu halten.

Zusammenfassung

Sie haben jetzt ein vollständiges Bild davon, wie dieses Repository ein React SPA Monorepo in ein Release-System verwandelt. Die Pipeline validiert jeden Pull Request mit sieben automatisierten Gates, re-validiert nach dem Merge, um Integrationsprobleme zu erkennen, deployt nur die von jeder Änderung betroffenen Apps, trennt Staging von Produktion durch branch-basierte Umgebungsregeln und schließt den Kreis mit Post-Deploy-Health-Checks und Ein-Befehl-Rollback.

Von hier aus empfehlen sich folgende nächste Schritte:

• Die Workflow-Dateien annotieren. Lesen Sie .github/workflows/validate-and-deploy.yml und .gitlab-ci.yml nebeneinander, um zu sehen, wie die gleiche Pipeline-Logik in beiden CI-Systemen ausgedrückt wird.
• Eine neue App zum Monorepo hinzufügen. Erstellen Sie eine vierte SPA unter apps/, verdrahten Sie sie in scripts/changed-files.sh und fügen Sie ihre Build-, Deploy- und E2E-Ziele zum CI-Workflow hinzu. Das ist der echte Test, ob das selektive Deploy-Modell skaliert.
• Den Genehmigungsprozess verschärfen. Experimentieren Sie mit Branch-Protection-Rules, Commit-Signierungsanforderungen und CODEOWNERS-Dateien, um mehr Struktur darum zu schaffen, wer in Staging und Main mergen darf.

Die stärksten Monorepo-CI/CD-Pipelines sind nicht die mit den meisten Jobs. Es sind die, bei denen jedes Gate einen klaren Zweck hat, jedes Deploy selektiv ist und jedes Release einen getesteten Pfad zurück zur vorherigen Version hat.

Verwandte Anleitungen

• Software-Lieferkettensicherheit im KI-Zeitalter — SBOM-Generierung und Abhängigkeits-Integritätsprüfungen zu Ihrer Pipeline hinzufügen
• CI/CD-Pipeline mit Sigstore, SLSA und SBOMs härten — Artefakte signieren und Provenance in Ihren Monorepo-Releases durchsetzen
• Absicherung von KI-Coding-Agent-Workflows — KI-generierten Code sandboxen und reviewen, bevor er in Ihr Monorepo einfließt

Häufig gestellte Fragen

Muss ich Docker installiert haben, um diesem Tutorial zu folgen?

Ja. Die Playwright E2E-Tests laufen gegen gebaute SPAs, die von einem nginx-Container über Docker Compose bereitgestellt werden. Docker ist für Schritt 4 und für das vollständige lokale Pipeline-Skript in Schritt 2 erforderlich. Wenn Sie die E2E-Schritte überspringen, können Sie die Konfiguration der Validierungs-Gates ohne Docker abschließen.

Kann ich diese Pipeline nur mit GitHub Actions verwenden, oder brauche ich auch GitLab CI?

Sie benötigen nur ein CI-System. Das Repository enthält sowohl .github/workflows/validate-and-deploy.yml als auch .gitlab-ci.yml, damit Teams die Plattform wählen können, die sie verwenden. Die Pipeline-Architektur ist in beiden gleich — nur die Syntax unterscheidet sich.

Wie lange dauert die vollständige CI-Pipeline?

Auf einem typischen GitHub Actions Runner dauert die vollständige Pipeline inklusive E2E-Tests 3 bis 6 Minuten, abhängig davon, welche Apps sich geändert haben. Selektives Deployment bedeutet, dass die meisten Pushes nur eine App bauen und testen, was die Feedback-Schleife schnell hält.

Was passiert, wenn ein Post-Deploy-Health-Check fehlschlägt?

Die Pipeline meldet einen Fehler, obwohl die Dateiübertragung erfolgreich war. Das gibt dem Team ein sofortiges Signal zur Untersuchung. Sie können dann das Rollback-Skript ausführen, um die vorherige Version wiederherzustellen, während Sie das Problem diagnostizieren.