Déployer
Lire la grille des environnements, déployer une branche ou mettre en service une version, lancer une action.
Vérifié dans l’application le 5 septembre 2026
L’écran Déploiements est l’entrée d’un espace en service. Il répond à une question : quelle version tourne où, et que puis-je promouvoir. Une tuile par environnement, dans l’ordre de promotion ; à droite, le détail projet par projet de la tuile sélectionnée.
Qui peut LecteurProduct ownerDéveloppeurManagerAdministrateur
Tout le monde lit l’écran en entier. Les boutons d’action (déployer, créer une version, exécuter un job, lancer une action) n’apparaissent que pour les développeurs, managers et administrateurs ; pour les autres rôles ils sont retirés, pas grisés.
Lire la grille
Chaque tuile est une ref : une branche suivie, ou un environnement. Elles se lisent dans l’ordre de la chaîne de promotion, et la première est sélectionnée à l’ouverture, toujours la même, pour que l’écran s’ouvre chaque matin au même endroit.
Ce qu’une tuile montre
| Zone | Ce qu’elle dit |
|---|---|
| Titre | Le nom de la branche (en mode branche) ou de l’environnement (en mode tag), avec le badge « principale » sur la branche de référence. |
| Version | Le numéro en service, avec la date et la personne qui a déployé. « Aucun déploiement » si la cible n’a jamais reçu de version. |
| Badges | « partiel » en ambre quand au moins un projet n’a pas reçu la version ; « échec » en rouge quand aucun projet n’a démarré. |
| Agrégat de pipelines | Un décompte, jamais un statut unique : « 1 en échec · 2 en attente d’action · 1 en cours · 3 sans pipeline · 12 à jour ». Seuls les nombres non nuls s’affichent. |
| Action | « Déployer » sur une cible, « Créer une version » sur la principale en mode tag. |
La pastille de la tuile prend la couleur du cas le plus grave : échec, puis en attente d’action, puis en cours, puis sans pipeline, puis à jour. « Sans pipeline » n’est pas une erreur : une branche suivie peut ne pas exister dans tous les dépôts, c’est le quotidien d’un projet neuf.
Quand une cible n’est pas déployable
Le bouton « Déployer » est grisé, avec une infobulle qui dit pourquoi :
- En mode branche, l’environnement n’a aucune branche source autorisée. À régler dans Configurer un espace.
- En mode tag, l’espace n’a livré aucune version : il faut d’abord « Créer une version » depuis la branche principale.
L’alerte de tête de grille
Dès qu’un environnement est dégradé, une ligne au-dessus de la grille le nomme : « 2 environnements demandent une action », avec un lien par environnement. Rouge s’il y a un échec, ambre s’il n’y a que des jobs en attente. Cliquer une entrée sélectionne la tuile et la fait défiler dans la grille.
Grouper et filtrer par étiquettes
Sur un espace à quinze cibles, la grille se lit mal : trois clients et cinq étages s’entrelacent dans l’ordre de promotion. Les étiquettes des environnements donnent les axes pour la réorganiser. Les deux contrôles n’apparaissent que si au moins un environnement porte une étiquette.
- Grouper
« Grouper » réorganise la grille en bandes, une par valeur de l’axe choisi, avec le compte de chaque bande. Rien n’est masqué : les cibles sans étiquette forment une dernière bande « Sans étiquette ». Le choix est mémorisé par espace.
- Filtrer
« Filtrer » ne garde que les cibles cochées : OU à l’intérieur d’un axe, ET entre axes. Le nombre de cibles masquées s’affiche sous le titre, et les puces retirables reprennent chaque valeur. Le filtre vit dans l’URL, donc dans le lien que vous partagez, et n’est pas mémorisé.
Le panneau de détail
Sélectionner une tuile ouvre le détail à droite : une carte par projet lié, dans l’ordre d’affichage des projets. Sur un petit écran, le panneau devient un tiroir par-dessus la grille.
L’en-tête
Le nom de la cible, le nombre de projets liés, la fraîcheur (« rafraîchi il y a 4 s »), les étiquettes de l’environnement en puces cliquables (cliquer une puce filtre la grille sur cette valeur), puis les boutons de lecture et les actions d’environnement :
- « Note de version » ouvre ce qui est parti dans la version en service, calculé entre les deux derniers déploiements. Absent tant que la cible n’a pas deux déploiements.
- « Évolutions à venir » ouvre ce qui attend d’y aller. Absent sur une cible jamais déployée.
- Les actions : les boutons manuels déclarés dans la configuration de l’environnement, voir plus bas.
Une carte par projet
| Ligne | Contenu |
|---|---|
| 1 | Le nom du projet, le badge de statut du pipeline. Le nom mène au projet dans GitLab. |
| 2 | Le chemin complet du dépôt. |
| 3 | Le numéro du pipeline (lien vers le pipeline), le commit court (lien vers le commit), la durée, l’auteur. |
| 4 | Les étapes du pipeline, une puce par étape avec l’état agrégé de ses jobs. |
| 5 | « Exécuter » quand le pipeline attend un job manuel, et le lien vers GitLab. |
Trois cas se distinguent : la ligne normale ; « Aucun pipeline sur cette ref », grisée, quand la branche n’existe pas dans ce dépôt (cas normal) ; et une erreur GitLab sur ce projet seulement, avec le message brut dessous, les autres projets restant lisibles.
Les jobs d’une étape
- Ouvrir une étape
Survoler une puce d’étape affiche « deploy · 5 jobs · 3 réussis, 2 en attente ». Cliquer la puce déplie la liste des jobs sous la carte ; recliquer la referme, cliquer une autre puce bascule. Un pipeline aval se déplie dans la carte du job qui l’a déclenché.
- Exécuter ou relancer
Chaque job porte une seule action : « Exécuter » s’il attend une main, « Relancer » s’il peut être rejoué. GitLab peut refuser malgré tout ; le refus s’affiche au retour et n’est pas conservé. Un job relancé est un nouveau job, qui remplace la ligne.
Déploiement partiel ou en échec
Quand la version en service est partielle, les projets qui ne l’ont pas reçue portent un liseré ambre et la mention « Version non déployée sur ce projet », suivie du message d’erreur brut de GitLab. Il n’est ni traduit ni reformulé : il nomme un réglage GitLab, par exemple le droit de poser des variables de pipeline, et c’est le terme exact qu’il faut chercher dans l’interface GitLab. Un déploiement en échec total ajoute un bandeau rouge en tête de panneau : rien n’a été mis en service.
Rafraîchissement
La ref sélectionnée se relit toutes les 5 secondes tant qu’un de ses pipelines tourne, toutes les 30 secondes sinon. L’aperçu de toutes les tuiles ne se relit qu’à l’ouverture et sur le bouton « Rafraîchir l’aperçu » : le rafraîchir en boucle coûterait des dizaines d’appels GitLab par minute. La fraîcheur affichée vient de l’heure du serveur.
Déployer
Qui peut DéveloppeurManagerAdministrateur
Le bouton « Déployer » d’une tuile de cible ouvre le dialog. La cible est celle de la tuile, en lecture seule : on ne choisit pas de cible ici.
- Choisir la branche source
La liste est restreinte aux branches sources autorisées de la cible ; le serveur refuse le reste. Le lien « Ce que cette branche embarque », sous le sélecteur, ouvre dans un nouvel onglet la note des évolutions à venir bornée sur la source choisie.
- Nommer la version
Le numéro est proposé d’après la dernière version de cette cible, et reste libre. Chaque cible a sa propre suite :
prod-1.2.3etqal-1.5.0sont indépendants, comparer deux tuiles n’a pas de sens.
- Déployer
Le bouton lance le déploiement sur tous les projets liés. Si la branche source manque dans certains projets, le refus les liste et rien n’est déployé. Une version déjà déployée intégralement est refusée ; un déploiement partiel rejoué avec le même numéro reprend là où il s’était arrêté.
- Choisir la version
Les versions livrées, plus récentes d’abord ; la première déployable est présélectionnée. Une version partielle (son tag manque dans un projet) est marquée « partielle : non déployable ». Redéployer la version courante ou remonter une version antérieure est possible, ce n’est pas une erreur.
- Lire ce que la version embarque
Le lien sous le sélecteur ouvre, dans un nouvel onglet, la note des évolutions entre la version en service et celle sélectionnée. C’est ici que la question se pose : passer la préproduction de 1.2.0 à 1.2.3, qu’est-ce que ça apporte ?
- Mettre en service
Si la CI du tag a échoué sur certains projets, le refus les nomme et un bouton « Mettre en service malgré tout » apparaît, seulement après ce refus précis. Les autres refus (tag absent, version incomplète) ne se contournent pas.
Créer une version
Qui peut DéveloppeurManagerAdministrateur
La version en construction
Entre « Créer une version » et « Déployer », une carte « Version en construction » apparaît dans la grille, du côté de la principale : le numéro, l’agrégat des pipelines de CI, et un verdict : « Construction des images en cours. », « Prête à déployer. », « CI en échec sur frontend. » ou « Aucune CI déclenchée sur ce tag. » (un dépôt sans règle CI sur les tags n’en produira jamais : ce n’est pas une attente). La carte disparaît quand la version est déployée, pas quand la CI finit. Cliquer la carte ouvre le panneau avec les pipelines par projet. Elle n’a pas de bouton « Déployer » : c’est la cible qui décide de ce qu’elle reçoit.
Les branches de maintenance
- Les branches actives sont listées : le nom de la branche, la version dont elle dérive, les environnements où cette version tourne encore. Le bouton de tag ouvre « Créer une version » avec la branche imposée et le numéro de correctif proposé (
1.0.0devient1.0.1). La version tague la branche là où elle existe, et le tag d’origine ailleurs : le tag est complet sur tous les projets, donc déployable. - Taguer ne déploie pas. La version apparaît dans l’écran Versions et devient sélectionnable dans le dialog « Déployer » des cibles.
- Les branches obsolètes sont comptées, pas listées : une branche est obsolète quand sa version n’est plus déployée nulle part, pas quand une version plus récente existe. « Nettoyer », réservé à l’administrateur, ouvre un dialog qui liste ce qui va disparaître, branche par branche et projet par projet, avant de supprimer.
- Cliquer une ligne ouvre le panneau avec l’état des pipelines de la branche.
Les actions d’environnement
Qui peut DéveloppeurManagerAdministrateur
Les boutons manuels déclarés dans la configuration de l’environnement s’affichent dans l’en-tête du panneau, au-dessus des cartes projet : reconstruire un index, vider un cache, relancer un service, avant une fenêtre de production.
- Lancer
Cliquer un bouton ouvre une confirmation qui rappelle la description de l’action et son dernier lancement (« Dernier lancement : hier 15:04, réussie »). Il n’existe aucun verrou contre un double lancement : cette ligne est la seule information qui permette de décider.
- Lire la réponse
La cible répond en quelques secondes : réussie, ou échouée avec son code. « Sans réponse » après dix secondes n’est pas un échec : l’opération a peut-être démarré, ne relancez pas trois heures de calcul pour rien. « Bloquée » veut dire que rien n’est parti, l’URL étant refusée : à corriger dans la configuration.
L’historique de tous les lancements se relit dans le menu Historique, entrée « Actions » : qui a lancé quoi, quand, et ce que la cible a répondu.
Le bandeau de connexion
Quand le token GitLab de l’espace est refusé, expiré ou que l’instance est injoignable, un bandeau rouge coiffe tous les écrans de l’espace, avec le geste à faire : fournir un nouveau token, élargir ses droits, vérifier l’URL, ou attendre la fin d’un quota. L’administrateur y trouve « Tester la connexion ». Un token qui expire bientôt donne un bandeau ambre, visible de tous les rôles : un manager doit pouvoir l’anticiper sans accès à la configuration.