Was vorher fertig sein muss
Es existiert ein Plattform- oder Enabling-Team mit Mandat, Standards für andere Teams zu setzen und Tooling bereitzustellen.
Architektur-Entscheidungen zu den im Golden Path empfohlenen Bausteinen sind als ADRs dokumentiert.
Was vor Start vorliegen muss
Repo oder Wiki-Bereich für Golden Path Docs; Diagramm-Tool (Mermaid, Excalidraw, Lucidchart); Beispiel-Repository als Template-Anker; Linkliste zu Tooling (CI-Templates, IaC-Module, Service-Bibliotheken); Liste der bisher genutzten Pfade pro Team.
Plattform-Team als Owner des Golden Path; ein Tech Writer oder Senior Engineer als Hauptautor; Vertreter von 2-3 Produktteams als Reviewer; ein Architect oder Principal Engineer als Approver.
Konkret abgegrenzter Use Case (z. B. „neuer Backend-Service mit Public API“); existierende Best-Practice-Beispiele aus 2-3 Teams; bekannte Schmerzpunkte, die der Pfad lösen soll; Compliance- und Security-Anforderungen, die nicht verhandelbar sind.
1-3 Tage Setup, laufend
Doku-Struktur anlegen: Übersicht, Voraussetzungen, Schritt-für-Schritt, Templates, Standards/Checks, Abweichungen, FAQ. Beispiel-Repo verlinken. Owner-Eintrag mit Slack-Channel für Fragen sichtbar.
Die eine Frage, die diese Methode beantwortet
Welcher Pfad führt ein Team in unter einem Tag von Null zu einem produktionsreifen Stand für den definierten Use Case, ohne Standards zu verletzen?
Marker: Sektion
| Schritt | Dauer | Aktion | Hinweis |
|---|---|---|---|
1Sektion 1: Use Case schärfen | 30-60 min | Use Case in einem Satz formulieren: was ist das Ziel des Pfades (z. B. „REST-Backend in Go, mit Postgres, Authentifizierung über zentrales SSO“). Out-of-Scope explizit listen. | Wenn der Use Case zu breit ist („beliebige Services“), wird Golden Path zur generischen Doku. Lieber drei eng definierte Pfade als einer für alles. |
2Sektion 2: Pfad beschreiben | 2-6 h | Schritt-für-Schritt-Anleitung von Repo-Erzeugung bis Produktionsdeploy. Pro Schritt ein konkreter Befehl, ein Template-Link oder eine Klick-Anleitung. Zeitabschätzung pro Schritt. | Wenn Schritte länger sind als 1 Absatz, fehlt Automatisierung. Templates und Skripte ersetzen Beschreibungen. Pfad sollte unter 12 Schritte haben. |
3Sektion 3: Templates und Automation | 4-16 h | Vorhandene Templates (Cookiecutter, GitHub Templates, Terraform-Module) verlinken oder neu anlegen. Backstage Software Templates oder ähnliches Tool prüfen. CI-Pipeline-Vorlagen bereitstellen. | Doku ohne Templates verfällt schnell. Wer Befehle und Konfigurationen nur als Text in einer Wiki-Seite hat, verliert Konsistenz nach 4 Wochen. |
4Sektion 4: Standards und Checks | 1-2 h | Welche Qualitäts- und Security-Checks sind Pflicht: Linting, Tests, SAST, SBOM, Logging-Convention. Wo sind sie automatisiert (CI), wo manuell. Akzeptanzkriterien für „auf dem Pfad“. | Wenn Pflicht-Checks nur als Text stehen, werden sie umgangen. Automatisierung in CI ist Pflicht für alle Sicherheits- und Compliance-relevanten Punkte. |
5Sektion 5: Abweichungen und FAQ | 1-2 h | Sektion „wenn dein Use Case abweicht“: wann ist Abweichung legitim, wie wird sie dokumentiert (ADR), wer entscheidet. Häufige Fragen aus Pilot-Teams als FAQ. | Ohne Opt-out-Pfad wirkt Golden Path autoritär und wird heimlich umgangen. Klarer Ausnahme-Prozess senkt Widerstand und macht Drift sichtbar. |
6Sektion 6: Pilot und Adoption | 2-4 Wochen | Pfad mit 1-2 Pilotteams durchlaufen. Beobachten, wo Friktion entsteht, Doku iterativ verbessern. Erst nach erfolgreichem Pilot breit kommunizieren. | Veröffentlichung ohne Pilot produziert Doku, die bei der ersten Nutzung scheitert. Pilot-Team gibt schriftliches Feedback, das in v1.0 einfließt. |
Was am Ende rauskommt
Golden Path Guide im Wiki, Backstage oder Repo mit Sektionen Übersicht, Voraussetzungen, Schritte mit Befehlen, Templates-Links, Standards/Checks-Liste, Abweichungsprozess, FAQ und Owner-Kontakt. Plus Template-Repositories oder Backstage Templates.
Semantische Versionierung des Pfades (v1.0, v1.1, v2.0 bei Breaking Changes). Changelog am Anfang der Doku. Veraltete Pfade bleiben verlinkt mit Migrations-Hinweis, nicht stillschweigend ersetzen.
Kompakte Arbeitsvorlage für Golden Path mit Kontext, Input, Ergebnisartefakten und nächstem Schritt.
# Golden Path Arbeitsvorlage
## Ziel
Beschreibt den empfohlenen Standardweg, mit dem Teams ein häufiges technisches Ziel sicher erreichen.
## Kontext
Wann und wofür nutzen wir diese Methode?
## Input
Welche Daten, Beobachtungen, Entscheidungen oder Materialien liegen vor?
## Durchführung
Kurze Notizen entlang des Run Sheets.
## Ergebnisartefakte
- Golden Path Guide:
- Templates:
- Quality Checks:
## Annahmen und offene Fragen
- ...
## Entscheidung / Nächster Schritt
Owner, Datum und Erfolgssignal.Konkret gefülltes Szenario
## Golden Path: Go Backend Service mit Postgres und SSO (v1.0, freigegeben 18.05.2026)
**Owner**: Plattform-Team, Slack #platform-help.
**Use Case**: REST-Backend in Go für internen oder externen Traffic, persistente Daten in Postgres, Authentifizierung über zentrales Okta-SSO, Deploy auf Kubernetes (Cluster `prod-eu1`).
**Out-of-Scope**: Event-driven Backends (siehe Golden Path Kafka-Service), Frontend-Hosting, ML-Workloads.
**Voraussetzungen**: GitHub-Mitgliedschaft, Okta-Account, lokale Tools (Go 1.22, Docker, kubectl, helm).
**Schritte**
1. Repo aus Template erzeugen: `gh repo create --template platform/template-go-service` (geschätzte Zeit: 2 min).
2. Service-Manifest in `service.yaml` ausfüllen (Owner-Team, SLOs, Datenkategorie).
3. Lokal starten: `make dev`. Postgres läuft in Docker-Compose. (~5 min).
4. SSO-Anbindung: `make auth-init` legt Okta-App über Terraform-Modul `okta-sso` an. (~10 min).
5. CI prüft Standards bei jedem PR (siehe Standards-Tabelle).
6. Deploy nach `staging` automatisch bei Merge in main.
7. Promote nach `prod` via `make promote` nach manuellem Approval. (~3 min).
**Standards (automatisiert in CI)**
- Go-Linter (golangci-lint), Tests (go test, Coverage >= 70%), SAST (gosec), Container-Scan (trivy), SBOM (syft).
**Abweichungen**: Wenn dein Service eine andere DB braucht (z. B. Redis als Primary), eröffne ADR im Repo `platform-adrs` und Slack-Thread in #platform-help. Plattform-Team entscheidet binnen 5 Werktagen.
**Pilot-Erfahrung (Team Discovery, Mai 2026)**: 4 h Setup bis erster Deploy. Friktion bei Okta-Modul (zu wenige Beispiele), behoben in v1.1.
**Nächste Version**: v1.1 mit erweiterter Okta-Doku, Stichtag 15.06.2026.Symptome erkennen, gegensteuern
Pfad ist als 30-seitige Wiki-Seite dokumentiert, aber keine Templates oder Skripte hinterlegt; Teams kopieren von Hand.
Pro Schritt prüfen: gibt es Befehl oder Template? Wenn nicht, vor v1.0 erstellen. Doku-only-Pfade veralten innerhalb von 8 Wochen.
Pfad wirkt verpflichtend ohne Ausnahme-Prozess, Teams umgehen ihn heimlich.
Abweichungs-Sektion mit klarem ADR-Prozess. Sichtbare Stelle. Bekannte Ausnahmen als Beispiel aufführen, damit Format akzeptiert wird.
„Golden Path für alle Services“, Doku wird generisch, Use Cases unterscheiden sich zu stark.
Use Case eng schneiden. Lieber 3 enge Pfade (z. B. Go-REST, Kafka-Consumer, Frontend-SPA) als ein breiter.
Pfad wird veröffentlicht ohne realen Durchlauf, erstes nutzendes Team scheitert nach Schritt 3.
1-2 Pilot-Teams vor Breitenkommunikation. Friktionen aus Pilot in v1.0 einarbeiten. Ohne Pilot keine v1.0.
Versionen von Tools (Go, Postgres, Terraform-Modul) sind alt, Pilot-Team läuft in Inkompatibilitäten.
Quartalsweise Review des Pfades als Pflicht. Automatische Tests im Template-Repo bei Tool-Updates. Owner verantwortlich, sonst Eskalation.
Done-Signale, in unter einer Minute prüfbar
Zum Steckbrief für Zweck, ähnliche Methoden und Quellen — oder direkt zur nächsten Methode im Katalog.