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/create_client.sh --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 → Secrets and variables → Actions:

Pflicht¶

Secret	Quelle
`FIREBASE_SA_PROD`	wird automatisch von `25_service_account.sh` angelegt
`CORE_REPO_PAT`	Org-Level Secret (sollte bereits vorhanden sein)

Optional, je nach Plattform¶

Plattform	Secrets
Sentry	`SENTRY_DSN`
Android (ERP)	`ANDROID_KEYSTORE_ERP_BASE64`, `ANDROID_KEYSTORE_ERP_PASSWORD`, `ANDROID_KEY_ERP_ALIAS`, `ANDROID_KEY_ERP_PASSWORD`
Android (Shop)	`ANDROID_KEYSTORE_SHOP_*`, `GOOGLE_PLAY_SERVICE_ACCOUNT_JSON`, `GOOGLE_SERVICES_JSON_SHOP_PROD`, `FIREBASE_CONFIG_SHOP_PROD`
iOS	`IOS_DIST_CERTIFICATE_`, `IOS_PROVISION_PROFILE_{ERP,SHOP}_BASE64`, `APP_STORE_CONNECT_API_`, `SHOP_IOS_BUNDLE_ID`

Wichtig: Keine FIREBASE_SA_DEV mehr — Pull-Modell kennt nur Prod.

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

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.