Runbook: Häufige Aktionen¶

Dieses Runbook beschreibt die häufigsten Betriebsaufgaben für die easySale-Instanz von Tech Schuppen V80.

Pull-Modell: Nur Production. Alle Deploys werden manuell vom Client-Team ausgelöst. Es gibt keinen automatischen Push aus dem Core-Repo.

Release deployen (Web + Android + Firebase)¶

Standard-Release auf Production:

gh workflow run client-release.yml \
  --repo Tech-Schuppen/easysale-client-techschuppen_v80 \
  -f platforms=all \
  -f environment=production

Oder im GitHub UI: Actions → client-release → Run workflow

Inputs: - platforms — all, web, android, ios, full oder firebase. - environment — aktuell production. - android_runner — JSON Runner Labels für Android (["ubuntu-latest"] oder ["self-hosted","macOS","android"]).

Runner-Beispiele: - GitHub Hosted (Standard): -f android_runner='["ubuntu-latest"]' - Self-hosted Mac: -f android_runner='["self-hosted","macOS","android"]'

Einmalig pro Client erforderlich: - Das Verzeichnis shop/android muss lokal erzeugt und committed sein.

Was passiert (platforms=all): - Web: Build mit Core-Pin → Firebase Hosting Deploy - Android: AAB-Build → Google Play Internal Track - Firebase: Rules + Indexes + Functions + Storage Rules

iOS Release (TestFlight)¶

iOS läuft im selben Workflow wie Web/Android, aber auf dem Self-Hosted Runner mac-mini-stefan:

gh workflow run client-release.yml \
  --repo Tech-Schuppen/easysale-client-techschuppen_v80 \
  -f platforms=ios \
  -f environment=production

Build wird zu TestFlight hochgeladen. Manuelle Promotion zu App Store über App Store Connect.

Core-Version pinnen / aktualisieren¶

Im Client-Repo den KI-Befehl ausführen:

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

Das aktualisiert die easysale_core-Dependency in erp/pubspec.yaml und shop/pubspec.yaml, erstellt einen PR und wartet auf grüne Tests.

Nach Merge des PRs:

release:client                 # oder gh workflow run client-release.yml ...

Manueller pubspec-Eintrag (Referenz):

dependencies:
  easysale_core:
    git:
      url: https://github.com/Tech-Schuppen/easySale.git
      ref: release/2.4.0       # oder: main

Rollback (Web)¶

Über die Firebase Console (< 2 min):

Firebase Hosting (Prod) öffnen
Bei der betroffenen Site auf "Release history" klicken
Vorherige Version → Drei-Punkte-Menü → "Rollback"

Für Android: vorherige AAB-Version in der Google Play Console wieder als "Production" markieren.

Nur Backend deployen (Rules + Functions)¶

Wenn nur Rules, Indexes oder Functions geändert wurden — kein App-Rebuild nötig:

gh workflow run client-release.yml \
  --repo Tech-Schuppen/easysale-client-techschuppen_v80 \
  -f platforms=firebase \
  -f environment=production

Lokale Alternative:

cd /path/to/easysale-client-techschuppen_v80
./deploy_rules.sh
./deploy_functions.sh techschuppen-v80-prod

CORS neu setzen¶

Notwendig wenn neue Domains zur App hinzugefügt werden oder CORS-Fehler bei Firebase Storage auftreten.

cd /path/to/easysale-client-techschuppen_v80
./deploy_cors.sh techschuppen-v80-prod

Neuen Benutzer anlegen¶

Firebase Auth (Prod) öffnen
"Add user" → E-Mail + Passwort eingeben
Nach dem Erstellen: User anklicken → "Edit user" → Custom Claims setzen:
```
{"customerId": "<kunden-id>", "role": "admin"}
```

Note

customerId muss mit der Kunden-ID in Firestore übereinstimmen (Dokument-ID unter customers/<id>).

Benutzer-Rolle / Custom Claims ändern¶

Rollen werden als Firebase Custom Claims gespeichert und können nur manuell in der Firebase Console geändert werden.

Firebase Auth (Prod) öffnen
Benutzer suchen und anklicken → "Edit user" → Custom Claims anpassen:

{"customerId": "<kunden-id>", "role": 0}

`role`-Wert	Bedeutung
`0`	User (Vertriebsmitarbeiter, Lese-Zugriff)
`1`	Admin (Vollzugriff ohne Benutzerverwaltung)
`2`	SuperAdmin (Vollzugriff inkl. Benutzerverwaltung)

Der Benutzer muss sich neu anmelden, damit die geänderten Claims wirksam werden.

Warning

Rollen-Änderungen über die ERP-App sind nur für SuperAdmins möglich. Direkt in der Firebase Console nur in Ausnahmefällen.

Benutzer deaktivieren oder löschen¶

Deaktivieren (Benutzer kann sich nicht mehr anmelden, Daten bleiben erhalten):

Firebase Auth (Prod) öffnen
Benutzer suchen → Drei-Punkte-Menü → "Disable account"

Löschen (irreversibel):

Benutzer im ERP-System über die Benutzerverwaltung löschen (empfohlen – löscht auch Firestore-Dokument)
Alternativ: Firebase Console → Benutzer → "Delete account"

DSGVO-Hinweis

Beim Löschen eines Benutzers auf DSGVO-Anfrage müssen zusätzlich alle personenbezogenen Daten in Firestore bereinigt werden. Siehe Löschkonzept.

Notfall-Kontakt¶

Bei kritischen Produktionsproblemen:


Tech-Schuppen Support	support@tech-schuppen.de
Security-Issues	security@easysale.de
Firebase Support	support.google.com/firebase