Déploiement bloqué dans la file d’attente : que vérifier en premier

Un déploiement bloqué dans la file d’attente est l’un des échecs les moins explicites qu’une plateforme puisse vous signaler. Rien n’a planté. Aucun log n’est apparu, puisque rien n’a été exécuté. Le release reste simplement là, et chaque actualisation affiche le même mot.

Le plus frustrant, c’est que « en file d’attente » recouvre au moins quatre situations différentes, qui n’ont rien à voir les unes avec les autres. Déterminer laquelle vous concerne prend environ trente secondes et permet de savoir s’il faut attendre, réessayer ou chercher ailleurs.

Ce que signifie réellement « en file d’attente »

Un déploiement en file d’attente a été accepté et enregistré, mais aucun worker ne lui a encore été attribué. Entre ces deux moments, plusieurs conditions doivent être réunies :

• La plateforme doit récupérer votre source, ce qui implique généralement un appel d’API à votre fournisseur Git.
• Un slot de build doit être disponible.
• Tout prérequis du release doit être terminé — une étape de migration, une opération sur un volume ou un déploiement précédent du même service.

Si l’un de ces éléments est bloqué, l’enregistrement existe, mais le travail ne démarre pas. C’est tout le mécanisme. Il n’y a pas de mystère, mais la plupart des dashboards affichent ces quatre cas avec le même mot.

Les quatre cas, dans l’ordre où il est utile de les vérifier

1. Votre fournisseur Git rencontre un problème

C’est la cause la plus fréquente, et celle contre laquelle vous ne pouvez rien faire. La plateforme a demandé votre repository et a reçu une réponse lente ou une erreur. Si plusieurs services sans lien entre eux se retrouvent en file d’attente au même moment, et qu’ils ne partagent pas de code, la dépendance commune est le fournisseur.

Consultez la page de statut de votre fournisseur avant toute autre chose. Un déploiement qui attend une API en amont se débloquera de lui-même, et réessayer ne fera qu’ajouter un nouvel enregistrement à la pile — c’est pourquoi une file d’attente bloquée se transforme si souvent en cinq files d’attente bloquées.

2. Un élément précédent n’est pas terminé

La plupart des plateformes sérialisent les déploiements par service, et c’est normal : deux builds qui écrivent le même tag d’image ne constituent pas une race que vous voulez gagner. Si un déploiement précédent de ce service est encore en cours — ou pire, est toujours considéré comme tel parce qu’un worker est mort sans le signaler — le suivant attend.

Sur Dockup, dockup deployments affiche l’historique du plus récent au plus ancien, avec le statut de chaque entrée. Si le déploiement juste au-dessus de votre release en file d’attente n’est pas dans un état final, vous avez votre réponse : l’annuler ou le laisser expirer est ce qui débloquera la file.

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

La sortie --json inclut le statut et la durée de chaque déploiement, ce qui rend évident le fait que « le précédent ne s’est jamais terminé », contrairement à un simple spinner.

3. Il n’y a plus de capacité disponible

Toutes les plateformes disposent d’un nombre limité de build workers. Sur un tier partagé, un pic d’activité sur l’ensemble de la plateforme peut vous faire passer derrière les builds d’autres utilisateurs. C’est une situation réelle, généralement brève, et le seul cas où attendre est véritablement la bonne décision.

L’important est de pouvoir le voir. Une position dans la file ou une estimation du délai transforme une expérience qui ressemble à une panne en situation normale. Un simple « en file d’attente » ne le permet pas.

4. Le déploiement n’allait jamais démarrer

C’est le cas problématique : l’enregistrement a été créé, mais l’élément censé le prendre en charge ne l’a jamais fait. Un worker a planté, un webhook a été perdu ou un token a expiré entre le déclenchement et la récupération de la source.

L’indice, c’est la durée. Les attentes dans une file se mesurent en secondes ou en quelques minutes. Un déploiement en file d’attente depuis dix minutes, sans autre release devant lui, n’attend pas : il est bloqué et le restera.

Comment distinguer une attente d’un blocage

Avant de réessayer, rassemblez trois informations :

1. Un autre déploiement est-il en cours ? Si un autre release du même service est en cours d’exécution, vous êtes dans le cas 2 et vous devriez le laisser tranquille.
2. Depuis combien de temps est-il en file d’attente ? Moins de deux minutes est normal. Plus de dix minutes ne l’est pas.
3. D’autres services se sont-ils retrouvés en file d’attente au même moment ? Si des services sans lien se sont tous arrêtés simultanément, cherchez du côté de l’amont, pas de votre code.

Ces trois réponses permettent presque toujours de distinguer « attendre » de « passer à l’action ».

Pourquoi réessayer aggrave généralement la situation

Face à un release bloqué, le premier réflexe consiste à relancer le déploiement. Sur un pipeline sérialisé, c’est contre-productif : vous ajoutez un deuxième enregistrement derrière le premier et, si le premier est réellement bloqué, le second hérite du blocage. Les développeurs confrontés à ce problème se retrouvent souvent avec une colonne d’entrées en file d’attente, dont aucune ne s’exécutera tant que la tête de file ne sera pas débloquée.

Si vous comptez réessayer, annulez d’abord celui qui est bloqué. Un seul déploiement en file d’attente qui échoue clairement est bien plus utile que cinq qui restent en attente.

Ce que nous faisons à ce sujet sur Dockup

La décision de conception importante ici est qu’un déploiement n’est jamais considéré comme étant en cours d’exécution indéfiniment. Chacun possède un état final, et c’est le fait de l’atteindre qui libère la file. Même un build qui s’arrête sans envoyer de rapport finit par expirer et libère le service.

Deux autres éléments sont plus utiles qu’il n’y paraît :

Les étapes sont nommées. Un déploiement Dockup passe par la récupération de la source, le build et le health gate, et chaque étape enregistre sa propre durée. Lorsqu’un élément est lent, vous pouvez voir lequel au lieu de regarder un seul mot. stageTimings figure dans chaque enregistrement de déploiement, y compris via --json.

Rien n’est mis en file derrière un release qui a déjà échoué. Si le health check n’aboutit jamais, le déploiement se termine : il ne reste pas à occuper le service pendant que vous vous demandez ce qui se passe. La version précédente continue de servir le trafic pendant toute la durée, ce qui explique aussi pourquoi un release bloqué ne constitue pas une panne sur 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 règle générale

La mise en file d’attente n’est pas un mode d’échec. La mise en file d’attente sans raison associée en est un. Toutes les plateformes vous feront parfois attendre un fournisseur Git ou un build slot ; la différence entre un désagrément de cinq minutes et une après-midi perdue tient à la capacité de l’interface à vous indiquer lequel des quatre cas vous concerne.

Lorsque vous évaluez l’endroit où exécuter quelque chose, vérifiez-le volontairement : déclenchez un déploiement et observez ce que la plateforme vous montre entre son acceptation et son démarrage. Si la réponse est un seul mot sans timestamp, vous finirez tôt ou tard par y passer une après-midi.

Questions fréquentes

Combien de temps un déploiement doit-il rester en file d’attente ? Quelques secondes à quelques minutes sur une plateforme saine. Au-delà de dix minutes, s’il n’y a rien devant lui, il faut le considérer comme bloqué plutôt que simplement lent.

Dois-je réessayer un déploiement en file d’attente ? Pas avant de l’avoir annulé. Sur un pipeline sérialisé, une nouvelle tentative se met en file derrière celui qui est bloqué et hérite du même blocage.

Un déploiement bloqué peut-il mettre mon site hors ligne ? Cela ne devrait pas arriver. Sur une plateforme qui ne bascule le trafic qu’après la validation du health check d’un nouveau release, la version en cours continue de servir les utilisateurs ; un déploiement en file d’attente ou en échec est un release qui n’a jamais eu lieu, pas une panne.

Pourquoi plusieurs services se retrouvent-ils en file d’attente en même temps ? Parce qu’ils partagent une dépendance, et qu’il s’agit presque toujours du fournisseur Git ou de la flotte de builds, plutôt que d’un problème dans votre code.