Esempio di uso

In questo post andremo ad esaminare un semplice esempio di uso di JIRA.

Iniziamo

Il nostro obbiettivo è quello di avere a disposizione un sistema che, attraverso una email sui inviamo delle richieste, abbiamo la contestuale creazione di email da parte di JIRA. Questa è una funzione nativa su JIRA e ci consente di poter implementare un semplice Help Desk per situazioni molto semplici.

Configurazione

Passiamo subito all’azione e configuriamo il tutto. Il primo passo è di disporre di una email per poter eseguire queste operazioni. Per questo ci viene incontro GMAIL. Creiamo la nostra email di servizio e da li procediamo di conseguenza.

Successivamente passiamo alla fase di configurazione di JIRA: Configuriamo le Incoming Mail. Posizioniamoci nella sezione di amministrazione di sistema e selezioniamo la sezione dedicata:

A questo punto, procediamo con la autocomposizione, completando tutte le sezioni richieste.

Terminata questa fase, si procede con la configurazione del Mail Handler, che di eseguire le varie operazioni

specificando la tipologia di Handler che si intende creare, ovvero (come mostrato in figura)

Quello che ci interessa è il primo, ovvero creare una nuova Issue/aggiungere i commenti alla esistente.

Anche in questo caso, una agevole autocomposizione, ci guida nella configurazione. In particolare ci indica quale progetto dobbiamo fare riferimento per generare queste Issue.

Una volta completato questa fase, possiamo iniziare a generare le nostre Issue. Semplicemente, basta inviare le mail all’account di posta che abbiamo creato in precedenza. In prima battuta, sarà creata una Issuedove:

• il titolo della mail sarà il titolo della Issue 
• il corpo della mail sarà la descrizione della Issue
• Gli allegati della mail saranno allegati alla Issue

A questo punto, se nel titolo della Issue andiamo a specificare la chiave della Issue, ovvero:

<CHIAVE>-<NUMERO>

allora, invece di creare una nuova issue, semplicemente andrà a generare un commento nella Issue indicata. Gli allegati alla mail saranno allegati alla Issue.

Conclusioni

Abbiamo un semplice esempio di Help Desk, che si può realizzare attraverso le funzionalità standard di JIRA. Questo è sicuramente molto comodo se si vuole realizzare una soluzione semplice.

Workflow & JIRA

In questo post, introduciamo il concetto di Workflow su JIRA, spiegando che cosa si intende per Workflow su JIRA ed approfondendo l’argomento in altri post.

Iniziamo dalle definizioni

Partiamo dalle definizioni, ovvero: Con il termine Workflow su JIRA si intende l’insieme degli stati e delle transazioni che una Issue può assumere nell’ambito di un progetto JIRA. La seguente figura rappresenta un esempio di Workflow.

Quando si JIRA si definisce un Workflow, si definisce quali stati una  Issue può assumere, quali passaggi di stato sono possibili, in che stato viene aperta una Issue. Un esempio di tale situazione può essere vista nel post, dove ho descritto come realizzare un Asset manager con JIRA.

JIRA mette a disposizione Workflow standard, come indicato in questo post.

Come JIRA Administrator, possiamo eseguire delle customizzazioni e crearne di nuovi, in base alla nostre esigenze:

Il  Workflow sopra riportato è stato utilizzato per dimostrare come realizzare un Asset manager con JIRA :-).

Occorre tenere presente i seguenti punti:

• Ogni JIRA Project dispone di un suo Workflow. In base alla tipologia di progetto, JIRA assegna un determinato Workflow;
• Il JIRA Administrator può creare dei Workflow ad hoc, in base alle esigenze del progetto.
• Lo stesso Workflow può essere utilizzato da più progetti;

Perchè personalizzare il Workflow?

La risposta è: Dipende. Quello che posso consigliare è verificare le esigenze del progetto e valutare in che modo si può eseguire l’operazione. Occorre però tenere presente che il Workflow di JIRA non è in grado di fare qualsiasi cosa. Rimanete con i piedi per terra :-).

Proprio in base alla definizione data all’inizio, si tratta di definire sia quali stati può possedere una Issue, sia quale sequenza di cambio stato può essere eseguita. Se si vuole eseguire delle operazioni più complesse, allora occorre tenere presente che si deve integrare JIRA con ulteriori addon, da valutare molto attentamente e con un determinato giudizio.

Conclusioni

In questo primo post è stato dato il first look al Workflow su JIRA. Nei prossimi post andremo ad esaminare come gestirli, modificarli e come crearne di nuovi.

Reference

• Definizione
• Manualistica

Prova su strada dell’addon

In questo post andremo a provare Colamatech Workflow, già presentato nel post precedente.

Installiamo l’addon

Procediamo con l’installazione dell’addon, come siamo sempre abituati e con estrema facilità. Accettiamo la EULA della Comalatech, come mostrato nella seguente figura:

quindi si procede con il download dell’addon.

Al termine del download, viene eseguita l’installazione.

Si passa quindi alla registrazione della licenza. In questo caso abbiamo scelto la licenza trial per testare il prodotto.

Una volta rilasciata la licenza, l’addon è pronto per poter essere utilizzato 🙂

A questo punto, possiamo vedere che cosa l’addon mette a disposizione :-). Possiamo andare nella sezione degli addon, selezionare il nostro e, una volta che la sezione viene aperta, selezionare il tasto configure, procedendo con la configurazione dello stesso.

Configurazione

Possiamo osservare che, nella sezione delle General Configuration, abbiamo una nuova sezione disponibile, come mostrato in figura:

dove possiamo accedere alle varie opzioni che l’addon mette a disposizione. Se selezioniamo la Configuration, come indicato in precedenza, siamo rediretti nella sezione delle configurazioni dell’addon:

Nelle varie configurazioni, possiamo stabilire chi può fare cosa, a livello generale. Possiamo stabilire, ad esempio:

• Chi può creare/importare dei Workflow
• In quali Space creare i Workflow (tutti o specifici)
• Chi vede le attività del Workflow. In questo caso possiamo scegliere se gli amministratori dello Space + i Page Editors oppure tutti gli utenti
• Il comportamento degli stati delle page
• Sezione sperimentale: Abbiamo anche delle features sperimentali, che sono presenti e che possiamo attivare/disattivare.

Workflow preinstallati

Al momento della prima installazione, abbiamo a disposizione tre Workflow preinstallati

Questo aiuta sicuramente tutti gli utenti che, la prima volta, iniziano ad avvicinarsi a questo addon. Possiamo anche vedere la struttura di questi Workflow, in quanto possiamo anche editarli in maniera grafica:

oppure possiamo anche editarli attraverso un opportuno linguaggio di markup

dove fondamentalmente andiamo a impostare tutti i possibili passaggi di stato che una pagina può … subire.

Proviamo il Workflow

A questo punto, selezioniamo uno dei tre workflow e proviamo ad usarlo nel nostro ambiente di test, andando a capire come si comporta e che risultati abbiamo.

Creiamo uno Space ad hoc, dove andremo a fare tutti i nostri test

Notiamo che, proprio in alto a destra, abbiamo le indicazioni del Workflow:

Al momento non abbiamo ancora aggiunto alcun Workflow. Procediamo con l’aggiunta 🙂

aggiungiamo proprio il Workflow Simple Approval. Al momento in cui eseguiamo il tutto, viene chiesto in quale stato deve essere assegnato alle pagine preesistenti allo space. Nel nostro esempio, impostiamo che tutte le pagine risultino già approvate, come mostrato nella figura successiva

Adesso proviamo a modificare una pagina. Per questo ci affidiamo ad un utente di test ed usiamo un altro browser per l’operazione, per cercare di ricostruire il tutto.

Come mostrato dalla figura precedente, adesso lo stato della pagina è stato modificato. In aggiunta, il revisore che deve approvare la pagina, viene avvisato in diversi modi:

• Abbiamo un messaggio che ci avvisa che la pagina è stata editata da un altro utente. Questo perché eravamo ancora posizionati sulla pagina;
• Il sistema di messaggistica di Confluence è attivo (notiamo in alto a destra che abbiamo un messaggio)
• Anche l’icona dell’addon presenta un messaggio

Se selezioniamo l’icona dell’addon, abbiamo il seguente risultato:

Abbiamo la possibilità di poter operare queste azioni:

• assegnare l’operazione ad altro utente, come mostrato in figura: In questo modo, sempre sfruttando il sistema di messaggistica di Confluence (e le relative email), l’utente assegnatario sarà avvisato.
• Approvare/Rigettare il documento. In questo modo possiamo mutare lo stato del documento. Nel secondo browser, abbiamo questo messaggio: 

Conclusioni

Abbiamo visto un semplice esempio di utilizzo di questo addon, ma abbiamo mostrato solo una piccolissima parte delle sue funzionalità. Nei prossimi post, vedremo anche come poterlo calare in determinate realtà o come poter realizzare dei Workflow ad hoc per determinate situazioni.

https://marketplace.atlassian.com/plugins/com.comalatech.workflow

Diagrammi in Confluence – Alternative

In questo post andremo ad esaminare quali alternative esistono, su Confluence, per poter realizzare dei diagrammi, completando quanto discusso nei seguenti post:

• Gliffy
• Graphviz

Draw.io

Si tratta di un addon, basato su mxGraph che consente di poter realizzare diagrammi e grafici in maniera molto semplice.

Dalle immagini vediamo che consente di poter realizzare dei grafici molto belli e chiari.

L’organigramma non sarà più un problema :-), come mostrato in figura.

Nulla da invidiare a nessuno degli altri addon al momento visti.

Conclusioni

Abbiamo una valida alternativa, da quanto si vede, a dei prezzi molto più bassi rispetto agli altri addon presentati. Nel prossimo post andremo a vedere la prova su strada, cui siamo abituati, per capire vantaggi/svantaggi, pro e contro nell’uso di questo addon.

Reference

• AtlassianMarket Draw.io

Introduciamo FishEye

In questo post andiamo a completare la panoramica dei prodotti Atlassian. Introduciamo FishEye e vediamo come possiamo usarlo per la gestione dei progetti .

Dove introduciamo FishEye?

Fisheye viene introdotto come interfaccia verso il sistema di controllo versione (SVN, Bitbucket, CVS, Mercurial, etc etc etc). L’obbiettivo è quello di avere a disposizione un sistema che, come già indicato in questi posts, aiuti nella gestione del codice.

Grazie alla perfetta integrazione con i prodotti della suite, FishEye consente di poter rintracciare tutte le operazioni che sono riferite ad una determinata Issue JIRA e di arrivare a completare il controllo indicando, sempre tramite JIRA, dove l’intervento è stato eseguito.

Come si può vedere, nella sezione Source abbiamo l’indicazione esatta, reperita proprio tramite FishEye, di dove si è intervenuti nel codice.

I vantaggi sono notevoli. Ve li lascio immaginare: Abbiamo il controllo completo del codice, degli interventi e possiamo rintracciare dove sono stati eseguiti.

In aggiunta possiamo anche operare la Code Review, come già indicato in precedente post, e arrivare a migliorare notevolmente il codice. In questo, Crucible, componente oramai agganciata a FishEye, ci aiuta senza grandi difficoltà.

Conclusioni

Abbiamo fatto una carrellata abbastanza vasta dei vari prodotti della Atlassian, ad eccezione di Bamboo. Questo ultimo, al momento, non viene trattato su questo blog. Spero entro la fine dell’anno di poter iniziare a trattare anche questo splendido prodotto e di poter completare l’analisi e la presentazione di TUTTI i prodotti della Atlassian.

Addons per Cloud

In questo post iniziamo ad analizzare come realizzare un addon per i prodotti Atlassian su Cloud. Parleremo di Atlassian Connect.

Due parole prima di iniziare

Lo sviluppo su Atlassian Connect non può essere fatto allo stesso modo degli addon per installazione Server. Essendo un sistema configurato in maniera differente, deve ragionare in maniera differente. Già in questo post, avevo indicato quali sono le differenze tra i Server e Cloud. Queste differenze si riflettono anche nello sviluppo degli addon per la versione Cloud.

Occorre tenere presente che, fondamentalmente, l’addon per Cloud è una webapp a se stante che si interfaccia con la componente Cloud, sfruttando le chiamate REST e controllandone le risposte che restiruisce.

Che cosa è Atlassian Connect?

Connect è un framework che la Atlassian mette a disposizione per mettere in comunicazione gli Addons, che come indicato in precedenza sono delle web application, con Confluence e JIRA Cloud.

Come indicato nel seguente diagramma, presente nella documentazione Atlassian:

l’addon si interfaccia con l’istanza cloud Atlassian. L’utente finale non vede alcuna differenza: non si deve preoccupare di dover modificare alcuna configurazione: Sarà il Confluence o il JIRA di turno a richiamare la web application e a comunicare con essa.

Come sarà organizzata?

L’addon sarà costruito secondo opportuni criteri e deve essere impostata in modo da riportare delle informazioni (in particolare, determinati contenuti) nella UI dei prodotti Atlassian, in modo da poter richiamare le funzionalità della web application.

L’addon dovrà poi comunicare con i prodotti Atlassian attraverso le chiamate REST e attendere/rispondere a Webhooks.

Conclusioni

Come precedentemente esposto, la realizzazione di addon per Cloud richiede un differente approccio rispetto agli addon per le versioni Server. Nei prossimi post andremo a vedere il classico Hello World .

Reference

La manualistica può essere reperita qui

Esempio di uso

In questo post andremo ad esaminare un addon, forse non molto considerati, ma che può sicuramente risultare utile nel proprio lavoro di tutti i giorni.

A cosa serve?

Questo addon consente di poter copiare una pagina, e la relativa alberatura sottostante, da uno space ad un’altro, specificando lo space dove andare a copiare, come mostrato nella figura precedente.

L’addon mette a disposizione la possibilità di poter modificare i nomi delle nuove pagine copiate e di poter eseguire delle operazioni di renaming/aggiunta prefissi e suffissi agli attachments. Viene anche data la possibilità di poter copiare o meno gli attachments stessi 🙂

UN agevole LOG consente di poter visionare l’avanzamento della operazione di copia, mettendo a disposizione uno strumento agevole.

Che utilizzi possiamo avere?

Questa è sicuramente la domanda più importante. Per quale motivo possiamo utilizzare questo addon?

Schede Clienti

Un primo utilizzo che mi viene in mente potrebbe essere quello di utilizzarlo come sistema per creare delle alberature standard nel nostro Confluence Cloud. Se abbiamo la necessità di disporre, anche su space differenti, di una particolare alberatura di pagine, che sia sempre la medesima, questo sistema è sicuramente il più semplice.

Un esempio banale, potrebbe essere quello di creare delle schede clienti. Potremmo avere necessità di una alberatura standard, dove andare a posizionare le varie informazioni del cliente, e con questo sistema, basta disporre di uno Space che contenga il template, ed il gioco è fatto. 🙂

Template standard

Nel caso in cui il semplice Template non sia sufficiente ai nostri obbiettivi, ovvero abbiamo la necessità di disporre di template di pagine standard per gestire i vari meeting, analisi, documentazione, etc. Questo può essere realizzato sia su installazioni Server che su installazioni Cloud.

Conclusioni

Anche se a prima vista gli addon non sembrano svolgere chissà quale funzione, consiglio vivamente di far correre la fantasia. Vedrete che i vari addon possono sopperire a necessità inaspettate, arrivando a sorprendere sempre 🙂

Ultime news

In questo post, proseguiamo quanto iniziato nei post dedicati agli addon della Kanoah.

• Presentazione
• Test su strada – 1
• Test su strada – 2

Andiamo in dettaglio

Il 2 luglio 2015 è stata rilasciata la versione 1.2.0 dell’addon Kanoah Tests. Di seguito riportiamo le ultime novità:

Possibilità di poter aggiungere dei campi custom nei Test Cases e nei Test Plans

Viene data la possibilità di poter aggiungere campi custom ai Test Cases ed ai Test Plans. Questo consente di poter aggiungere informazioni supplementari che prima non era possibile gestire. Nel caso di situazioni che richiedono informazioni ad hoc, possiamo aggiungere nuove informazioni 🙂

Validazione di campi custom

Viene offerta la possibilità di poter eseguire una validazione dei campi custom, proprio in base ai campi stessi.

Aggiornare i Test Cases massivamente

Viene offerta la possibilità di poter selezionare più Test Cases al fine di poterli aggiornare massivamente.

Conclusioni

Si tratta di migliorie operative, che sicuramente aiuteranno gli operatori nell’espletare il proprio lavoro nelle sessioni di test.

Reference

Maggiori dettagli sono reperibili qui

Workflow su Confluence

In questo post andremo ad introdurre un concetto di Workflow su Confluence.

Che cosa è un Workflow?

Come prima cosa, cerchiamo di dare una definizione di Workflow Per fare ciò, consiglio questo link, dove ho trovato una bella definizione di workflow e consiglio anche la pagina di wikipedia (in inglese, ma la consiglio).

Fondamentalmente, andando al sodo, un Workflow è il flusso di lavoro che deve essere eseguito per svolgere una determinata operazione, in ambito di un business.

Come si può introdurre il concetto di workflow su Confluence?

Spieghiamo in che modo possiamo calare questo concetto su Confluence 🙂

In ambito wiki, si ha la necessità di un Workflow quando si devono pubblicare delle pagine in cui, per evidenti motivi, le informazioni devono essere prima vagliate/approvate da un responsabile che deve accertare che tutte le informazioni presenti siano corrette.

Basti pensare ad un sistema in cui ogni pagina wiki presenta delle informazioni finanziarie di una società. Se questa pagina è visionata da un numero molto elevato di utenti, la pubblicazione di una informazione errata potrebbe scatenare problemi non indifferenti.

Quindi, in situazioni come questa, dove se viene eseguita una pubblicazione senza controllo esiste un grosso rischio, trova la sua naturale applicazione un Workflow.

Come possiamo applicare un Workflow in Confluence?

In Confluence abbiamo a disposizione un Addon che consente di poter aggiungere un Workflow su Confluence. SI tratta del Comala Workflow.

Questo addon consente di poter assegnare uno stato specifico alle pagine di uno space. In aggiunta, possiamo assegnare un Workflow specifico ad ogni singolo space.

Possiamo assegnare task specifici ad un singolo utente, come mostrato nella precedente figura. Questi riceverà una opportuna segnalazione, in modo da poter poi procedere con le operazioni richieste.

Opportune macro consentono di poter creare delle pagine, in cui riassumere gli stati assunti dalle pagine

Nei prossimi post andremo a collaudare questo addon per saggiarne le potenzialità e limiti.

Alternative?

Come prima cosa, l’addon indicato è disponibile solo per installazioni Server, mentre non è affatto disponibile per Cloud. Quindi, sorge spontanea la domanda: Esistono delle alternative?

La risposta è si, e sarà oggetto di un post dedicato esclusivamente a questo punto.

L’idea è la seguente e si basa sull’uso di funzionalità standard.

Come prima cosa, occorre disporre di due space:

• Space Pubblicato, ovvero lo space effettivamente disponibile al pubblico utenti
• Space privato, clone dello space pubblicato, dove gli autori eseguono le correzioni/modifiche/aggiunte.

Come seconda cosa, possiamo associare degli stati agli space basandoci sulle Page properties, descritte in questo mio post, e usate anche in tanti altri esempi 🙂

Come seconda cosa, utilizziamo i Tasks di Confluence, per assegnare i compiti alle persone e mandare loro delle segnalazioni, un pò come avviene con l’addon, ma facendo uso solo delle funzionalità standard.

In questo modo, ed usando un pò di organizzazione, gli utenti lavorano nello space privato, a meno di correzioni del tipo:

• errori di battitura;
• correzioni dell’ultimo minuto, etc

cambiando stato (nelle page properties) ed impostando i task su di una opportuna pagina di uno space di lavoro.

Conclusioni

Abbiamo a disposizione degli strumenti opportuni per poter impostare un Workflow su Confluence, sia come addon specifici, sia come unione di funzionalità standard che, alla fine dei giochi, possono metterci a disposizione un Workflow molto primordiale ma, nel contempo, semplice e funzionale. Questi argomenti saranno approfonditi su altri post.

Prova su strada

In questo post andremo a verificare il funzionamento di questo addon. Facciamo seguito al post pubblicato in precedenza.

Installazione

L’installazione, come sempre molto semplice, non ci preoccupa più di tanto. Una volta rintracciato l’addon, procediamo

Una volta accettata la EULA, possiamo procedere con il download

Terminato quest’ultimo, si procede con l’installazione

Quindi si procede con la richiesta della licenza (come sempre TRIAL)

Inseriti i dati dell’account atlassian, viene generata in automatico la licenza

quindi, se non ci sono stati intoppi, l’addon risulta disponibile.

Al termine della installazione, ci potrebbe essere richiesto di eseguire una operazione di reindex. Questo può capitare quando si installa un nuovo addon che potrebbe prevedere la generazione di nuovi campi custom. In questo caso, consiglio sempre di eseguire questa operazione di reindex subito. L’operazione è safe e normalmente non prevede alcuna controindicazione :-). Dalla immagine sottostante si vede che JIRA stesso richiede di eseguire tale operazione e fornisce il link diretto.

Selezionare l’opzione di Backgroud re-index e dopo pochi istanti l’operazione è conclusa.

Primi passi

A questo punto possiamo procede con l’utilizzo dell’addon stesso. Il primo passo è la generazione di un progetto XRAY Test Project, come mostrato in figura:

Una volta selezionato il progetto evidenziato, viene indicato quale tipologia di issue avremo a disposizione

Come indicato nel post di presentazione, i test sono gestiti sfruttando le ISSUE di JIRA. Proseguendo, assegniamo il nome al nuovo progetto:

Una volta confermato, il progetto viene generato e nella schermata di Overview di progetto.

Gestiamo un TEST

A questo punto, per creare un TEST, semplicemente creiamo una nuova ISSUE, di tipo Test, come mostrato in figura:

Inseriamo un pò di informazioni, per creare il nostro test

Dalla figura precedente, osserviamo che possiamo descrivere in ogni singola componente tutti i vari step che compongono il test, definendo ogni singolo passo che deve essere eseguito al fine di verificare la funzionalità oggetto del test. Possiamo associarlo ad una Test Sets, ovvero ad un insieme di test (lo possiamo definire anche in questa fase)

e possiamo anche eseguire il link alle issue JIRA del progetto

A questo punto a issue è pronta ed usabile per il nostro test. Vediamo adesso come procedere.

Creiamo il nostro Test Sets di lavoro

e quindi creiamo il nostro Test Execution

Procediamo quindi alla esecuzione del test. Spostiamoci nel dettaglio del Test Execution creato in precedenza. Quindi inseriamo i dati di quando iniziamo ad eseguire il test

quindi andiamo nella sezione Tests ed aggiungiamone uno nuovo, o il Test Sets o il Test creato in precedenza.

Supponiamo di aggiungere il nuovo test XRAY-1

A questo punto sarà visualizzata la sezione dedicata alla esecuzione del test.

e possiamo procedere con il test, o attraverso il menù cog, a fianco della colonna status, che compare non appena il mouse si porta proprio li sopra:

dove possiamo lanciare l’esecuzione del test oppure possiamo direttamente settare il risultato del test.

Fatto ciò, abbiamo concluso l’esecuzione del test e possiamo chiudere il task. Una volta selezionato il risultato del test, dalla interfaccia principale del progetto di test, possiamo visualizzare i risultati dei vari test, come mostrat in figura.

Conclusioni

Abbiamo a disposizione un addon molto semplice, che possiamo usare senza grandi problemi o addestramenti particolari. Questo è sicuramente un vantaggio: chiunque disponga di un addestramento su JIRA, può tranquillamente impostare i vari TASK ed usarli senza problemi :-).

In aggiunta, ma non meno importante, il costo molto contenuto, lo rende un addon appetibile  🙂