Queued Durumunda Takılan Deployment: Önce Neleri Kontrol Etmeli?

Queued durumunda takılan bir deployment, bir platformun size sunabileceği en az bilgi veren hatalardan biridir. Hiçbir şey çökmemiştir. Hiçbir log görünmüyordur, çünkü henüz hiçbir şey çalışmamıştır. Release olduğu yerde durur ve her yenilemede aynı kelimeyi görürsünüz.

İşin can sıkıcı tarafı, "queued" ifadesinin birbiriyle hiç ilgisi olmayan en az dört farklı durumu kapsamasıdır. Hangi durumda olduğunuzu anlamak yaklaşık otuz saniye sürer ve beklemeniz mi, retry yapmanız mı, yoksa tamamen başka bir şeyi mi kontrol etmeniz gerektiğini belirler.

"Queued" aslında ne anlama gelir?

Queued durumundaki bir deployment kabul edilmiş ve kayda alınmıştır, ancak henüz bir worker'a atanmamıştır. Bu iki an arasında birkaç koşulun sağlanması gerekir:

• Platformun source kodunuzu alması gerekir; bu da genellikle Git provider'ınıza yapılan bir API çağrısı anlamına gelir.
• Bir build slot'unun boş olması gerekir.
• Release içindeki tüm ön koşulların tamamlanmış olması gerekir — bir migration adımı, bir volume işlemi veya aynı service'in daha önceki bir deployment'ı.

Bunlardan biri engellenirse kayıt oluşturulur, ancak işlem başlamaz. Mekanizma bundan ibarettir. Gizemli bir durum değildir, ancak çoğu dashboard dört durumu da aynı kelimeyle gösterir.

Kontrol etmeye değer sırayla dört durum

1. Git provider'ınız sorun yaşıyor

Bu, en yaygın nedendir ve sizin yapabileceğiniz bir şey yoktur. Platform repository'nizi istemiş, ancak yavaş bir yanıt veya hata almıştır. Aynı anda birbiriyle ilgisiz birkaç service queue'ya giriyor ve hiçbiri kod paylaşmıyorsa ortak dependency provider'dır.

Her şeyden önce provider'ınızın status page'ini kontrol edin. Upstream API'yi bekleyen bir deploy kendiliğinden düzelir; retry yapmak ise yığına yalnızca yeni bir kayıt ekler. Bu nedenle takılan bir queue çoğu zaman beş takılan queue'ya dönüşür.

2. Önündeki bir işlem tamamlanmadı

Çoğu platform deployment'ları service başına serialise eder ve bunun iyi bir nedeni vardır: aynı image tag'ine yazan iki build'in yarışmasını istemezsiniz. Aynı service'in önceki deployment'ı hâlâ çalışıyorsa — daha kötüsü, bir worker raporlama yapmadan öldüğü için hâlâ çalıştığı sanılıyorsa — sonraki deployment bekler.

Dockup'ta dockup deployments, geçmişi en yeniden en eskiye doğru listeler ve her kaydın status bilgisini gösterir. Queued durumundaki release'in üstündeki kayıt terminal state'te değilse yanıt budur; onu cancel etmek veya timeout olmasını beklemek sırayı açar.

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

--json çıktısı her deployment'ın status ve duration bilgilerini içerir. Böylece "önceki işlem hiç tamamlanmadı" durumu, bir spinner'a bakmaya kıyasla açıkça görülür.

3. Capacity yok

Her platformun sınırlı sayıda build worker'ı vardır. Shared tier'da platform genelindeki yoğunluk, build'inizi diğer kullanıcıların build'lerinin arkasına atabilir. Bu gerçek bir durumdur, genellikle kısa sürer ve beklemenin gerçekten doğru seçenek olduğu tek durum budur.

Burada önemli olan bunu görebilmenizdir. Queue position veya tahmini bekleme süresi, outage benzeri bir deneyimi normal bir duruma dönüştürür. Sadece "queued" yazması ise bunu yapmaz.

4. Deployment aslında hiç başlamayacaktı

İşlerin kötü gittiği durum şudur: kayıt oluşturulmuştur, ancak onu alması gereken işlem hiç çalışmamıştır. Bir worker çökmüş, bir webhook kaybolmuş veya trigger ile fetch arasındaki sürede bir token'ın süresi dolmuş olabilir.

Belirleyici işaret süredir. Queue beklemeleri saniyelerle veya birkaç dakikayla ölçülür. On dakika boyunca queued durumunda kalmış ve önünde başka bir release bulunmayan deployment beklemiyordur — takılmıştır ve takılı kalmaya devam edecektir.

Bekleme ile takılma arasındaki fark nasıl anlaşılır?

Retry yapmadan önce şu üç bilgiyi toplayın:

1. Başka bir deployment çalışıyor mu? Aynı service'in başka bir release'i çalışıyorsa 2. durumdasınız; işlemi olduğu gibi bırakmalısınız.
2. Ne kadar süredir queued durumunda? İki dakikadan kısa süre normaldir. On dakikadan uzun süre normal değildir.
3. Başka service'ler de aynı anda queue'ya girdi mi? Birbiriyle ilgisiz service'lerin tümü aynı anda durduysa kodunuza değil, upstream dependency'lere bakın.

Bu üç yanıt, neredeyse her seferinde "bekle" ile "müdahale et" arasındaki farkı ortaya koyar.

Retry yapmak neden genellikle durumu kötüleştirir?

Takılan bir release karşısında ilk refleks deploy düğmesine yeniden basmaktır. Serialise edilmiş bir pipeline'da bu ters etki yaratır: ilk kaydın arkasına ikinci bir kayıt eklersiniz ve ilk kayıt gerçekten takılmışsa ikincisi de aynı engeli devralır. Bu durumla sık karşılaşan developer'lar sonunda, hiçbiri sıranın başı açılana kadar çalışmayacak queued kayıtlarından oluşan bir sütunla karşılaşır.

Retry yapacaksanız önce takılan deployment'ı cancel edin. Görünür şekilde başarısız olan tek bir queued deployment, olduğu yerde duran beş deployment'dan çok daha faydalıdır.

Dockup'ta bu durumu nasıl ele alıyoruz?

Buradaki önemli design kararı, bir deployment'ın hiçbir zaman çalışıyor sanılmamasıdır. Her deployment'ın bir terminal state'i vardır ve sırayı serbest bırakan da bu state'e ulaşılmasıdır. Bir build raporlama yapmadan sonlansa bile timeout olur ve service'i serbest bırakır.

Kulağa geldiğinden daha fazla fayda sağlayan iki şey daha vardır:

Stage'ler adlandırılmıştır. Dockup deployment'ı source fetching, building ve health gate aşamalarından geçer; her stage kendi duration bilgisini kaydeder. Bir şey yavaşladığında tek bir kelimeyi izlemek yerine hangi şeyin yavaş olduğunu görebilirsiniz. stageTimings, --json dahil olmak üzere her deployment kaydında bulunur.

Zaten başarısız olmuş bir release'in arkasında hiçbir şey queue'da beklemez. Health check geçmezse deployment sona erer — ne olduğunu anlamaya çalışırken service'i meşgul ederek beklemez. Önceki version bu süre boyunca traffic sunmaya devam eder; takılan bir release'in Dockup'ta neden outage anlamına gelmediğinin diğer yarısı da budur.

# 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

Genel kural

Queueing bir failure mode değildir. Sebebi belirtilmeden queueing durumunda kalmak failure mode'dur. Her platform zaman zaman sizi bir Git provider'ı veya build slot'unu beklemeye zorlayabilir; beş dakikalık bir sıkıntı ile bütün bir öğleden sonranın kaybı arasındaki fark, arayüzün hangi dört durumdan birinde olduğunuzu size gösterip göstermemesidir.

Bir şeyi nerede çalıştıracağınıza karar verirken bunu özellikle kontrol etmeye değer: Bir deploy tetikleyin ve platformun, deploy'u kabul etmesiyle başlatması arasında neler gösterdiğine bakın. Yanıt timestamp içermeyen tek bir kelimeyse, er ya da geç bütün bir öğleden sonranızı buna harcarsınız.

Sık sorulan sorular

Bir deployment ne kadar süre queued durumunda kalmalı? Sağlıklı bir platformda saniyelerden birkaç dakikaya kadar. Önünde başka bir işlem bulunmadığı hâlde on dakikayı aşan her durum yavaş değil, takılmış kabul edilmelidir.

Queued durumundaki bir deployment için retry yapmalı mıyım? Önce cancel etmeden retry yapmayın. Serialise edilmiş bir pipeline'da retry, takılan deployment'ın arkasında queue'ya girer ve aynı engeli devralır.

Takılan bir deployment sitemi erişilemez hâle getirir mi? Getirmemelidir. Traffic'i yalnızca yeni bir release health check'i geçtikten sonra değiştiren bir platformda çalışan version süreç boyunca traffic sunmaya devam eder — queued veya failed bir deploy, gerçekleşmemiş bir release'tir; outage değildir.

Birden fazla service neden aynı anda queue'ya giriyor? Çünkü ortak bir dependency kullanıyorlardır ve bu dependency neredeyse her zaman kodunuzdaki bir şeyden ziyade Git provider veya build fleet'tir.