Deployment fastnar i kö: Det här bör du kontrollera först

Ett deployment som fastnat i kön är ett av de minst informativa fel som en plattform kan visa. Ingenting har kraschat. Inga loggar har skapats, eftersom inget har körts. Release-versionen ligger helt enkelt kvar där, och varje uppdatering visar samma ord.

Det frustrerande är att ”i kö” täcker åtminstone fyra olika situationer som inte har något med varandra att göra. Det tar ungefär trettio sekunder att ta reda på vilken situation du befinner dig i, och det avgör om du bör vänta, försöka igen eller undersöka något helt annat.

Vad ”i kö” faktiskt betyder

Ett deployment i kö har accepterats och registrerats, men har ännu inte tilldelats en worker. Mellan dessa två tidpunkter måste ett antal saker vara uppfyllda:

• Plattformen måste hämta din källkod, vilket vanligtvis innebär ett API-anrop till din Git-leverantör.
• En build-plats måste vara ledig.
• Alla förutsättningar för releasen måste vara klara — ett migreringssteg, en volymåtgärd eller ett tidigare deployment av samma tjänst.

Om något av detta är blockerat finns posten, men arbetet startar inte. Det är hela mekanismen. Det är inget mysterium, men de flesta dashboards visar alla fyra fallen med samma ord.

De fyra fallen, i den ordning de är värda att kontrollera

1. Din Git-leverantör har en dålig dag

Det här är den vanligaste orsaken och den enda som du inte kan göra något åt. Plattformen bad om ditt repository och fick ett långsamt svar eller ett fel. Om flera orelaterade tjänster hamnar i kö samtidigt och ingen av dem delar kod, är den gemensamma beroendepunkten leverantören.

Kontrollera leverantörens statussida innan du gör något annat. Ett deployment som väntar på ett upstream-API kommer att lösa sig av sig självt, och om du försöker igen lägger du bara till ännu en post i högen — vilket är anledningen till att en kö som fastnat så ofta blir fem köer som fastnat.

2. Något framför det har inte blivit klart

De flesta plattformar serialiserar deployments per tjänst, och det är rätt: två builds som skriver samma image-tag är inte en race condition du vill vinna. Om ett tidigare deployment av tjänsten fortfarande körs — eller ännu värre, fortfarande anses köra eftersom en worker dog utan att rapportera — får nästa vänta.

I Dockup visar dockup deployments historiken med den senaste posten först och status för varje post. Om posten ovanför din release i kön inte har ett slutgiltigt tillstånd har du svaret, och att avbryta den eller låta den löpa ut är det som frigör kön.

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

Utdata från --json innehåller status och varaktighet för varje deployment, vilket gör ”det förra blev aldrig klart” uppenbart på ett sätt som en spinner inte gör.

3. Ingen kapacitet

Alla plattformar har ett begränsat antal build workers. På en delad nivå kan en aktivitetsökning på plattformen placera dig bakom andra personers builds. Det här är verkligt, brukar gå över snabbt och är det enda fallet där det faktiskt är rätt att vänta.

Det viktiga här är om du kan se det. En köposition eller uppskattad väntetid gör en upplevelse som liknar ett avbrott till en normal situation. Ett ensamt ”i kö” gör det inte.

4. Deploymentet skulle aldrig ha startat

Det olyckliga fallet: posten skapades, men det som skulle hämta den gjorde aldrig det. En worker kraschade, en webhook försvann eller en token löpte ut mellan triggern och hämtningen.

Tidsåtgången avslöjar det. Väntan i kön mäts i sekunder till ett par minuter. Ett deployment som har stått i kö i tio minuter utan någon annan release framför sig väntar inte — det har fastnat och kommer att fortsätta vara fast.

Så skiljer du väntan från ett häng

Innan du försöker igen bör du ta reda på tre saker:

1. Håller något annat på att deployas? Om en annan release av samma tjänst körs befinner du dig i fall 2 och bör låta den vara.
2. Hur länge har den stått i kö? Under två minuter är normalt. Över tio minuter är det inte.
3. Hamnar andra tjänster i kö samtidigt? Om orelaterade tjänster stannade samtidigt bör du undersöka upstream, inte din kod.

De här tre svaren skiljer nästan alltid mellan ”vänta” och ”agera”.

Varför det oftast blir värre om du försöker igen

När en release har fastnat är den naturliga reaktionen att trycka på deploy igen. I en serialiserad pipeline blir det kontraproduktivt: du lägger till en andra post bakom den första, och om den första verkligen har fastnat ärver den andra samma blockering. Utvecklare som råkar ut för detta får ofta en kolumn med poster i kö, varav ingen körs förrän kön längst fram har frigjorts.

Om du tänker försöka igen bör du först avbryta den som har fastnat. Ett deployment i kö som misslyckas tydligt är betydligt mer användbart än fem som bara ligger kvar.

Så hanterar vi det i Dockup

Det viktiga designbeslutet här är att ett deployment aldrig bara antas köra. Varje deployment har ett slutgiltigt tillstånd, och det är när det nås som kön frigörs. En build som dör utan att rapportera får ändå timeout och frigör fortfarande tjänsten.

Två andra saker hjälper mer än man kanske tror:

Stegen har namn. Ett Dockup-deployment går igenom att hämta källkod, bygga och passera health gate, och varje steg registrerar sin egen varaktighet. När något går långsamt kan du se vad som går långsamt i stället för att titta på ett enda ord. stageTimings finns i varje deployment-post, även via --json.

Ingenting hamnar i kö bakom en release som redan har misslyckats. Om health check aldrig godkänns avslutas deploymentet — det fortsätter inte att uppta tjänsten medan du undrar vad som händer. Den tidigare versionen fortsätter att hantera trafik hela tiden, vilket är den andra anledningen till att en release som fastnat inte innebär ett avbrott i 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

Den allmänna regeln

Köbildning är inte ett feltillstånd. Köbildning utan en angiven orsak är det. Alla plattformar kommer ibland att låta dig vänta på en Git-leverantör eller en build-plats; skillnaden mellan fem minuters irritation och en förlorad eftermiddag är om gränssnittet talar om vilket av de fyra fallen det handlar om.

När du utvärderar var du ska köra något är det värt att kontrollera detta medvetet: trigga ett deployment och titta på vad plattformen visar mellan att det accepteras och att det startar. Om svaret är ett enda ord utan tidsstämpel kommer du förr eller senare att ägna en hel eftermiddag åt det här.

Vanliga frågor

Hur länge bör ett deployment vara kvar i kön? Sekunder till ett par minuter på en plattform som fungerar normalt. Allt över tio minuter utan något framför sig bör betraktas som fastnat, inte som långsamt.

Bör jag försöka igen med ett deployment i kö? Inte innan du har avbrutit det. I en serialiserad pipeline hamnar ett nytt försök bakom det som fastnat och ärver samma blockering.

Tar ett deployment som fastnat ner min webbplats? Det bör det inte göra. På en plattform som endast växlar trafik efter att en ny release har klarat sin health check fortsätter den körande versionen att hantera trafik hela tiden — ett deployment som står i kö eller har misslyckats är en release som aldrig genomfördes, inte ett avbrott.

Varför hamnar flera tjänster i kö samtidigt? För att de delar ett beroende, och det är nästan alltid Git-leverantören eller build-farmen snarare än något i din kod.