Deployment hängt in der Warteschlange: Was Sie zuerst prüfen sollten

Ein Deployment, das in der Warteschlange festhängt, gehört zu den wenig aussagekräftigen Fehlern, die eine Plattform anzeigen kann. Nichts ist abgestürzt. Es sind keine Logs erschienen, weil noch nichts ausgeführt wurde. Das Release bleibt einfach dort stehen, und bei jeder Aktualisierung sehen Sie dasselbe Wort.

Das Frustrierende daran: „queued“ kann mindestens vier unterschiedliche Situationen bedeuten, die nichts miteinander zu tun haben. Herauszufinden, in welcher Sie sich befinden, dauert etwa dreißig Sekunden – und entscheidet, ob Sie warten, es erneut versuchen oder sich um etwas völlig anderes kümmern sollten.

Was „queued“ tatsächlich bedeutet

Ein Deployment in der Warteschlange wurde angenommen und erfasst, aber noch keinem Worker zugewiesen. Zwischen diesen beiden Momenten müssen einige Voraussetzungen erfüllt sein:

• Die Plattform muss Ihren Quellcode abrufen, normalerweise über einen API-Aufruf bei Ihrem Git-Provider.
• Ein Build-Slot muss frei sein.
• Alle Voraussetzungen für das Release müssen abgeschlossen sein – etwa ein Migrationsschritt, eine Volume-Operation oder ein früheres Deployment desselben Service.

Wenn eine dieser Voraussetzungen blockiert ist, existiert zwar der Eintrag, aber die Arbeit beginnt nicht. Das ist der gesamte Mechanismus. Es ist kein Rätsel, aber die meisten Dashboards stellen alle vier Fälle mit demselben Wort dar.

Die vier Fälle – in der Reihenfolge, in der Sie sie prüfen sollten

1. Ihr Git-Provider hat gerade einen schlechten Tag

Das ist die häufigste Ursache und diejenige, gegen die Sie nichts tun können. Die Plattform hat Ihr Repository angefordert und eine langsame Antwort oder einen Fehler erhalten. Wenn mehrere voneinander unabhängige Services gleichzeitig in die Warteschlange geraten und keinen Code gemeinsam haben, liegt die gemeinsame Abhängigkeit beim Provider.

Prüfen Sie zuerst die Statusseite Ihres Providers. Ein Deployment, das auf eine Upstream-API wartet, wird sich von selbst erledigen. Ein erneuter Versuch fügt lediglich einen weiteren Eintrag zum Stapel hinzu – deshalb werden aus einer festgefahrenen Warteschlange so oft fünf festgefahrene Warteschlangen.

2. Etwas davor ist noch nicht abgeschlossen

Die meisten Plattformen serialisieren Deployments pro Service – und das aus gutem Grund: Zwei Builds, die in dasselbe Image-Tag schreiben, sind kein Race, das Sie gewinnen möchten. Wenn ein früheres Deployment dieses Service noch läuft – oder schlimmer noch: weiterhin als laufend betrachtet wird, weil ein Worker gestorben ist, ohne seinen Status zu melden –, wartet das nächste.

Auf Dockup listet dockup deployments die Historie, beginnend mit dem neuesten Eintrag, einschließlich des Status jedes Eintrags. Wenn das Deployment über Ihrem wartenden Release noch keinen finalen Status hat, kennen Sie die Ursache. Es abzubrechen oder auf einen Timeout zu warten, gibt die Warteschlange wieder frei.

dockup deployments my-project/my-api --json

Die Ausgabe von --json enthält den Status und die Dauer jedes Deployments. Dadurch wird „Das vorherige Deployment wurde nie abgeschlossen“ auf eine Weise offensichtlich, die ein Spinner nicht leisten kann.

3. Keine Kapazität

Jede Plattform verfügt über eine begrenzte Anzahl an Build-Workern. Bei einem Shared-Tarif kann eine Aktivitätsspitze auf der Plattform dazu führen, dass Ihre Builds hinter den Builds anderer Nutzer zurückstehen. Das kommt tatsächlich vor, dauert normalerweise nicht lange und ist der einzige Fall, in dem Warten wirklich die richtige Entscheidung ist.

Entscheidend ist, ob Sie das sehen können. Eine Position in der Warteschlange oder eine geschätzte Wartezeit macht aus einem Erlebnis, das wie ein Ausfall wirkt, einen normalen Vorgang. Ein schlichtes „queued“ tut das nicht.

4. Das Deployment hätte nie gestartet

Der ungünstige Fall: Der Eintrag wurde erstellt, aber das System, das ihn abholen sollte, hat dies nie getan. Ein Worker ist abgestürzt, ein Webhook ging verloren oder ein Token ist zwischen dem Trigger und dem Abruf abgelaufen.

Der entscheidende Hinweis ist die Zeit. Wartezeiten in der Warteschlange werden in Sekunden bis wenigen Minuten gemessen. Ein Deployment, das seit zehn Minuten in der Warteschlange steht, obwohl kein anderes Release davor liegt, wartet nicht – es hängt fest und wird auch festhängen bleiben.

So unterscheiden Sie Warten von einem Hänger

Bevor Sie es erneut versuchen, sammeln Sie drei Fakten:

1. Wird gerade noch etwas anderes deployed? Wenn ein anderes Release desselben Service läuft, befinden Sie sich in Fall 2 und sollten nichts unternehmen.
2. Wie lange befindet es sich bereits in der Warteschlange? Weniger als zwei Minuten sind normal. Mehr als zehn Minuten nicht.
3. Sind andere Services gleichzeitig in die Warteschlange geraten? Wenn voneinander unabhängige Services alle gleichzeitig angehalten wurden, sollten Sie die Ursache upstream suchen, nicht in Ihrem Code.

Diese drei Antworten trennen „warten“ fast immer von „handeln“.

Warum ein erneuter Versuch die Situation meist verschlimmert

Bei einem festgefahrenen Release besteht der erste Impuls darin, erneut auf Deploy zu klicken. Bei einer serialisierten Pipeline ist das kontraproduktiv: Sie fügen einen zweiten Eintrag hinter dem ersten hinzu. Wenn der erste tatsächlich festhängt, übernimmt der zweite dieselbe Blockade. Entwickler, die darauf stoßen, haben am Ende oft eine ganze Reihe wartender Einträge, von denen keiner ausgeführt wird, bis der erste in der Reihe freigegeben wird.

Wenn Sie es erneut versuchen möchten, brechen Sie das festgefahrene Deployment zuerst ab. Ein wartendes Deployment, das sichtbar fehlschlägt, ist wesentlich hilfreicher als fünf Einträge, die einfach stehen bleiben.

Wie wir das Problem bei Dockup lösen

Die entscheidende Designentscheidung ist, dass ein Deployment nie nur als laufend betrachtet wird. Jedes Deployment erreicht einen finalen Status, und erst dadurch wird die Warteschlange freigegeben. Ein Build, der stirbt, ohne seinen Status zu melden, läuft trotzdem in einen Timeout und gibt den Service weiterhin frei.

Zwei weitere Dinge helfen mehr, als man zunächst vermuten würde:

Stages sind benannt. Ein Dockup-Deployment durchläuft das Abrufen des Quellcodes, den Build und die Health-Prüfung. Jede Stage erfasst dabei ihre eigene Dauer. Wenn etwas langsam ist, sehen Sie, welcher Schritt langsam ist, statt nur ein einziges Wort zu beobachten. stageTimings ist in jedem Deployment-Eintrag enthalten, auch bei Verwendung von --json.

Hinter einem bereits fehlgeschlagenen Release wird nichts eingereiht. Wenn die Health-Prüfung nicht erfolgreich ist, endet das Deployment – es bleibt nicht im Service hängen, während Sie sich fragen, was passiert. Die vorherige Version liefert während der gesamten Zeit weiterhin Traffic aus. Das ist der andere Grund dafür, dass ein festgefahrenes Release bei Dockup keinen Ausfall bedeutet.

# What is the current state, and how long has each stage taken?
dockup status my-project/my-api --json

# Follow the build as it happens rather than waiting for a summary
dockup logs my-project/my-api --build --follow

Die allgemeine Regel

Eine Warteschlange ist kein Fehlerzustand. Eine Warteschlange ohne den dazugehörigen Grund schon. Jede Plattform wird Sie gelegentlich auf einen Git-Provider oder einen Build-Slot warten lassen. Der Unterschied zwischen einem fünfminütigen Ärgernis und einem verlorenen Nachmittag besteht darin, ob die Oberfläche Ihnen mitteilt, in welchem der vier Fälle Sie sich befinden.

Wenn Sie entscheiden, wo Sie etwas ausführen möchten, sollten Sie das gezielt prüfen: Lösen Sie ein Deployment aus und sehen Sie sich an, was die Plattform zwischen der Annahme und dem Start anzeigt. Wenn die Antwort aus einem einzigen Wort ohne Zeitstempel besteht, werden Sie irgendwann einen ganzen Nachmittag damit verbringen.

Häufig gestellte Fragen

Wie lange sollte ein Deployment in der Warteschlange bleiben? Auf einer gesunden Plattform wenige Sekunden bis ein paar Minuten. Alles, was länger als zehn Minuten dauert und bei dem kein anderer Eintrag davor liegt, sollte als festgefahren und nicht lediglich als langsam betrachtet werden.

Sollte ich ein Deployment in der Warteschlange erneut versuchen? Nicht, bevor Sie es abgebrochen haben. Bei einer serialisierten Pipeline wird ein erneuter Versuch hinter dem festgefahrenen Deployment eingereiht und übernimmt dieselbe Blockade.

Führt ein festgefahrenes Deployment dazu, dass meine Website ausfällt? Das sollte nicht passieren. Bei einer Plattform, die den Traffic erst umschaltet, wenn ein neues Release seine Health-Prüfung bestanden hat, liefert die laufende Version weiterhin Traffic aus. Ein wartendes oder fehlgeschlagenes Deployment ist ein Release, das nie aktiv wurde – kein Ausfall.

Warum geraten mehrere Services gleichzeitig in die Warteschlange? Weil sie eine Abhängigkeit gemeinsam nutzen. Dabei handelt es sich fast immer um den Git-Provider oder die Build-Flotte und nicht um etwas in Ihrem Code.