[Procédure] Branches Correctifs/évolutions

1. Fonctionnement

1. Branches fixes

Pour les projets FME

Quand les projet abritent des fichiers non textuels (audio, fmw, zip etc..) des conflits non résolvables vont apparaître régulièrement lors des étapes de merge, dans ce cas il est préférable de créer une branche de travail ouverte à tous les contributeurs, de protéger la branche master pour y faire des merge quand les développements ont étés validés.

Pour les projets de développement

Dans ce cas il est possible d’utiliser 100% des capacités de Git et c’est ce que nous allons faire en appliquant la procédure suivante.

Sur la branche master nous appliquerons uniquement les correctifs, cette branche doit absolument être stable à tout moment car elle permettra de générer un correctif si on le souhaite.

Une deuxième branche next_version permettra quand à elle à appliquer les évolutions, quand des correctifs sont appliqués à master, il faudra les merger sur cette branche de manière à avoir les dernières évolutions ainsi que les derniers correctifs.

Une fois les développements d’une version terminés il est important de tester dans un environnement de pré-production notre application, à ce moment nous créerons à partir de next_version une branche pre-20xx.xx.xx contenant le numéro de build à générer (on utilise parfois pre_prod si il n’y a pas de numéro associé). Les correctifs à effectuer se feront sur master puis seront mergés sur next_version et sur la branche de pré-production.

Quand l’environnement de pré-production est validé, il est alors mergé sur next_version puis sur master à partir duquel on créera le tag correspondant.

branches depots

2. Faire un correctif

Cette section est réservée aux projets de développement

Un correctif est un bug remonté sur l’application en cours de production qui doit être corrigé pour publier une nouvelle version mineure, pour ce faire on créera une branche à partir de master qui prendra comme nom l’intitulé du bug (nom automatiquement pre-saisi par GitLab).

Une fois le bug corrigé nous le rapatrierons sur master à l’aide d’une merge request puis nous effectuerons une deuxième merge request de master vers next_version

branches depots 2

Chaque correctif doit être fait à travers une issue (documenté plus bas)

3. Faire une évolution

Cette section est réservée aux projets de développement

Les évolutions ne sont pas intégrées sur master qu’après la phase de pré-production, c’est pour cela qu’elles seront faites à partir de next_version et qui prendra comme nom l’intitulé du bug (nom automatiquement pre-saisi par GitLab).

Une fois terminée, la branche sera rapatriée sur next_version.

branches depots 3

Chaque évolution doit être faite à travers une issue (documenté plus bas)

2. Créer un correctif/évolution dans GitLab

Dans GitLab la notion de correctif ou d’évolution est lié à une issue, une issue est une demande aux développeurs de résoudre un problème sur l’application actuellement en production ou alors de déveloper une nouvelle fonctionnalité.

Gitlab permettra en 4 étapes effectuer tout le processus de création de demande, création de branche, demande de validation et intégration.

2.1 Céation d’une issue

Le titre de l’issue doit contenir sur quelques mots le but de la demande, puis dans la description il est possible de détailler.

En cas de bug, il vaut mieux associer la demande au responsable produit de telle sorte à ce qu’il reçoive par mail et dans l’interface une notification.

Pas besoin de fournir de milestone car ce dernier sera décidé par le responsable produit.

Parmi les labels disponibles il faudra spécifier si il s’agit d’un bug ou d’une évolution.

issues 1

Lorsqu’un responsable produit va accepter une issue il voudra si c’est un bug créer une branche ainsi qu’une merge request, pour cela plusieurs étapes sont nécessaires.

issues 2

2.2 Assigner la demande

En assignant la branche à quelqu’un il recevra une notification par mail ainsi que sur l’interface.

issues 3

Le milestone permettra de connaître l’avancement du projet dans sa globalité, il est important de le spécifier pour savoir à quelle version de l’application correspond cette issue.

issues 4

Les labels permettront de filtrer les issues, les deux labels bug et evolution sont toujours présents, sur les applications vitis on retrouve autant de labels que de modules pour savoir rapidement à quel module correspond chaque issue.

issues 5

2.3. Corriger la demande

Quand l’issue vous est attribuée et que vous commencez à la résoudre il faudra créer de manière automatique une branche ainsi qu’une merge request.

Ne cliquez pas directement sur le bouton Create merge request, en revanche cliquez sur le bouton déroulant situé à sa droite pour définir le nom de la branche à créer ainsi que la source.

Si il s’agit d’un bug on choisira comme source master.

Si il s’agit d’une évolution on choisira comme source next_version

issues 6

Désormais une branche portant le nom de l’issue a été créée. Vous remarquerez que le nom de la merge request commence par WIP (Work In Process) ce qui nous permet de savoir si la travail du développeur est terminé ou non.

issues 7

Une fois les développements terminés sur la branche il est temps de terminer la merge request pour demander au responsable projet d’intégrer les développements sur la banche source. Pour cela il faudra lui assigner la merge request puis enlever le status WIP en cliquant sur Resolve WIP status.

2.4. Valider la demande

Une fois que le développeur a terminé et vous a assigné la demande de merge vous pouvez visualiser les modifications effectuées et valider la demande.

Si la demande ne correspond pas à vos attentes il faudra l’éditer pour ajouter à nouveau WIP: au début du titre, puis décrire dans la fenềtre de discussion pourquoi la demande n’est pas valide.

Une fois la demande de merge effectuée l’issue se met à jour automatiquement en état terminé.