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.

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.

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

Ablauf

Build — die Plattform führt Ihren Build aus (siehe Build-Pipeline).
Vor dem Bereitstellen — wenn preDeployCommand gesetzt ist, wird es einmal ausgeführt (z. B. Migrationen).
Start — Lizard startet die Anwendung für ihre konfigurierte Laufzeitumgebung.
Health-Checks — die Plattform prüft, ob der Port der App erreichbar ist (entfällt bei Workers).
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.

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:

{ "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.

Verlauf prüfen

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

Im Dashboard zeigt die Ansicht Bereitstellungen die vollständige Zeitleiste, Build-Logs pro Deployment und einen Detailbereich für jedes Release.

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.

Wiederherstellung nach einem Absturz

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

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

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.

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.

Build-Pipeline Übersicht