28 lines
1.3 KiB
Plaintext
28 lines
1.3 KiB
Plaintext
|
---
|
||
|
|
description: Deployment und Tests — kein lokaler Lauf; Verifikation über develop auf Raspberry
|
||
|
|
alwaysApply: true
|
||
|
|
---
|
||
|
|
|
||
|
|
# Kairo — Deployment & Tests
|
||
|
|
|
||
|
|
## Kein lokaler Test-/DB-Lauf
|
||
|
|
|
||
|
|
Backend-Tests (pytest), Migrationen und Integrationstests **können auf der Entwicklungsmaschine in der Regel nicht ausgeführt werden** — PostgreSQL/Docker ist lokal oft nicht verfügbar.
|
||
|
|
|
||
|
|
Versuche nicht wiederholt, lokale pytest-/Migration-Läufe als Abnahme zu erzwingen, wenn die DB nicht erreichbar ist.
|
||
|
|
|
||
|
|
## Verifikation über Remote-Deploy
|
||
|
|
|
||
|
|
Praktische Verifikation erfolgt durch **Deployment auf ein entferntes System (Raspberry Pi)**:
|
||
|
|
|
||
|
|
1. Änderungen **committen** und auf Branch **`develop`** pushen
|
||
|
|
2. Deployment wird dadurch ausgelöst (CI/Deploy-Pipeline auf dem Raspberry)
|
||
|
|
3. Dort laufen Migrationen, Backend-Tests und Smoke-Checks gegen echte Infrastruktur
|
||
|
|
|
||
|
|
## Konsequenz für Agenten
|
||
|
|
|
||
|
|
- Code und Tests **schreiben** und dokumentieren — aber fehlende lokale DB nicht als Implementierungsblocker behandeln
|
||
|
|
- Frontend: `npm test` / `vite build` lokal weiterhin sinnvoll, wenn Node verfügbar
|
||
|
|
- Backend: nach AP-Umsetzung Abschlussbericht mit „Remote-Verifikation nach Push auf develop“ kennzeichnen
|
||
|
|
- **Nicht** proaktiv committen/pushen, es sei denn, der Nutzer bittet explizit darum
|