Status und Liste – gooddeploy

Status eines Projekts

gooddeploy status
gooddeploy status --project kunde-website

Die Ausgabe hat diese Zeilen:

Zeile	Inhalt
Live	das Deployment, das gerade live ist, mit ID, Commit, Nachricht und Alter; darunter die Live-Adressen und die Preview-Adresse der Live-Version
Rollback	das Ziel von `gooddeploy rollback` ohne ID, mit seiner Preview-Adresse, oder der Hinweis „kein Rollback-Ziel: Es gibt keine frühere Live-Version“
Läuft	ein laufender Vorgang, z. B. ein Build oder ein Umschalten (nur, wenn gerade etwas läuft)
Preview	die neueste Preview, die noch besteht, mit ihrer Adresse; entfernte (`gooddeploy rm`) und abgelaufene Previews zählen nicht. Gibt es keine, steht dort „–“
Verlauf	die letzten fünf Live-Wechsel: `promote`, `rollback` oder `auto-rollback` (automatisches Zurückschalten nach Verify), mit wer und wann

Direkt nach einem promote prüft gooddeploy die neue Version noch eine Weile (Verify, siehe Deploy und Live). In dieser Zeit ist sie schon live: status zeigt sie unter „Live“ als „live, wird geprüft (noch 38 s)“ und die bisherige Version unter „Rollback“ als „bisher live, bei Fehlern automatisch zurück“:

 kunde-website
  Live      … new00001  live, wird geprüft (noch 38 s)  3333333 „Neu“  vor 1 h
              https://kunde-website.gooddeploy.de
  Rollback  ● live0001  bisher live, bei Fehlern automatisch zurück  2222222 „Live“  vor 1 h

Im Terminal stehen Zustände als farbige Etiketten ( LIVE grün, BEREIT hervorgehoben, ZURÜCKGEROLLT rot); ohne Terminal, z. B. in einer Pipe, steht dasselbe als Text mit „·“ zwischen den Angaben, etwa ● live0001 · live · 2222222 „Live“ · vor 1 h.

Ist noch nichts live, steht bei „Live“ ein „–“, und die Zeile „Rollback“ entfällt. Sind eigene Domains eingerichtet, aber noch nichts live, nennt status sie mit dem Hinweis, dass sie ab dem ersten Promote gelten.

Warum die Preview-Adresse der Live-Version? Jedes Deployment behält seine eigene Preview-Adresse, auch nachdem es live gegangen ist. So kannst du genau die Version, die live ist, unter einer festen Adresse ansehen oder weitergeben, auch wenn die Live-Adresse später auf eine neuere Version zeigt.

Steht oben „gestört: Soll und Ist weichen ab“, hat gooddeploy eine Abweichung bemerkt und repariert sie selbst. Hält das an, melde dich bei goodDEV.

Alle Deployments

gooddeploy ls

ls (oder list) zeigt die Deployments des Projekts, neueste zuerst, als Tabelle mit ID, Zustand, Commit, Nachricht, Alter und Adresse.

Das Live-Deployment zeigt in der Spalte URL die Live-Adresse und in einer zweiten Zeile seine Preview-Adresse.
Frühere Live-Versionen, auf die rollback zurückschalten kann, sind als „(Rollback-Ziel)“ markiert.
Die Zeichen vorne: ● live, ✓ bereit, … läuft gerade, ✗ fehlgeschlagen oder zurückgerollt, · abgelöst, abgebrochen, abgelaufen oder entfernt. Im Terminal kommen Farben dazu; die Zeichen und Wörter allein reichen, auch ohne Farben (NO_COLOR).

Optionen:

Option	Wirkung
`--limit <n>`	Anzahl je Seite, 1 bis 100, Standard 20
`--cursor <wert>`	nächste Seite; gooddeploy nennt den Befehl am Ende der Liste („Weitere: gooddeploy ls --cursor …“)

Ein Deployment im Detail

gooddeploy inspect k7m2q9xa

zeigt ein Deployment mit Zustand, Commit (mit Branch und Nachricht), Alter, Buildpack, Live-Adresse (falls es live ist, mit eigenen Domains) und Preview-Adresse, dazu die Phasen mit ihrer Dauer. Frühere Live-Versionen, auf die rollback zurückschalten kann, sind als „(Rollback-Ziel)“ markiert; ist ein Deployment gescheitert, steht der Fehler mit Hinweis darunter.

● k7m2q9xa · kunde-website
  Zustand     LIVE
  Commit     2222222 (main) „Neue Startseite“
  Erstellt   vor 1 h
  Buildpack  nextjs
  Live       https://kunde-website.…
             https://www.kunde.de
  Preview    https://kunde-website--k7m2q9xa.…

Optionen:

Option	Wirkung
`--wait`	wartet, bis das Deployment fertig ist (bereit, live, fehlgeschlagen oder zurückgerollt), und endet mit dem passenden Exit-Code: 0 bei Erfolg (auch wenn die Preview inzwischen abgelaufen oder entfernt ist), 4 bei einem gescheiterten Build, 5 bei einem roten Check oder einem Rollback nach Verify, 6, wenn die Plattform ein Scheitern ohne Grund meldet
`--timeout <dauer>`	höchste Wartezeit mit `--wait`, Standard 20 Minuten
`--logs`	zeigt danach das Build-Log, auch nach einem gescheiterten Build

Ohne --wait endet inspect immer mit 0, auch wenn das Deployment gerade gebaut wird oder gescheitert ist. Hast du deploy mit Strg+C abgebrochen, läuft das Deployment auf der Plattform weiter; mit gooddeploy inspect <id> --wait wartest du auf sein Ende.

Im Browser öffnen

gooddeploy open k7m2q9xa          # Preview-Adresse dieses Deployments öffnen
gooddeploy open                   # Live-Adresse des Projekts (wie launch)
gooddeploy open k7m2q9xa --no-open  # Adresse nur ausgeben

open <id> öffnet die Preview-Adresse des Deployments (auf macOS mit open, auf Linux mit xdg-open). Ist es live, nennt open die Live-Adresse in einer zweiten Zeile. Klappt das Öffnen nicht, etwa auf einem Server ohne Browser, gibt gooddeploy nur die Adresse aus. Ohne ID verhält sich open wie gooddeploy launch; ein Projektname statt einer ID (gooddeploy open kunde-website) geht wie bisher auch.

Zustände eines Deployments

Zustand	Bedeutung
Warteschlange, Build, Start, Health-Check	wird gerade gebaut und gestartet
bereit	Preview läuft und kann live geschaltet werden
Umschalten, Prüfen	wird gerade live geschaltet bzw. nach dem Umschalten geprüft (Verify)
live	ist die aktuelle Live-Version
abgelöst	war live, eine neuere Version hat übernommen; kann Rollback-Ziel sein
zurückgerollt	war live und wurde zurückgenommen (von Hand oder automatisch); kann Rollback-Ziel sein
fehlgeschlagen, abgebrochen	Build oder Start hat nicht geklappt bzw. wurde abgebrochen
abgelaufen	Preview, die nach einer Frist abgelaufen ist (kommt mit dem automatischen Aufräumen)
entfernt	von Hand mit `gooddeploy rm` offline genommen

Je Team laufen höchstens zwei Builds gleichzeitig. Weitere Deployments warten in der Warteschlange und starten von selbst, sobald ein Build fertig ist; gooddeploy inspect <id> zeigt dann die Position, z. B. „Warteschlange (Position 2)“.

Mit --json liefern status, ls, inspect und open dieselben Daten maschinenlesbar, siehe Für Skripte und CI.