Dopo aver discusso l’argomento Issue Tracker non potevo non soffermarmi nel dettaglio su qualche strumento di bug tracking. Questo intervento è dedicato a Bugzilla, uno dei più diffusi e datati sistemi di bug tracking.

Bugzilla nasce circa nel 1998 per far fronte alle esigenze del nascente progetto Mozilla.org.

Scritto in PERL, anche se non dal principio, oggi rappresenta uno dei più longevi (se non decisamente il più anziano) sistema di bug tracking esistente.

Nonostante la sua età, si comporta in modo a dir poco eccellente considerando lo stress al quale è sottoposto, per esempio, nella gestione dei bug di tutti i progetti della Mozilla Foundation, incluso Firefox.

Dettagli tecnici e requisiti

Come anticipato, Bugzilla è scritto in PERL e richiede dunque un server in grado di interpretare questo linguaggio. Non si tratta tuttavia di un problema poiché la quasi totalità dei server integra il supporto via CGI a script PERL.

Tuttavia, il mio personale consiglio è di installarlo su un server gestito da sistema operativo Linux e, possibilmente, web server Apache.

Per esperienza diretta posso affermare che installarlo sotto Windows + IIS non è una delle scelte più geniali che un sistemista possa fare nella propria vita.

Bugzilla necessita inoltre di una lista di moduli PERL, un database compatibile (di solito MySQL) ed un mail server installato per l’invio delle notifiche.

Tutto sommato una configurazione comune, salvo forse qualche modulo di PERL che gli hosting meno smaliziati potrebbero non aver installato di default.

Nozioni base di Buzilla

Per quanto riguarda installazione e configurazione di Bugzilla delego volentieri il compito alla documentazione ufficiale.

Vorrei dedicare invece qualche minuto al tema della gestione e dell’utilizzo del software.

Tutto ruota intorno ai ticket

Come per la maggior parte degli issue tracker, tutto ruota attorno al concetto di ticket. Un ticket normalmente è un bug, ma non necessariamente. Potremmo ricondurre il valore di un ticket al concetto di attività.

Infatti, sono disponibili diverti tipi di ticket, o per meglio dire, livelli:

• trivial
• minor
• normal
• major
• critical
• enhancement

Sebbene questa classificazione non possa competere in completezza con altre soluzioni come Atlassian Jira che presentano una ricca lista di tipi di ticket, è sufficiente a svolgere la maggior parte delle attività compreso il tracking di nuove feature utilizzando la voce enhancement.

Ciascun ticket inserito deve corrispondere ad una di queste classificazioni a seconda della gravità della richiesta.

La vita di un ticket

Il valore di severity non è di certo l’unica proprietà fondamentale di un ticket.

L’aspetto forse più importante è lo status di un bug. Un bug è infatti associato ad uno status che ne descrive la situazione attuale del bug e determina la vita del but stesso, ovvero a bug’s life cycle.

L’immagine seguente, presa da Wikipedia, riepiloga la vita di un bug utilizzando un diagramma di flusso.

Ma cosa significa tutto questo esattamente?

In sintesi, un bug ha una vita propria che comincia nel momento in cui il ticket viene inserito ed automaticamente associato allo status di New.

In questo caso il bug è stato inserito ed aspetta un volontario che lo prenda in gestione.

A seconda delle configurazioni un bug può essere inserito di default come Unconfirmed, in attesa che qualcuno ne confermi l’esistenza ad esempio tentando di riprodurlo sulla propria versione del programma.

Una volta che il bug viene confermato come tale può essere assegnato. Questo significa che qualcuno è ora incaricato di valutare l’entità del problema ed attivarsi per risolverlo.

Una volta assegnato il bug può essere a sua volta riassegnato o contrassegnato come risolto.

Risolvere un bug può significare diverse casistiche. Il bug può essere contrassegnato come risolto in quanto non sussiste (invalid), non è riproducibile (worksforme), è un duplicato di uno esistente (duplicate) oppure è incompleto (incomplete).

Ah, ovviamente un bug può essere semplicemente risolto in quanto è stata applicata la correzione (fixed) necessaria.

Un bug risolto, una volta rilasciata la versione, può essere chiuso (closed) ma allo stesso tempo potrebbe resuscitare in futuro (reopened).

Questa è the bug’s life cicle.

Proprietà di un bug

Oltre allo status ed alla gravità, un bug consiste di numerose altre proprietà che ne specificano dettagli utili a riprodurlo e correggerlo.

E’ possibile specificare una priorità da 1 a 5 (priority), la piattaforma che presenta il problema (platform), il sistema operativo (operating system) e, a partire da Buzilla 3, è possibile creare dei nuovi campi personalizzati.

Poiché un sistema di ticket è fortemente condizionato dal concetto di versione del programma, è possibile specificare quale release presenta il bug così come una milestone prevista per la correzione del problema.

Contenuto di un bug

Mi stavo dimenticando uno degli aspetti fondamentali… cosa contiene un bug?

Un ticket è sostanzialmente composto da un titolo ed da un messaggio, un po’ come una classica email.

Al primo messaggio, che normalmente descrive il problema, possono essere inseriti commenti in successione, allegati file ed un URL esplicativo.

Ecco come si presenta, ad esempio, la pagina di un bug su Mozilla.org.

Interazione con Bugzilla

I bug, ovvero i ticket, possono essere inseriti, gestiti ed amministrati a seconda dei propri privilegi.

Per interagire con il sistema è necessario disporre di un account, ottenibile in seguito ad una registrazione.

Una volta autenticati con il proprio username e password sarà possibile interagire con il programma a seconda dei privilegi concessi.

Bugzilla dispone di un’area di amministrazione che consente di gestire sia i bug sia i privilegi degli utenti.

Inoltre, gli amministratori hanno accesso ad una vasta lista di configurazioni.

Per cercare e navigare tra i bug, di norma, non è necessario un account.

Ad esempio, questa pagina che riassume la lista degli ultimi bug inseriti su Mozilla.org è accessibile anche senza essere autenticati.

Non è tutto rosa e fiori

Bugzilla è un ottimo prodotto e vanta una lunga esperienza alla base.

Affronta con onore le necessità fondamentali di un issue tracker anche grazie all’evoluzione dovuta all’utilizzo da parte della Mozilla Foundation.

Tuttavia, rispetto ad altri concorrenti, presenta alcuni difetti, almeno secondo il mio modesto parere.

Innanzi tutto non integra nativamente il supporto per un sistema di versioning, come ad esempio Subversion.

E’ un peccato poiché è tutt’altro che raro che un issue tracker venga installato in parallelo ad un software per il controllo delle versioni. L’interazione tra i due prodotti rappresenta un notevole vantaggio in fase di sviluppo e manutenzione di un software.

Bugzilla non integra wiki o sistemi anche basilari di publishing.

Questo comporta la necessità di affiancare una sorta di lavagna virtuale esterna, di norma un prodotto Wiki per gestire al meglio l’aggiornamento collaborativo.

Infine, l’interfaccia predefinita di Bugzilla non è tra le pià accattivanti, per non dire concettualmente organizzate.

Non è difficile rischiare di perdersi, soprattutto le prime volte, o notare una certa freddezza nella disposizione dei contenuti.

Insomma, anche l’occhio vuole la sua parte!

API

Bugzilla integra un sistema XML-RPC che permette a software esterni di interagire con il programma. Uno di questi è Deskzilla, al quale dedicherò un articolo nei prossimi giorni. Inoltre, Bugzilla offre feed RSS per iscriversi a specifiche ricerche/collezioni di bug.

In conclusione

Se state cercando un issue tracker nudo e crudo, gratuito e facilmente configurabile allora Bugzilla può essere una valida soluzione ai vostri problemi.

L’installazione non è immediata, assicuratevi di seguire passo passo la ricca e dettagliata documentazione.