Case: Developer Onboarding in 15 Minuten

Lernziele

Nach dieser Lektion kannst du den Case „Developer Onboarding in 15 Minuten” im Interview durchspielen: Du designst einen Zero-Touch-Prozess von der Team-Anfrage bis zum ersten Deploy, kannst Backstage-Templates mit GitOps und Policy-Generierung verknüpfen, hast Antworten auf Security-Automatisierung und Fehlerbehandlung parat und weißt, wie du Time-to-First-Deploy als Plattform-Metrik begründest.

Das Szenario

Die Aufgabe: „Ein neues Team startet Montag. Designe einen Prozess, bei dem das Team in 15 Minuten produktiv ist — Namespace, CI, Monitoring, Katalog-Eintrag, Security-Guardrails. Self-Service, kein Platform-Ticket.” Der Case ist der Praxistest für alles, was du in den vorherigen Lektionen gelernt hast: Multi-Tenancy, Policies, CI, Observability — nicht als Einzelkomponenten, sondern als orchestrierter Golden Path.

Anforderungen klären: Was heißt „produktiv”?

„15 Minuten” ist nur messbar, wenn du definierst, wann die Uhr stoppt:

• „Was muss am Ende funktionieren?” — Angenommen: Namespace existiert, erstes Deployment läuft, Logs und Metriken sind sichtbar, Team steht im Software-Katalog, Getting-Started-Docs sind generiert.
• „Wer triggert den Prozess?” — Angenommen: Tech-Lead über Self-Service-Portal. Kein Platform-Engineer involviert.
• „Welche Inputs braucht das System?” — Team-Name, Mitglieder (SSO-Gruppe), Cost Center, gewünschte Umgebungen (dev/staging).
• „Welche Security-Defaults sind Pflicht?” — NetworkPolicy (default deny), ResourceQuota, RBAC-Bindings, LimitRange — automatisch, nicht manuell.
• „Was passiert bei Fehler in Schritt 3 von 7?” — Rollback oder partieller Zustand? Das ist ein Designthema, kein Detail.

Fasse zusammen: „Backstage-Template, Input: Team-Name und Mitglieder, Output: lauffähiger Namespace mit CI, Monitoring und Docs — alles in Git, alles auditierbar, Ziel: Time-to-First-Deploy unter 15 Minuten.”

Architektur: Ein Template, sieben Schritte, null Tickets

Der Kern ist ein Backstage Software Template „Create Team Environment”. Der Entwickler füllt ein Formular aus, der Rest ist Automatisierung:

Schritt 1 — Identity und Source. Template erstellt GitHub-Team mit Mitgliedern, Repository aus Org-Template (Dockerfile, CI-Workflow, Kubernetes-Manifeste vorhanden). Gruppe wird im Identity Provider synchronisiert.

Schritt 2 — Tenant-Provisionierung. Pull Request im Tenants-Git-Repo mit Namespace-Manifest. Nach Merge legt Argo CD die Namespaces an. Kyverno Generate-Rules feuern automatisch: default-deny NetworkPolicy, ResourceQuota, LimitRange, RBAC-Bindings (Team-Gruppe → edit im Namespace). Kein Namespace ohne Guardrails.

Schritt 3 — GitOps-Einbindung. Argo CD ApplicationSet erkennt den neuen Namespace-Eintrag und erstellt eine Application für das Team-Repo. Erstes Deployment startet automatisch.

Schritt 4 — CI-Freischaltung. GitHub Actions Workflow im Template-Repo ist vorkonfiguriert: Self-hosted Runner, Kaniko-Build, Push nach Harbor. Der Golden Path ist der einzige empfohlene Weg.

Schritt 5 — Observability. Grafana-Ordner und Standard-Dashboards. Alert-Rules für Pod-CrashLoop und Quota-80 %-Warnung. Logs über Label team=<name>.

Schritt 6 — Katalog und Docs. Backstage Catalog registriert die Team-Komponente. TechDocs generiert Getting-Started: wie deployen, wo Logs, wen fragen.

Schritt 7 — Kommunikation. Slack-Channel mit Links zu Dashboard, Docs und Deployment-Status.

Alles läuft über Scaffolder Actions — idempotent, mit Status im Portal. Bei Fehler: Rollback (Namespace löschen, Repo archivieren) und Retry-Option.

Einwände des Interviewers

„15 Minuten — was, wenn der erste Build länger dauert?” Die Metrik endet bei „Team kann deployen”, nicht bei „Image gebaut”. CI-First-Build braucht 5–8 Minuten extra — im Interview sauber trennen.

„Was, wenn das Team vom Golden Path abweichen will?” Golden Path ist Default, nicht Gefängnis. Custom-Setup über dokumentierten Escape Hatch mit Review. 90 % brauchen den Standard.

„Wer reviewed den PR im Tenants-Repo?” Auto-Merge bei validiertem Input (Team-Name neu, Cost Center gültig). Platform reviewt stichprobenartig — Geschwindigkeit ohne Blindheit.

„Alles in Git — was bei Secret-Rotation?” Template erzeugt ExternalSecret-Referenzen, nicht die Werte. RBAC und Registry über OIDC und Vault Dynamic Secrets.

Praxis

Spiele den Case 40 Minuten am Whiteboard. Diese fünf Punkte müssen vorkommen:

1. Definition von „produktiv” und Time-to-First-Deploy als Metrik.
2. Backstage-Template mit mindestens fünf der sieben Schritte als Datenfluss.
3. Kyverno-Generierung von NetworkPolicy, Quota, RBAC — automatisch beim Namespace-Anlegen.
4. Fehlerbehandlung: Rollback bei fehlgeschlagenem Schritt.
5. Golden Path vs. Escape Hatch — bewusst benennen.

Variiere: „Das Team braucht auch Staging — wie erweiterst du das Template?”

Typische Stolperfallen

Onboarding als Ticket-Kette. „Platform erstellt Namespace, Security setzt Policy” — das ist der Ist-Zustand, nicht die Lösung.

Guardrails vergessen. Schnelles Onboarding ohne NetworkPolicy und Quota ist ein schneller Incident.

Kein Katalog-Eintrag. Ohne Backstage-Eintrag findet das Team seine Ressourcen nicht — 15 Minuten technisch, Stunden an Orientierung.

Idempotenz ignorieren. Zweimal ausführen erzeugt doppelte Namespaces oder kaputte Zustände.

Interview-Vorbereitung

Deine Kernbotschaft: Ein Backstage-Template orchestriert Identity, Git, GitOps, Policy-Generierung, CI, Observability und Docs — alles in Git, Time-to-First-Deploy unter 15 Minuten als messbare Metrik.

Rechne mit diesen Follow-ups:

• „Wie misst du Erfolg?” — Time-to-First-Deploy, manuelle Tickets pro Onboarding, Template-Nutzungsrate.
• „Wie onboarded du das 50. Team?” — Gleicher Prozess, Automatisierung skaliert, Menschen nicht.
• „Unterschied zu Account Vending?” — Onboarding auf Cluster-Ebene; Landing Zone auf Cloud-Account-Ebene. In Enterprise: beides verkettet.

Zusammenfassung

Der Onboarding-Case vereint Plattform-Bausteine zu einem Golden Path: Backstage-Template → GitHub-Team und Repo → Argo CD Namespace → Kyverno-Guardrails → CI, Monitoring, Katalog, Docs — in einem Durchlauf, ohne Ticket. Metrik: Time-to-First-Deploy. Fehlerbehandlung und Idempotenz sind Pflicht. Damit schließt du die inhaltliche Vorbereitung — in der nächsten Lektion simulierst du alles in einem 45-Minuten-Mock-Interview unter Zeitdruck.