git-bug: un bug tracker distribué intégré dans git

À l’occasion de la sortie de la version 0.4 de git-bug, je me suis dit que je pourrai te raconter un peu de quoi il retourne. git-bug est un gestionnaire de bugs distribué intégré dans git.
Le logo de git-bug
git-bug est un bug tracker distribué intégré dans git, c’est-à-dire que l’ensemble des données des bugs est stocké sous forme d’objet git, sans polluer les branches et fichiers normaux. Mais pour quoi faire ? Et bien par rapport à un bug tracker classique, il y a plusieurs avantages :

  • pas de dépendance à un service en particulier (par exemple si ton bugtracker préféré se fait racheter par tousse Microsoft tousse) ;
  • pas besoin d’infrastructure particulière : si tu utilises déjà un remote git pour collaborer, tu as un bugtracker ;
  • tu peux consulter et éditer les bugs hors-ligne, avec l’interface que tu préfères, sans latence.

Mais alors, comment on fait un bug tracker distribué ? Le plus gros problème c’est la gestion des conflits. Comment faire si Alice et Bob modifient le même bug et s’échangent les données ensuite ?

La solution choisie, plutôt que de stocker simplement l’état d’un bug, est de stocker chaque opération d’édition individuellement.

      +-------------+    +-----------+    +-------------+   +--------+
* --->| ADD_COMMENT |--->| SET_TITLE |--->| ADD_COMMENT |-->| CREATE |
      +-------------+    +-----------+    +-------------+   +--------+

Quand une fusion doit avoir lieu, l’une des deux versions voit ses nouvelles opérations placées à la fin de la chaine, à la manière d’un rebase. On a donc la garantie d’avoir un état final cohérent puisque c’est git-bug qui dérive l’état final de la chaîne d’opérations. Mais que se passe-t-il si deux personnes suppriment la même étiquette ? Elle sera simplement supprimée une fois et l’action des deux personnes sera visible dans l’historique.

Voilà à quoi pourrait ressembler une opération :

{
  "type": "SET_TITLE",
  "author": {
    "name": "René Descartes",
    "email": "rene.descartes@example.com"
  },
  "timestamp": 1533640589,
  "title": "This title is better"
}

Ces opérations sont ensuite sérialisées et stockées dans des blob git et reliées dans une chaîne de commits. Chaque bug a sa propre chaîne de commits, accessible via une référence git. À chaque fois que le bug est modifié, une nouvelle série d’opérations est ajoutée à la chaîne et la référence est mise à jour.

 refs/bugs/<bug-id>
       |
       |
       v
 +-----------+    +-----------+             "ops"    +-----------+
 |  Commit   |--->|   Tree    |---------+----------->|   Blob    | (OperationPack)
 +-----------+    +-----------+         |            +-----------+
       |                                |
       |                                |
       v                                |   "root"   +-----------+ 
 +-----------+    +-----------+         +----------->|   Blob    | (OperationPack)
 |  Commit   |--->|   Tree    |-- ...   |            +-----------+
 +-----------+    +-----------+         |
       |                                |
       |                                |   "media"  +-----------+        +-----------+
       v                                +----------->|   Tree    |---+--->|   Blob    | bug.jpg
 +-----------+    +-----------+                      +-----------+   |    +-----------+
 |  Commit   |--->|   Tree    |-- ...                                |
 +-----------+    +-----------+                                      |    +-----------+
                                                                     +--->|   Blob    | demo.mp4
                                                                          +-----------+

Comme tout est stocké sous forme d’objet git, on peut pousser tout ça vers un remote et collaborer, comme si on s’échangeait du code source.

Une autre propriété intéressante de la méthode, c’est qu’on peut stocker et lier les médias (typiquement, une capture d’écran) à un bug et les diffuser de la même façon.

Alors, à quoi ça ressemble tout ça ? Et bien ça dépend des goûts. Si tu préfères la ligne de commande, le scripting ou intégrer ça dans ton Vim, c’est possible. Voilà un aperçu:

# Ajouter un nouveau bug
git bug add

# Liste les bugs ouverts, trié par dernière édition
git bug ls "status:open sort:edit"

# Affiche l'état du bug f3781aee
git bug show f3

# Selectionne le bug f3781aee parce que je sais bien que tu es un peu flemmard
git bug select f3

# Ajoute un nouveau commentaire
git bug comment add

# Pousse les modifications vers le remote par défaut
git bug push

Pour un usage plus efficace, il y a aussi l’interface interactive en terminal :

Capture d'écran de git-bug en terminal interactif

Ou sinon, pour les amateurs de vrai pixels et de clic-clic, git-bug embarque une interface web, mais il faut avouer qu’il y a encore du boulot :

Capture d'écran de git-bug en interface web
Capture d'écran de git-bug en interface web

Techniquement, le binaire de git-bug lance un serveur web local qui sert les fichiers d’une application REACT (JavaScript) qui ont été compilés et inclus dans ce même binaire. L’application web s’interface avec le binaire grâce à une API GraphQL. Le déploiement reste donc extrêmement simple avec un unique binaire à copier, sans configuration.

La nouvelle version 0.4 apporte une fonctionalité qui a été beaucoup demandée, un importeur incrémental pour Github ! Après avoir utilisé git bug bridge configure pour saisir ses identifiants, un token d’API est généré automatiquement et git-bug devient capable d’aspirer les issues en local dans son modèle de données.

Et le futur ? Une de mes priorités est d’implémenter un exporteur vers Github. Quand ça sera fait, il sera possible d’utiliser git-bug comme un Github déporté, qui fonctionne en local et offline.

Une autre idée qui me trotte dans la tête est d’avoir une véritable gestion d’identité en embarquant les données publiques dans des objets git, clé de chiffrement incluse. De cette façon, il devient possible de les distribuer facilement, avec les données des bugs, de signer ses éditions, les vérifier, et même pourquoi pas ? de vérifier les commits git normaux sans avoir à chercher et importer les clés GPG.

Mais tout ça, c’est quand même beaucoup pour, en gros, un seul bonhomme. Mais peut-être, mon cher journal, que je trouverai des âmes vaillantes pour m’accompagner dans cette aventure…

Commentaires :
voir le flux atom
ouvrir dans le navigateur

(Source: LinuxFr.org : les dépêches)
Logo