<span id="deployments" />

# Bereitstellungen

Ein **Deployment** ist ein Build-und-Release eines Service. Der Release-Ablauf hängt von der Laufzeitumgebung des Service ab. Ein erfolgreicher Build belegt für sich allein nicht, dass die Anwendung gestartet ist oder Anfragen verarbeiten kann.

<span id="how-a-deploy-happens" />

## Wie ein Bereitstellen erfolgt

Ein Deployment wird ausgelöst durch:

- Ein **`git push`** auf den verfolgten Branch (bei Services mit **`github`**-Quelle).
- **`lizard redeploy`** — Neuaufbau vom neuesten Commit (git) oder letzten Upload mit den aktuellen Variablen.
- **`lizard up`** — lädt das aktuelle Verzeichnis hoch und deployt es.
- Ein **`service set`**, das ein buildrelevantes Feld ändert.

```bash
lizard redeploy --service api      # rebuild + redeploy from current source
lizard up                          # upload cwd and deploy
```

<span id="lifecycle" />

## Ablauf

1. **Build** — die Plattform führt Ihren Build aus (siehe [Build-Pipeline](https://lizard.build/de/docs/concepts/build-pipeline)).
2. **Vor dem Bereitstellen** — wenn `preDeployCommand` gesetzt ist, wird es einmal ausgeführt (z. B. Migrationen).
3. **Start** — Lizard startet die Anwendung für ihre konfigurierte Laufzeitumgebung.
4. **Health-Checks** — die Plattform prüft, ob der Port der App erreichbar ist (entfällt bei [Workers](https://lizard.build/de/docs/deploy/workers)).
5. **Prüfen** — prüfen Sie den Release-Status und rufen Sie die Anwendungs-URL auf. Die Erreichbarkeit des Ports ist kein vollständiger Health-Checks der Anwendung.

<span id="streaming-output" />

## Streaming-Ausgabe

Wenn Sie ein nicht-detachtes `lizard up` (oder `redeploy`) ausführen, werden Build-Logs live gestreamt. Mit `--json` erhalten Sie ein JSON-Ereignis pro Zeile:

```json
{ "event": "log", "line": "..." }
{ "event": "deployed", "status": "...", "url": "https://..." }
```

endet mit `deployed`, `failed` oder `deploying`. Verwenden Sie `--detach`, um das Bereitstellen zu starten und sofort zurückzukehren, ohne Streaming.

<span id="inspecting-history" />

## Verlauf prüfen

```bash
lizard events                  # deploy history + per-replica status
lizard events --limit 25       # show more
lizard ps                      # current services, status, and URLs
```

Im [Dashboard](https://lizard.build/de/docs/dashboard) zeigt die Ansicht **Bereitstellungen** die vollständige Zeitleiste, Build-Logs pro Deployment und einen Detailbereich für jedes Release.

<span id="restarts-vs-redeploys" />

## Neustarts vs. Redeploys

| Befehl | Was es tut |
|---------|--------------|
| `lizard restart --service <svc>` | Neustart des **aktuellen** Builds — kein Neuaufbau |
| `lizard redeploy --service <svc>` | Neuer **Build** vom neuesten Commit/Upload, dann Release |

Verwenden Sie `restart`, um Replikate neu zu starten (z. B. um ein Runtime-Secret zu übernehmen, das nicht per Hot-Reload geladen wurde); verwenden Sie `redeploy`, wenn Sie einen neuen Build benötigen.

<span id="recovering-from-a-crash" />

## Wiederherstellung nach einem Absturz

Prüfen Sie die Logs des letzten Absturzes oder Neustarts:

```bash
lizard logs --restart latest       # log tail around the latest restart
lizard logs --restart <id>         # a specific restart
lizard events                      # see replica status
```

<span id="config-changes-no-rebuild" />

## Konfigurationsänderungen (kein Neuaufbau)

Die meisten Änderungen an Umgebungsvariablen und Secrets werden ohne Neuaufbau übernommen: Lizard aktualisiert die Konfiguration des Service und startet ihn neu, was einige Sekunden dauert. Build-Zeit-Werte (`VITE_*`, `NEXT_PUBLIC_*`) und Änderungen an Build-Feldern erzwingen jedoch einen Neuaufbau — siehe die [Tabelle der Rebuild-Auslöser](https://lizard.build/de/docs/concepts/build-pipeline#what-triggers-a-rebuild).

<span id="failed-releases-and-recovery" />

## Fehlgeschlagene Releases und Wiederherstellung

Ein fehlgeschlagener Build und ein fehlgeschlagener Start der Anwendung sind unterschiedliche Fälle. Gehen Sie nicht davon aus, dass ein altes Release in jeder Laufzeitumgebung weiter Anfragen verarbeitet. Prüfen Sie den aktiven Service, die Build-Logs und die Runtime-Logs. `lizard redeploy` baut die ausgewählte Quelle erneut; es ist kein Befehl zum Wiederherstellen eines vorherigen Builds. Setzen Sie bei Bedarf den Quell-Commit zurück, deployen Sie ihn und prüfen Sie das Ergebnis. Siehe [bekannte Probleme](https://lizard.build/de/docs/platform/known-issues).