Prova su strada

In questo post andiamo a provare questo addon, che consente di poter generare degli space in base a template, verificando come poter creare dei template per gli space, come descritto in questi posts.

Installiamo ed usiamo

Procediamo con l’installazione solita dell’addon.

Una volta accettata la EULA, procediamo con il download dell’addon, come siamo sempre stati abituati dalla Atlassian.

Eseguito il download, si procede con l’installazione

Quindi procediamo con la licenza (in questo caso TRIAL):

Fornite le credenziali del nostro account, viene creata la licenza trial:

Quindi, se non si sono verificati dei problemi, l’addon è pronto all’uso.

Passiamo all’utilizzo

Una volta installato e licenziato, l’addon è immediatamente usabile. Basta semplicemente creare un nuovo space e ci accorgiamo subito della sua presenza:

Dalla immagine sopra riportata, notiamo subito la presenza di Mind Map Space, che attiva il nostro addon :-). Se lo selezioniamo, possiamo vedere subito quali scelte ci permette:

Possiamo creare (come mostrato dalla figura sopra riportata):

• New Product (public)
• New Project (public) 
• New Marketing Campaign (public)
• Se abbiamo i nostri template, questi sono visualizzati di seguito. Nella immagine sopra riportata, abbiamo un esempio, in quanto abbiamo creato un template di prova (che abbiamo chiamato Home Page (public)) e che abbiamo importato da file.

Le prime tre voci ci consentono di creare un template partendo da uno schema predefinito. Se li selezioniamo, accediamo alla interfaccia che si occupa della generazione del template, come mostrato nella figura successiva:

L’interfaccia che viene messa a disposizione è semplice e consente di poter … disegnare il template indicando quali saranno le pagine principali dello Space. Fondamentalmente viene creata l’ossatura del nuovo space. :-). Nella immagine seguente è mostrato il menù principale di questo editor di template. Questo mette a disposizione delle funzioni importantissimi, non ultima il link diretto alla documentazione dell’addon.

Possiamo esportare/importare il template, verificare le configurazioni. Abbiamo anche un menù di tasto destro del mouse, che si attiva se selezioniamo un elemento del template, come mostrato in figura.

che non è affatto male avere. In questo modo possiamo creare tutti i template che vogliamo, senza grossi problemi. Non sono infatti presenti particolari configurazioni o altre indicazioni particolari. Quindi non sono necessari skill ad hoc per gestire il tutto.

Limitazioni e suggerimenti

Analizzando l’addon, quello che si vede è che: chiunque può creare uno space, può creare il proprio template usufruendo dell’addon. Non sarebbe male che le versioni successive potessero implementare una limitazione sulla creazione di un nuovo space. Questo per evitare che, nella peggiore delle ipotesi, ci sia un proliferare di space oltre un certo limite. Quello che si può suggerire, in questo caso, è che nelle Global Permission sia organizzato in maniera tale da poter che gli utenti generici non possano creare degli space. In questo modo si evita che ci sia una proliferazione di template.

Conclusioni

Abbiamo a disposizione un addon veramente importante, di semplice utilizzo e che ci mette a disposizione la possibilità di poter impostare un template di space in maniera semplice e veloce. Possiamo creare degli space su misura per le nostre esigenze e possiamo anche pensare di organizzare il nostro Confluence in maniera standard, al fine di avere le informazioni… al loro posto. 🙂

Gestiamo i test con JIRA

In questo post andremo ad esaminare un nuovo addon, che può estendere JIRA in modo da poter gestire dei TEST. Vediamo una alternativa a questi addon.

Vediamo le caratteristiche

Questo addon estende le funzionalità di JIRA e consente di poter gestire i test.

In particolare:

• Crea i test come issue JIRA. Questo facilità l’approccio per tutti coloro che sono abituati alla gestione delle issue JIRA;
• Aiuta nella definizione dei passi del test stesso e nella definizione dei risultati aspettati.
• Consente di inserire le informazioni su quali argomenti sono coperti dai test, quali requireents e defects
• Precondizioni e informazioni associate al test
• Consente di poter raggruppare i test
• Aiuta nella gestione ,assegnazione, guida passo passo e verifica dei progressi del test

In aggiunta, reportistica e grafici sono a disposizione di chi deve gestire il tutto

Conclusioni

Da una prima analisi, l’addon sembra molto semplice e di rapido apprendimento. Sembra integrarsi molto bene con le caratteristiche e le funzionalità di JIRA ed i costi sono molto contenuti. Nei prossimi post andremo a eseguire la classica…. prova si strada.

Riferimenti

• Atlassianmarket
• Articolo (in Portoghese Brasiliano) che parla dell’addon.
• http://www.youtube.com/watch?v=w_9-Un6moGk

Proseguiamo il nostro confronto

In questo post, proseguiremo il nostro viaggio, verificando come possiamo gestire un progetto utilizzando altri prodotti Atlassian.

JIRA Service Desk

Ad un certo punto, il progetto sarà eseguito il deploy del progetto e sarà reso fruibile agli utenti. Da quest momento in avanti, quello che si andrà a dover gestire è la manutenzione dello stesso.

A tale proposito JIRA Service Desk è la soluzione migliore per poter gestire il Service Desk del progetto. Facilmente integrato con tutti i prodotti della Atlassian, consente di poter implementare un sistema di gestione delle anomalie/richieste/nuove evolutive, in maniera molto semplice.

In maniera molto semplice, e con pochi click, come già spiegato in questi posts, possiamo implementare un sistema molto semplice, con una interfaccia chiara e diretta. Pochi passi e anche chi si occupa di gestire queste situazioni, dispone di un quadro completo.

Pochi click e già si dispone di un sistema comprensivo di reportistica e di strumenti in grado di monitorare la produttività.

L’integrazione con JIRA, consente agli agenti di potersi interfacciare direttamente con il gruppo di sviluppo / manutenzione senza grandi difficoltà e, una issue generata con JIRA Service Desk viene subito reindirizzata alla persona giusta affinché la gestisca nel minor tempo possibile.

La possibilità di poter modificare il workflow, in modo da gestire tutte le situazioni di cui si ha la necessità, ci consente di poter coprire le nostre esigenze al meglio.

Conclusioni

Abbiamo uno strumento valido per gestire il servizio di trouble ticketing, che abbiamo già esaminato in dettaglio in altri posts, che nella gestione di un progetto non deve assolutamente mancare. Nei prossimi post, andremo ad inserire FISHEYE e JIRA Capture per andare a gestire meglio determinate situazioni.

Una piccola novità

Vediamo, in questo post, una piccola novità riguardante le tabelle standard di Confluence.

In dettaglio

Andiamo subito in dettaglio per vedere che cosa ci ha riservato la Atlassian.

Dalla GIF animata, vediamo subito la prima novità, ovvero quello di poter eseguire lo scroll delle tabelle grandi senza modificare le testate. Questo è sicuramente un vantaggio quando si deve leggere una tabella molto grande e con un numero molto alto di righe, mentre lo spazio che abbiamo a disposizione è limitato

Questo va a completare quanto già introdotto sulle tabelle, e ampiamente spiegato nel post precedentemente pubblicato.

Conclusioni

Caratteristica molto importante. Questo di sicuro aiuterà gli utenti nella consultazione e nella implementazione di tabelle molto grandi.

Nuove migliorie

In questo post andremo a visionare le ultime novità introdotte dalla Atlassian, su JIRA Service Desk per la versione 2.5. Continuiamo quanto riportato nei post:

• JIRA Service Desk 2.0
• JIRA Service Desk 2.2
• JIRA Service Desk 2.3
• JIRA Service Desk 2.4

Ultime novità

Le ultime novità riguardano i seguenti aspetti:

• Reporting: Migliorato ed aggiunte nuovi reports, per meglio monitorare le attività degli agenti.

• Portal: Migliorata ulteriormente la possibilità di personalizzare il Portal

• Queue Update: Migliorato il comportamento delle code e migliorato l’update

Conclusioni

Si tratta mi piccole migliorie, ma sono sicuro che introducono un grande miglioramento. Nei prossimi post andremo ad esaminarle nel dettaglio, continuando il percorso iniziato con i seguenti post:

• Esempio di uso – Parte 1
• Esempio di uso – Parte 2
• Esempio di uso – Parte 3

Un suggerimento

In questo post, andremo a vedere un piccolo trucchetto che ho usato per poter esportare dei dati, sopratutto quando si tratta di esportare dati di una certa mole.

Andiamo nel dettaglio

L’idea è di fare uso di SQLPLUS, che si presta bene a questo genere di lavori. sfruttando le sue capacità. In particolare ci appoggiamo alla possibilità di poter inviare su file il risultato della esecuzione della query. Stiamo parlando del comando: SPOOL;

Andiamo nel dettaglio e vediamo come fare.

Una volta definita la query, con tutti i dati che sono necessari. Quindi componiamo la query come segue:

Select <campo1> || <campo2> || ..... || <campon> from .....

oppure come

Select <campo1> || <delimitatore> || <campo2> || <delimitatore> ||  ..... || <campon> from .....

a seconda che si voglia avere una estrazione dove i campi sono a lunghezza fissa (primo caso) o con delimitatore (secondo caso).

A questo punto, vediamo come procedere per avere l’estrazione vera e propria.

Attiviamo SQLPLUS, da riga di comando:

sqlplus <utente>/<password>@<dbsid>

Quindi forniamo la sequenza di comandi:

set heading off
set pagesize 0
set linesize 200
set feedback off
Spool on
Spool <file_destinazione>.txt
<scriviamo la Query, mettendo il ';' finale >
Spool off <da lanciare al termine della esecuzione della query>

La precedente figura da una idea per capire come procedere. Ovviamente mi sono limitato a eseguire una query di esempio per mostrare il funzionamento.

Conclusioni

Abbiamo un sistema molto semplice per eseguire delle estrazioni dati molto semplici. Il metodo è automatizzabile, creando degli script ad hoc, per semplificarci ulteriormente la vita :-).

Hello World

In questo post, continuiamo ad esaminare le User Macro. In particolare andremo a vedere quale iter seguire per creare la prima User Macro: HELLO WORLD 🙂

Premessa

Le User Macro sono disponibili solo per le installazioni server. Sulle installazioni Cloud, non abbiamo alcuni Addon, causa motivi di sicurezza. In altri post, andremo ad esaminare più in dettaglio le differenze tra le due installazioni.

Procediamo

Dato che si tratta di una funzionalità esistente nello standard, non abbiamo bisogno di preparazione o di installare alcunché. Come già descritto nel precedente post, andiamo a posizionarci nella sezione dedicata alla generazione delle user macro.

Quindi, sotto la sezione delle Configuration, andiamo a selezionare le User Macro.

Procediamo quindi a generare la nostra User Macro, selezionando Create a user macro si procede con la creazione vera e propria

Si impostano i primi parametri, quali:

• Nome: assegniamo il nome alla macro.
• Visibilità: indichiamo chi può vedere/utlizzare la macro
• Titolo: Sarà il testo che sarà visualizzato nella lista delle macro
• Descrizione: Sarà la descrizione che sarà posizionata nella lista delle varie macro.
• Categorie cui assegnare la macro. Le macro sono normalmente raggruppate in categorie. Si tratta solo di definire dove la macro sarà visualizzata
• Icona  da visualizzare nell’elenco delle macro. Si tratta di una URL in cui sarà disponibile l’icona da usare.
• Documentazione. URL di riferimento della documentazione associata.
• Codice vero e proprio della macro. Si tratta del codice della macro. Qui abbiamo l’azione definita.

In questo caso abbiamo inserito il codice del nostro Hello World. Ricordiamoci ci settare il parametro Macro Body Processing come Rendered .  Questo parametro è importante in quanto indica se la macro presenta un body da trattare. Chiariamo meglio: Per body si intendono quelle macro in cui è possibile scrivere un testo da poter poi processare. Come si vede nella figura successiva:

Abbiamo la visualizzazione della macro Panel, usata per generare un Pannello dove raggruppare informazioni. Il Body è la sezione dove viene posizionato il cursore e dove possiamo riportare del testo.

Chiarito questo primo concetto, vediamo le possibili alternative del parametro precedentemente indicato:

• No macro body – La macro non presenta tale body.
• Escaped – da usare se si vogliono visualizzare i markup HTML. In questo modo, saranno aggiunti dei codici escape per la visualizzazione dei tag
• Unrendered – Il codice HTML sarà processato all’interno del codice vero e proprio.
• Rendered – HTML presente nel body sarà processato e l’output sarà visualizato. Ad esempio: <b>Hello World</b> sarà visualizzato come: Hello World 🙂

Una volta salvata, la macro è disponibile. Creiamo una nuova pagina, come mostrato in figura:

Selezioniamo la macro, come una qualsiasi macro disponibile. Quindi scriviamo un qualsiasi testo all’interno

Quindi salviamo la pagina. Il risultato è il seguente:

Conclusioni

Abbiamo visto come si può creare una semplice User Macro in Confluence.

https://confluence.atlassian.com/display/DOC/Writing+User+Macros

https://developer.atlassian.com/confdev/tutorials/macro-tutorials-for-confluence/creating-a-new-confluence-macro

https://developer.atlassian.com/confdev/tutorials/macro-tutorials-for-confluence

Prova su strada – Parte 2

In questo post, concludiamo la prova su strada degli addons rilasciati dalla Kenoah, presentato nel post. La prima parte della prova su strada è visibile nel seguente post.

Test cases – Definizioni preliminari

Prima di iniziare la prova su strada, partiamo dalle definizioni preliminari e facciamoci aiutare da Wikipedia. Prima di continuare, fare riferimento a:

• Test Case o caso di test. Si tratta delle condizioni per verificare se il programma risponde correttamente
• Test Plan o piano dei test che devono essere eseguiti per verificare che le funzionalità, che compone un software, rispondono correttamente

Test test test test

Iniziamo con l’installazione dell’addon

Dopo aver eseguito l’installazione, l’addon è pronto all’uso 🙂

Possiamo usare subito l’addon. Tra i vari menù, abbiamo a disposizione una nuova voce: Tests.

Se selezioniamo questa nuova voce di menù, passiamo alla definizione dei vari Test Case

Procediamo con la definizione di un Test Case di prova :-). Selezioniamo NEW

Possiamo definire le seguenti sezioni:

• Details, intesi come i dettagli generali del test
• Test Script, dove definiamo il dettaglio dei vari passi che devono essere eseguiti
• Run History, dove vediamo le volte in cui il test è stato eseguito
• Coverage, dove abbiamo l’elenco delle issues che sono coperte da questo test
• Attachments, dove indichiamo tutti gli attachments che sono utili

Nel definire i Test Script, abbiamo la possibilità di poter definire quali passi devono essere eseguiti per eseguire il caso di test.

ovviamente si tratta di un esempio :-). Ma immaginate quali informazioni potete inserire. Possiamo dettagliare il test in tutti i passi che sono necessari per ricostruire la situazione. Questo significa che possiamo avere il dettaglio completo di quello che si vuole fare 🙂

A questo punto, dopo aver definito tutti i Test Case, possiamo costruire tutti i Test Plans. Vediamo come:

Come per i Test Case, andiamo a definire prima il Dettaglio generale.

Quindi, andiamo a selezionare i Test Case che vogliamo siamo eseguiti. Un drag & Drop ed il gioco e fatto.

Salviamo ed il gioco è Fatto

Quindi?? andiamo ad eseguire il nostro Test Plan interessato

Selezioniamo il tasto Run per procedere con il test vero e proprio.

Creando il Test Run, andiamo a indicare che caratteristiche deve possedere, indicando anche quando deve essere eseguita e conclusa.

Quindi, una volta indicate queste informazioni, passiamo al RUN vero e proprio. Abbiamo a disposizione un Timer, che indica quanto tempo ha richiesto il test vero e proprio.

Se Il test è passato, settiamo lo stato in Pass. Altrimenti indichiamo lo stato richiesto.

Al termine, possiamo vedere i risultati nella reportistica, che l’addon mette a disposizione.

Come si vede, abbiamo tutte le informazioni del caso.

Conclusioni

Abbiamo un addon che consente di poter pianificare e gestire in maniera semplice e ben fatta tutti i test di cui abbiamo bisogno. In questo modo, possiamo disporre di una libreria di test, rendendo la vita del Team di test …. molto più piacevole e sicura.

Prova su strada – Parte 1

In questo post andiamo ad esaminare la prova su strada degli addons, presentati nel precedente post.

Checklist

Partiamo dall’addon della checklist. Installiamo l’addon, come sempre:

L’addon viene scaricato e installato sulla nostra istanza server di JIRA.

Completata l’installazione, si passa a richiedere la licenza. Nel nostro caso, ho richiesto la licenza Trial.

Terminata l’operazione, si può usare l’addon. 🙂

Il primo passo è quello di creare un nuovo Campo Custom, come mostrato nelle seguenti immagini.

Possiamo creare direttamente dalla form di gestione della Issue oppure dalle form di amministrazione dei campi.

Come tipo del campo, selezioniamo Checklist, che consente di poter generare quello che ci serve.

Concludiamo la configurazione, indicando una descrizione. A questo punto possiamo definire le voci che compongono la checklist

oppure possiamo entrare nel dettaglio dell’editing della issue e procedere con la generazione della checklist

Possiamo, ad esempio, stabilire i passi per eseguire il test e verificare che l’anomalia sia effettivamente risolto. Il risultato è il seguente:

Quando si verifica che il passo è rispettato, su può selezionare il passo stesso

e come si vede, la barra di avanzamento, si modifica.

Risultato?

Questo addon mette a disposizione uno strumento visuale che, in maniera molto semplice, fornisce una indicazione dell’avanzamento della verifica anomalia. In questo modo, sia chi esegue il test, sia chi esegue la correzione, dispone di una indicazione per capire fino a che punto si è arrivato nella verifica o nello sviluppo.

Le potenzialità sono tantissime.

Conclusioni

Abbiamo un addon che introduce una piccola feature, ma mette a disposizione una funzionalità visuale non indifferente. Nel prossimo post, andremo a vedere il secondo addon della Kenoah.

https://marketplace.atlassian.com/plugins/com.kanoah.test-manager

https://marketplace.atlassian.com/plugins/com.kanoah.jira-checklist

Cloud o Server?

In questo primo post, di una serie dedicati all’argomento, andremo ad esaminare quali sono le differenze principali tra le due release dei prodotti. Obbiettivo è quello di fornire tutte le informazioni necessarie per operare la scelta migliore, in base alle esigenze.

Andiamo nel dettaglio

Credo che il primo punto da chiarire sia dare una prima spiegazione del perché di queste differenze. Innanzitutto, si tratta di situazioni differenti. Le versioni cloud (ex onDemand) sono gestite centralmente dal personale Atlassian e, di conseguenza, alcune funzionalità sono controllate direttamente da loro. Fornirle in mano ai clienti potrebbe essere controproducente in quanto potrebbe arrivare ad impattare altre installazioni.

Quali prodotti sono disponibili in cloud?

Prima di vedere le differenze, vediamo quali prodotti Atlassian sono disponibili.

• Confluence
• JIRA
• JIRA Service Desk
• JIRA Agile
• JIRA Portfolio
• Hipchat
• Bamboo

Adesso vediamo il dettaglio delle varie caratteristiche.

Il ruolo di System Administrator  viene ricoperto dal personale Atlassian. Di conseguenza, tutte le funzionalità che ruotano a tale ruolo, non sono disponibili.

I Backup schedulati non sono possibili, ma è comunque possibile eseguire una esportazione dati, al fine di riportarla su installazioni Server. I backup giornalieri NON sono consentiti in quanto il personale Atlassian li gestisce a livello centrale.

User Macro, HTML Macro e tutto ciò che impatta HTML (come macro standard) è disabilitato. Non esiste altra possibilità di poter abilitare tali addon su Cloud. Tuttavia, sono disponibili degli addon di terze parti che consentono di includere pagine web di siti terzi.

Mail Account e Mail server sono configurati e gestiti a livello centralizzato. Questo per gestire il tutto a livello centrale. Di conseguenza non è possibile customizzare questa parte.

Le versioni cloud utilizzano dei propri layout, ma non risulta possibile inserire delle variazioni ai CSS per la versione Cloud nè personalizzare il layout della versione cloud.

Non tutti gli addon sono disponibili per la versione Cloud. Il motivo è da ricercarsi nel fatto che, essendo la versione cloud centalizzata, la Atlassian ha modificato il come impostare gli addon per la soluzione cloud. Di conseguenza, anche lo sviluppo deve avvenire in maniera differente. Il seguente link aiuta a capire quali addon sono, al momento, disponibili. Come ho già avuto modo di evidenziare in post pubblicati, il numero di addon per la versione cloud è notevolmente aumentato nell’ultimo anno. Per la tecnologia da usare, fare riferimento ad Atlassian Connect. dedicheremo post a questo argomento.

Conclusioni

In questo post abbiamo dato una prima scorsa alle differenze tra le due installazioni, dove abbiamo visto quali operazioni sono possibili per una o per l’altra installazione. Questo aiuta sicuramente nella scelta del prodotto che si vuole e nel bugdet a disposizione. Nei prossimi post andremo a dettagliare le differenze, evidenziandole e commentandole.

Riferimenti

Pagina della documentazione Confluence disponibile qui.