Una piccola panoramica

Affrontiamo, in questo post, una piccola panoramica di vari addon, che sono a disposizione della versione onDemand di Confluence e Jira. In questo modo, esploriamo ulteriormente quali funzionalità sono state incluse di recente e riscopriamone altre.

 

Confluence

Si parte da Google Maps for Confluence, che consente di poter aggiungere le Google Maps nelle pagine di Confluence, comprensiva di Street View, come mostrato nelle seguenti immagini:

Si continua per il Comala Canvas for Confluence, che consente di poter inserire delle schede (sull’esempio di Jira AGILE BOARD) su Confluence, come mostrato nelle seguenti figure.

Citiamo anche vSecure, un semplice addon che consente di poter criptare/decriptare informazioni all’interno di pagine Confluence:

 

JIRA

Partiamo citando l’addon Aha! Visual Product Roadmaps, che consente di poter creare delle roadmap interattive molto belle.

Citiamo Gantt Cloud, che consente di poter generare dei grafici GANTT su Jira, come mostrato dalle seguenti figure:

 

Conclusioni

Non possiamo che notare con piacere che, anche per la versione onDemand, si inizia a vedere il proliferare di nuovi addon e di nuove funzionalità. Non ci resta che attendere i nuovi sviluppi. Una piccola precisazione: Non tutti gli addon che sono stati citati sono a pagamento, ma alcuni di essi sono gratuiti. Questo per sottolineare che non tutti gli addon che sono disponibili per l’onDemand sono necessariamente sempre a pagamento 🙂

Una buona notizia

Una buona notizia da Atlassian. Come annunciato dal loro Blog, Atlassian University è adesso accessibile a tutti. tutti i contenuti soo disponibili a chiunque voglia imparare.

Basta connettersi al link university.atlassian.com per poter usufruire gratuitamente di tutti i contenuti.

Migliaia di Tips, informazioni, articoli sono a disposizione :-). Anche se in inglese, questi articoli sono molto interessanti. Li consiglio a tutti coloro che vogliono imparare, iniziare ad imparare i prodotti della Atlassian o che sono curiosi di capire quali potenzialità può offrire. Buon divertimento 😀

 

In questo post sarà fornito un esempio di come realizzare, attraverso l’utilizzo combinato di Confluence e Jira,  una buona gestione delle risorse riusabili in uso presso una azienda. Si rimanda al seguente post blog, dove viene fornita una prima indicazione di come sia possibile utilizzare Jira e Team Calendar.

Per risorse riusabili si intende:

• automezzi aziendali (macchine/furgoni);
• pc notebook
• borse di attrezzi
• sale riunioni
• carte di credito aziendali
• etc

Nel post sarà mostrato un esempio di utilizzo di Confluence e Jira, al fine di realizzare la gestione di sale riunioni. Il concetto può essere tranquillamente esteso anche ad altre risorse.

 

Prerequisiti

Per realizzare quanto indicato, si deve disporre di:

• Confluence, dove è stato installato il Team Calendar
• Jira, dove è stato installato il Jira Service Desk

Il primo sarà utilizzato prevalentemente per la visualizzazione, su apposite pagine della allocazione delle risorse riusabili.

Il secondo sarà utilizzato prevalentemente per gestire tutte le richieste, il Workflow di avanzamento delle stesse e l’indicazione dei vari dati.

 

Passo 1 – Configurazione

Il primo passo è configurare i due applicativi affinché possano comunicare. Questo link  fornisce le indicazioni. Il secondo passo è quello di creare un Service Desk su Jira. Questo lo si ottiene attivando la relativa autocomposizione dal menù Service Desk , come mostrato nella figura sottostante.

Selezionare New Service Desk Project, quindi specificare i parametri del progetto (nome progetto e chiave).

Il Service Desk sarà quindi generato.

Fondamentalmente, questo crea un progetto sotto Jira, impostandolo in maniera opportuna affinché possa essere utilizzato per gestire delle richieste. L’unica differenza, in questo caso,  è che queste richieste dovranno:

• presentare un periodo temporale (data/ora inizio e data/ora termine);
• presentare degli attributi, che danno la possibilità di poter identificare la risorsa riusabile. Nel nostro esempio, si tratta del numero della sala riunione ;

Fatto ciò, arriva la parte più difficile: Eventuale configurazione del Workflow, qualora siano necessarie ulteriori stati aggiuntivi nella sequenza di approvazione, oltre che aggiungere dei campi alle segnalazioni, affinché diano la possibilità di poter impostare le informazioni aggiuntive che sono necessarie per la gestione della risorsa riusabile. In questo esempio sarà utilizzato un Workflow standard, generato dalle procedure di autocomposizione, fornendo i dati i riferimenti alla manualistica Atlassian per poter eseguire le modifiche.

L’aggiunta dei nuovi campi non è particolarmente problematica. Basta semplicemente andare in configurazione del progetto, associato al Jira Service Desk precedentemente creato (nel nostro esempio progetto Sale riunioni, chiave SR).

Selezionare la sezione di amministrazione:

quindi modificare il tipo di Issue Type per il Service Desk, creando un tipo opportuno di Issue. L’autocomposizione imposta alcuni tipi di issue. Dal Menù Action , in alto a destra, selezionare Edit Issue e procedere con la generazione del nuovo tipo: Reserve Meeting Room . Selezionare Add Issue Type . Questo attiverà la funzione che genera il nuovo tipo:

mostrado l’autocomposizione:

Deve trattarsi di un Standard Issue Type. Fatto ciò, lo selezioniamo come il tipo di default di Issue da generare.

Fatto ciò, da qui in avanti possiamo impostiare il workflow.

Sempre dalla schermata delle Issue Type attivare, come mostrato in figura:

dove si accede alla pagina di gestione del workflow. Selezionare il tasto EDIT per eseguire l’editing del workflow

Si segnala il seguente link, per avere maggiori informazioni su come lavorare con il workflow di Jira.

A questo punto, inseriamo dei campi custom, nella issue, in modo da poter gestire le informazioni che ci identificano, in maniera univoca, le risorse riusabili. Nel nostro caso si tratta del nome delle sale riunioni, della data/ora di inizio della riunione e data/ora termine della stessa.

Selezionare la sezione Fields quindi editare i campi della Issue selezionando Actions –> Edit fields .

 

Selezionare la sezione Custom Fields, quindi procedere con l’aggiunta dei seguenti campi:

• Sale Riunioni
• Inizio Riunione
• Termine Riunione

Mentre gli ultimi due campi devono essere configurati come DateTime, il primo campo deve essere configurato affinché fornisca i dati da una lista ben definita:

 

 

Come ultimo passo, occorre indicare quali campi deve compilare l’utente in fase di richiesta. Questo viene eseguito attraverso la configurazione del portale del Service Desk. Dal menù Service Desk –> Sale Riunione accedere alla pagina di gestione delle varie richieste.

Selezionare Customer Portal , in modo da impostare quali richieste può generare un utente. Quindi impostare le possibili richieste, accertandosi di specificare, nell’ambito della richiesta, i campi che devono essere valorizzati:

A questo punto possiamo iniziare a mettere a disposizione degli utenti la possibilità di poter richiedere l’utilizzo delle sale riunioni.

 

Passo 2 – Utilizziamo il tutto

Iniziamo ad usare il sistema per riservare le sale riunioni.

Dal menù Service Desk –> Nuova richiesta si entra nella pagina di selezione:

dove troviamo il link alla funzione per creare la richiesta. Doppio click su Accesso sala riunione per impostare i campi della richiesta, come mostrato nella seguente figura:

Confermando il tutto, la richiesta inizia il suo iter. Da Jira  possibile esaminare tutte le varie fasi, come se si trattasse di normali issue Jira. Dal portale di gestione Service Desk, il responsabile del progetto accetterà o meno la richiesta. Il sistema di gestione delle mail si occuperà di avvisare gli utenti dell’accettazione o meno della richiesta stessa.

 

Come rendiamo visibile agli utenti il tutto??

Adesso, possiamo pubblicare, su di una pagina di apposito space o sullo space pubblico, una macro che pubblica su di un Calendar, dedicato a questo scopo, queste informazioni. Nel post blog  pubblicato in passato, è possibile vedere come poter collegare Team Calendar a Jira. Seguendo le semplici istruzioni, questo è il risultato che otteniamo:

 

Conclusioni

Ecco un buon esempio di come poter utilizzare Confluence e Jira per poter gestire delle risorse riusabili. Tuttavia, proprio dall’ultima immagine, notiamo un piccolo difetto: Non possiamo visualizzare tutti i nuovi campi aggiunti. Infatti non riusciamo a vedere di che sala riunioni si tratta: occorre entrare nel dettaglio della Issue per poterla vedere. Tuttavia è un buon inizio per arrivare ad avere una prima gestione, centralizzata, delle risorse riusabili.

La configurazione non è proprio agevole, ma una volta impostata, gli utenti possono usare lo strumento senza nessuna difficoltà, in maniera semplice con pochi click.

Rimaniamo in attesa di ulteriori sviluppi sui vari componenti indicati. Sono sicuro che la Atlassian saprà sicuramente stupire. Fino a qualche anno fa, Jira non conosceva neanche il concetto di risorsa, mentre con l’introduzione del Jira Service Desk, ha finalmente introdotto un concetto indispensabile nelle aziende.

 

Referenze e letture varie

Si suggerisce la lettura dei seguenti link come ulteriore approfondimento:

• Gestione delle ferie – Link
• Uso combinato Team Calendar – Jira – Link

 

Affrontiamo un argomento abbastanza spinoso. Backup e Restore dei dati di Confluence e JIRA.

Premessa

Almeno una volta nella vita capiterà di dover eseguire il restore. Lo stesso accadrà anche per Confluence e JIRA, che non sono da meno. Il consiglio che dò è di preparavi a tale evento, eseguendo dei test di restore dai backup che sono stati realizzati, cercando di capire bene tutte le operazioni che devono essere eseguite e tutti i problemi che si possono presentare. Al termine delle prove, si disporrà della esperienza per poter eseguire le operazioni necessarie senza grosse difficoltà.

In questo post vedremo alcuni scenari e descriveremo come eseguire il restore dei dati, rischi e punti di attenzione.

Tipologie di backup

Esaminiamo le possibili tipologie di backup che abbiamo a disposizione.

Per tutte le installazioni (onDemand e download) messe a disposizione, possiamo eseguire un backup generale di:

• Confluence – Tutti gli space (pagine, commenti, allegati, etc), comprensivi degli utenti, sono esportati su di un unico file ZIP;
• JIRA – Tutti i progetti e gli allegati, comprensivi degli utenti, sono esportati su di unico file ZIP.

Per Confluence è possibile anche eseguire una esportazione di un singolo Space ed importarlo. Lo stesso può essere eseguito anche su JIRA, con la differenza che è possibile eseguire l’import di un singolo progetto, sempre partendo da un intero backup (Rif. alla seguente risposta su Atlassian Answer).

Per grandi installazioni, su server locali, non è conveniente eseguire delle esportazioni così indicate, in quanto i file XML risultano troppo grandi per essere gestiti. In questo caso occorre fare riferimento alla seguente pagina, dove viene specificato meglio quale strategia utilizzare per i backup e per i ripristini. Di seguito comunque indicheremo come eseguire un restore.

Una considerazione….

I dati presenti sul file ZIP possono variare da versione a versione (sia per Confluence che per JIRA) e non sempre si riesce ad importare da una versione all’altra. E’ possibile operare una workaround, come  riportato nel seguente link, ma nel caso di  evidenti differenze di versioni (es. da una versione 3.5 ad una 5.5), allora conviene procedere all’aggiornamento dei dati attraverso un upgrade del sistema Confluence o JIRA.

 

Possibili scenari

I principali scenari che vi si possono presentare sono:

• Restore di un sistema installato su di un server locale, sia esso il server di produzione, sia esso il server di test da utilizzare per vari scopi (test di nuovi plugin, ambiente di test per replicare eventuali malfunzionamenti, etc);
• Spostamento dei dati da un confluence ondemand ad una installazione in locale (in questo ultimo caso si vuole portare le informazioni da uno o più space verso una installazione che già contiene degli space e che risulta in uso).

Nel caso del primo scenario, nella ipotesi che si disponga di una installazione della stessa versione del backup, possiamo eseguire il ripristino come segue:

1. Riportare il file di backup su (CONFLUENCE_HOME)/restore oppure posizionarlo su apposita directory dove eseguire il restore delle informazioni. La procedura consente di poter selezionare dove prelevare il file ZIP (vedi figura successiva);
2. Accedendo alla sezione di amministrazione, sezione Import Site, selezionare quindi il file da importare, come mostrato nelle due figure successiva, per Confluence e per JIRA.

 

CONFLUENCE ADMINISTRATION

 

 

JIRA ADMINISTRATION

 

 

Qualora sia stata eseguita una strategia di backup differente (come indicato prima, facendo riferimento alla pagina del manuale di confluence), dove si è eseguito:

• Backup del database;
• Backup della Confluence Home (o JIRA Home)

il ripristino deve essere eseguito ripristinando entrambe le due componenti sopra indicate, a server spento. Quindi riattivare il tomcat ed attendere il riavvio, controllando tutti i messaggi che si presentano nel log. Qualora si stia predisponendo una nuova installazione, vuoi di un server di test o di altro, occorre allora modificare i puntamenti al database, presenti nel file confluence.cfg.xml, e inserire dove è stato eseguito le coordinate del database di cui si è eseguito il restore. Questa modalità può essere eseguita solo su installazioni in locale.

 

 Punti di attenzione

Come ho indicato prima, i file ZIP presentano anche le indicazioni degli utenti. DI conseguenza, quando si esegue il restore, occorre prestare molta attenzione. Se si vuole eseguire un restore di un backup su di una installazione già avviata (vuoi per eseguire una unificazione di sistemi diversi, una on demand ed una locale), quando si esegue una importazione dello ZIP, gli utenti vengono riportati sulla installazione in cui si esegue il restore, rimuovendo il contenuto preesistente. Se non si agisce con criterio, si rischia di fare dei danni.

In questo caso occorre operare degli accorgimenti. Nel caso di JIRA, eseguire una importazione di un singolo progetto (nel caso di più progetti, l’operazione potrebbe richiedere molto tempo: Valutare bene le operazioni in questo caso). Nel caso di Confluence, procedere ad una esportazione di singolo space e relativa importazione.

L’unione fa la forza

Vedremo, in questo post, come integrare Team Calendar di Confluence e JIRA, in modo da sfruttare al meglio le caratteristiche di entrambi i sistemi.

Nel precedente post, è stata fornita una prima visione di Team Calendar e delle sue potenzialità. Vediamo come poterle indirizzare meglio collegandoci a JIRA.

In prima battuta occorre che i due sistemi siano stati collegati, affinché sia possibile questa operazione. Si rimanda al seguente link per maggiori dettagli.

Fatto ciò, possiamo impostare Team Calendar affinché visualizzi, come eventi del calendario, i task di JIRA, come mostrato nella seguente figura:

 

Verrà proposta una form in cui si richiede di specificare la tipologia di evento:

 

Se viene specificato JIRA Issue Dates, la form si connetterà a JIRA e proporrà in automatico l’elenco dei progetti cui andare a leggere i dati. In alternativa è possibile sfruttare anche i filtri già salvati oppure costruirsene di propri, sfruttando il linguaggio JQL, che JIRA mette a disposizione per poter costruire delle query sulle issues.

Un esempio di evento preconfigurato è il seguente:

 

dove è stato impostato un filtro JQL ad hoc. Il risultato è il seguente:

In questo modo si ha una visione globale dei vari task.

 

Conclusioni??

 

Possiamo utilizzare questi strumenti per coordinare un team di sviluppo, pianificare riunioni ed eventi, visualizzare i task di progetto, coordinare diversi gruppi di lavoro e sviluppo. Le potenzialità sono infinite :-).

Nei prossimi post cercheremo di descrivere ulteriori funzionalità dei prodotti Atlassian.

Collect, service, report

 

Si tratta di un nuovo Addon per JIRA, che fondamentalmente si occupa di gestire le richieste utenti ed implementare un Service Desk completo, comprensivo della gestione degli SLA in base al tipo di richiesta.

L’addon è disponibile sia nella versione onDemand che nella versione download. L’installazione dell’Addon non richiede particolari competenze, grazie anche al lavoro svolto da Atlassian, che ha reso il lavoro di manutenzione molto semplice.

Una volta installato (Visibile fin da subito nella toolbar in alto), si procede alla configurazione. Quindi si crea un nuovo progetto destinato alla gestione del service desk oppure viene data la possibilità di poter associare tale funzionalità ad un progetto già esistente. A questo punto è possibile definire i vari SLA e definire la reportistica per valutare le performance del servizio.

Fatto ciò, l’addon è a completa disposizione degli utenti, che possono fare subito uso delle nuove funzionalità e impostare le prime richieste.

Attraverso le opzioni del menù sopra riportato, è possibile generare le richieste, che fondamentalmente sono dei task di JIRA, visionabili anche attraverso le normali viste di ISSUE e di progetto.

Utilizzando l’addon, è possibile visionale le code di gestione dei vari task:

 

Una volta che il task viene assegnato ad un utente, il lavoro di gestione è il medesimo di un task JIRA. L’addon mette a disposizione diverse possibilità di modificare o adeguare le varie code di task, in base alle richieste ed esigenze dell’utente.

Una sezione report, consente di poter visionare l’andamento dei task e valutare la situazione, come mostrato dalla seguente immagine:

A questo punto la fantasia non deve far altro che scatenarsi. Gli utilizzi possono essere molteplici. Si può configurare l’addon per gli usi più svariati:

• Richiesta/Gestione Ferie e permessi
• Richiesta installazione software
• Richiesta supporto su vari sistemi

Nei prossimi post vedremo un uso combinato di JIRA Service Desk con altri addon e sistemi della Atlassian.