URL: https://linuxfr.org/users/michaelmure/journaux/git-bug-un-bug-tracker-distribue-integre-dans-git Title: git-bug: un bug tracker distribué intégré dans git Authors: MichaelMure Date: 2018年12月05日T21:54:39+01:00 License: CC By-SA Tags: git, github, bug et distribué Score: 48 Cher journal, À l'occasion de la sortie de la version 0.4 de **git-bug**, je me suis dit que je pourrais te raconter un peu de quoi il en retourne. ![Le logo de git-bug](https://user-images.githubusercontent.com/5607130/44865043-e65aaf80-ac89-11e8-87ac-d0c9f95b4f84.png) * [Le projet git-bug](https://github.com/MichaelMure/git-bug) * [Téléchargement et versions](https://github.com/MichaelMure/git-bug/releases) **git-bug** est un [bug tracker](https://fr.wikipedia.org/wiki/Logiciel_de_suivi_de_probl%C3%A8mes) 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 bugtracker 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 chaine d'opération. Mais que se passe-t-il si deux personnes supprime 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 : ```json { "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 chaine de **commit**. Chaque bug a sa propre chaine de commit, 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 chaine et la référence est mise à jour. ``` refs/bugs/ | | 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: ```bash # 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](https://raw.githubusercontent.com/MichaelMure/git-bug/master/doc/termui_recording.gif) 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](https://raw.githubusercontent.com/MichaelMure/git-bug/master/doc/webui1.png) ![Capture d'écran de git-bug en interface web](https://raw.githubusercontent.com/MichaelMure/git-bug/master/doc/webui2.png) Techniquement, le binaire de **git-bug** lance un serveur web local qui sert les fichiers de l'application js/react qui ont été compilé et inclus dans ce même binaire. L'application web s'interface avec le binaire grâce à une [API GraphQL](https://github.com/MichaelMure/git-bug/blob/master/graphql/schema.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ée. 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...

AltStyle によって変換されたページ (->オリジナル) /