AssignBot facilite la relecture de code

A Logilab, dans un esprit d'amélioration continue, nous consacrons du temps à développer des projets qui facilitent notre travail au quotidien. Dernièrement le projet AssignBot a été développé par Simon Chabot. Afin d'en savoir plus sur sa création nous lui avons posé quelques questions :

  • Bonjour Simon, peux-tu tout d'abord te présenter en quelques mots ?

En quelques mots : j’ai étudié l’informatique à l’Université de Technologie de Compiègne, puis je suis allé à Nice, entre autre, faire une thèse sur la simulation numérique des séismes, avant de rejoindre Logilab fin 2018.

  • Peux-tu nous expliquer ce qu'est AssignBot et à quel besoin il répond ?

Lorsqu’on écrit du code, une des bonnes pratiques (peut être l’une des plus importante ?), est la relecture par les pairs. L’objectif de la relecture est d’améliorer la qualité du code produit, de favoriser la collaboration et de faire en sorte que les connaissances soient partagées.

À Logilab, nous avons plusieurs centaines de projets dans notre forge. Certains sont des logiciels écrits spécifiquement pour nos clients, généralement avec une équipe dédiée, et d’autres sont « communs ». Il peut s'agir de briques de base utiles à différents projets, d'outils internes (intranet, des tableaux de bords), ou de logiciels libres développés avec des tiers (comme CubicWeb et ses nombreux cubes).

AssignBot est un petit robot dont la mission est d’organiser cette relecture, notamment pour nos projets « communs ». Lorsqu’une personne propose un changement elle envoie sur notre forge une merge request. AssignBot va alors choisir une personne volontaire pour s’occuper de cette merge request. Je dis “volontaire”, parce qu'un des objectifs d’AssignBot est de laisser aux relecteurs la possibilité de régler le nombre de relectures qu’ils veulent bien faire par jour / semaine, afin de permettre aux personnes qui le souhaitent de participer, même si leur emploi du temps est chargé.

  • N'existait-il pas des solutions équivalentes que tu aurais pu utiliser ?

Pour être honnête, je n’ai pas vraiment cherché avant d'écrire AssignBot. Suite à diverses discussions avec des collègues, nous sommes arrivés à la conclusion que ce petit outil pourrait nous aider, et… je trouvais ça rigolo. Un soir, ça m’a démangé et AssignBot est né. Dans l’histoire de Logilab, un tel logiciel a déjà existé, mais il a été petit à petit abandonné car il était trop rigide je crois.

  • Avec quelle(s) technologie(s) l'as-tu fait et pourquoi celle(s)-ci ?

AssignBot est écrit en Python. C’est le langage qui accompagne Logilab depuis ses débuts et qui est connu par toute l’équipe. Pour trouver les nouvelles merge requests, AssignBot utilise la bibliothèque Python gitlab, qui permet d’interagir avec notre forge, basée sur Heptapod (un fork de Gitlab qui permet de gérer des entrepôts Mercurial). Le code est en réalité très court grâce à cette bibliothèque. Il suffit simplement de demander les merge requests non-assignées, et de choisir une personne dans la liste en fonction des préférences qu’elle a définies (en terme de nombre de relectures par jour/semaine).

AssignBot utilise également un petit fichier d’historique, pour pouvoir respecter ces préférences. Ce fichier est quand à lui placé sur notre serveur de stockage S3.

  • Est-il actuellement utilisé ? As-tu eu des retours des personnes utilisatrices ?

AssignBot est utilisé aujourd’hui par une dizaine de personnes à Logilab (j’espère d’ailleurs que cet article permettra d’augmenter ce nombre :smile:)

Oui, j’ai eu quelques retours. Principalement positifs, les merge requests restent moins longtemps en attente dans un coin sur la forge, car il y a une personne qui est en charge de sa publication. AssignBot ne connait pas les domaines avec lesquels les gens ont plus ou moins d’affinité. Donc il arrive des fois que l’on se retrouve assigné une merge request qui est assez loin de ce qu’on maîtrise. Ce qui a été un peu déroutant au début. Mais je pense qu’il faut voir cela du bon côté, ça permet de découvrir de nouvelles choses, d’être informé de ce qui est fait par l’équipe. Et il faut voir la mission comme « je dois faire en sorte que ce travail avance » et non pas comme « je dois relire et trouver les erreurs potentielles de ce code », ça peut donc vouloir dire, aller voir un·e collègue et poser des questions, ou demander si quelqu’un veut bien jeter un œil en parallèle. Voilà… en fait l’objectif d’AssignBot, pour revenir à la question du début, c’est ça : « faire en sorte que les choses avancent ».

  • AssignBot est-il publié sous licence libre ? Est-il utilisable dans un autre contexte que Logilab ?

Oui, tout à fait, AssignBot est libre, publié sous licence LGPL. Le code-source est disponible sur notre forge: https://forge.extranet.logilab.fr/open-source/assignbot et un paquet python est disponible sur pipy: https://pypi.org/project/assignbot/.

AssignBot est utilisable − normalement :) − sur toutes les forges Heptapod ou Gitlab, à partir du moment où un service d’intégration continue est disponible et qu’un compte applicatif pour AssignBot a été crée.

  • Quelles sont les perspectives d'évolution de cet outil (s'il y en a) ?

Il y a deux évolutions possibles qui me viennent en tête.

La première serait d’avoir une fonctionnalité pour publier automatiquement les merge requests qui ont été validées depuis un certain temps. Il est courant dans nos pratiques à Logilab, de mettre un tag « To Publish » ou simplement d’approuver une merge request pour que l’auteur publie ensuite. Dès fois, ça nous sort de la tête, on a oublié qu’il y avait du code à publier. AssignBot pourrait peut être s’en charger, en disant « si les tests passent et que quelqu’un a approuvé il y a plus de XXX jours alors je publie », ce qui est aligné avec l’objectif « faire en sorte que les choses avancent ».

L’autre idée est qu’actuellement AssignBot sauvegarde un historique sur un serveur S3. Donc il est nécessaire d’avoir un tel serveur pour utiliser AssignBot. Une évolution sans doute intéressante serait d’utiliser tout simplement un artifact Gitlab. Ça permettrait de supprimer cette dépendance et d’avoir un robot “tout en un”.