Anmeldung live: Von Null auf Cloud Run in einer Session

Wir haben das Registrierungssystem der Academy von einem fehlerhaften Build zu einem vollständig bereitgestellten, öffentlich zugänglichen System in einer einzigen Engineering-Session gebracht. So sah das tatsächlich aus.

Ausgangspunkt: fünf aufeinanderfolgende Build-Fehler

Das deploy.sh-Skript existierte. Die Docker-Images existierten. Was nicht existierte: ein funktionierender Build.

Der erste Fehler war ein Go-Syntaxfehler in backend/main.go — ein roher Zeilenumbruch in einem String-Literal:

// Fehlerhaft
fmt.Printf("...starting on port %s...
", port)

// Korrigiert
fmt.Printf("...starting on port %s...\n", port)

Go erlaubt keine nicht maskierten Zeilenumbrüche in String-Literalen. Die Korrektur war ein einziges Zeichen.

IAM-Berechtigungskaskade

Nachdem das Backend baute, schlug der Push zur Container Registry fehl — das Compute-Servicekonto hatte die nötige Rolle, das Cloud-Build-Servicekonto nicht. Wir gewährten die fehlende Rolle beiden Konten und der Build lief durch.

Das fehlende Frontend-Gerüst

Das React-Frontend hatte App.tsx und EnrollmentForm.tsx — aber kein public/index.html, kein src/index.tsx und eine ungültige tsconfig.json. react-scripts build braucht alle drei.

Dazu ein TypeScript-Fehler: In einem Early-Return-Block verengte TypeScript eine View-State-Variable auf einen Literaltyp, was einen späteren Vergleich zu einem toten Zweig machte (TS2367). Behoben durch Refactoring auf ein einziges Return mit bedingtem Rendering.

Terraform durch direkte Bereitstellung ersetzt

Das Deploy-Skript endete mit terraform init && terraform apply — aber Terraform war nicht installiert und das Infra-Verzeichnis existierte nicht. Statt zu blockieren, ersetzten wir es durch direkte gcloud run deploy-Aufrufe. Backend und Frontend waren in 60 Sekunden live.

Firestore-Persistenz

Das ursprüngliche Backend speicherte Datensätze im Arbeitsspeicher — bei jedem Kaltstart gelöscht. Wir schrieben den Speicher-Handler um auf Firestore mit elegantem In-Memory-Fallback:

• Mandantenspezifische Namensräume für Sammlungen
• Thread-sicherer In-Memory-Fallback, wenn Firestore nicht erreichbar ist
• Der /health-Endpunkt meldet, welcher Speicher aktiv ist

---

Historische Notiz: Die Endpunkte aus dieser Session sind nicht mehr live. Dieser Beitrag bleibt als technischer Bericht des Builds erhalten.