Deployment bloccato in queued: cosa controllare per prima cosa

Un deployment bloccato in queued è uno dei problemi meno informativi che una piattaforma possa mostrarti. Non è andato in crash nulla. Non è comparso alcun log, perché non è stato eseguito nulla. Il release resta semplicemente lì e ogni refresh mostra la stessa parola.

La parte frustrante è che "queued" comprende almeno quattro situazioni diverse, che non hanno nulla a che fare l'una con l'altra. Capire in quale ti trovi richiede circa trenta secondi e ti permette di decidere se aspettare, riprovare o controllare qualcosa di completamente diverso.

Cosa significa davvero "queued"

Un deployment in queued è stato accettato e registrato, ma non è ancora stato assegnato a un worker. Tra questi due momenti devono verificarsi alcune condizioni:

• La piattaforma deve recuperare il tuo source code, in genere tramite una chiamata API al tuo provider Git.
• Deve esserci uno slot di build libero.
• Eventuali prerequisiti del release devono essere terminati: un migration step, un'operazione su un volume o un deployment precedente dello stesso servizio.

Se uno di questi elementi è bloccato, il record esiste ma il lavoro non parte. Questo è tutto il meccanismo. Non è un mistero, ma la maggior parte delle dashboard rappresenta tutti e quattro i casi con la stessa parola.

I quattro casi, nell'ordine in cui conviene controllarli

1. Il tuo provider Git sta avendo una brutta giornata

È la causa più comune e quella su cui non puoi fare nulla. La piattaforma ha richiesto il tuo repository e ha ricevuto una risposta lenta o un errore. Se più servizi non correlati entrano in coda nello stesso momento e non condividono codice, la dipendenza comune è il provider.

Controlla innanzitutto la status page del provider. Un deploy in attesa di una API upstream si sbloccherà da solo; riprovare aggiunge soltanto un altro record alla coda. Ecco perché una coda bloccata si trasforma così spesso in cinque code bloccate.

2. Qualcosa che lo precede non è ancora terminato

La maggior parte delle piattaforme serializza i deployment per servizio, e giustamente: due build che scrivono lo stesso image tag non sono una race che vuoi vincere. Se un deployment precedente dello stesso servizio è ancora in esecuzione o, peggio, risulta ancora in esecuzione perché un worker è terminato senza segnalarlo, quello successivo resta in attesa.

Su Dockup, dockup deployments mostra la cronologia con l'elemento più recente per primo e lo status di ogni voce. Se quella sopra il tuo release in queued non è in uno stato terminale, hai trovato la risposta: cancellarla o lasciarla andare in timeout è ciò che sblocca la coda.

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

L'output --json include lo status e la durata di ogni deployment, rendendo evidente che "quello precedente non è mai terminato", in un modo che uno spinner non permette.

3. Non c'è capacità disponibile

Ogni piattaforma ha un numero finito di build worker. Su un tier condiviso, un picco di attività sull'intera piattaforma può metterti in coda dietro ai build di altri utenti. È una situazione reale, di solito breve, ed è l'unico caso in cui aspettare è davvero la scelta giusta.

Qui è importante poterlo vedere. Una posizione in coda o una stima del tempo di attesa trasformano un'esperienza che sembra un outage in una situazione normale. Un semplice "queued" non lo fa.

4. Il deployment non sarebbe mai partito

Il caso peggiore: il record è stato creato, ma ciò che avrebbe dovuto prenderlo in carico non l'ha mai fatto. Un worker è andato in crash, un webhook è andato perso o un token è scaduto tra il trigger e il fetch.

L'indizio è il tempo. Le attese in coda si misurano in secondi o al massimo in un paio di minuti. Un deployment che è in queued da dieci minuti senza alcun altro release davanti non è in attesa: è bloccato e resterà bloccato.

Come distinguere un'attesa da un blocco

Prima di riprovare, raccogli tre informazioni:

1. È in corso qualche altro deployment? Se è in esecuzione un altro release dello stesso servizio, ti trovi nel caso 2 e dovresti lasciarlo procedere.
2. Da quanto tempo è in queued? Meno di due minuti è normale. Più di dieci no.
3. Altri servizi sono entrati in coda nello stesso momento? Se servizi non correlati si sono fermati tutti insieme, cerca il problema upstream, non nel tuo codice.

Queste tre risposte distinguono quasi sempre tra "aspetta" e "intervieni".

Perché riprovare di solito peggiora la situazione

Quando un release è bloccato, l'istinto è premere di nuovo il pulsante di deploy. In una pipeline serializzata è controproducente: aggiungi un secondo record dietro al primo e, se il primo è effettivamente bloccato, anche il secondo eredita il blocco. Chi sviluppa e si trova in questa situazione finisce spesso con una colonna di voci in queued, nessuna delle quali verrà eseguita finché la prima della fila non si sblocca.

Se vuoi riprovare, cancella prima quello bloccato. Un deployment in queued che fallisce in modo visibile è molto più utile di cinque deployment che restano lì.

Come gestiamo il problema su Dockup

La scelta progettuale più importante è che un deployment non viene mai considerato in esecuzione senza una verifica. Ogni deployment ha uno stato terminale e raggiungerlo è ciò che libera la coda. Un build che termina senza inviare il proprio stato va comunque in timeout e libera comunque il servizio.

Altri due aspetti sono più utili di quanto possa sembrare:

Gli stage hanno un nome. Un deployment Dockup passa dal fetching del source, al building e all'health gate; ogni stage registra la propria durata. Quando qualcosa è lento, puoi vedere che cosa è lento invece di osservare una sola parola. stageTimings è presente in ogni record di deployment, anche tramite --json.

Nessun deployment resta in coda dietro a un release già fallito. Se l'health check non passa mai, il deployment termina: non resta a occupare il servizio mentre ti chiedi cosa stia succedendo. La versione precedente continua a gestire il traffico per tutto il tempo, ed è anche per questo che un release bloccato non equivale a un outage su Dockup.

# 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

La regola generale

L'accodamento non è una modalità di errore. Lo è l'accodamento senza una motivazione associata. Qualsiasi piattaforma, prima o poi, ti farà aspettare un provider Git o uno slot di build; la differenza tra un fastidio di cinque minuti e un pomeriggio perso sta nel fatto che l'interfaccia ti dica in quale dei quattro casi ti trovi.

Quando valuti dove eseguire qualcosa, vale la pena verificarlo intenzionalmente: avvia un deploy e osserva cosa mostra la piattaforma tra l'accettazione della richiesta e l'avvio. Se la risposta è una sola parola senza timestamp, prima o poi finirai per perderci un pomeriggio.

Domande frequenti

Quanto dovrebbe restare in queued un deployment? Da pochi secondi a un paio di minuti su una piattaforma in buone condizioni. Oltre dieci minuti, senza nulla davanti, dovrebbe essere considerato bloccato e non semplicemente lento.

Devo riprovare un deployment in queued? Non prima di averlo cancellato. In una pipeline serializzata, il retry viene messo in coda dietro a quello bloccato ed eredita lo stesso blocco.

Un deployment bloccato può rendere irraggiungibile il mio sito? Non dovrebbe. Su una piattaforma che sposta il traffico solo dopo che un nuovo release ha superato l'health check, la versione in esecuzione continua a gestire il traffico per tutta la durata del problema: un deploy in queued o fallito è un release che non è mai avvenuto, non un outage.

Perché diversi servizi entrano in coda contemporaneamente? Perché condividono una dipendenza, che quasi sempre è il provider Git o la build fleet, non qualcosa nel tuo codice.