Η ανάπτυξη έχει κολλήσει σε queued: Τι να ελέγξετε πρώτα

Μια ανάπτυξη που έχει κολλήσει σε queued είναι μία από τις λιγότερο κατατοπιστικές αστοχίες που μπορεί να σας εμφανίσει μια πλατφόρμα. Τίποτα δεν έχει καταρρεύσει. Δεν έχουν εμφανιστεί logs, επειδή δεν έχει εκτελεστεί τίποτα. Το release απλώς παραμένει εκεί και κάθε refresh εμφανίζει την ίδια λέξη.

Το εκνευριστικό είναι ότι το "queued" καλύπτει τουλάχιστον τέσσερις διαφορετικές καταστάσεις, οι οποίες δεν έχουν καμία σχέση μεταξύ τους. Το να καταλάβετε σε ποια βρίσκεστε απαιτεί περίπου τριάντα δευτερόλεπτα και καθορίζει αν πρέπει να περιμένετε, να κάνετε retry ή να αναζητήσετε την αιτία κάπου εντελώς αλλού.

Τι σημαίνει πραγματικά το "queued"

Μια deployment σε queued έχει γίνει αποδεκτή και έχει καταγραφεί, αλλά δεν έχει ακόμη ανατεθεί σε worker. Ανάμεσα σε αυτές τις δύο στιγμές, πρέπει να ισχύουν μερικά πράγματα:

• Η πλατφόρμα πρέπει να κάνει fetch τον κώδικά σας, κάτι που συνήθως σημαίνει ένα API call προς τον Git provider σας.
• Πρέπει να υπάρχει διαθέσιμο build slot.
• Οποιοδήποτε prerequisite του release πρέπει να έχει ολοκληρωθεί — ένα migration step, μια volume operation ή ένα προηγούμενο deployment της ίδιας υπηρεσίας.

Αν κάποιο από αυτά είναι μπλοκαρισμένο, η καταχώριση υπάρχει, αλλά η εργασία δεν ξεκινά. Αυτός είναι ολόκληρος ο μηχανισμός. Δεν είναι μυστήριο, όμως τα περισσότερα dashboards εμφανίζουν και τις τέσσερις περιπτώσεις με την ίδια λέξη.

Οι τέσσερις περιπτώσεις, με τη σειρά που αξίζει να τις ελέγξετε

1. Ο Git provider σας αντιμετωπίζει προβλήματα

Αυτή είναι η συνηθέστερη αιτία και η μοναδική για την οποία δεν μπορείτε να κάνετε κάτι. Η πλατφόρμα ζήτησε το repository σας και έλαβε αργή απάντηση ή error. Αν πολλά άσχετα services μπουν σε queue ταυτόχρονα και κανένα δεν μοιράζεται κώδικα με τα υπόλοιπα, η κοινή dependency είναι ο provider.

Ελέγξτε πρώτα τη status page του provider σας. Ένα deploy που περιμένει απάντηση από upstream API θα ολοκληρωθεί μόνο του και το retry απλώς προσθέτει άλλη μία καταχώριση στη λίστα — γι’ αυτό μια queue που έχει κολλήσει συχνά καταλήγει σε πέντε queues που έχουν κολλήσει.

2. Κάτι που προηγείται δεν έχει ολοκληρωθεί

Οι περισσότερες πλατφόρμες εκτελούν σειριακά τα deployments ανά service, και σωστά: δύο builds που γράφουν το ίδιο image tag δεν είναι race που θέλετε να κερδίσετε. Αν ένα προηγούμενο deployment του service εξακολουθεί να εκτελείται — ή, ακόμη χειρότερα, θεωρείται ότι εκτελείται επειδή ένας worker τερμάτισε χωρίς να ενημερώσει — το επόμενο περιμένει.

Στο Dockup, το dockup deployments εμφανίζει το ιστορικό με τα πιο πρόσφατα πρώτα και το status κάθε καταχώρισης. Αν εκείνο που βρίσκεται πάνω από το queued release σας δεν είναι σε terminal state, αυτή είναι η απάντηση και το cancelling ή η αναμονή μέχρι να λήξει είναι αυτό που θα ξεμπλοκάρει τη σειρά.

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

Το output του --json περιλαμβάνει το status και τη διάρκεια κάθε deployment, κάνοντας προφανές ότι «το προηγούμενο δεν ολοκληρώθηκε ποτέ», με τρόπο που ένα spinner δεν μπορεί.

3. Δεν υπάρχει capacity

Κάθε πλατφόρμα διαθέτει πεπερασμένο αριθμό build workers. Σε ένα shared tier, μια απότομη αύξηση δραστηριότητας σε ολόκληρη την πλατφόρμα μπορεί να σας βάλει πίσω από τα builds άλλων χρηστών. Αυτό είναι πραγματικό, συνήθως διαρκεί λίγο και είναι η μία περίπτωση όπου η αναμονή είναι πράγματι η σωστή κίνηση.

Αυτό που έχει σημασία εδώ είναι αν μπορείτε να το δείτε. Μια θέση στην queue ή μια εκτίμηση χρόνου αναμονής μετατρέπει μια εμπειρία που μοιάζει με outage σε μια φυσιολογική διαδικασία. Ένα σκέτο "queued" δεν το κάνει.

4. Το deployment δεν επρόκειτο να ξεκινήσει ποτέ

Η δυσάρεστη περίπτωση: η καταχώριση δημιουργήθηκε, αλλά αυτό που υποτίθεται ότι θα την αναλάμβανε δεν το έκανε ποτέ. Ένας worker κατέρρευσε, ένα webhook χάθηκε ή ένα token έληξε ανάμεσα στο trigger και το fetch.

Η ένδειξη είναι ο χρόνος. Οι αναμονές σε queue μετρώνται σε δευτερόλεπτα έως λίγα λεπτά. Ένα deployment που παραμένει σε queued για δέκα λεπτά, χωρίς άλλο release μπροστά του, δεν περιμένει — έχει κολλήσει και θα παραμείνει κολλημένο.

Πώς να ξεχωρίσετε την αναμονή από το κόλλημα

Πριν κάνετε retry, συγκεντρώστε τρία στοιχεία:

1. Εκτελείται κάποιο άλλο deployment; Αν εκτελείται άλλο release του ίδιου service, βρίσκεστε στην περίπτωση 2 και πρέπει να το αφήσετε να ολοκληρωθεί.
2. Πόση ώρα βρίσκεται σε queued; Κάτω από δύο λεπτά είναι φυσιολογικό. Πάνω από δέκα δεν είναι.
3. Μπήκαν άλλα services σε queue την ίδια στιγμή; Αν άσχετα services σταμάτησαν όλα ταυτόχρονα, αναζητήστε την αιτία upstream και όχι στον κώδικά σας.

Αυτές οι τρεις απαντήσεις ξεχωρίζουν σχεδόν πάντα την «αναμονή» από την «ενέργεια».

Γιατί το retry συνήθως κάνει τα πράγματα χειρότερα

Η αυθόρμητη αντίδραση όταν ένα release έχει κολλήσει είναι να πατήσετε ξανά deploy. Σε ένα σειριακό pipeline αυτό είναι αντιπαραγωγικό: προσθέτετε μια δεύτερη καταχώριση πίσω από την πρώτη και, αν η πρώτη έχει πράγματι κολλήσει, η δεύτερη κληρονομεί το ίδιο block. Οι developers που το αντιμετωπίζουν συχνά καταλήγουν με μια στήλη από queued καταχωρίσεις, καμία από τις οποίες δεν θα εκτελεστεί μέχρι να ξεμπλοκάρει η αρχή της σειράς.

Αν πρόκειται να κάνετε retry, ακυρώστε πρώτα εκείνο που έχει κολλήσει. Ένα queued deployment που αποτυγχάνει με εμφανή τρόπο είναι πολύ πιο χρήσιμο από πέντε που παραμένουν εκεί.

Πώς το αντιμετωπίζουμε στο Dockup

Η σχεδιαστική απόφαση που έχει σημασία εδώ είναι ότι ένα deployment δεν θεωρείται ποτέ ότι εκτελείται χωρίς επιβεβαίωση. Κάθε deployment έχει terminal state και η μετάβασή του σε αυτό είναι που απελευθερώνει τη σειρά. Ένα build που τερματίζει χωρίς να ενημερώσει εξακολουθεί να λήγει και εξακολουθεί να απελευθερώνει το service.

Δύο ακόμη πράγματα βοηθούν περισσότερο απ’ όσο ίσως φαίνεται:

Τα stages έχουν ονόματα. Ένα deployment στο Dockup περνά από το fetching source, το building και το health gate, ενώ κάθε stage καταγράφει τη δική του διάρκεια. Όταν κάτι είναι αργό, μπορείτε να δείτε ποιο ακριβώς πράγμα είναι αργό, αντί να παρακολουθείτε μία μόνο λέξη. Το stageTimings υπάρχει σε κάθε deployment record, ακόμη και μέσω του --json.

Τίποτα δεν μπαίνει σε queue πίσω από ένα release που έχει ήδη αποτύχει. Αν το health check δεν περάσει ποτέ, το deployment ολοκληρώνεται — δεν παραμένει να καταλαμβάνει το service όσο αναρωτιέστε τι συμβαίνει. Η προηγούμενη έκδοση συνεχίζει να εξυπηρετεί traffic σε όλη τη διάρκεια, κάτι που αποτελεί το άλλο μισό του λόγου για τον οποίο ένα release που έχει κολλήσει δεν προκαλεί outage στο 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

Ο γενικός κανόνας

Το queueing δεν είναι failure mode. Το queueing χωρίς αιτιολογία είναι. Κάθε πλατφόρμα θα σας κάνει περιστασιακά να περιμένετε έναν Git provider ή ένα build slot· η διαφορά ανάμεσα σε μια ενόχληση πέντε λεπτών και σε ένα χαμένο απόγευμα είναι το αν το interface σας ενημερώνει σε ποια από τις τέσσερις περιπτώσεις βρίσκεστε.

Όταν αξιολογείτε πού θα εκτελέσετε κάτι, αξίζει να το ελέγξετε σκόπιμα: κάντε trigger ένα deploy και δείτε τι εμφανίζει η πλατφόρμα ανάμεσα στην αποδοχή και την έναρξή του. Αν η απάντηση είναι μία μόνο λέξη χωρίς timestamp, αργά ή γρήγορα θα χάσετε ένα ολόκληρο απόγευμα με αυτό το πρόβλημα.

Συχνές ερωτήσεις

Πόσο καιρό πρέπει να παραμένει ένα deployment σε queued; Από μερικά δευτερόλεπτα έως λίγα λεπτά σε μια υγιή πλατφόρμα. Οτιδήποτε ξεπερνά τα δέκα λεπτά, χωρίς να υπάρχει κάτι μπροστά του, πρέπει να αντιμετωπίζεται ως stuck και όχι απλώς ως αργό.

Πρέπει να κάνω retry σε ένα queued deployment; Όχι πριν το ακυρώσετε. Σε ένα σειριακό pipeline, το retry μπαίνει σε queue πίσω από εκείνο που έχει κολλήσει και κληρονομεί το ίδιο block.

Ένα deployment που έχει κολλήσει μπορεί να ρίξει το site μου; Δεν θα έπρεπε. Σε μια πλατφόρμα που αλλάζει το traffic μόνο αφού ένα νέο release περάσει το health check, η running έκδοση συνεχίζει να εξυπηρετεί traffic καθ’ όλη τη διάρκεια — ένα queued ή failed deploy είναι ένα release που δεν πραγματοποιήθηκε, όχι outage.

Γιατί μπαίνουν πολλά services σε queue ταυτόχρονα; Επειδή μοιράζονται μια dependency και αυτή είναι σχεδόν πάντα ο Git provider ή το build fleet, όχι κάτι στον κώδικά σας.