Et si on commençait par expliquer ce qu'est GitLab.
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.
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
GitLab et sa gestion de projets via le 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 :
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) :
Travailler avec des 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.
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.
Utiliser les merge requests (MR)
Lorsqu’une issue a été prise ou attribuée à une personne, qu’elle est passée 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
Penser à noter ses timetracking sur GitLab
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 :
- /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 :
Proposition de process classique à suivre
Voici un process à suivre pour intégrer efficacement cette gestion de projet dans votre quotidien
Pour commencer, s'attribuer une issue
Si vous n'avez pas encore de tâche, 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.
Ensuite, 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éée.
A. 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, faites un git checkout [nom-de-votre-nouvelle-branche]
B. 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 à faire un git commit dès que vous voulez changer de branche.
C. 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).
Pour terminer, 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 B.
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...
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…
GitLab, un outil bien utile dans la gestion de projet
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.
