Deployment blijft op Queued staan: wat je eerst moet controleren

Een deployment die op queued blijft staan is een van de minst informatieve fouten die een platform je kan laten zien. Er is niets gecrasht. Er zijn geen logs verschenen, omdat er niets is uitgevoerd. De release blijft simpelweg staan en bij elke refresh zie je hetzelfde woord.

Het frustrerende is dat 'queued' minstens vier verschillende situaties kan betekenen, die niets met elkaar te maken hebben. Bepalen in welke situatie je zit, duurt ongeveer dertig seconden. Daarna weet je of je moet wachten, opnieuw moet proberen of ergens anders moet kijken.

Wat 'queued' eigenlijk betekent

Een deployment in de wachtrij is geaccepteerd en geregistreerd, maar heeft nog geen worker toegewezen gekregen. Tussen die twee momenten moet aan een aantal voorwaarden zijn voldaan:

• Het platform moet je source ophalen, meestal via een API-call naar je Git-provider.
• Er moet een build-slot beschikbaar zijn.
• Elke prerequisite in de release moet zijn afgerond — een migratiestap, een volume-operatie of een eerdere deployment van dezelfde service.

Als een van deze stappen geblokkeerd is, bestaat de registratie wel, maar start het werk niet. Dat is het hele mechanisme. Het is geen mysterie, maar de meeste dashboards tonen alle vier de situaties met hetzelfde woord.

De vier situaties, in de volgorde waarin je ze het best kunt controleren

1. Je Git-provider heeft een slechte dag

Dit is de meest voorkomende oorzaak en de enige waar je zelf niets aan kunt doen. Het platform heeft je repository opgevraagd en een traag antwoord of een fout teruggekregen. Als meerdere niet-gerelateerde services tegelijkertijd in de wachtrij komen en geen code delen, is de provider de gedeelde dependency.

Controleer eerst de statuspagina van je provider. Een deploy die op een upstream API wacht, wordt vanzelf vrijgegeven. Opnieuw proberen voegt alleen een extra registratie aan de stapel toe — daarom verandert een vastgelopen wachtrij zo vaak in vijf vastgelopen wachtrijen.

2. Iets ervoor is nog niet klaar

De meeste platforms voeren deployments per service sequentieel uit, en terecht: twee builds die naar dezelfde image tag schrijven is geen race die je wilt winnen. Als een eerdere deployment van die service nog actief is — of erger nog, nog steeds als actief wordt beschouwd omdat een worker is uitgevallen zonder dit te melden — wacht de volgende deployment.

Op Dockup toont dockup deployments de geschiedenis, met de meest recente deployment bovenaan en de status van elke entry. Als de deployment boven je release in de wachtrij geen eindstatus heeft, is dat je antwoord. Annuleren of wachten tot de deployment een timeout bereikt, maakt de weg weer vrij.

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

De --json-output bevat de status en duur van elke deployment. Daardoor zie je meteen dat 'de vorige is nooit klaar gekomen', op een manier die een spinner niet duidelijk maakt.

3. Geen capaciteit

Elk platform heeft een eindig aantal build-workers. Op een gedeelde tier kan een piek in activiteit op het platform ervoor zorgen dat je achter de builds van anderen terechtkomt. Dit komt echt voor, duurt meestal maar kort en is de enige situatie waarin wachten daadwerkelijk de juiste keuze is.

Belangrijk is of je dit ook kunt zien. Een positie in de wachtrij of een schatting van de wachttijd maakt van een ervaring die op een storing lijkt weer een normale situatie. Alleen 'queued' tonen doet dat niet.

4. De deployment zou nooit starten

Dit is de vervelende situatie: de registratie is aangemaakt, maar datgene wat de deployment moest oppakken heeft dat nooit gedaan. Een worker is gecrasht, een webhook is verloren gegaan of een token is verlopen tussen de trigger en het ophalen van de source.

De belangrijkste aanwijzing is de tijd. Wachttijden in een queue duren seconden tot hooguit enkele minuten. Een deployment die al tien minuten queued is zonder dat er een andere release voor staat te wachten, wacht niet — die zit vast en blijft vastzitten.

Zo onderscheid je een wachttijd van een vastloper

Verzamel voordat je opnieuw probeert drie feiten:

1. Is er nog iets anders aan het deployen? Als er een andere release van dezelfde service actief is, zit je in situatie 2 en kun je het proces het best met rust laten.
2. Hoe lang staat de deployment al queued? Minder dan twee minuten is normaal. Meer dan tien minuten niet.
3. Kwamen andere services op hetzelfde moment in de wachtrij? Als niet-gerelateerde services allemaal tegelijk zijn gestopt, kijk dan upstream en niet naar je code.

Met deze drie antwoorden kun je vrijwel altijd onderscheid maken tussen 'wachten' en 'ingrijpen'.

Waarom opnieuw proberen het meestal erger maakt

Bij een vastgelopen release is de eerste impuls vaak om nogmaals op deploy te drukken. In een sequentiële pipeline werkt dat averechts: je voegt een tweede registratie achter de eerste toe en als de eerste echt vastzit, erft de tweede dezelfde blokkade. Developers die dit meemaken, eindigen vaak met een kolom queued entries, die geen van alle worden uitgevoerd totdat de eerste in de rij is vrijgegeven.

Als je opnieuw wilt proberen, annuleer dan eerst de vastgelopen deployment. Eén deployment in de wachtrij die zichtbaar mislukt, is veel nuttiger dan vijf deployments die blijven staan.

Wat we hier op Dockup aan doen

De belangrijkste ontwerpkeuze is dat een deployment nooit alleen maar wordt verondersteld actief te zijn. Elke deployment heeft een eindstatus en het bereiken daarvan maakt de weg vrij. Ook een build die uitvalt zonder dit te melden, bereikt uiteindelijk een timeout en geeft de service weer vrij.

Twee andere dingen helpen meer dan je misschien zou verwachten:

Stages hebben een naam. Een Dockup-deployment doorloopt het ophalen van de source, het builden en de health gate. Elke stage registreert zijn eigen duur. Als iets traag is, zie je welk onderdeel traag is in plaats van naar één woord te kijken. stageTimings staat in elke deploymentregistratie, ook in --json.

Er wordt niets achter een al mislukte release in de wachtrij gezet. Als de health check nooit slaagt, eindigt de deployment — de service blijft niet bezet terwijl jij je afvraagt wat er aan de hand is. De vorige versie blijft de hele tijd verkeer verwerken. Dat is de andere reden waarom een vastgelopen release op Dockup geen storing veroorzaakt.

# Wat is de huidige status en hoe lang heeft elke stage geduurd?
dockup status my-project/my-api --json

# Volg de build terwijl die wordt uitgevoerd in plaats van op een samenvatting te wachten
dockup logs my-project/my-api --build --follow

De algemene regel

Queueing is geen foutmodus. Queueing zonder dat er een reden aan gekoppeld is wel. Elk platform laat je soms wachten op een Git-provider of een build-slot. Het verschil tussen vijf minuten ergernis en een verloren middag zit in de vraag of de interface laat zien in welke van de vier situaties je zit.

Als je beoordeelt waar je iets wilt draaien, controleer dit dan bewust: start een deploy en kijk wat het platform toont tussen het accepteren en het starten ervan. Als het antwoord uit één woord zonder timestamp bestaat, zul je hier uiteindelijk een middag aan besteden.

Veelgestelde vragen

Hoe lang mag een deployment queued blijven? Op een gezond platform: seconden tot enkele minuten. Alles wat langer dan tien minuten duurt zonder dat er iets voor staat te wachten, moet je als vastgelopen beschouwen in plaats van als traag.

Moet ik een deployment die queued is opnieuw proberen? Niet voordat je deze hebt geannuleerd. In een sequentiële pipeline komt een nieuwe poging achter de vastgelopen deployment in de wachtrij en erft deze dezelfde blokkade.

Haal ik mijn website offline met een vastgelopen deployment? Dat zou niet moeten gebeuren. Op een platform dat pas verkeer omschakelt nadat een nieuwe release de health check heeft doorstaan, blijft de actieve versie het verkeer verwerken — een queued of mislukte deploy is een release die nooit heeft plaatsgevonden, geen storing.

Waarom komen meerdere services tegelijk in de wachtrij? Omdat ze een dependency delen. Dat is vrijwel altijd de Git-provider of de build fleet, en niet iets in je code.