Ultime novità su JIRA Software

Prosegue la serie di post dedicati alle ultime novità dei prodotti della Atlassian. Ci occupiamo adesso di JIRA Software.

Cosa abbiamo di nuovo?

Iniziamo con la prima schermata che viene visualizzata all’inizio di tutte le attività è la seguente:

Tutte le prime schermate che venivano proposte, sono state unificate nella precedente schermata, che risulta di più agevole e rapida nell’utilizzo.

Per dare maggiore flessibilità al team Agile, viene messa a disposizione la possibilità di poter gestire e delegare le responsabilità delle Sprint. Di conseguenza, è stata introdotta una nuova permission: manage sprint; come mostrato nella precedente Gif.

Questo ovviamente presuppone una grande fiducia ed un team molto affiatato, altrimenti questa opzione potrebbe generare delle situazioni molto inconsistenti.

Altra novità è quella di Flag and comment una issue contemporaneamente. In questo modo è possibile marcarla come importante (Flag) e successivamente inserire un commento. Si tratta di una piccola feature, ma utile per coloro che lavorano tutti i giorni su questi punti.

Conclusioni

Si tratta di piccole modifiche, ma che semplificano notevolmente il lavoro.

References

Maggiori informazioni sono disponibili qui.

 

Esaminiamo JIRA Software

In questo post andiamo a completare il giro di prova su strada. Abbiamo già eseguito una installazione su di una nostra macchina virtuale. Andiamo quindi a completare l’opera.

Test test test test test test

Iniziamo, come prima cosa a collegarci sul nostro JIRA SOFTWARE e vedere che cosa ci offre subito :-). Eseguiamo la Login nella nostra installazione di prova:

Osserviamo subito che la dashboard è la medesima di JIRA CORE: non notiamo alcuna differenza.

Notiamo invece che possiamo selezionare due tipologie di progetti:

• Software, ovvero i progetti dedicati allo sviluppo di software;
• Business, ovvero i progetti non di sviluppo software (i medesimi di JIRA CORE).

Fondamentalmente, quello che possiamo fare è generare e gestire progetti come siamo abituati, avendo a disposizione, in questa installazione di JIRA, la Board Agile. Infatti, se creiamo un progetto ex-novo, quello che andiamo a vedere è:

a differenza di JIRA CORE, che prevede quanto segue:

Andiamo a gestire, oltre alle stesse tipologie di JIRA CORE , anche le tipologie di progetti dedicate allo sviluppo Software. Se andiamo a selezionare il progetto di tipo KANBAN, come mostrato dalla figura siccessiva, viene indicato il workflow necessario.

Procedendo con la normale procedura, assegniamo il nome al progetto e…..

…. questo viene creato. In questo caso, la board agile kanban viene subito proposta all’utente, in modo da metterlo in condizione di poter svolgere la propria attività.

A questo punto, si può procedere con lo sviluppo del software, second la metodologia kanban 🙂

Funzionalità disponibili?

Sono presenti le funzionalità che lo stesso JIRA CORE presenta, con l’aggiunta della Board AGILE. Sono presenti altre tipologie di Issue, come mostrato in figura:

Ricordiamoci che è sempre possibile creare delle nuove issue type, in base alle nostre esigenze, come per il JIRA CORE.

Faccio notare una cosa. Diamo una occhiata alla seguente immagine:

Possiamo osservare che su JIRA SOFTWARE è presente anche JIRA CORE. Questo vuol dire che JIRA SOFTWARE estende JIRA CORE. In aggiunta abbiamo che JIRA Service Desk,  che estende a sua volta JIRA SOFTWARE. Queste informazioni sono presenti nella sezione SYSTEM (COG menù) -> Application.

La configurazione di un progetto è identica sia per JIRA CORE che per JIRA SOFTWARE.

 

Conclusioni

Abbiamo visto JIRA SOFTWARE in azione. Abbiamo visionato alcune differenze con JIRA CORE, cercando di aiutare gli utenti ad usare entrambe le versioni, cercando anche di identificare le differenze tra le due installazioni, cosa che sicuramente aiuta gli utenti e gli amministratori nell’uso di tutti i giorni.

 

JIRA Software

In questo post, come per i casi prececenti, andremo ad esaminare come eseguire l’installazione di JIRA Software, esaminandone tutti gli aspetti.

Premessa

Come per quanto riportato in questo post, e successivi, le indicazioni da seguire sono le medesime. Occorre sempre tenere d’acconto le stesse considerazioni. Unica variante, rispetto a quanto indicato nel post, consiste nel fatto che installiamo questa versione solo se abbiamo la necessità di un JIRA che ci supporti nello sviluppo di software. Infatti, questa installazione ci mette a disposizione una serie di strumenti dedicati allo sviluppo software.

A differenza della installazione JIRA CORE, abbiamo a disposizione fin da subito le BOARD AGILE, per agevolare lo sviluppo software, tutto già incluso nella installazione, oltre che tutta una serie di strumentazioni che ci agevolano in questo obbiettivo.

Installazione & Configurazione

Che cosa cambia rispetto a quanto descritto per JIRA CORE? Assolutamente nulla :-). L’installazione viene eseguita seguendo gli stessi passi e avendo a disposizione le stesse accortezze già descritte nel post. Di conseguenza, vi rimando al post di installazione su JIRA CORE per qualsiasi dettaglio, ovvero ai seguenti post:

• Parte 1
• Parte 2

 

Conclusioni

Concludiamo questo post, dove abbiamo specificato una prima parte. Suggerisco ai lettori di ripassare quanto riportato nei post citati, dedicati a JIRA CORE, prima di passare alle fasi successive.

 

Continuiamo l’approfondimento

Proseguiamo il nostro viaggio verso le novità di JIRA. Iniziamo a parlare di JIRA SOFTWARE.

JIRA SOFTWARE

Come anticipato in questo post, abbiamo una nuova specializzazione di JIRA, espressamente dedicata per lo sviluppo software. Mentre abbiamo JIRA CORE, dedicato ai progetti non IT, questa pacchettizzazione è espressamente pensata e rilasciata per il software.

JIRA SOFTWARE non è altro che JIRA, cui siamo già abituati, con già integrate le funzionalità di AGILE programming. Nulla di più. Il tutto espressamente dedicato allo sviluppo software.

 

In aggiunta, sono presenti le ultime realizzazioni che, ad oggi, la Atlassian ci ha costantemente abituati, comprensive di migliorie che ci aiutano costantemente nella realizzazione del software. Segnaliamo anche ulteriori miglioramenti sulla grafica e sulla interfaccia web, come mostrato in figura.

Conclusioni

Abbiamo una nuova pacchettizzazione di JIRA che continua ad offrire molto agli sviluppatori. Con già inclusi i tools per lo sviluppo AGILE, ne fa uno tra i tool più potenti 🙂

Proviamo a rispondere alla domanda partendo dalle informazioni di base che abbiamo a disposizione. Se infatti consultiamo la Community, ci imbattiamo in queste risposte:

…. ed invece NO.

Non da tantissimo tempo, possiamo usare gratuitamente Confluence per implementare la KB basta che siamo titolari di una licenza JSM pagata ed annuale. Come riportato in questa documentazione ufficiale.

In questo caso, se abbiamo una licenza mensile, possiamo aggiungere Confluence con profilo Free (questo è sempre stato possibile) ma la vera novità è ceh con profilo annuale è possibile usufruire di Confluence per gestire la KB. Questo è molto interessante e l’articolo spiega come arrivare ad ottenere il risultato.

In questo post affrontiamo un argomento interessante, inerente le Regole di Automazione. Già recentemente abbiamo parlato, in questo post, di come la gestione dei limiti di queste regole cambiano dal prossimo primo novembre. Vediamo in questo caso come sopperire ad una necessità, ovvero come possiamo aggiungere un link ad una Pagina di Confluence ad una issue, direttamente da Regola di automazione.

Andiamo con ordine

Vogliamo associare ad una issue, quella che ha causato l’esecuzione della nostra regola, una pagina di Confluence ben precisa. Una cosa che notiamo subito è che non abbiamo a disposizione una azione specifica attraverso le Automazioni. DI conseguenza siamo leggermente frustrati. La domanda sorge spontanea. Come possiamo fare??

Abbiamo una soluzione

Ebbene si. Possiamo sfruttare una delle azioni che meglio si adegua per poter agganciare una pagina ad una issue. In particolare possiamo sfruttare questa azione:

Da questa azione possiamo fare ua cosa molto semplice: Chiamare una API di Atlassian e agganciare la pagina alla issue. ma vediamo quale è la API che andiamo a richiamare.

https://yourdomain.atlassian.net/rest/confluenceIssueLink/1/confluence?issueId={{issue.id}}&pageUrl={{createdPage.url}}

Questa è la chiamata alla API che ci interessa

Quello che occorre fare è impostare i parametri che ci servono e successivamente applicarli tramite la regola.

Il risultato è il seguente:

Conclusione

Questo è molto interessante. Possiamo agganciare una pagina Confluence alla nostre issue in maniera veramente semplice. Ci sono degli accorgimenti da tenere presente quando si utilizzano delle API, ma ne parleremo in maniera più approfondita in separata sede. Si tratta di una sorpresa. Rimaniamo in contatto.

Reference

Un ringraziamento a tutti i partecipanti a questa discussione della Atlassian Community, dove è stato chiarito questo punto e che ha permesso di poter scrivere questo articolo in Italica Lingua.

In questo post andremo ad esaminare un addon veramente interessante. Vi posso assicurare che ho avuto la possibilità di eseguire un collaudo molto accurato ed il risultato mi ha lasciato seriamente a bocca aperta dai grandi risultati ottenuti. Ma andiamo con ordine: Partiamo dall’inizio e spieghiamo il caso di uso cercando di mostrare come funziona questo addon.

Il caso di uso che mi si è presentato

In questa situazione, avevo la necessità di dover modificare massivamente il contenuto di un determinato campo, risultato della Migrazione da Server a Cloud per conto di un mio cliente. In questo caso, i campi migrati erano il risultato della migrazione del valore di Elements (ex nFeed). Il problema è che il valore dei campi risultava un qualcosa di questo genere, inaccettabile da proporre al cliente.

{“key:[“XXXXXXXX – Una descrizione del codice”]}

il risultato era un Json che non rispecchia proprio il valore desiderato dal cliente. Le funzionalità standard non permettono delle modifiche così approfondite. Si rendeva necessaria una operazione di ingegno. Iniziavo una analisi alchemica che mi aiutasse nella risoluzione del problema.

…. ma alla fine il risultato è giunto insperato

Una soluzione si è presentata quando oramai sembrava tutto perduto. Un addon mi salvava la vita e mi permetteva di poter correggere il valore e risolvere la questione. Si tratta di Advanced Bulk Edit for Jira, un addon della Codefortynine molto molto interessante.

Questo addon permette di poter eseguire delle operazioni sui campi permettendone la MODIFICA. Questa è una caratteristica molto molto interessante.

Dalla precedente immagine possiamo osservare che abbiamo diverse possibilità per modificare i campi. Possiamo aggiungere dei valori, eseguire delle operazioni di Sostituzione di testo con altro, etc. La faccenda diventa interessante

La mia esperienza lavorativa

Nell’utilizzo di questo addon ho notato una cosa molto molto interessante. Se andiamo ad eseguire una query JQL, quello che otteniamo è il seguente risultato (il particolare sul CLOUD): La query JQL non restituisce più di 1000 risultati, anche se le issue sono più di 1000. Questa è una limitazione che le API di Jira dispongono. DI conseguenza abbiamo sempre qualche problema

La seguente schermata è stata presa (opportunamente trattata per non mostrare dati riservati) al fine di riuscire a mostrare il risultato. Se ci fate caso il numero di issue selezionato è maggiore di 1000.

Quello che si nota è che il limite di 1000 issue è superato con questo addon. Non male, assolutamente non male.

Conclusione

Abbiamo un addon MOOOOOOOLTO MOOOOLTO interessante. Ho già identificato una serie di possibili utilizzi di questo addon in altri casi di uso. Verificherò e vi riporterò di seguito in altri post. Rimaniamo in contatto.

Reference

Maggiori informazioni sono disponibili presso la pagina del Marketplace.

Un annoso problema che ci assilla è causato dal fatto che non sempre possiamo collegare Jira Cloud con i Database….. fino ad ora. Qualche mese fa stavo eseguendo delle sperimentazioni che mi hanno portato a scoprire un addon molto interessante. Adesso, dopo la sperimentazione posso descrivere i primi risultati.

Descriviamo lo scenario

Questa situazione la conosciamo bene. Quando i clienti ci chiamando perché vogliono leggere le informaizoni dai loro database locali e le vogliono rendere reperibili anche su Jira Clòoud. Questa di solito è la nostra faccia

Proviamo a chiarire. Sappiamo beniussimo che il nostro Cloud è una macchina remota AWS localizzata, nel nostro caso, a Dublino o Francoforte (quindi GDPR RISPETTATA. CHIARO??). Concetto da tenere sempre presente è che Jira Cloud è su Internet e di conseguenza per poter accedere ad un database, questa macchina su internet deve essere (UDITE UDITE) autorizzata.

Ora, se andiamo in una azienda qualsiasi, i responsabili della sicurezza avrebbero qualcosa da dire. Se apriamo una porta del genere, occorre ben presidiarla oppure si rischia di fare dei danni. Ricordiamoci sempre che quando si apre una porta su internet, prima o poi si rischia che qualcuno di non desiderato entri dentro senza il nostro permesso. Fa parte dei rischi.

Quali precauzioni?

Possiamo prendere diverse precauzioni per far si che chiunque tenti di entrare non possa andare oltre un certo limite e, se anche dovesse arrivare, li si fermi. Parafrasando il celebre film “Il Codice da Vinci”, mi permetto di citare un verso della Bibbia: (Giobbe 38-11). e dissi: `Fin qui tu giungerai, e non oltre; qui si fermerà l’orgoglio de’ tuoi flutti?’

Possiamo fare in modo che il database che colleghiamo a Jira Cloud sia una copia con pochi dati. In questo modo, anche se qualcuno dovesse arrivare a leggerli, le informazioni siano parziali e non servibili allo scopo. Questo però implica che:

• i dati devono essere aggiornati a cadenze regolari
• In alcuni istanti i dati non saranno perfettamente disponibili (intendo gli ultimi)
• In ogni caso se qualcuno arriva li, legge dei dati e potrebbe comunque tentare delle operazioni di ricostruzioni.

Sicuramente questo è un sistema per limitare il danno, ma non eliminiamo completamente la possibilità di eliminare il danno.

La vera precauzione consiste nell’inserire il database direttamente su Jira, o sulla macchina remota. Solo così avremmo a disposizione la possibilità di poter gestire una sicurezza molto alta. Se il database è già interno a Jira, allora abbiamo la sicurezza di Atlassian che ci protegge. Tuttavia la macchina remota NON è usabile da parte nostra e non credo che Atlassian ci permetta di poter mettere mano a tali macchine dall’oggi al domani. Di conseguenza le possibilità sono molto ridotte….. oppure no?

Non disperiamo. Abbiamo una soluzione

Ebbene si. Abbiamo una soluzione. Possiamo portare i dati direttamente su Jira e usarli come un database e per questo obiettivo un potente addon ci permette di poter gestire questa situazione. ma come?

Semplice. Possiamo memorizzare i dati all’interno di un progetto di comodo, dove i record sono presenti nelle issue. Come ben sapete, le issue possono diventare qualsiasi cosa noi vogliamo. Questa è una delle grandi possibilità che Jira mette a disposizione di noi utenti.

Benissimo. Se mappiamo i record usando le issue type seguendo questa logica: è un tipo di record. Nell’issue type andiamo a memorizzare i dati che ci servono, utilizzando i campi custom per memorizzare anche altre informazioni del nostro record. Risultato? abbiamo il nostro database locale.

A questo punto passiamo alla seconda domanda. Come lo usiamo?

Anche qui ci viene incontro uno splendido addon che ci aiuta a rispondere a questa seconda domanda. Si tratta di:

Questo addon permette di poter eseguire delle interrogazioni direttamente su Jira come se fosse un database. In questo caso abbiamo a disposizione la nostra arma segreta: il JQL; che ci aiuta nell’interrogare i dati senza grandi problemi. Lo stesso lo possiamo fare con questo addon che ci permette di poter gestire il risultato finale.

L’addon permette di poter creare una connessione a Jira Cloud stesso . Questo consente di gestire Jira Cloud come un database e, come sempre sostengo da immemore tempo, il JQL ci aiuta a creare la query di selezione dei dati

Moooolto interessante e quale è il risultato?

Il risultato finale è che abbiamo a disposizione la possibilità di definire dei campi ‘database’, se mi si può concedere la libertà di scrivere così, dove i valori visualizzati sono prelevati dal progetto che abbiamo definito su Jira

Sfruttando l’addon possiamo ottenere questo risultato:

Come possiamo vedere, l’addon ci permette di poter sfruttare le issue di un progetto come se si trattasse dei record del nostro simil-quasi-database (concedetemi questo termine), ma l’utente finale non vede questa cosa: per lui è una lista. L’addon permette anche di poter aggiornare il campo a cadsenze regolari. Ciò che si deve fare e aggiornare l’elenco delle issue del progetto che abbiamo battezzato. L’addon può essere programmato per far si che l’elenco sia aggiornato a cadenza regolare.

Ovviamente consiglio di trovare un compromesso al tempo di aggiornamento che vogliamo: Questo per evitare comunque di sovraccaricare la nostra istanza di Jira Cloud.

Risultato?

Abbiamo una nuova arma in più per definire un database all’interno di Jira e sopratutto abbiamo la possibilità di poter mantenere una discreta sicurezza senza aprire quella della nostra sicurezza. In aggiunta, questo sistema può essere usato anche per:

• definire assets aziendali senza avere insight
• definire delle tabelle di un database interno a Jira
• definire delle semplici liste valori aggiornabili facilmente
• definire quello che vogliamo all’interno di Jira.

L’unico limite è la nostra fantasia.

Un mio appunto personale

Il 29 Giugno ho avuto il piacere di presentare questa soluzione al Meetup Madrid/Buenos Aires. Mi permetto di condividere il Video del mio intervento, disponibile su Linkedin

Reference

Maggiori informazioni sull’addon sono disponibili nella pagina del marketplace.

Domanda:

Sappiamo che nel profilo Standard, l’utilizzo delle regole globali è limitato. Come possiamo tenere sotto controllo il numero di esecuzioni?

Risposta

Possiamo sempre controllare il numero di esecuzioni. Gli utenti Jira Administrator possono accedere alla relativa sezione che gestisce le regole di Automation. Li troviamo una sezione che ci dice quanto è il consumo.

Adesso è bene chiarire un punto importante

Questo post mi serve anche per dare un chiarimento molto importante. Si tratta di una cosa che mi ha lasciato abbastanza basito e credo che sia bene chiarire, altrimenti mi trasformo nell’Incredibile Hulk…..

Sulle regole di automazione, si sta diffondendo una convinzione che non ha proprio ragione di esistere. Alcune aziende mi hanno segnalato che per poter sfruttare al massimo le regole di automazione, occorre disporre di un profilo Cloud PREMIUM, mentre con un profilo free o standard non si ottiene nulla a causa delle eccessive limitazioni sulla esecuzione delle regole stesse. Scusate ma proprio non comprendo proprio questa frase perché, cosi come viene impostata, non ci dice nulla, anzi. genera molta più confusione di quanto si possa immaginare. Proviamo a chiarire meglio.

Mi permetto di citare il link di documentazione ufficiale dove si spiegano diverse cose e invito una attenta lettura dello stesso in modo da chiarirsi le idee.

La limitazione riguarda l’esecuzione delle regole che sono applicate a:

• più progetti o multiprogetto
• globali

In particolare ripongo l’attenzione su questa frase:

All multi-project and global rule executions will count toward your usage. Single-project rule executions do not count toward your usage.

Fonte : Il documento sopra citato

In particolare mi permetto di riportare la seguente immagine, tratta dallo stesso documento sopra citato:

Quindi mi sembra di capire che le limitazioni sono attive, nei profili standard e free, solo quando la regola non è più applicata ad un singolo progetto. Se la regola è monoprogetto, non abbiamo alcuna limitazione.

Quindi l’informazione corretta è: Se si usano le regole su singolo progetto, non dobbiamo preoccuparci per il limite. Altrimenti, si.

Vero, ma avere una regola globale la gestiamo meglio ….

Verissimo, ma proviamo a ragionare alla Italiana (anzi: alla Siciliana). Lo so, mi piace vincere facile 🙂 . E’ vero che usando una regola per singolo progetto ci limitiamo e abbiamo il problema che se la dobbiamo applicare su più progetti = gestire più regole e modificare più regole. Concettualmente è sbagliato. Se il numero di regole è inferiore a 10, allora possiamo anche rischiare. Se superiamo questo limite, allora possiamo anche valutare il numero di esecuzioni e verificare se abbiamo la necessità di andare su profilo PREMIUM. Andare alla cieca equivale impegnare un budget in maniera errata. Vi lascio immaginare le conseguenze.

Come sempre dico: VALUTARE BENE e poi decidere, ma ancora meglio se abbiamo a disposizione tutte le informazioni. In caso contrario quello che potrebbe succedere è che decidiamo in maniera errata senza avere la soluzione che ci serve.

Conclusione

Invito a tutti i lettori ad una ovvietà: ragionate sempre con la vostra testa. Se vi dicono che le cose funzionano in un certo modo, FATE UN CONTROLLO, come sempre faccio io. Tutto quello che scrivo è frutto della mia esperienza e di conseguenza di quello che ho visto all’opera. Vi lascio con una fonte di ispirazione:

I questo post andremo ad esaminare e verificare il funzionamento di un nuovo addon dedicato alla integrazione tra i sistemi nell’ecosistem Atlassian. Parliamo di GetInt

Presentazioni

Sono sempre doverose e riguardano una soluzione che intendo portare avanti sempre e comunque per cercare di fornire al lettore tutte le informazioni di cui abbisogna. Quando voglio descrivere un addon, voglio assolutissimamente voglio, anche presentare gli autori dell’addon, non per chissà quale motivo, ma per far vedere che dietro a questi logo e software ci sono delle persone fantastiche e che si fanno in quattro per cercare di arrivare ad ottenere risultati spettacolari. Per questo motivo ci tengo a ringraziare Jacek Wizmur-Szymczak, che continuo a ringraziare per avermi mostrato questo splendido addon, quali meraviglie è possibile realizzare e farlo sopratutto in maniera semplice.

Di cosa si occupa?

L’addon permette tante possibilità, non ultima di mettere in comunicazione la nostra istanza Cloud con altri servizi cloud. Le possibilità che l’addon offre sono spettacolari ed in questo caso voglio descrivere un caso di uso che mi sono trovato ad affrontare nei mesi passati e che permette di poter fare tante belle cose.

In particolare l’addon permette di poter collegare Jira Cloud con diversi servizi Cloud e non solo. Se diamo una occhiata a questa imagine, possiamo avere una idea di che cosa è possibile fare con questi servizi 🙂

Queste integrazioni ci permettono in ventaglio di possibilità ed oggi ne voglio descrivere una in particolare: Voglio descrivere cosa ho realizzato per un mio lavoro. Ovviamente mi limito ad una descrizione della funzione senza raccontare altri dettagli, garantendo la privacy del mio cliente.

Caro Lettore, mettiti comodo e lasciati guidare in questo viaggio che ti propongo alla scoperta di un importante addon.

Cosa ho realizzato

In questo post voglio mostrare come sia possibile far dialogare Jira Cloud con Gitlab Cloud. Il nostro obiettivo è permettere una sincronizzazione tra le issue di Jira e le issue di Gitlab Cloud. Vogliamo mostrare che questa operazione è assolutamente possibile grazie all’addon di GetInt. Vediamo come.

La richiesta, in questo caso, era la seguente:

Vogliamo mantenere separati i gruppi di lavoro. Gli sviluppatori devono lavorare solo ed esclusivamente su GitLab Cloud mentre il management deve lavorare su Jira Cloud. L’obiettivo è che le issue di Jira siano riportate in Gitlab e viceversa. Mantenendo la sincronizzazione, possiamo garantire il lavoro di entrambi i gruppi: Management e Developers.

Richiesta ricevuta

Questo implica che sia eseguita una sincronizzazione tra i due sistemi in modo che tutte le variazioni impostate da una parte siano riportate dall’altra. Chiariamo quali operazioni devono essere garantite

• Creazione di una issue in un sistema deve scatenare la creazione nell’altro
• l’aggiornamento di una issue in un sistema deve scatenare la modfica nell’altro

La soluzione adottata

In questo caso, dopo lunga e ponderata analisi, abbiamo scelto di usare GetInt per impostare questa sincronizzazione. Abbiamo esaminato diverse soluzioni ma questa è risultata la più adatta in questa circostanza. Cerchiamo di dare delle indicazioni generali per aiutare a capire come è stata operata tale scelta

L’addon presenta una interfaccia semplice e diretta. Anche per coloro che non sono esperti sviluppatori, ma power user, possono usarlo facilmente. Questo permette di poter aprirsi ad una platea di utenti ben più ampia.

L’addon permette anche di controllare l’andamento della sincronizzazione e mette a disposizone una apposita Dashboard lato Jira per comprendere meglio quello che sta facendo.

La configurazione che ci permette questo addon, ci offre una buona scelta:

Andiamo adesso nel dettaglio della configurazione.

Colleghiamo GitLab Cloud a Jira.

La configurazione richiede che l’addon sia in grado di collegarsi con GitLab. Per fare questo occorre impostare una connessione. QUindi prima selezioniamo GitLab (il logo ci aiuta nella scelta)

Fatto ciò, andiamo a configurare la connessione e seguiamo la autocomposizione

Basta seguire tutti i passi, ottenendo senza alcuna difficoltà la connessione a GitLab. Passiamo a Jira (ovvero diciamo all’addon che la seconda connesione è Jira stesso).

A questo punto abbiamo anche qui una scelta da operare. Dobbiamo indicare che stiamo andando a connetterci con l’istanza locale (local)

Indicando Local, attiviamo le altre opzioni di configurazioni:

Possiamo scegliere il progetto di Jira che sarà oggetto della sincronizzazione, cui possiamo aggiungere anche un JQL per selezionare le issue da sincronizzare.

Una volta selezionato sorgente e destinazione, procediamo con la configurazione della operazioni di sincronizzazioni. In questo caso occorre stabilire che cosa sincronizzare nel dettaglio. Di seguito la sincronizzazione che abbiamo impostato ….

che prevede questo dettaglio …

Una volta terminata l’intera configurazione, siamo pronti alla nostra prima sincronizzazione

Test dell’addon

Partiamo dal creare una issue su Jira

e questo è quello che vediamo su Gitlab

Questa è la dashboard dell’addon

Ma non è finita. Possiamo avere a disposizione una ulteriore infromazione dalla Dashbord….. IL LOG….. Non abbiamo che una sola parola: SPETTACOLO

Le immagini precedenti ci forniscono un buon esempio di dashboard necessarie per poter avere sempre sotto controllo tutto. Ribadisco: SPETTACOLO

CONCLUSIONE

L’immagine che ho inserito in precedenza, esprime molto bene il mio giudizio. Questo addon è molto interessante e molto semplice da usare. ed conseguenza lo consiglio a tutti. Sono riuscito ad ottenere una buona integrazione tra i due prodotti seguendo i pochi e semplici passi che l’addon mette a disposizione e consentendo di poter gestire al meglio il passaggio delle informazioni. La presenza di Dashboard di controllo e di un LOG (Alleluja) ci aiuta nel controllare quello che succede e capire eventuali problematiche.

Reference

Maggiori informazioni sono reperibili dal Marketplace e dal sito ufficiale.