Image fusée

La gestion de projet avec GitLab

1. GitLab, c’est quoi ?

GitLab est une application web libre qui permet de gérer en ligne ses dépôts git*, avec de la gestion de droits d’accès, de projets et de groupes. De nombreuses fonctionnalités permettent d’utiliser cet outil pour gérer ses projets, telles que la gestion des tickets en tableau façon Kanban ou le suivi du temps (timetracker).

*git : logiciel libre de gestion de versions décentralisées créé par Linus Torvalds (auteur du noyau Linux) et distribué selon les termes de la licence publique générale GNU.

2. Principal intérêt

Cette approche permet :

  • aux développeurs d’être plus rigoureux dans leur code 
  • la mise en place de codes review réguliers entre membres de l’équipe
  • de travailler de façon asynchrone sur une même étape importante du projet
  • de créer, attribuer et gérer des tâches qui sont intimement liées au code du projet

3. Projets et notions de groupes

GitLab permet de regrouper des projets dans un même groupe (un projet est en fait un repository git). Sachez qu’il est également possible d’imbriquer des sous-groupes dans un groupe :

gitlab-projets

L’avantage d’organiser ses projets en groupes/sous-groupes, c’est qu’il est très facile d’y gérer les membres, facilitant ainsi le travail entre plusieurs équipes. Un projet hérite des membres du groupe qui le contient, mais il est possible d’ajouter aux membres tout un groupe extérieur. Par contre, il est impossible d’ajouter un groupe à un autre groupe.

5 profils utilisateurs sont disponibles avec différentes permissions :

  • reporter (seulement pour gérer les issues mais pas les supprimer, les commenter ou assigner des personnes, etc.)
  • developer
  • maintainer
  • etc.

Notez qu’il est également possible d’importer depuis de nombreuses autres plateformes. Pratique si vous souhaitez passer de Github (Microsoft) à Gitlab (libre) :

import-projets

4. Les issues (tickets et notion de board)

La gestion des issues (tickets) se fait par projet. Mais il est tout de même possible d’afficher l’ensemble des tickets des projets d’un même groupe ou sous-groupe. Sur le même modèle qu’un KANBAN (à la trello), les issues sont en fait des tâches à faire. Elles peuvent être attribuées à une ou plusieurs personnes.

Différents labels (statuts/étiquettes) peuvent leur être assignés. Par défaut, nous avons : Open, To Do, Doing, Closed. Cela permet de regrouper les issues par thématique.

gitlab-issues

Vous pouvez aussi regrouper les issues par jalon (milestone), qui peuvent représenter par exemple des sprints dans une méthodologie agile. Il s’agit en fait des étapes importantes d’un projet. Le milestone est terminé lorsque toutes les issues liées à cette dernière ont été “closed”.

Sous format board, on peut déplacer facilement les différentes issues de labels en labels en fonction de leur état d’avancement.

5. Les merge requests (MR)

Lorsqu’une issue a été prise ou attribuée à une personne, qu’elle est passé en “Doing” et que la merge request (MR) a été ouverte, le développeur n’a plus qu’à aller travailler sur la branche associée de cette dernière. Le nom de la branche sera alors : <id_issue>-nom_branche. De même, dans tout message de commit ou commentaire sur l’UI, vous pouvez faire référence vers une issue en écrivant #<id_issue>

Chaque MR permet de :

  • comparer les changements entre deux branches lors des codes review
  • examiner et discuter des modifications
  • avoir un aperçu des modifications
  • empêcher de merger grâce au mot-clé WIP
  • résoudre automatiquement les problèmes de fusion
  • solutioner les conflits via l’UI
  • de squash les commits pour un historique plus propre

6. Estimation et saisie du temps

Il est possible de saisir des estimations du temps passé sur une issue en utilisant les commandes Gitlab. Il suffit alors d’écrire dans le champs commentaire ces commandes :

timetracking
  • /estimate <temps> : pour ajouter une estimation
  • /spend <temps> : pour indiquer le temps passé

Le temps se décline en :

  • mo : mois
  • w : semaines
  • d : jours
  • h : heures
  • m : minutes 

Dès lors, une barre de progression sera affichée pour l’issue en question :

gitlab-progressbar

7. Le process classique à suivre

Voici un process à suivre pour intégrer efficacement cette gestion de projet dans votre quotidien

A.Prendre une issue

Si la tâche ne vous a pas encore été attribuée, rendez-vous dans la section issues et assignez-vous une issue ayant pour label “To Do”. Il ne vous reste plus qu’à lire les éventuels commentaires associés.

B. Débuter le travail

Une fois assigné, glissez l’issue vers le label “Doing”. Ouvrez ensuite l’issue puis cliquez sur “Create Merge Request”. Cette action va créer automatiquement une merge request avec le statut WIP. La branche de travail associée à cette dernière est également créé.

C. Dans votre terminal

Passez sur la branche develop. Faites de préférence toujours un git pull pour être sûr d’être à jour. La nouvelle branche que vous venez de créer a été rapatriée. Après cela, fâites un git checkout [nom-de-votre-nouvelle-branche]

D. Coder

Puis, une fois vos modifications effectuées, faites des git commit/push de temps en temps. Le code sera ensuite pousser sur la branche de travail. Pensez également un git commit dès que vous voulez changer de branche.

E. Passer en mode review

  • Une fois l’issue traitée, allez voir dans GitLab votre Merge Request. Il se peut que vous ayez des Merge Conflit. Vous pouvez tenter de les résoudre automatiquement directement sur l’UI sur GitLab (ou via votre terminal).
  • Une fois résolu, faites un git commit de votre travail puis faites un git checkout develop suivi d’un git pull.
  • Retournez ensuite sur votre branche de travail avec un git checkout [nom-de-votre-nouvelle-branche].
  • Ensuite, faites un git rebase develop. Des merge conflits sont alors apparus… ! Résolvez-les puis faites un git rebase -continue. Ensuite, même process : git commit, git push -f
  • Retournez voir dans GitLab, désormais votre problème de Merge Conflit a bien disparu.-
  • Puis, cliquez sur Resolve Wip Status, ceci afin de montrer que le travail est terminé pour cette merge request.
  • Passez également le statut de la MR en review.
  • Enfin, llez dans le board (tableau Kanban) et glissez l’issue concernée dans le label Review (créez-le s’il n’existe toujours pas).

F. Attendre les retours de la review

Les codes review sont souvent effectués par les gestionnaires des projets (lead-developers, CTO, etc.). Si vous avez des retours de la part de votre reviewer, reprenez alors à l’étape D.

Pensez aussi à close les discussions pour chaque commentaire fait lorsque vous avez résolu le problème, ça permettra de garder un historique propre.

Si à l’inverse, tout s’est bien passé et qu’aucun retour sur votre MR n’a été fait, votre reviewer se chargera lui-même de faire le Merge sur la branche courante.

Enfin, il vous faudra répéter ces étapes depuis le début jusqu'à avoir terminé le sprint en cours...

8. Bonus : documentation projet

Sur un dépôt git, je vous conseille toujours d’ajouter, au minimum, un fichier README (.md de préférence pour que celui-ci soit directement interprété par l’UI GitLab). Dedans, listez simplement les logiciels requis pour installer et lancer votre projet.

De fait, décrivez les commandes nécessaires pour installer/configurer/lancer votre projet sur une machine en local. L’usage est généralement de loger la documentation de votre projet dans un dossier docs (explication des features, du contexte du projet, etc.). Notez que chaque dépôt gitlab dispose d’une fonctionnalité de wiki, sur laquelle vous pouvez y renseigner certaines documentations/instructions. L’inconvénient est que si vous souhaitez migrer votre dépôt un jour vers un autre dépôt, le wiki ne sera pas de la partie…

9. Conclusion

En résumé, le principal intérêt d’utiliser GitLab dans sa gestion de projet, c’est de pouvoir centraliser toutes les actions en un seul et même endroit. Cela concerne principalement les développeurs et les aide dans leurs tâches quotidiennes, mais les chefs de projet pourront également y trouver leur compte en évitant de passer par plusieurs outils tiers tels que Trello, Redmine ou encore Podio.

Laissez nous un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Vous aimerez aussi ...

Image POC me I'm Famous

POC me I'm Famous

Connaissez-vous la différence entre une preuve de concept (POC) et un prototype ? Dans…

02/07/2019 | 0
Icone fusée

Démarrez votre projet digital !

Je me lance