GITLAB - une âme charitable pour m'expliquer le process dans Gitlab, svp?

Communauté Scrum Life
,
1

Bonjour!

Je replace le contexte, très brièvement : je suis Scrum Master dans une très petite équipe de dévs qui travaillent à maintenir (+ qq nouvelles features de temps en temps) une appli vieille de 7/8 ans.
Ils travaillent avec Gitlab.
Je n’ai aucun background technique, mais j’ai qq ami-es dans l’informatique + j’ai fait une formation de reconversion comme cheffe de projet informatique => j’ai les bases (concepts généraux, terminologie).

Ni la P.O. ni moi ne comprenons vraiment bien comment ils travaillent, et jusqu’ici je n’ai pas réussi à obtenir de l’équipe des explications claires et uniformes sur leur process.

Plutôt que m’échiner inutilement, et continuer de passer pour la débile de service (je sens bien qu’ils ont l’impression de m’avoir expliqué cent fois les choses), je me dis que je peux peut-être trouver mes infos ailleurs = ici! :smiley:

Ce forum étant devenu, j’avoue, mon havre de réconfort, quand ça ne va pas.
@const et @jplambert vous pouvez me citer dans vos communications d’auto-promo, sans problème :wink:

Si quelqu’un-e avait la patience de répondre à certaines de mes questions, ou simplement de partager la façon dont sa propre équipe travaille avec Gitlab, par exemple, ça pourrait beaucoup m’aider, je pense.

J’ai notamment du mal à comprendre comment on est censé savoir qu’un ticket (PBI) est déployé en Préprod ou en Prod.
Apparemment, le seul moyen de le savoir, serait d’aller dans la Release Pré-prod pour y trouver la liste des tickets.
Pour savoir si la release est une Préprod ou Prod, il faut compter sur un des humains de l’équipe, qui l’aurait annoncé (dans notre canal de Chat). Sans quoi, il n’y aurait aucun moyen de distinguer les releases Prod et Preprod.

D’une façon générale, je trouve ardu de savoir où en est tel ou tel ticket. Nous avons une étiquette « Merged », qui indique si le ticket est mergé ou pas, et il existe deux étiquettes « Develop » et « Master » censées respectivement désigner les branches Develop et Master.
J’avais cru comprendre que les Dévs devraient mettre une étiquette Develop ou Master en pluss de l’étiquette « Merged », pour indiquer sur quelle branche le ticket est mergé, mais finalement, on vient de me dire que non. Que c’est pas comme ça qu’on fait…
Une chatte (non technique) n’y retrouverait pas ses petits…

Quand je cherche à savoir, on me répond « t’façon, c’est pas important pour toi, ça, c’est un outil pour les Dév, t’as pas besoin de savoir ». :no_mouth:

Moralité : à votre bon coeur, mesdames, messieurs, si quelqu’un-e a le temps et le courage d’essayer de m’expliquer, je lui/leur serais reconnaissante pour l’éternité! :kissing_heart:

2

D’abord il faudra que tu aies les droits en lecture de ton projet sur Gitlab sans quoi, tu ne pourras rien voir. Au niveau de l’outil que vous utilisez pour suivre votre avancement, type jira, tu devrais avoir l’indication de la version dans laquelle ton ticket a été traité. Concernant Gitlab, une fois que ton ticket est déployé, tu auras l’indication de la version, donc si c’est mergé de la préprod sur la prod, ton ticket apparaitra aussi dans le contenu de la version de ta branche prod…
Si tu regardes l’arborescence de ta branche, tu y trouveras tous les tickets qu’elle contient avec également les étiquettes correspondant à tes versions releasées… tu devrais ainsi pouvoir retrouver ce que tu cherches.
Si ce n’est pas comme ça, c’est une ligne de commande à ajouter lorsque l’équipe release pour que l’étiquette de la version apparaisse… ça vaut le coup d’ajouter ça dans votre process.
De mon côté, j’étais dev, suis passé PO, on m’a retiré tous les droits, donc plus possible pour moi de suivre quoi que ce soit sur gitlab… utilisant Jira, j’exige donc que les devs indiquent sur quelle version un ticket est commité et au moment de la release, on renomme le nom de version snapshot avec son vrai nom/numéro.
Ca n’évite pas les erreurs, mais sans l’accès à gitlab en lecteur, tu ne pourras pas faire beaucoup mieux…
En espérant avoir un peu clarifié l’histoire :slight_smile:

3

Bonjour la transparence… oO

4

t’as vu ça ? c’est beau hein !

5

Qu’est ce qui a motivé cette décision ?

6

c’est la loi du tout ou rien… personne n’a les droits en dehors des devs sur gitlab… quand je leur ai dit qu’il y avait des droits en lecture également, l’argument qui m’avait été retourné était une histoire de coût de la licence :wink: mais bon… en dehors de cela, tu imagines bien qu’en étant un PO qui a un bagage technique, voir ce que les devs ont écrit pour éviter de laisser partir en prod un code mal écrit, c’était quelque chose d’important pour moi pour garantir un niveau de qualité acceptable, mais non, à la place, c’est devenu : ton rôle est uniquement fonctionnel, laisse les équipes techniques faire leur travail… bref. Mais ne nous éloignons pas du sujet de ce fil :wink:

7

Bonjour Franck,

Merci pour ton message :slight_smile:

Sur Gitlab, j’ai des droits en tant que « Developer » (je m’en rends compte à l’instant, après être allée vérifier, car avant, je n’étais que « Reporter »).

Tu dis :

Concernant Gitlab, une fois que ton ticket est déployé, tu auras l’indication de la version, donc si c’est mergé de la préprod sur la prod, ton ticket apparaitra aussi dans le contenu de la version de ta branche prod…

OK. Je peux la voir en passant par où, la branche prod, stp?

8

Dans un sens ils ont raison, c’est leur outil de travail. Par contre, là où tu peux les challenger c’est la compréhension de ta partie. « Ok, par contre moi je ne comprends pas ce qui est en préprod ou pas, et ça c’est un problème pour bien faire mon travail. Que me proposez-vous pour que ce soit clair pour moi ? »

Car oui, tu n’as pas forcément besoin de savoir leur process de dev (même si ça peut t’intéresser), mais tu as d’autres besoins.

Pour moi : leur comportement est nul (mais sûrement logique).

1 « J'aime »
9

Finalement, à force de relire ta réponse, je crois que j’ai fini par la comprendre.
Détrompe-moi, si c’est pas ça : tu confirmes que c’est bien l’annonce verbale faite par un des dév que telle ou telle release est faite en Preprod ou en Prod, qui va me permettre de connaître l’existence d’une release, que je vais aller voir dans Gitlab (dans le menu « Deploy », puis « Releases »), et dans laquelle j’aurai la liste des tickets déployés.

Autrement dit, il n’y a pas moyen, juste en regardant les « boards » ou un ticket lui-même de savoir s’il est déployé en Préprod? (En Prod, en général, les dév « ferment » les tickets).

10

Oh si, y’a pleins d’outils qui peuvent être mis en place pour que ça puisse se faire automatiquement plutôt qu’avec une annonce orale. Des bots slack/teams, des notifs mails, de sms ou des pigeons voyageurs. Maintenant, si tu veux faire quelque chose de rigolo, je t’invite à créer une US qui ressemblerait à :

En tant que Scrum Master
Je souhaiterais pouvoir être tenue au courant des mises en preprod/prod de manière écrite et traçable
Afin de ne pas avoir à gérer en charge cognitive des annonces orales qui peuvent arriver à des moments où je ne suis pas disponible notamment, en plus de pouvoir revenir dessus plus tard.

2 « J'aime »
11

Techniquement si. Les dev peuvent ajouter une colonne « déployé en preprod » et une « déployé en prod » et ranger les tickets au bon endroit.

1 « J'aime »
12

c’est vraiment génial une communauté, tu n’as même pas besoin de répondre, les autres le font pour toi :slight_smile: oui tu peux, tout dépend de l’outil que vous utilisez aujourd’hui pour suivre vos tickets si vous en utilisez un… si vous êtes en mode post-it, ajouter une colonne comme l’a proposé @const et mettre les tickets dans la bonne colonne… pareil avec un outil en ligne… et sinon, côté gitlab, toujours pareil, tu cliques sur la release et tu vois ce qui y est…

1 « J'aime »
13

J’adore! :sweat_smile:

Ca me semble impossible, cependant : l’équipe est en sous-effectif, y a qu’un seul dév vraiment Senior, et la P.O. n’est pas très collaborative = vont me dire qu’ils n’ont pas que ça à faire.

Sans parler des chieurs dans mon équipe (surtout une, en fait, une caractérielle qui fait flipper tout le monde) qui vont sûrement re-dire « mais en quoi ça te concerne? C’est pas ton boulot, ça!? »

14

OK, du coup, je fais écho à ce qu’on t’a dit dans un autre thread: environnement toxique, protège toi.

1 « J'aime »
15

Eh bien, deux étiquettes existent qui sont censées indiquer où est mergé le ticket (« Develop » et « Master » pour Develop et Preprod), mais finalement, la QC caractérielle m’a dit que, non, non, c’est pas ça, on fait pas comme ça. Et, en effet, il semble que de nombreuses fois, les dév oublient de rajouter ces étiquettes aux tickets.

Tout compte fait, je ne sais pas si les autres dév préfèrent ne pas la contredire, et se rangent derrière elle, sachant qu’elle a tort, ou si c’est moi qui n’ai pas compris à quoi servent ces étiquettes.
Et je n’ose plus demander.

J’attends que la P.O. revienne de vacances. Si elle me dit qu’elle aussi est larguée, j’organiserai un meeting pour re-re-re-clarifier les choses. Sinon, je laisserai tomber.

16

Je précise quand même qu’on est en full-remote = les annonces orales sont toujours doublées d’un message dans notre canal (Chat) d’équipe.

17

Merci Franck :slight_smile:

On est en full-remote et on travaille donc uniquement avec des outils en ligne.
On a un tableur Google sheet pour le calcul de la vélocité, où les dév, aux Daily, indiquent un pourcentage de progression du ticket, mais, sur la fin du process (quand les tickets ont été acceptés par la P.O., notamment) on a souvent des erreurs & oublis de mise à jour de ce tableur.

Quand j’en ai fait la remarque, on m’a répondu : « C’est pas là qu’il faut regarder, c’est dans Gitlab. On ne veut pas, nous, dév, avoir à reporter des infos d’un outil vers l’autre ». Autrement dit, c’est à moi d’aller dans Gitlab si je veux des infos.

18

Gitlab sera rapide à appréhender. Dans la mesure du possible éliminez la multiplication des outils donc le reporting faites le à un seul endroit et base toi sur ce qui est fait pas ce qu’il reste à faire. C’est dans ta version ou pas à la fin du sprint le reste sera pour le prochain… ou pas. Ne demande pas aux devs de saisir des RAF… ca me semble suffisant de communiquer sur ce qui est réellement livré.
Pour la vélocité tu te bases sur les sprints précédents avec les tickets livrés dans ta version et utilises des Story Point ou points de complexité pas besoin d’utiliser une notion de temps qui de toute façon sera fausse… et faites cette estimation au début du sprint pas au fur et à mesure. Prends la vélocité moyenne sur par exemple les 5 derniers sprints pour savoir ce que l’équipe pourrait embarquer dans le sprint à venir…

19

C’est pas ton boulot de savoir ce qui est en prod ou pas ??

20

Ben je finis par penser que non…
Mon seul argument, c’est que si le client me demande l’info (ou mon management), j’ai envie de pouvoir la fournir.
Je ne saurais pas quoi répondre d’autre si on me demandait…

En l’occurrence, mon problème initial c’était de savoir identifier un ticket dans Gitlab qui soit merged sur Develop OU sur Master, car les dév souhaitent faire les démos de tickets qui soient déjà déployés en Préprod.
Je voulais donc aider à la préparation de la réunion, pour qu’elle ne dure pas trop longtemps, et j’avais besoin d’identifier les tickets en Preprod.
Je vous passe les autres détails.

A la relecture des différents commentaires ci-dessus (exceptés ceux que je ne comprends pas! :sweat_smile:), j’ai tendance à penser que, oui, c’est raisonnable d’attendre des dév qu’ils posent, dans Gitlab, l’étiquette « Develop » ou « Master » sur leur ticket, en complément de l’étiquette « Merged », pour indiquer où ce ticket est mergé.