In Amateurmannschaften ist der Einsatz ein „Ereignis“. Der leitende Entwickler ruft: „Hört alle auf zu fusionieren! Ich führe eine Bereitstellung durch!“ Sie stellen eine SSH-Verbindung zu einem Server her. Sie führen „Git Pull“ aus. Sie beten. Wenn es kaputt geht, geraten sie in Panik.

In professionellen Teams ist der Einsatz ein Nicht-Ereignis. Es passiert 20 Mal am Tag. Es ist langweilig. Es ist unsichtbar. Wenn es kaputt geht, führt das System automatisch einen Rollback durch, bevor der Benutzer es sieht.

Dies wird durch Continuous Integration / Continuous Deployment (CI/CD) erreicht. Die Pipeline ist ein Roboter, der Ihre Produktionsumgebung bewacht. Seine Aufgabe ist einfach: Schlechter Code rücksichtslos zurückgewiesen.

Warum Maison Code darüber spricht

Bei Maison Code Paris fungieren wir als das architektonische Gewissen unserer Kunden. Wir übernehmen oft „moderne“ Stacks, die ohne grundlegendes Verständnis für Skalierung gebaut wurden.

Wir diskutieren dieses Thema, weil es einen kritischen Wendepunkt in der technischen Reife darstellt. Die korrekte Implementierung unterscheidet ein fragiles MVP von einer widerstandsfähigen Plattform auf Unternehmensniveau.

1. Die Philosophie: Der Hauptzweig ist heilig

Das Ziel von CI/CD besteht darin, sicherzustellen, dass der „Hauptzweig“ immer bereitstellbar ist. Sie drängen nie direkt auf „main“. Sie halten sich an die Trunk Based Development (oder Short-Lived Feature Branches).

Dev erstellt den Zweig „feat/new-checkout“.
Entwickler pusht Code.
CI-Pipeline wird ausgeführt. Tests bestehen.
Dev öffnet Pull Request (PR).
Vorschauumgebung wird bereitgestellt.
Es findet ein Peer-Review statt.
Mit „main“ zusammenführen.
CD-Pipeline wird ausgeführt. Wird in der Produktion bereitgestellt.

2. Schicht 1: Statische Analyse (Die Grammatikpolizei)

Die am günstigsten zu behebenden Fehler sind diejenigen, die erkannt werden, bevor der Code ausgeführt wird. Wir führen dies bei jedem „Git-Push“ aus.

Linting (ESLint): Fängt Syntaxfehler und fehlerhafte Muster („no-unused-vars“) ab.
Formatierung (hübscher): Erzwingt den Stil. Keine Diskussionen über Tabulatoren und Leerzeichen während der Codeüberprüfung.
Typprüfung (TypeScript): Die kritischste Prüfung. „Sie haben einen String an eine Funktion übergeben, die eine Zahl erwartet.“

„yaml

.github/workflows/ci.yml

Name: CI auf: [drücken] Jobs: validieren: läuft weiter: ubuntu-latest Schritte: - verwendet: actions/checkout@v3 - verwendet: actions/setup-node@v3 - Ausführen: npm ci - run: npm run type-check # tsc —noEmit - run: npm run lint „ Kosten: 30 Sekunden. Wert: Spart stundenlanges Debuggen „undefiniert ist keine Funktion“.

3. Schicht 2: Unit-Tests (Die Logikprüfung)

(Siehe Unit Testing). Gibt die Funktion „calculateTax()“ den korrekten Wert für einen deutschen Benutzer zurück? Wir verwenden Vitest. Es muss schnell gehen. Wenn Unit-Tests mehr als 5 Minuten dauern, beenden Entwickler die lokale Ausführung.

4. Ebene 3: Die Vorschauumgebung (Vercel)

Das ist der Game Changer. Wenn ein PR geöffnet wird, stellt Vercel diesen Code automatisch unter einer eindeutigen URL bereit: „https://my-app-git-feat-checkout.vercel.app“. Dies ermöglicht:

Visuelle Qualitätssicherung: Der Designer kann durch den Checkout klicken, um zu sehen, ob die Pixel perfekt sind.
Produktbewertung: Der PM kann überprüfen, ob die Funktion den Anforderungen entspricht.
Automatisierte E2E-Tests: Die Pipeline kann einen Browser für diese echte URL ausführen.

5. Schicht 4: End-to-End-Tests (E2E) (Der Benutzersimulator)

Unit-Tests reichen nicht aus. „Die Datenbankverbindung funktioniert. Die Schaltfläche wird gerendert. Durch Klicken auf die Schaltfläche wird jedoch nicht in der Datenbank gespeichert.“ Nur Playwright (oder Cypress) erkennt dies.

Die CI-Pipeline startet einen Headless-Browser und verhält sich wie ein Benutzer.

Gehen Sie zu „/product/sneaker“.
Klicken Sie auf „In den Warenkorb“.
Erwarten Sie, dass „Warenkorb (1)“ sichtbar ist.

„yaml e2e: Bedarf: Vorschau läuft weiter: ubuntu-latest Schritte: - verwendet: actions/checkout@v3 - Name: Playwright ausführen Ausführen: Npx-Dramatikertest Umgebung: BASE_URL: €{{ github.event.deployment_status.target_url }} „ Blocker: Wenn E2E-Tests fehlschlagen, ist die Schaltfläche „Zusammenführen“ in GitHub deaktiviert.

6. Kontinuierliche Bereitstellung: Die Veröffentlichung

Sobald der Code mit „main“ zusammengeführt wurde, startet die CD-Pipeline. Bei Vercel/Netlify erfolgt dies automatisch. Für AWS (Docker/ECS) verwenden wir GitHub-Aktionen, um den Container zu erstellen, an ECR zu übertragen und die Aufgabendefinition zu aktualisieren.

Keine Ausfallzeit (Blau/Grün)

Wir starten niemals einen Live-Server neu.

Starten Sie Green (Neue Version).
Warten Sie auf den Gesundheitscheck („200 OK“).
Schalten Sie Load Balancer auf Grün.
Töte Blue (alte Version). Dadurch wird sichergestellt, dass kein Benutzer etwas sieht, wenn die neue Version beim Booten abstürzt.

7. Die „Friday Deploy“-Regel

Es gibt ein Meme: „Nicht am Freitag einsetzen.“ Bei Maison Code sind wir freitags im Einsatz. Wenn Sie Angst vor der Bereitstellung am Freitag haben, bedeutet das, dass Sie Ihrer Pipeline nicht vertrauen. Das bedeutet, dass Sie sich auf die manuelle Qualitätssicherung oder auf Hoffnung verlassen. Eine robuste Pipeline gibt Ihnen die Sicherheit, jederzeit zu versenden.

8. Sicherheitsscan (nach links verschieben)

Die Sicherheit erfolgt oft „am Ende“ über einen Pentest. Wir verschieben es in den Pull Request.

Snyk / Dependabot: Durchsucht „package.json“ nach anfälligen Abhängigkeiten.
Trivy: Scans Docker containers for OS vulnerabilities.
SonarQube: Scannt Code nach Hotspots (z. B. hartcodierte Passwörter). Wenn Sie einen AWS-Schlüssel festschreiben, explodiert die Pipeline. Es verhindert, dass das Geheimnis jemals den Verlauf des „Hauptzweigs“ erreicht.

9. Kostenmanagement (Infracost)

Entwickler lieben es, große Instanzen hochzufahren. „Ich benötige zum Testen eine X1.Large-Datenbank.“ Wir nutzen Infracost. Es läuft in der PR und kommentiert:

„Diese PR erhöht die monatliche Rechnung um 150 € (Upgrade auf X1.Large).“ Dadurch werden die Kosten transparent. Der CTO kann die „Finanzänderung“ genau wie eine „Kodexänderung“ genehmigen oder ablehnen. Es bringt FinOps in DevOps.

10. Geheimnisse verwalten (Env Vars)

Übertragen Sie niemals „.env“-Dateien. Wir verwenden Vercel Env Management oder AWS Secrets Manager. Die CI-Pipeline fügt diese zur Build-Zeit ein. Bei Open-Source-Prüfungen (wie „npm audit“) stellen wir sicher, dass Geheimnisse nicht in der Konsole protokolliert werden.

9. GitOps (ArgoCD): Der Heilige Gral

Für unsere Kubernetes-Cluster verwenden wir GitOps. Der Status des Clusters wird in Git definiert. Wenn Sie von 3 Pods auf 5 Pods skalieren möchten, führen Sie „kubectl Scale“ nicht aus. Sie bearbeiten „deployment.yaml“ in Git. ArgoCD erkennt die Änderung und synchronisiert den Cluster. Drift-Erkennung: Wenn ein Cowboy-Ingenieur den Cluster manuell (SSH) ändert, erkennt ArgoCD die Abweichung und überschreibt sie zurück in den Git-Status. Dies setzt „Infrastruktur als Code“ religiös durch.

10. Datenbank-Seeding für Vorschauen

Eine Vorschauumgebung ist nutzlos, wenn sie über eine leere Datenbank verfügt. Sie melden sich an und es sind keine Produkte vorhanden. Wir implementieren Automatisiertes Seeding.

Stellen Sie die Datenbank bereit (Neon-/Supabase-Zweig).
Führen Sie „npm run seeds“ aus.
Injektionen: 10 Produkte, 2 Benutzer (Administrator/Kunde), 5 Bestellungen. Jetzt kann der PM die Seite „Bestellhistorie“ sofort testen. Dies ist der Unterschied zwischen einem „Technical Deploy“ und einem „Usable Product“.

11. Erweitertes Rollback: Canary-Bereitstellungen

Für Apps mit hohem Risiko ist Blau/Grün zu binär. Wir verwenden Canary Deployments.

Stellen Sie v2 für 5 % des Datenverkehrs bereit.
Pipeline überwacht die Fehlerrate.
Wenn die Fehlerrate < 0,1 % ist, erhöhen Sie sie auf 20 %.
Wenn die Fehlerrate ansteigt, automatisches Rollback auf 0 %. Dies begrenzt den „Explosionsradius“ eines schlechten Bugs. Nur 5 % der Benutzer sahen den Fehler. Dies erfordert hochentwickelte Load Balancer (AWS ALB / Cloudflare), ist aber das ultimative Sicherheitsnetz.

12. Fazit

Manuelle Vorgänge sind der Feind der Skalierung. Jedes Mal, wenn ein Mensch einen Server berührt, beträgt das Fehlerrisiko 10 %. Jedes Mal, wenn ein Skript einen Server berührt, beträgt das Risiko 0 % (nach der ersten erfolgreichen Ausführung). Automatisieren Sie alles. Machen Sie „das Richtige tun“ zur „einfachen Sache“.

Lesen Sie mehr über [Automatisiertes Testen](/de/blog/tech-automated-testing-de) und [Infrastruktur als Code](/de/blog/tech-infrastructure-code-de).