Porter un correctif

Un bug est en production, le correctif existe déjà sur la branche principale, et il faut le porter dans six dépôts sans ouvrir douze onglets GitLab. C’est l’écran Correctif : vous donnez une issue ou une branche, Deployer retrouve les commits, ouvre une branche et une merge request par projet touché, puis vous suivez et fusionnez depuis le même endroit.

Deployer ne crée aucun correctif : il porte un correctif qui existe. Il ne résout pas non plus les conflits : un cherry-pick en conflit se règle dans GitLab.

L'écran Correctif après résolution d'une issue. Rien n'est écrit avant le bouton « Créer le correctif ».

Faites glisser pour parcourir la capture

Qui peut DéveloppeurManagerAdministrateur

Tout le monde peut résoudre une issue, lire les commits et suivre l’état des merge requests. Créer un correctif et fusionner demandent le rôle de développeur au moins.

Dire ce qu’on porte

Un seul champ, « Issue ou branche », qui accepte l’un ou l’autre. Une référence d’issue contient un # ; un nom de branche n’en porte jamais.

1. Par une issue

   Tapez un numéro de ticket (3865) ou quelques mots de son titre : l’écran propose les issues trouvées dans les sources déclarées de l’espace, et choisir une suggestion lance la résolution. Vous pouvez aussi coller la référence complète, groupe/projet#3865. Sans source d’issues déclarée, il n’y a pas de suggestion ; la référence complète fonctionne toujours (voir Sources d’issues).

   

2. Par une branche

   Tapez le nom de la branche, par exemple hotfix/BUG-343. Deployer la cherche dans tous les projets liés : ceux qui l’ont sont cochés, avec leur dernier commit en contrôle. On fusionne alors la branche entière, il n’y a pas de commit à cocher. Un champ « Issue : facultative » permet de rattacher un ticket au suivi.

   

3. Par sélection manuelle

   « Sélection manuelle » est disponible en permanence, pas seulement après un échec : choisissez une source, un projet dans le rail, et cochez des commits dans son historique. Un filtre texte porte sur les commits déjà chargés, et le dit. Des repères intercalés situent les versions posées : « 1.0.0 · en service sur Production », pour ne pas porter un correctif qui y est déjà.

   

Lire le périmètre examiné

Après résolution, une ligne dit ce qui a été cherché et où : « 4 commits trouvés dans 2 projets, via les merge requests liées à l’issue », ou « 200 derniers commits de master, 12 projets examinés ». Sans elle, « aucun commit trouvé » serait ambigu : pas de correctif, ou pas assez cherché ? Un résultat vide propose de passer en sélection manuelle.

Chaque projet porte un badge : « commits trouvés », « aucun commit » (examiné, rien trouvé), « non examiné » (l’historique n’a pas été lu, aucune conclusion), ou une erreur GitLab avec son message brut, les autres projets restant utilisables. Les merge requests de l’issue qui ne visent pas la branche principale sont comptées à part : ce sont souvent celles que Deployer a lui-même créées.

Composer le correctif

Le panneau de droite montre ce qui va partir, et rien n’est écrit avant son bouton.

1. Vérifier la sélection et l'ordre

   Chaque commit retenu porte un rang. Les cherry-picks s’appliquent du plus ancien au plus récent, chacun sur le résultat du précédent ; l’ordre est modifiable, pour le cas où un commit en corrige un autre. Le plafond est de 50 commits par projet, annoncé à partir de 40.

   

2. Nommer la branche

   Le nom est pré-rempli d’après le motif de l’espace, hotfix/3865 par défaut. Sans issue, le repli réglé dans la configuration s’applique : trois mots tirés au sort, ou le titre du premier commit. Avec plusieurs cibles, chaque cible reçoit un nom suffixé, modifiable un par un.

   

3. Choisir les cibles

   Voir ci-dessous, la forme dépend du mode.

   

4. Créer

   « Créer le correctif » ouvre la branche et une merge request par projet touché, cible par cible dans l’ordre de promotion. La progression est visible ; un échec sur une cible n’annule pas les autres. Avec une seule cible, l’écran bascule sur son suivi ; avec plusieurs, il reste sur le résultat, qui liste chaque cible avec son bouton « Voir le suivi ».

   

Ce qu’une merge request de correctif ne fait pas

• Elle est ouverte par le compte du token de l’espace, sauf si vous avez rattaché votre compte GitLab (menu « Mon compte GitLab ») : elle porte alors votre nom et vos droits.
• Personne n’est notifié par Deployer : c’est GitLab qui notifie selon vos règles.
• La merge request de retour vers la branche principale n’est pas créée : c’est à vous de la faire, et Deployer ne la voit pas.

Suivre et fusionner

Le suivi. Un bouton « Fusionner vers … » par cible, jamais un bouton global.

Faites glisser pour parcourir la capture

En tête d’écran, un bandeau replié liste les cinq correctifs les plus récents, les en cours devant, avec le compte exact des correctifs en attente. Cliquer une ligne ouvre son suivi dans le panneau : les projets, leur merge request (lien vers GitLab), leur état, les échecs avec le message brut.

1. Lire l'état

   Chaque projet est « ouverte », « fusionnée », « fermée » ou « échec de création » (un conflit de cherry-pick, le cas d’échec normal, à résoudre dans GitLab). L’état est un cache, relu à l’ouverture du correctif et sur demande, jamais en boucle : la date de lecture est affichée.

   

2. Fusionner

   « Fusionner vers prod » fusionne toutes les merge requests encore ouvertes de ce correctif sur cette cible. GitLab peut en refuser : tant que le pipeline d’une merge request tourne, ce n’est pas une panne, réessayez dans quelques minutes ; un conflit se résout à la main dans GitLab. Ce qui est fusionné le reste ; rejouer ne retouche que le reste.

Quand le correctif porte une issue, le panneau montre aussi l’état par cible : « #3865, test fusionné, prod en attente ». Seules les cibles que Deployer a visées y figurent : la merge request de retour vers la principale, ouverte à la main, lui est invisible.

L’historique : l’écran Correctifs

Le bandeau de l’écran Correctif ne montre que les cinq derniers. Au-delà, l’écran Correctifs, dans le menu Historique, liste tout, du plus récent au plus ancien, avec un seul filtre : « Tous » ou « En cours » (au moins une merge request encore ouverte).

L'écran Correctifs. L'état affiché est celui lu en base, daté ; le détail relit GitLab.

Faites glisser pour parcourir la capture

Une ligne porte la référence de l’issue (ou le titre seul pour un correctif d’urgence), la branche créée et la cible, la version corrigée en mode tag, l’avancement (« 3 fusionnées · 1 en attente · 1 en échec »), qui et quand, et la fraîcheur de l’état.

1. Ouvrir un correctif

   « Ouvrir » relit l’état chez GitLab, puis montre les faits (branche créée, cible, commits pris depuis, créé par, version corrigée), une carte par projet, les refus de fusion, et en mode tag l’encart de la branche de maintenance qui renvoie vers Déploiements. « Fusionner » y est aussi, pour les merge requests encore ouvertes.

   

2. Retirer du suivi

   Proposé seulement sur un correctif qui n’a produit aucune merge request (création en échec dans tous les projets). Il retire la ligne de suivi, pas les branches ni les merge requests dans GitLab.