La branche assemblée
Une branche d’essai reconstruite depuis la principale et les fonctionnalités prêtes : lire, reconstruire, geler, exclure.
Vérifié dans l’application le 5 septembre 2026
Entre « la merge request est ouverte » et « elle est fusionnée dans la principale », il faut essayer. La branche assemblée est une branche d’essai, dev par défaut, que Deployer reconstruit à chaque changement depuis la branche principale et les fonctionnalités éligibles, puis pousse dans chaque dépôt. La CI de l’équipe fait le reste : c’est elle qui déploie l’environnement d’essai, jamais Deployer.
L’écran Assemblage répond à trois questions : qu’est-ce qui tourne sur la branche assemblée, pourquoi ma fonctionnalité n’y est pas, et qu’est-ce qui s’est passé. C’est un écran qu’on lit en quatre secondes ; ses actions sont des recours.
Qui peut Product ownerDéveloppeurManagerAdministrateur
Tout le monde lit l’écran, les candidats et l’historique. Reconstruire, geler, exclure et réintégrer demandent le rôle de product owner au moins. La mise en route et les réglages sont dans la configuration, réservée à l’administrateur.
Mettre le module en route
Qui peut Administrateur
Le module est éteint à la création d’un espace, donc le premier contact avec l’écran est un état vide qui renvoie l’administrateur vers Configuration, section « Assemblage », et dit aux autres rôles qui contacter.
- Activer le module et nommer la branche
Tant que le module est éteint, l’onglet n’existe pas. Le nom de la branche assemblée est un champ libre,
devpar défaut, validé comme une référence Git : elle n’existe pas encore quand on la nomme. Le changer ne renomme rien et ne supprime rien dans GitLab.
- Choisir le projet orchestrateur
La reconstruction tourne dans un pipeline GitLab, sur un projet dédié cherché dans tout GitLab, jamais parmi les projets liés (il s’assemblerait lui-même). Le gabarit de pipeline se télécharge à côté, avec la marche à suivre en trois lignes. Le sélecteur signale un accès inférieur à Maintainer et un projet déjà déployé.
- Poser le jeton d'assemblage
Facultatif : sans lui, les assemblages passent par le jeton de la connexion GitLab. Posé, il se montre par son préfixe, comme le token de connexion, avec « Remplacer » et une corbeille ; rien ne part avant « Enregistrer ». Son échéance est affichée en dessous, en ambre à trente jours ; « Expiration inconnue » n’est pas une panne, certains jetons ne s’introspectent pas.
- Installer les webhooks
C’est par eux que Deployer apprend qu’une merge request a bougé. L’état est relu chez GitLab projet par projet, et le bouton installe ce qui manque. Un projet sans hook fonctionne en aveugle : un bandeau le nommera sur l’écran Assemblage.
- Exiger l'approbation, ou non
Par défaut, une merge request non approuvée peut être embarquée : l’essai précède l’approbation. Exiger l’approbation a une contrepartie : une approbation remise à zéro à chaque push fait sortir la fonctionnalité de l’environnement d’essai au moment où le développeur vient de la corriger.
Chaque étape affiche ce qui a été constaté chez GitLab, pas ce que Deployer croit avoir fait : une mise en route qui s’annonce réussie et ne fonctionne pas se découvrirait des heures plus tard.
Lire la carte d’état
Une phrase, lisible sans rien connaître du module : « dev = master@a1b2c3 + 3 fonctionnalités, reconstruite il y a 4 minutes ». Puis l’état du dernier assemblage (réussi, partiel, en cours, en échec, expiré), le nombre de dépôts repoussés (« 2 projets sur 16 repoussés » est une information, les quatorze autres étaient déjà à jour), et l’état agrégé des pipelines de CI sur la branche, dépôt par dépôt, recoupé sur le commit poussé : un pipeline vert sur un autre commit est compté à part, « 1 dépôt sur une autre version ».
La carte compte ce que la branche porte, pas ce qui lui a été envoyé : un candidat refusé à la fusion par la construction n’y est pas. Tant qu’un assemblage tourne, la phrase dit « assemble n fonctionnalités ». Tant qu’aucun n’a tourné, elle dit ce qui partirait.
La barre d’écran porte deux fraîcheurs : la date du dernier événement GitLab reçu, et la date du dernier assemblage. Un écran alimenté par événements peut afficher une photo périmée avec aplomb : après un silence anormalement long sur un espace actif, un bandeau propose de vérifier les webhooks. « Relire GitLab » relance une lecture complète des merge requests ouvertes, quelques dizaines de secondes, visible par tous les membres.
La liste : quatre groupes
Les candidats sont rangés dans l’ordre de l’utilité : ce qui tourne, ce qui devrait tourner et ne tourne pas, ce qui n’est pas prêt, ce que personne n’a proposé.
| Groupe | Ce qu’il contient |
|---|---|
| Embarquées | Les fonctionnalités sur la branche, numérotées dans l’ordre d’assemblage. Le rang explique qu’une fonctionnalité perde un conflit contre une autre : le premier arrivé garde sa place. |
| Écartées | Ce qui devrait y être et n’y est pas, avec la cause sur la ligne : conflit avec qui, exclue par qui, plus éligible. La seule catégorie sur laquelle on agit. |
| En attente | Ce qui n’est pas encore éligible, avec ce qui manque et où : « attend frontend », « CI en échec sur backend ». Ce n’est pas un défaut. |
| Brouillons | Replié d’entrée : leur auteur a lui-même dit qu’ils n’étaient pas prêts. Une exclusion ou un conflit les sortent de ce groupe. |
Une carte porte le board, le numéro, le titre de l’issue, et un badge par projet touché dont l’icône dit l’état de sa merge request : coche verte assemblable, croix ambre bloquée, pendule grise pas encore tranchée par GitLab. Une merge request sans issue s’affiche comme les autres, avec la mention « sans issue » : elle est légitime, mais coordonnée avec rien.
- Filtrer et chercher
Le même rail que Fonctionnalités : Boards, Ce qui retient (le conflit de GitLab contre la principale, qui se règle par un rebase, est distinct du conflit entre deux candidats, qui se règle en attendant le prochain assemblage), Sur la branche, Dépôts, Étiquettes. La recherche fouille aussi la branche source des merge requests : on arrive souvent ici avec un nom de branche sous les yeux. Le filtre ne touche que la liste, jamais la carte d’état.
- Ouvrir un candidat
Le panneau dit, dans l’ordre : ce que c’est (le board, le numéro, le titre, les étiquettes de l’issue) ; pourquoi elle est là ou pas (« conflit avec #3857, déjà assemblée, sur pom.xml dans backend ; le premier arrivé garde sa place, #3857 est éligible depuis mardi 9 h ») ; par quoi ça passe (les merge requests, avec leur état vis-à-vis de l’assemblage, pas de la fusion) ; le recours ; et l’historique des verdicts du candidat, qui répond à « depuis quand est-ce cassé ».
Reconstruire, geler, exclure
Qui peut Product ownerDéveloppeurManagerAdministrateur
Les trois actions sont des recours. En temps normal, la branche se reconstruit toute seule : un webhook signale qu’une merge request a bougé, une courte fenêtre s’ouvre (« Reconstruction dans 30 s »), et l’assemblage part.
- Reconstruire
« Reconstruire » relance un assemblage. Quand rien n’a changé depuis le dernier, Deployer le refuse et propose « Reconstruire quand même ? » : c’est le chemin de la réparation, par exemple quand la reconstruction précédente n’est jamais partie. Un assemblage déjà en cours ne se double pas.
- Geler
« Geler » fige la branche pour une durée choisie, le temps d’un essai qui ne doit pas bouger sous les pieds. La carte prend un bandeau bleu qui dit qui, depuis quand, jusqu’à quand, pourquoi, et combien de changements attendent ; « Reconstruire » disparaît, « Dégeler » prend sa place. La raison est suggérée, pas exigée : geler doit tenir en un clic. À l’expiration, la reconstruction repart toute seule si des changements attendent.
- Exclure une fonctionnalité
En bas du panneau d’un candidat, « Exclure des assemblages » le retient pour une durée choisie, avec une raison obligatoire : c’est la seule explication que recevra son auteur. La fonctionnalité passe dans les écartées, marquée « Exclue par Claire : casse le build front », avec l’échéance. « Réintégrer » et « Prolonger » sont alors proposés. C’est le seul recours quand la simulation ne voit rien mais que la construction casse.
L’historique des assemblages
Dans le menu Historique, l’entrée « Assemblages » liste chaque assemblage : quand, déclenché par quoi (demandé, dégel, ou un changement), son état, combien de fonctionnalités il portait, et le lien vers le pipeline de l’orchestrateur. Ouvrir un assemblage montre ce qui est entré et ce qui a été refusé, candidat par candidat. Un lien discret sur la carte d’état y mène aussi, à côté de l’état du dernier assemblage : c’est là qu’on va après avoir lu « échoué ».
| État d’un assemblage | Ce que ça veut dire |
|---|---|
| Réussi | La branche a été poussée partout, les dépôts déjà à jour n’ont pas été repoussés. |
| Partiel | Certains dépôts ont échoué ; ils sont nommés, avec le lien vers leur pipeline. Les autres sont bons. |
| Échoué | Rien n’a été poussé. Le pipeline dit pourquoi. |
| Expiré | Le job n’a pas rendu compte dans le délai. Ce n’est pas un problème de code : voir le pipeline. |
| Abandonné | Quelqu’un a arrêté un assemblage qui tournait. |
Deux états sains qu’il ne faut pas lire comme des erreurs : « Rien à assembler », quand aucune merge request n’est ouverte, la branche assemblée vaut alors la principale ; et « Rien ne partirait : les 10 fonctionnalités sont toutes retenues », qui est au contraire le cas à regarder de près.