0 comments
17th Apr 09
gianSu istigazione di questa persona, mi sono messo a giocare con i BTS distribuiti.
I BTS distribuiti non hanno un database centrale, copiando quindi la logica dei vari programmi di gestione delle versioni (VCS, da Version Control system) distribuiti come git, mercurial, darcs etc.
Come i VCS distribuiti si contrappongono ai VCS centralizzati per la mancanza di un repository cerntrale dove vengono memorizzare le revisioni e così via, allo stesso modo i BTS (Bug Tracking System) distribuiti non hanno un unico database in cui vengono memorizzate le richieste e i bug.
Potremmo dire che se un software tipo bugzilla o flyspray è il compagno ideale di CVS o subversion, un BTS distribuito è il compagno ideale di Git o Bazaar.
Finita questa breve premessa, vediamo di passare ad analizzare gli eventuali vantaggi e svantaggi di questi sistemi, tenendo presente che ovviamente non è un’analisi completa.
Dopo aver valutato diversi sistemi di BTS distribuiti, la mia scelta è caduta su Bugs Everywere, per due semplici ragioni:
- è scritto in python
- si integra meglio di altri con git (almeno per me)
A dire il vero, il primo lo si vede da sè, mentre il secondo nasce dall’uso. L’altro candidato era Ditz. Altri sistemi ci sono, ma non mi hanno impressionato.
Come per i VCS distribuiti il vantaggio maggiore è quello di poter fare tutto off-line. Si può quindi ad esempio aggiungere un bug, modifcarne un altro e chiuderne un terzo senza il bisogno di essere on-line. Questo è il completamento ideale per un VCS tipo git, in quanto rende indipendente lo sviluppatore dall’essere sempre on-line anche per il lato BTS.
Ovviamente ci sono anche degli svantaggi: ad esempio, sono mediamente più complessi da usare per l’utente finale, visto che di solito hanno un’interfaccia testuale e accompagnano i sorgenti (e non gli eseguibili).
Una cosa interessante è che i repository dei bug vengono generalmente trattati come dei qualsiasi file del progetto e quindi i vari elenchi possono essere gestiti in maniera naturale.
Tutti i problemi sono però superabili in un modo o in un altro. Ad esempio Ditz ha un generatore di pagine html statiche per consentire di pubblicare lo stato del progetto via web.
Come ho già detto la mia scelta è caduta su Bugs Everywere, con il quale traccio i bug di Chiamami (una semplice agenda telefonica).
Il vantaggio principale di BE è la migliore integrazione con git (il VCS che uso), anche se a scapito di una peggiore interfaccia rispetto a Ditz.
Guida veloce a Bugs Everywhere
Adesso una veloce e minuscola guida all’uso di BE per la gestione di un progetto. Lanciando BE senza parametri otteniamo l’elenco dei comandi supportati.
galactica:~/Devel/Test2> be Bugs Everywhere - Distributed bug tracking Supported commands be assign Assign an individual or group to fix a bug be close Close a bug be comment Add a comment to a bug be diff Compare bug reports with older tree be help Print help for given subcommand be list List bugs be new Create a new bug be open Re-open a bug be remove Remove (delete) a bug and its comments be set Change tree settings be set-root Assign the root directory for bug tracking be severity Show or change a bug's severity level be show Show a particular bug be status Show or change a bug's status be target Show or change a bug's target for fixing galactica:~/Devel/Test2>
Si nota abbastanza facilmente che sono abbastanza simili a quelli di un qualsiasi BTS tradizionale.
Un problema che ho riscontrato (ma forse sono io che sbaglio) è che mentre ovviamente non esistono elenchi di target predisposti al contrario di status e severity, non c’è un modo di avere l’elenco dei target già presenti, e questo su progetti un pò più grandi del piccolo progetto personale potrebbe essere un problema. Dopo un rapido scambio di mail con l’autore, questa funzionalità verrà inserita in una prossima versione.
Inizializzare il repository
Partendo dal presupposto di avere già un repository git, per inizializzare il repository be si usa il comando
be set-root
e se tutto va bene il sistema ritorna
galactica:~/Devel/Test2> be set-root Using git for revision control. Directory initialized. galactica:~/Devel/Test2>
Si può notare che BE riconosce automaticamente il fatto che si usa git.
Una nota: il repository git deve avere nella sezione config i valori si user.name e user.email settati, altrimenti il comando fallisce.
Lavorare con i bug
Per aggiungere un nuovo issue, si usa il comando new
galactica:~/Devel/Test2> be new "Test" Created bug with ID 90c galactica:~/Devel/Test2>
L’elemento viene creato usando i valori di default del sistema. Creato l’elemento, è possibile modificarlo usando i vari comandi per impostare la gravità, a chi è assegnato, la deadline per la quale si deve chiudere (in termini di versione, ma dato che la versione è una stringa arbitraria, potrebbe anche essere una data) o aggiungere una descrizione più estesa del problema/richiesta.
Ad esempio, per alzare la gravità del bug appena inserito da minor, che è il default, a serious si usa il comando severity
be severity 90c serious
dove 90c è l’id dell’elemento.
Possiamo vedere i dettagli del bug con il comando show
galactica:~/Devel/Test2> be show 90c
ID : 90cc54c6-d3e3-4562-b340-9c50d8d9ca31
Short name : 90c
Severity : serious
Status : open
Assigned :
Target :
Creator : gian <gian@grys.it>
Created : Thu, 16 Apr 2009 23:01 (Thu, 16 Apr 2009 21:01:05 +0000)
Test
--------- Comment ---------
Name: 90c:1
From: gian <gian@grys.it>
Date: Thu, 16 Apr 2009 21:11:53 +0000
Aggiungere un commento
galactica:~/Devel/Test2>
.Per chiudere un bug, si usa abbastanza ovviamente il comando close
be close 90c
Se invece abbiamo già un elendo di bug e lo vogliamo visualizzare, allora ci viene in aiuto il comando list
galactica:~/Devel/Test2> be list 90c:os: Test 981:om: Test galactica:~/Devel/Test2>
Il formato e’ questo:
- 90c indica l’id del bug
- os indica stato e severità del bug
- il resto è il sommario
Questo è tutto quello che serve per poter usare Bugs Everywhere nel lavoro di tutti i giorni.
