Lifehacking - Gitlab, outil idéal ?

, par  Genma , popularité : 3%

Depuis quelques années, je suis adepte du lifehacking et nombreux sont les articles que j’ai écrit sur le sujet. Des Todo j’en ai fait des tas, sur toutes les formes...Je suis familier de toutes les techniques organisationnelles projets comme les RIDA, RACI et autres... J’avais essayé de trouver un formalisme sous forme de tableau pour avoir un suivi des tâches, au sein de nombreuses itérations. Avec de nombreuses colonnes : projet, acteur, date de début, de fin, échéance, priorité, remarques... Mais quelque soit la mise en forme, la façon de faire (un onglet par projet ou autre), cela était toujours aussi peu flexible.

Gitlab

Au sein de mon entreprise, comme nous faisons du développement logiciel, nous avons une instance Gitlab auto-hébergée de la version communautaire. Parmi les fonctionnalités de Gitlab, au delà de l’aspect forge logicielle / hébergement de code, il y a différentes fonctionnalité que nous utilisons de plus en plus et ce pour chaque projet, dans le cadre de notre industrialisation. Dans le présent billet, je voudrais donc faire un retour d’expérience des différents outils.

Le Kanban

Le Kanban est probablement l’outil que j’utilise le plus. J’avais déjà fait des Kanban sur base de post-it dans une mission en AGIL dans une vie antérieure, j’avais un mur chez moi pour la gestion des mes projets personnels avec des post-it de différentes couleurs... Mais cela n’est pas pratique pour un partage, pour un travail à plusieurs et n’a pas de solution pour un usage en mobilité...

Les locaux actuels sont vitrés, les équipes avec lesquelles je travaille sont réparties au sein de différents services... J’ai besoin d’avoir une vision sur les différents projets et de pouvoir la partager.

La solution a donc été la généralisation de la mise en place d’un projet par service avec l’activation du Kanban pour chacun de ces projets. Et un Kanban pour les sous-projets. Je travaille encore avec une todo-liste que j’ai dans un bloc de papier dans lequel je note ma liste de choses à faire, que je raye au fur et à mesure de la journée. Toute tâche qui nécessite plus de détail, de suivi, d’être déléguée est si besoin rayée de la liste et mise dans le Kanban.

Avec le Kanban, j’ai un suivi des actions sur plusieurs jours ou plusieurs semaines, je suis sûr de ne rien oublier. En un ticket, j’ai un numéro de suivi si besoin, un acteur, je peux ajouter des dates. Et sur le ticket, je peux faire un suivi, commenter, ajouter des précisions, des liens vers le wiki et faire vivre l’action. Comme tout est électronique et au sein d’un navigateur web, c’est accessible, partageable. Les commentaires et le suivi sur un ticket sont cachés par défaut mais permettent d’avoir un suivi, de copier coller des échanges par mail, de mettre des liens vers d’autres tickets, des documents, des pages wiki... J’ai l’état d’avancement. Chacun peut commenter le ticket, ajoute des liens vers les pages wiki en cours de rédaction. On sait qui a quelle tâche. On voit l évolution. Il est possible de taguer un fichier avec plusieurs mots clefs chacun associés à une couleur. Il est possible pour chaque ticket de définir des dates de fin, un nombre de jours de réalisation, un "milletsone".

Dans les conseils que je donnerai il y a celui de prêter attention au nom des tickets qui doivent être autoporteur. Il ne doit pas être nécessaire d’ouvrir le fil du discussion du ticket mais il ne faut pas trop détailler non plus dans le titre. Un équilibre se trouve assez facilement au final.

Bref, j’ai trouvé dans le Kanban de Gitlab tout ce que j’avais cherché en essayant de structurer mes suivis d’action dans des fichiers avec colonnes...

En Kanban, j’avais auparavant testé l’usage de celui de Nextcloud (Deck) et celui de Kanboard. Mais celui de Gitlab, au delà de son intégration dans l’écosystème Gitlab, a de suite eu mon adhésion définitive. Un design plus moderne, plus riche, intégré avec tout un écosystème d’outils complet que je présente dans la suite de ce billet.

Le wiki

Pour chaque projet, Gitlab permet de créer un wiki dédié au projet. Chaque page est une page texte au format Markdown, qu’il est possible d’éditer au sein du navigateur même (avec une fonction de prévisualisation). Les fichiers étant des fichiers textes, ils sont suivis dans une branche dédiée par Git, avec toute la puissance niveau historisation que cela peut avoir.

Le wiki est récupérable en local en tant que projet Git, la bonne pratique est donc que chacun clone le wiki comme projet en local. Il n’y a pas de fork d’implémenté au sein même de Gitlab, on ne peut donc pas faire des forks et ensuite des branches etc. Tout le monde travaille donc sur un même dépôt qu’est le wiki ; cela nécessite donc de s’astreindre à certaines règles : mise à jour régulière du serveur vers le local et ce avant toute modification. Remontée rapidement sur le serveur les ajouts fait au wiki localement.

Pour l’édition, comme je le disais, le format est le format Markdown. On peut éditer au sein de l’interface web ou en local. C’est et ça reste du fichier texte. Nous avons mis en place un tutoriel utilisant l’éditeur Atom qui permet l’édition et la prévisualisation du Markdown (pratique pour avoir du WYSIYG) et un plugin Git pour pousser les modifications depuis Atom sur le serveur. Cela facilite la vie pour l’édition du wiki. Je pense que mettrai ce tutoriel en ligne sur ce blog pour le rendre accessible à tous.

La wikification : ce que j’appelle wikification c’est le fait de tracer dans le wiki toute information pertinente qu’il est nécessaire de garder, de conserver, au sein d’une base de connaissances. Nous généralisons, traçons, mettons à jour les procédures, les astuces etc. Tout ce que l’on peut attendre d’un wiki, nous le faisons au sein des wikis des différents projets de Gitlab.

Nous sommes d’ailleurs en train de reverser peu à peu les informations pertinentes en les mettant à jour d’un ancien wiki qui était sous Media Wiki dans le nouveau wiki. Un chantier long et fastidieux, mais nécessaire. L’ancien wiki était peu pratique, devenu lourd avec le temps, rédigé par des générations successives de collaborateurs sans suivi d’un formalisme particulier. Repartir sur une base saine est souvent le mieux à faire et nous le faisons.

L’espace fichier

Initialement prévu pour stocker du code source, nous utilisons cet espace pour stocker une arborescence définie de fichier. Avant il y avait un Intranet mais un simple partage de fichiers (nous n’avons pas de GED), mais avec le temps et l’accumulation des fichiers, c’est un peu devenu un fourre-tout inutilisable et inexploitable.

Nous utilisons donc pour chaque nouveau projet l’espace de fichier pour y stocker les fichiers de travail (fichier de configuration, documentation, procédures) dont nous avons besoin d’avoir une historisation, une centralisation et qui ne sont pas wikifiables.

Dans les pistes en cours d’étude il y a le fait que nous cherchons à pouvoir convertir des notes saisies en Markdown en documentation livrable au client, dans un format LibreOffice Writer avec un template de fichier défini (avec des codes couleurs précis). Un projet comme Pandoc pour la conversion avec ensuite application d’une feuille de style particulière sera à creuser.

Organisation des projets

Un service donne lieu à un projet, un projet donne lieu à un projet en lui-même dans Gitlab. Les pages wiki et la documentation sont mises au sein du projet pour lequel c’est le plus pertinent. Dans les autres wikis des autres projets, des liens sont fait vers les pages wiki et documentation de références. On utilise ainsi la puissance du web.

Pour faire un suivi à la hiérarchie, lors des réunions hebdomadaires, il suffit de présenter deux planches : une capture d’écran du Kanban prise en semaine N-1 et un une capture du Kanban de la semaine en cours. On peut alors visuellement voir l’avancement avec les tickets déplacés, les tickets en cours...

Bref, Gitlab est devenu un outil incontournable, efficace et indispensable pour moi.

Non intuitif pour les non informaticien.ne.s

Comme nous industrialisons nos projets, tout nouveau projet quel-qu’il soit est désormais créé dans Gitlab. Et le constat a été fait rapidement que dès que l’on sort d’une population purement d’informaticien, Gitlab nécessité des améliorations de son interface graphique pour pouvoir permettre une appropriation de l’outil en particulier dans la partie gestion des fichiers et suivi des modifications, qui restent avant tout pensé comme du "diff de code".

Et je ne suis pas seul à avoir saisi à la fois la puissance de Gitlab et le fait que ce n’est pas adapté aux non-informaticien.ne.s. En effet, dans le cadre de sa campagne Contributopia de Framasoft, dans la partie "Éducation populaire - Inspirer les possibles", il y a un projet Git à la portée de tou·te·s dont la description est la suivante : Git est un outil qui permet de collaborer collectivement sur du code. La manière dont il a été conçu ouvre une magnifique porte d’entrée vers les méthodes, pratiques et états d’esprits de la contribution. Comment faire pour que les personnes qui ne codent pas puissent profiter de la philosophie d’un tel outil ? Comment adapter git, son jargon, son interface, etc. afin que tout le monde puisse co-construire et collaborer sur des textes ou d’autres communs contributifs ? Des projets existent et c’est avec eux que Framasoft désire étudier des solutions.

Conclusion(s)

Au bout de quelques jours, Gitlab est devenu comme une révélation, un peu comme si je venais de trouver l’outil miracle. Nombreux sont les avantages que j’ai trouvé (me demandant même comment je faisais avant). Dans les autres avantages à avoir toute ma gestion au sein d’un même outil c’est que c’est pratique pour faire les sauvegardes.

Dans les autres petites choses que j’aimerai avoir et sur lesquelles il faut que je me penche, il y a celles d’avoir des métriques ou des statistiques en utilisant le temps de réalisation des tickets. Ce sera sûrement le sujet d’un autre billet, quand j’aurai pris le temps de me pencher sur ce sujet. Hop, c’est ajouté au backlog dans le kanban.