Deployment blocat în coadă: ce să verifici mai întâi

Un deployment blocat în coadă este unul dintre cele mai puțin informative tipuri de erori pe care ți le poate afișa o platformă. Nimic nu s-a oprit cu eroare. Nu au apărut loguri, pentru că nu a rulat nimic. Release-ul pur și simplu rămâne acolo, iar fiecare reîmprospătare afișează același cuvânt.

Partea frustrantă este că „queued” acoperă cel puțin patru situații diferite, care nu au nimic în comun. Să identifici situația în care te afli durează aproximativ treizeci de secunde și îți spune dacă trebuie să aștepți, să încerci din nou sau să verifici cu totul altceva.

Ce înseamnă de fapt „queued”

Un deployment în coadă a fost acceptat și înregistrat, dar încă nu a primit un worker. Între aceste două momente, trebuie să fie îndeplinite câteva condiții:

• Platforma trebuie să preia codul sursă, ceea ce înseamnă de obicei un apel API către furnizorul tău Git.
• Trebuie să existe un slot de build disponibil.
• Orice condiție prealabilă din release trebuie să se fi încheiat — un pas de migrare, o operațiune pe un volum sau un deployment anterior al aceluiași serviciu.

Dacă oricare dintre acestea este blocată, înregistrarea există, dar procesul nu începe. Acesta este întregul mecanism. Nu este un mister, însă majoritatea dashboard-urilor afișează toate cele patru cazuri folosind același cuvânt.

Cele patru cazuri, în ordinea în care merită verificate

1. Furnizorul tău Git are o zi proastă

Aceasta este cauza cea mai frecventă și cea asupra căreia nu poți face nimic. Platforma a cerut repository-ul tău și a primit un răspuns lent sau o eroare. Dacă mai multe servicii fără legătură între ele intră în coadă în același timp și nu folosesc același cod, dependența comună este furnizorul.

Verifică pagina de status a furnizorului înainte de orice altceva. Un deploy care așteaptă un API upstream se va debloca singur, iar o nouă încercare doar adaugă încă o înregistrare la grămadă — de aceea o coadă blocată se transformă atât de des în cinci cozi blocate.

2. Ceva din fața lui nu s-a încheiat

Majoritatea platformelor serializează deployment-urile pentru fiecare serviciu, și pe bună dreptate: două build-uri care scriu același tag de imagine nu reprezintă o cursă pe care vrei să o câștigi. Dacă un deployment anterior al serviciului încă rulează — sau, și mai rău, încă este considerat activ deoarece un worker a murit fără să raporteze — următorul așteaptă.

Pe Dockup, dockup deployments afișează istoricul începând cu cea mai recentă intrare, împreună cu statusul fiecăreia. Dacă deployment-ul de deasupra release-ului tău în coadă nu se află într-o stare finală, acesta este răspunsul, iar anularea lui sau așteptarea expirării este ceea ce deblochează rândul.

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

Rezultatul --json include statusul și durata fiecărui deployment, ceea ce face evident faptul că „cel anterior nu s-a terminat niciodată”, într-un mod în care un spinner nu o poate face.

3. Nu există capacitate disponibilă

Orice platformă are un număr finit de build workers. Pe un tier partajat, o creștere bruscă a activității pe întreaga platformă te poate pune în spatele build-urilor altor utilizatori. Situația este reală, de obicei de scurtă durată și este singurul caz în care așteptarea este cu adevărat alegerea corectă.

Important este dacă poți vedea acest lucru. O poziție în coadă sau o estimare a timpului de așteptare transformă o experiență care pare o întrerupere într-una normală. Un simplu „queued” nu face asta.

4. Deployment-ul nu urma să înceapă niciodată

Cazul neplăcut: înregistrarea a fost creată, dar procesul care trebuia să o preia nu a făcut-o niciodată. Un worker s-a oprit cu eroare, un webhook s-a pierdut sau un token a expirat între declanșare și preluare.

Indiciul este durata. Așteptările în coadă se măsoară în secunde până la câteva minute. Un deployment care a stat zece minute în coadă, fără niciun alt release înaintea lui, nu mai așteaptă — este blocat și va rămâne blocat.

Cum diferențiezi o așteptare de un blocaj

Înainte să încerci din nou, adună trei informații:

1. Se mai face vreun deployment? Dacă rulează un alt release al aceluiași serviciu, te afli în cazul 2 și ar trebui să nu intervii.
2. De cât timp este în coadă? Sub două minute este normal. Peste zece minute, nu.
3. Au intrat și alte servicii în coadă în același timp? Dacă servicii fără legătură s-au oprit toate deodată, caută problema upstream, nu în codul tău.

Aceste trei răspunsuri separă aproape de fiecare dată situația în care trebuie să „aștepți” de cea în care trebuie să „acționezi”.

De ce o nouă încercare înrăutățește de obicei situația

La un release blocat, instinctul este să apeși din nou pe butonul de deploy. Într-un pipeline serializat, acest lucru este contraproductiv: adaugi o a doua înregistrare după prima, iar dacă prima este într-adevăr blocată, a doua moștenește blocajul. Developerii care se lovesc de această situație ajung adesea cu o coloană de intrări în coadă, dintre care niciuna nu va rula până când capul rândului nu se eliberează.

Dacă vrei să încerci din nou, anulează mai întâi intrarea blocată. Un deployment în coadă care eșuează vizibil este mult mai util decât cinci care rămân acolo.

Cum gestionăm situația pe Dockup

Decizia de design care contează aici este că un deployment nu este niciodată considerat activ la nesfârșit. Fiecare are o stare finală, iar atingerea acesteia eliberează rândul. Un build care se oprește fără să raporteze expiră totuși și eliberează în continuare serviciul.

Alte două lucruri ajută mai mult decât ai crede:

Etapele au nume. Un deployment Dockup trece prin preluarea codului sursă, build și verificarea de sănătate, iar fiecare etapă își înregistrează propria durată. Când ceva este lent, poți vedea ce anume este lent, în loc să urmărești un singur cuvânt. stageTimings se află în fiecare înregistrare de deployment, inclusiv prin --json.

Nimic nu este pus în coadă după un release care a eșuat deja. Dacă verificarea de sănătate nu trece niciodată, deployment-ul se încheie — nu rămâne să ocupe serviciul în timp ce te întrebi ce se întâmplă. Versiunea anterioară continuă să servească trafic pe toată durata, ceea ce explică și de ce un release blocat nu înseamnă o întrerupere pe 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

Regula generală

A sta în coadă nu este un mod de eșec. A sta în coadă fără un motiv asociat este. Orice platformă te va face ocazional să aștepți un furnizor Git sau un slot de build; diferența dintre o neplăcere de cinci minute și o după-amiază pierdută este dacă interfața îți spune în care dintre cele patru cazuri te afli.

Când evaluezi unde să rulezi ceva, merită să verifici intenționat acest aspect: declanșează un deploy și uită-te la ce îți afișează platforma între momentul acceptării și cel al pornirii. Dacă răspunsul este un singur cuvânt fără timestamp, la un moment dat vei pierde o după-amiază din cauza acestei probleme.

Întrebări frecvente

Cât timp ar trebui să rămână un deployment în coadă? Câteva secunde până la câteva minute pe o platformă sănătoasă. Orice depășește zece minute, fără nimic înaintea lui, ar trebui tratat ca un blocaj, nu ca o simplă întârziere.

Ar trebui să încerc din nou un deployment aflat în coadă? Nu înainte să îl anulezi. Într-un pipeline serializat, o nouă încercare intră în coadă după cel blocat și moștenește același blocaj.

Un deployment blocat îmi poate scoate site-ul din funcțiune? Nu ar trebui. Pe o platformă care comută traficul numai după ce un nou release trece verificarea de sănătate, versiunea activă continuă să servească trafic — un deploy aflat în coadă sau eșuat este un release care nu s-a întâmplat niciodată, nu o întrerupere.

De ce intră mai multe servicii în coadă în același timp? Pentru că folosesc o dependență comună, iar aceasta este aproape întotdeauna furnizorul Git sau infrastructura de build, nu ceva din codul tău.