Je ne sais pas sur Jira mais sur Slack, à chaque merge request déployée, le lead dev avait mis une fonctionnalité pour que la carte Trello mise en prod soit visible avec une étiquette qui indique où, en master ou preprod. De mémoire, un message type « MR preprod deployed » sous l’intitulé de la carte.
1 « J'aime »
Hello Paul!
Merci pour ton témoignage! 
Je crains que mon souci ne soit pas réglé avant un bail : le Dév Senior de l’équipe, qui est constamment sous l’eau pour cause de sous-effectif de l’équipe, a dit, assez clairement, qu’il ne souhaite pas avoir à indiquer ces infos (sur quel environnement les tickets sont déployés, par exemple). Qu’il a assez à faire comme ça. Ce qui est compréhensible.
Ma nouvelle idée, (en espérant que l’équipe ne s’y oppose pas), c’est de la faire moi-même! => créer une nouvelle étiquette dans Gitlab « Deployed in Preprod », et chaque fois que les dév annoncent qu’ils ont fait une release en Preprod, je vais voir la Release, et j’ajoute moi-même cette étiquette aux tickets concernés.
Et pour la Prod, en principe, les tickets sont fermés par les Dév quand ils sont déployés.
A suivre…
Salut,
J’ai mis en place Gitlab dans mon ancienne boite (ça remonte à quelques années déjà 
) et tout le process qui va avec. J’ai pas mal de retour d’Xp.
D’une manière générale, à partir d’un ticket, tu devrais pouvoir remonter jusqu’au commit implémentant le ticket (ou la branche, ou la merge request). Sur Gitlab, çela se fait, par ex. en préfixant le commit de dev par le numéro du ticket. Par ex:
#MIC-152 Fix crash at startup.
Check that service is properly initialized blablabla
Si le dev est implémenté par plusieurs commits, tu peux rajouter le numéro sur chaque commit, ou sur le dernier, ou quand tu y penses, ce n’est pas très grave. L’important est qu’il apparaisse dans la branche de dev. Si la branche fix plusieurs tickets d’un coup, tu peux mettre plusieurs numéros dans le message de commit.
Gitlab est capable de parser les commit message et de faire le lien avec le ticket. Ca marche nativement si tu utilises les tickets de Gitlab. Il y a des plugins pour Jira, Redmine et probablement la majorité des issues tracker.
Coté Gitlab, il t’affichera un message du tyle « This Merge Request fix ticket #MIC-142 ». Coté Issue tracker (si la connexion a bien été configuré), il t’affichera « This issue has been fixed by MR42 », avec un lien vers la Merge Request.
Vois ici pour plus de détail:
Ce système permet aussi de vérifier si un ticket est dans une branche en tirant directement la branche sur ta machine et en cherchant dans l’historique.
Si tu pars sur ce système, attention à une dérive classique qui est de forcer les dev à rattacher toutes leurs branches à un ticket. Le but est de savoir si une demande client a été shippé et dans quelle version. Le but n’est pas, à partir d’un commit, de remonter jusqu’à une demande client. Il faut savoir qu’il y a énormément de petites améliorations qui sont faites gratuitement par les dev sans qu’on leur demande 
. Si tu les forces à ouvrir des tickets pour tout, ils vont juste arrêter de faire ce boulot « gratuit » et regarder des vidéos de chat à la place.
1 « J'aime »
Merci beaucoup pour ton message!
J’ai cherché la mention « commit » dans les tickets, et j’ai suivi les liens.
Pour l’un d’eux, j’ai eu la mention « Production » quelque part dedans (dans la rubrique « Changes », je crois). Mais pour plein d’autres, je ne trouve pas d’indication sur l’environnement où le ticket est déployé (Preprod ou Prod)…
Les dév font ce que tu dis = indiquent le numéro de ticket dans leurs commits.
Mais où dois-je aller pour voir si le ticket est déployé en Prod ou Préprod?
Peut-être que ça remonte à trop loin pour que tu te souviennes?
Pour les histoires de preprod/prod ca dépend beaucoup de ce qu’ont mis en place les dev 
.
Lorsqu’ils merge leur branche de dev, ils mergent dans quel branche ? (la « Target branche » de la Merge Request) ?
Y-a-til une branche de preprod et une branche de prod (Develop et Master) ?
Dans ce cas, pour envoyer les dev en prod, mergent-il la Develop dans la Master, ou refont-il une Merge Request pour remerger leur branche dans la Master ?
Ou bien y-a-til une seule branche « master » qui est déployé (plus ou moins à la main) sur un environnement de preprod ou un environnement de prod ?
Selon ce que j’ai compris :
Oui, il y a une branche Develop et une branche Master.
Ils mergent leur code dans Develop,
Et ils mergent la Develop dans Master.
Est-ce que ça t’aide à savoir si il y aurait bien moyen de partir du ticket pour savoir si celui-ci est déployé en Prod ou Préprod?
Ouaip, ça m’aide 
, ça a l’air d’être workflow standard.
Merge-t-il la develop dans la master avec une Merge Request ou à la main ?
S’ils utilisent une Merge Request, Gitlab vas parser les messages de commit de la Develop qui vont arriver dans la Master grace à ce merge. Les tickets devraient donc contenir le lien vers cette Merge Request (en plus de la 1ère MR qui a mergée la branche du développeur dans la Develop). A partir du ticket, tu devrait donc pouvoir remonter jusqu’a cette nouvelle MR et voir qu’il est bien arrivé dans la master.
S’ils mergent à la main… tu perds un peu en traçabilité mais tu peux encore t’en sortir.
Ce que tu peux faire pour être totalement autonome, c’est cloner le repos chez toi et regarder ce qu’il y a dans la master:
-
Trouve un développeur sympa pour te montrer ce que je vais t’expliquer
. Rassure-le en lui disant que tu veux juste un accès en lecture. -
Install git: https://gitforwindows.org/
-
Clone le repos sur ton PC
-
Dans un terminal, tape :
gitk origin/master. Ca t’ouvre une fenêtre un peu austère. Faut pas avoir peur, on s’y fait. C’est moche mais c’est rapide !
-
Cherche le numéros du ticket dans la barre de recherche. (au niveau de Find commit containing: ) S’il trouve un commit associé, c’est que le ticket est dans la master (donc en prod)
-
S’il ne le trouve pas, ferme gitk et retape
gitk origin/developpour chercher le ticket dans la develop. -
S’il ne le trouve toujours pas, c’est que le ticket est encore chez un développeur (ou qu’il n’a pas mis le numéros du ticket dans son commit, et ça c’est pas bien !).
L’étape 3 n’est à faire qu’une seul fois. Par la suite, il faudra juste taper git fetch de temps en temps pour synchroniser ton PC avec ce qu’il y a sur Gitlab.
En espérant que ça t’aide.
Merci Thibaut,
Cependant, ce que j’ai appris (en tant que non-technique), c’est que la branche Master correspond à l’environnement Preprod (et non Prod)!
Du coup, je suis re-perdue… 
Et donc l’environnement de prod, il est créé à partir de quoi ?
J’ai cru comprendre que les deux environnements Préprod et Prod sont issus de la branche Master.
Donc, au temps pour moi : la branche Master correspond aux deux environnements, pas seulement à la Préprod, pardon!
Ca te semble cohérent?
Oui, c’est tout à fait possible, mais cela a plusieurs inconvénients. Notamment celui qu’on ne sait pas à quoi correspond la prod 
Sait-tu si un tag est posé sur la master lorsque qu’une Prod est déployé ?
La question que tu peux leur poser est: « Comment je sais à quel commit correspond la prod courante ? »
Si tu permets, je poursuis en MP : j’ai peur que ce sujet n’intéresse que moi (et merci pour ta patience et ta solidarité!! A tout de suite dans ta messagerie! )
1 « J'aime »