Neuen Client anlegen (Pull-Modell)¶

Diese Anleitung beschreibt den vollständigen Setup-Flow für einen neuen Client. Pull-Modell: ein Firebase-Projekt pro Kunde (nur Production), Client pinnt Core-Version selbst.

Voraussetzungen¶

gcloud CLI authentifiziert (gcloud auth login)
gh CLI authentifiziert mit Org-Zugriff auf Tech-Schuppen
firebase CLI installiert
Firebase-Projekt für den Kunden bereits angelegt (Region europe-west3), z. B. <kunde>-prod

1. Client-Repo erzeugen¶

Vom Core-Repo aus:

cd /path/to/easySale
./onboarding-cli/bin/easysale-cli client create --slug <kunde> --name "Kunde GmbH" --project-id <kunde>-prod

Was passiert: - GitHub-Repo Tech-Schuppen/easysale-client-<kunde> wird angelegt (privat) - Struktur wird geseedet: erp/, shop/, firebase/, handbook/ - Workflows kopiert: client-release.yml, client-ci.yml, client-release-handbook.yml - .firebaserc mit Production-Alias - pubspec.yaml mit easysale_core auf main gepinnt - Branch Protection auf main (falls Org-Plan es erlaubt)

2. GitHub Secrets setzen¶

Im Client-Repo unter Settings → Environments → production → Environment secrets:

Pflicht¶

Secret	Quelle
`DEPLOY_FIREBASE_SERVICE_ACCOUNT`	wird automatisch von `setup_github_secrets.sh --phase=web` gesetzt
`CORE_REPO_PAT`	Org-weites Secret auf `Tech-Schuppen` — wird automatisch in allen Client-Repos verfügbar

Pflicht-Variable¶

Variable	Quelle
`FIREBASE_PROJECT`	wird automatisch aus `.firebaserc` gesetzt

Optional, je nach Plattform¶

Plattform	Secrets
Sentry	`SENTRY_DSN` (Phase web)
Branding	`SHOP_APP_ICON_BASE64` (Phase web)
Android (Shop)	`ANDROID_SHOP_KEYSTORE_BASE64`, `ANDROID_SHOP_KEYSTORE_PASSWORD`, `ANDROID_SHOP_KEY_ALIAS`, `ANDROID_SHOP_KEY_PASSWORD`, `ANDROID_SHOP_GOOGLE_SERVICES_JSON`, `ANDROID_SHOP_APPLICATION_ID`, `ANDROID_PLAY_SERVICE_ACCOUNT_JSON` (Phase android)
iOS	`IOS_DISTRIBUTION_CERTIFICATE_BASE64`, `IOS_DISTRIBUTION_CERTIFICATE_PASSWORD`, `IOS_SHOP_PROVISION_PROFILE_BASE64`, `IOS_SHOP_GOOGLE_SERVICE_INFO_PLIST`, `IOS_SHOP_BUNDLE_ID`, `IOS_APP_STORE_KEY_ID`, `IOS_APP_STORE_ISSUER_ID`, `IOS_APP_STORE_KEY_BASE64` (Phase ios)

Phasen-basiert: setup_github_secrets.sh --phase=web|android|ios|all. Web läuft an Tag 1 automatisch, Android sobald der Play Service Account vorliegt, iOS sobald Apple Developer + App Store Connect Key da sind.

3. Core-Version pinnen¶

Im Client-Repo:

core:upgrade --latest          # neueste release/x.y.z aus Core
# oder
core:upgrade 2.4.0             # spezifische Version

Erstellt PR, Tests müssen grün sein, dann mergen.

Fallback wenn noch kein release/*-Branch im Core existiert: Pin bleibt auf main (im pubspec.yaml initial gesetzt). Sobald der erste Release-Branch existiert → core:upgrade --latest.

4. Ersten Release ausführen¶

release:client                            # Web + Android + Firebase auf Production
release:client --platforms=ios            # iOS separat (TestFlight, Self-Hosted Mac-Runner)

Oder manuell:

gh workflow run client-release.yml \
  --repo Tech-Schuppen/easysale-client-<kunde> \
  -f core_version=main \
  -f platforms=all

Der neue Standard fuehrt vor jedem Deploy harte Preflight-Checks aus: - CORE_REPO_PAT wird gegen Tech-Schuppen/easySale getestet - Pflicht-Secrets im GitHub Environment production werden validiert - FIREBASE_PROJECT muss gesetzt sein - der Functions-Deploy prueft smtp-config und Secret-Manager-Zugriff des Deploy-Service-Accounts

5. Validierung¶

Check	Wie
Web-App erreichbar	`https://<kunde>-prod.web.app`
Firestore Rules deployed	Firebase Console → Firestore → Rules → Timestamp prüfen
Functions deployed	Firebase Console → Functions → Region `europe-west3`
Android in Play Console	Internal Track sollte neue Version zeigen
iOS in TestFlight	App Store Connect → TestFlight

Was es nicht mehr gibt (Push-Modell-Reste)¶

Alt	Neu
`auto-build.yml` (Push-Trigger aus Core)	Manueller `client-release.yml`
`promote-to-prod.yml`	Entfällt — kein Dev mehr
`sync-prod-to-dev.yml`	Entfällt — kein Dev mehr
`env-health-check.yml`	Entfällt — eine Umgebung
`manual-deploy.yml`	Ersetzt durch `client-release.yml -f platforms=web`
`FIREBASE_SA_DEV` Secret	Entfällt
`repository_dispatch` aus Core	Entfällt — Pull statt Push

Updates eines bestehenden Clients¶

Wenn das Core-Repo ein neues Release veröffentlicht (release/x.y.z-Branch):

cd /path/to/easysale-client-<kunde>
core:upgrade --latest          # PR mit Pin-Update
# PR mergen
release:client                 # Deploy

Keine zentrale Promotion — jeder Client entscheidet selbst, wann er upgraded.