Creiamo un link ad una pagina di Confluence su Jira

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.

Come moderni Bandeirantes, andiamo in esplorazione

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??

Stiamo calmi

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:

Send Web Request è quello che ci serve

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:

Un esempio che ho impostato su di un mio ambiente di prova

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.




Sulla necessità di modificare massivamente i dati di un campo Jira Cloud

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.

Set explore mode = ON

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.

Questa immagine descrive la mia situazione. Nottate ad elucubrare per un risultato

…. 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.

La pagine dell’addon su Marketplace.

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

Fonte Marketplace Atlassian

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

Iniziamo a rilassarci e a pensare quante possibili applicazioni possiamo farne

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

Calma, non disperiamo. Abbiamo una piacevole novità

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.

Tratto da una operazione di Bulk Edit che hi eseguito.

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.




Primi test su Atlassian Intelligence

In questo post provo a riassumere i primissimi test che ho operato su Atlassian Intelligence. Si tratta delle primissime funzioni che sono state introdotte e, faccio ancora presente che si tratta di funzionalità che sono ancora in BETA.

Set explore mode = ON

Quali funzioni sono state rilasciate?

Al momento tutte le funzionalità rilasciate sono presenti solo su Jira (principalmente su Jira Software e su Jira Service Management). Siamo in trepida attesa di poterle testare anche su Confluence, dove sicuramente saranno un validissimo aiuto nella redazione dei documenti. Per il momento ci acconenteremo di eseguire un valido test anche su Jira.

Su Jira Software ….

…. abbiamo a disposizione una funzione molto interessante, La possiamo vedere subito nella nuova maschera di ricerca:

Il primo impatto

Abbiamo a disposizione nella Nuova maschera di ricerca delle issue (in questo caso abbiamo la necessità di fare una piccola digressione: con la nuova maschera di ricerca intendo la maschera che presenta delle caratteristiche grafiche carine ed interessanti, ma che ci propone anche delle limitazioni non indifferenti, che saranno affrontate in un apposito articolo) e che presenta un apposito tasto che ci permette di poter attivare le nuove funzioni ai Atlassian Intelligence.

Una volta che selezioniamo tale tasto, questo è il primo risultato

Nella nuova text box possiamo richiedere, in linguaggio naturale, le richieste che vogliamo. Queste saranno tradotte in JQL, come mostrato nelle seguenti figure

Un primo esempio di conversione eseguito da Atlassian Intelligence
Un secondo esempio di conversione eseguito da Atlassian Intelligence

L’esempio che vediamo è molto interessante. Anche se amante del JQL, sono affascinato dal fatto che abbiamo a disposizione una funzione che da linguaggio naturale ci conferte la richiesta in JQL e ci permette di poter generare i nostri filtri in maniera semplice. Mi sembra un buon inizio.

Su Jira Service Management ….

…. abbiamo a disposizione altre funzioni interessanti, quali ad esempio:

Riassunto di tutti i commenti di una issue

Abbiamo a disposizione una funzione che ci permette di poter eseguire il rassunti di tutti i commenti di una issue, permettendoci di risalite in pochissimo tempo ai fatti salienti ed essere allineati subito.

Un esempio di applicazioen ad un caso reale

In questo caso ho provato un esempio su di una mia segnalazione interna, dove (ahime ancora in Inglese) riassume la sitiazione, ma non disperiamo: presto sarà disponibile in lingua. Abbiamo infatti visto che l’interprete che converte in JQL legge perfettamente l’Italiano

I commenti possono essere implementati anche con l’aiuto di Atlassian Intelligence

Abbiamo la possibilità di poter scrivere i commenti sfruttando le potenzialità di Atlassian Intelligence

Ecco un esempio

La precedente immagine ci mostra un possibile esempio. Il risultato è interessante, ma come sempre pongo sempre l’attenzione sul fatto che si tratta di una applicazione (per quanto sofisticata ed attentamente sviluppata) e quindi tutti i risultati devono essere sempre valutati e confermati prima di essere inviati.

Non solo commenti, ma anche un aiuto nello scrivere la descrizione del task

Atlassian Intelligence ci fornisce un aiuto anche nello scrivere la descrizione della nostra issue. Anche in questo caso possiamo sfruttare le sue potenzialità per meglio esprimere quello che necessitiamo, ma come sempre e costantemente ribadisco, l’ultima parola è e rimane la nostra.

Interessante, ma quali funzioni su Confluence?

UDITE UDITE

Fino a qualche settimana fa non era possibile includere Confluence. Mentre stavo eseguendo la revisione del post mi hanno fatto notare che le funzionalità sono adesso disponibili per Confluence. Cosa facciamo? Ma andiamo ad analizzare immediatamente quello che è possibile fare con Confluence, ma lo riporteremo nella prossima puntata.

Corriamo immediatamente a fare un test

Conclusione

Abbiamo un primo risultato che è molto incoraggiante e sopratutto ci mostra come questo strumento è e rimane sempre a nostra disposizione per migliorarci, supportarci e permetterci di fare meglio il nostro lavoro. Rimaniamo in attesa della funzionalità applicata a Confluence.

Aggiungo un video molro interessante, dove troverete altre informazioni e indicazioni sulle funzionalità aggiunte

Poi porto carico (Cit. Il Commissario Montalbano). Ho avuto il piacere di assistere all’ACE di Boston di recente e li ho avuto modo di poter vedere i risultati di Atlassian Intelligence e quali meraviglie ci presenterà. Per questo motivo mi permetto di condividere il video (in Inglese) dell’evento. L’ultimo intervento è proprio relativo alla parte di Atlassian Intelligence. Buona visione.

Il video dell’ACE di Boston



Team managed Vs Company Managed

Sono sempre stato leggerissimamente scettico dei progetti Team Managed. In questo articolo provo a spiegare come mai lo sono e perché, sempre secondo la mia modestissima personale opinione, è sempre preferibile creare dei progetti Company Managed. In qualsiasi caso

Esplorazione alchemica in corso

Le ragioni che porto sempre con me

La prima cosa che indico come difetto di tali progetti è il fatto di avere una configurazione molto molto (in alcuni casi uso anche il termine TERRIBILMENTE) limitata. Questo fa si che sia molto semplice configurare un progetto siffatto. Tuttavia non sempre questo può risultare una arma vincente. Infatti se mettimao a confronto le due possibili configurazioni che abbiamo

Il confronto che troviamo quando generiamo nuovi progetti

Team Managed configuration

Company Managed configuration

La prima cosa che notiamo è che le opzioni sono limitate per i Team Managed. I Company managed, per quanto più complicati, sono sempre più completi nella configurazione e nella gestione. Questo sicuramente ci aiuta (per citare un vecchio adagio che ho imparato nella meravigliosa città di Lucca: Nel più c’è il meno).

In aggiunta, nei Team managed ho notato una cosa molto grave (secondo sempre il mio modesto parere): Non possiamo usare le risorse condivise. In alcuni casi mi sono trovato costretto ad una trasformazione di un progetto da TEAM a COMPANY perché non c’era alcuna possibilità di poter espandere tali progetti e sopratutto gli utenti erano stati costretti a replicare all’infinito (copiando manualmente e non assegnando una configurazione preesistente).

In aggiunta, non sempre gli addon sono usabili anche su tali progetti. Ho rilevato che alcuni di essi non rispondono correttamente quando si prova ad applicarli.

Il mio dubbio è che questa tipologia di progetti, per quanto comodi, semplici e rapidi, non presentino delle strutture condivise e standard. Di conseguenza, occorre un qualcosa ad hoc per poter loro agganciare delle funzionalità standard.

Un progetto Company Managed, per quanto sia complicato, hai comunque il controllo completo della configurazione e riesci sempre a cadere in piedi. Mi permetto di condividere un meme che ho visto qualche tempo fà ed esprime esattamente dei concetti molto importanti:

Direi che l’immagine si commenta da sola

In questo caso è come disporre di un Linux e della sua splendida POTENZA.

Conclusioni

Quello che continuerò a suggerire, consigliare, fare presente e ribadire sotto tutti i punti di vista è che un progetto Team Managed va bene per fare cose molto semplici. Se si prevede nel futuro di fare qualcosa di più, partite subito con un progetto Company Managed.

A tale proposito, vi chiedo di visionare questo video di Monika Rani, che spiega in maniera molto chiara e semplice la differenza tra i due tipi di progetti:

e questo ottimo articolo, sempre scritto da Monika Rani, che spiega come migrare da Team a Company




Database exporter – Come ti estraggo i dati dal Cloud

In questo post andremo ad esaminare un addon che ci permette di poter estrarre i dati dal Cloud in modo da permetterci di poter eseguire delle interrogazioni mirate.

Esplorazione alchemica in corso

Una premessa importante

Chi lavora con il Cloud sa perfettamente che quando vogliamo eseguire delle interrogazioni sui dati, la risposta è sempre una. Il seguente memo ce lo spiega

Vediamo di chiarire il punto

Sul Cloud non abbiamo alcuna possibilità: Ci è precluso l’accesso al database interno. Di conseguenza non possiamo fare nulla per lanciare query… almeno fino ad ora.

Abbiamo una soluzione

Inventato da Bob Swift ma adesso sotto il controllo della Appfire, abbiamo un addon che ci aiuta in tal senso, fornendoci la possibilità di costruire un simil-database su cui poter eseguire le nostre interrogazioni.

L’addon di cui parleremo oggi.

Questo addon è nato con l’obiettivo di ricostruire un database simile, rispetto a quello che avevamo a disposizione con la versione onPremise, e permettere agli utenti cloud di riuscire a ricostruire delle query ed interrogazioni.

Fonte Marketplace

Come possiamo vedere dalla precedente immagine, riusciamo a ricostruire sia i dati della parte standard, compresi i campi custom. Dalla documentazione dell’addon abbiamo a disposizione anche uno schema dati che ci spiega come ricostruire le relazioni tra le varie tabelle:

Fonte: Documentazione dell’addon

Possiamo, attraverso questo addon, ricostruire un simil-database (non è proprio il database effettivo: Teniamolo sempre a mente).

L’addon al momento permette di poter estrarre i dati direttamente su di un database Postgresql. Questo ci limita un pò i movimenti, ma non più di tanto. Se in azienda abbiamo uno standard che ci impone l’utilizzo di altre tipologie di Database (ad esempio: In azienda si usano database MS SQL Server). Tuttavia, usando dei server Linux, il problema viene risolto.

Punti di attenzione

Dobbiamo però tenere sempre a mente alcuni punti di attenzione. Ricordiamoci sempre che il nostro Cloud Atlassian è prevalentemente una macchina virtuale localizzata su Internet e di conseguenza abbiamo:

  • Il nostro cloud deve poter accedere al database e di conseguenza questo deve essere raggiungibile da internet
  • Essendo raggiungibile da internet, occorre che questo database sia gestito in maniera opportuna.
  • Non possiamo esporre direttamente i nostri database verso internet
  • Il database da usare deve essere un database che viene immediatamente blindato o svuotato non appena viene compilato

Come si può vedere non si tratta di semplici raccomandazioni, ma di punti di attenzione molto importanti. Se non li rispettiamo abbiamo dei problemi abbastanza seri.

Se perdiamo i dati questa sarà la nostra espressione.

Di conseguenza abbiamo molto da considerare.

La mia esperienza

Ho avuto modo di collaudare questo addon direttamente presso un mio cliente e posso dire che l’addon lavora in maniera egregia. Nel senso che i dati estratti sono effettivamente il clone dei dati. Ma vorrei fare alcune ulteriori considerazioni.

Abbiamo principalmente i dati dello standard

Non ci facciamo illusioni. Non riusciamo a disporre di tutti i dati come nel caso delle nostre installazioni onPremise. Infatti quando possibile, si accedeva anche ai dati degli addon semplicemente andando a leggere le tabelle con prefisso AO%, come riportato in questa documentazione ufficiale Atlassian.

In questo caso l’addon ricostruisce, con buona approssimazione, le informazioni standard e attraverso opportune query, riusciamo a leggere le informazioni che ci servono.

Solo alcuni addon sono disponibili

L’addon riesce a leggere i dati di alcuni addon, come TEMPO TIMESHEET, ma una cosa che ho notato è che le informazioni che sono scaricate sono sotto forma di un JSON che deve essere ‘lavorate’ per poter estrarre i dati che servono.

Possibile eseguire backup totali ed incrementali

E’ possibile eseguire entrambe le modalità. Nel mio caso, potrebbe essere utile eseguire un primo backup generale e poi tutti i backup incrementali. Questo aiuterebbe notevolmente

Conclusioni

Abbiamo un addon interessante ma che deve essere usato con tutti i crismi del caso. Possiamo estrarre i dati che ci interessano e fare le statistiche personalizzate del caso, anche se in ultima istanza suggerisco di appoggiarsi ad appositi tools che permettono di poter portare le informazioni di Jira su PowerBI o QLIK e consentono di gestire le statistiche molto meglio che con un semplice database da rimettere in piedi.

Come sempre riporto le mie indicazioni perché, questo sicuramente lo avrete compreso leggendo i miei post, che è sempre meglio avere più possibilità che solo una possibilità. La libertà di scelta è una arma molto potente che intendo sempre sfruttare e mettere a disposizione, anche quando eseguo le mie consulenze.

Reference

Maggiori informazioni sono reperibili alla pagina del Marketplace.




Cambiano le Automation Rules su Cloud, ma come?

In questo post andremo ad esaminare alcuni aspetti delle Automation Rules. Dal 1 di Novembre 2023 cambiano e vengono aggiornate in un modo partioclare, In questo post andremo ad esaminare come cambiano e che novità ci sono, come saranno strutturate e che cosa porteranno.

La situazione attuale

Partiamo dalla situazione attualmente in essere delle automation. Quello che abbiamo a disposizione è un sistema che:

  • Se usiamo delle regole monodedicate ad un singolo progetto, allora possono essere eseguite senza alcun limite
  • Se usiamo delle regole multiprogetto o Globali, allora siamo soggetti ad una serie di limitazioni

In questo ultimo caso abbiamo, nel caso del profilo Standard, fino a 500 esecuzioni per prodotto (ovvero 500 per Jira Software, 500 per Jira Service Management, etc).

Il seguente prospetto spiega la situazione precedente, comparata con la situazione attuale.

Fonte Atlassian Community

Un mio commento personale

Dallo schema che ho pubblicato ci sono dei punti che non mi quadrano. Ad esempio: I profili PREMIUM mi risulta che hanno un numero di esecuzioni illimitato, mentre nello schema non sembra. Sembra che l’unico profilo che permetta un utilizzo illimitato delle esecuzioni sia solo l’ENTERPRISE. Probabilmente mi sbaglio, ma ho qualche dubbio e ci terrei a sottolinearlo.

Come cambiano le cose

Dal primo di Novembre, le regole cambieranno come segue. Non abbiamo più la possibilità di sfruttare l’esecuzioni infinite delle regole mono-progetto, dato che adesso le regole saranno conteggiate per singolo prodotto, ovvero:

  • Jira Work Management
  • Jira Software
  • Jira Service Management
  • etc.

Chi dispone di un profilo Standard vede aumentare i limiti da 500 al mese a 1700 (per Jira Software) e 5000 (per Jira Service Management). In ogni caso, venendo meno l’esecuzione sul singolo progetto, anche ipotizzando un uso sapiente delle regole, quello che otteniamo è che abbiamo una media di 56 esecuzioni al giorno massimo per Jira Software e di 166 esecuzioni massimo per Jira Service Management. Questo ci deve fare riflettere che le regole devono essere a questo punto dimensionate per le reali esigenze.

Il rischio che si corre è che non appena si supera il limite delle esecuzioni fissato, fino al reset dei limiti (ovvero al mese successivo) non ci saranno altre esecuzioni: Le regole risulteranno bloccate.

SI. Questa è la nostra espressione non appena esaurito il limite di esecuzioni mensile

Ovviamente il conteggio delle esecuzioni viene incluso solo ed esclusivamente quando abbiamo una regola che esegue qualcosa. Se la regola viene attivata ma sul log abbiamo questa situazione:

Un esempio di Activity Log di una regola, tratta da un mio ambiente di test

In questo caso questa esecuzione non viene conteggiata e non abbiamo problemi. In aggiunta, come aiuto per valutare la numerosità e se occorre intervenire, Atlassian dal primo di Ottobre (ovvero un mese prima della entrata in vigore delle nuove regole) ha attivato un pannello riassuntivo che ci permette di poter capire le esecuzioni che ci sono state nel mese di Settembre 2023, fornendoci un primo aiuto, come mostrato in figura:

Il nuovo TAB presente nella sezione Globale delle regole
Una prima vista di insieme
Il grafico con l’andamento delle esecuzioni.

Da queste informazioni abbiamo una misura per decidere come intervenire.

Come possiamo ovviare e contenere le esecuzioni?

Una prima soluzione consisterebbe nell’usare delle altre soluzioni, quali usare delle Postfunction dei WF per far si che il limite si esaurisca molto più tardi possibile. In aggiunta, l’esecuzione delle regole deve essere limitato alle situazioni effettivamente reali e possibilmente che includano il maggior numero di issue possibile.

Se ad esempio abbiamo la necessità di completare dei dati, se riusciamo applichiamo delle Postfunction. In alternativa, sempre intervenendo sui WF, forziamo gli utenti a complemare i vari dati in modo da non. necessitare della esecuzione di regole per completare gli stessi.

Mettiamoci del nostro per limitare il numero delle esecuzioni

Conclusioni

Personalmente non mi sento di chiedere alle aziende di passare ai profili superiori: In diversi casi non ha letteralmente alcun senso. Se per ovviare a questi limiti si deve spendere il 2.3 in più, sinceramente verrei meno al mio ruolo di consulente. Le aziende si affidano a me per avere delle soluzioni e non un conto maggiorato da pagare.

Sarà mia cura contattare i miei clienti per analizzare con loro la situazione e verificare come ridurre l’utilizzo delle automation rules a dove serve.

Reference

Maggiori informazioni sono presenti nell’articolo di Atlassian Community e nella pagina della documentazione, dove trovate indicazioni anche per le Automation per Confluence.




Un addon interessante per il Cloud

La gestione degli utenti è molto importante per i Site Administrator dei prodotti Atlassian. Lo sappiamo bene noi che ci lavoriamo tutti i giorni e che ci scontriamo con le varie problematiche.

Tuttavia i produttori di Addon ci aiutano in questo arduo compito. Grazie a loro riusciamo a risolvere al meglio tutte le nostre problematiche, arrivando ad avere

Altra esplorazione alchemica

Cosa ci permette di fare?

Questo addon ci aiuta nella gestione utenti semplificata, permettendo anche di poter gestire alcune funzioni interessanti. Andiamo subito a curiosare sulle possibilità offerte.

Fonte Marketplace

Possiamo avere una gestione semplificata degli utenti attraverso una funzione di importazione degli stessi e permetterci di semplificarci la vita. Infatti, non tutte le organizzazioni si possono permettere di acquistare Access e l’utilizzo di Addon che dispongono di questa funzione, ci permette di poter avere delle funzioni non indifferenti

IN aggiunta abbiamo la possibilità di poter inserire, sempre in maniera semplice, i nostri customer interni in maniera semplice e veloce, sfruttando le funzionalità che sono presenti a sistema.

Fonte Marketplace

La mia esperienza lavorativa

Posso dire che questo addon, in un particolare caso, ci ha permesso di poter gestire al meglio i customer interni di una azienda, permettendoci di poterli creare e configurare in pochissimo tempo (neanche 1 ora).

Abbiamo usato con successo la funzione che ci permette di poter attivare tali customer velocemente ed il cliente è rimasto piacevolmente soddisfatto del risultato. Lui stesso lo utilizza per poter attivare i nuovi customer.

L’immagine serve per descrivere la soddisfazione del cliente

Questa immagine non può che esprimere al meglio quanto penso dell’addon

Il mio giudizio: POSITIVO

Reference

Maggiori informazioni sono reperibili alla pagina del Marketplace.




Manteniamo sincronizzati i nostri Space di Confluence

In questo post andremo ad esaminare come possiamo gestire una sincronizzazione di Space, sia nella stessa istanza, che su istanze differenti. Andiamo in modalità esplorativa

Vestiamo i panni del moderno alchimista

Introduzione dello scenario

Lo scenario che mi piacerebbe implementare serve nel caso di problemi che si possono presentare nella istanza di produzione. Se abbiamo a disposizione una istanza, minore con un numero inferiore di utenti, possiamo avere un backup sempre pronto all’uso che ci permette di poter ripristinare in tempi brevi l’operatività, permettendoci poi di ripristinare tutti gli aggiornamenti nel caso di riattivazione dell’ambiente di produzione.

Questo articolo rientra in un insieme di studi che sono nati dopo che ho pubblicato questo articolo, visto che sono stato uno dei fortunati a ricevere questa situazione. Per questo motivo voglio avere delle alternative da poter ottenere un esempio di Disaster Recovery anche per le nostre istanze Atlassian Cloud.

Vediamo in questo articolo come riuscire a creare un ambiente di Disaster Recovery

Come possiamo eseguire questa operazione?

Analizzando il Marketplace, operazione che eseguiamo quotidianamente, identifichiamo il seguente addon che ci permette di eseguire la sincronizzazione di due space relativi a due istanze Cloud differenti.

In questo caso abbiamo un addon che ci può aiutare.

Andiamo ad esaminarlo.

Che cosa offre l’addon

L’addon permette di eseguire una sincronizzazione da uno Space all’altro, nell’ambito di una stessa istanza, ma anche su istanze differenti. Questa funzionalità ci permette di poter creare degli scenari non indifferenti, permettendo di creare degli ambienti di Disaster Recovery, ma non solo. possiamo anche sfruttare questa funzionalità anche in scenari in cui dobbiamo gestire l’approvazione dei contenuti. Le idee scorrono potenti 🙂

Questa volta ci vuole 😛

Il seguente schema riassume il funzionamento e ci permette di capire come ragiona l’addon

Fonte: Marketplace Atlassian

Osserviamo che la sincronizzazione, una volta impostata, è bidirezionale, di conseguenza qualsiasi operazione eseguita in uno degli Space viene immediatamente riverberata sugli altri. Non solo. Oltre alla sincronizzazione completa dello Space, abbiamo anche la sincronizzazione della singola pagina, come vediamo dalla seguente figura:

Fonte: Marketplace Atlassian

dove vediamo tutti i collegamenti impostati e abbiamo la possibilità di poter sincronizzare anche le singole pagine. La stessa interfaccia ci permette di capire se abbiamo eseguito l’aggiornamento della pagina o meno.

Fonte: Marketplace Atlassian

La configurazione non risulta impossibile, sempre guardando le schermate che sono presenti sul Marketplace. Viene fatto uso di Token per rendere sicura la sincronizzazione.

Convinto subito: Lo provo.

Iniziamo quindi a Installare l’addon. Come sempre ci serviamo di una GIF animata per vedere come eseguire l’installazione dell’addon.

Nota Bene – Lo installo ovviamente su due istanze per poi anche provare la sincronizzazione tra due istanze cloud differenti.

Andiamo ad analizzare subito la configurazione generale, cui accediamo dal menù Apps

Che ci mostra l’elenco degli space disponibili e ci fornisce il link diretto alla configurazione, che ci permette di poter accedere alla configurazione diretta dell’addon che è presente nelle configurazioni dei singoli Space

Se selezioniamo Edit sync settings veniamo reindirizzati alla pagina di configurazione vera e propria.

La configurazione di una sincronizzazione non richiede tantissimo. Semplicemente definiamo una sincronizzazione in quello che è lo Space sorgente. Da questo andiamo a scaricare il Token (è un file JMT), che andremo a caricare nella configurazione dello Space Destinazione.

A questo punto ho creato prima una sincronizzazione tra due Space di una stessa istanza e successivamente una sincronizzazione tra due istanze. A tale scopo ho due istanze Cloud dedicate allo scopo che ho preparato per un test che è diventato questo Case Study. Mi sono quindi limitato a configurare e a verificare

Ho scelto questi Space perché presentavano delle informazioni differenti ed ho verificato come si comportavano.

Un esempio di esecuzione negli ambienti di test Cloud

Come possiamo vedere dalla GIF animata, l’esecuzione è molto semplice e non abbiamo molti output. Lo stesso LOG non ha dato alcun risultato e non abbiamo nulla da vedere dopo. Questo è un punto importante.

Anche l’esecuzione della parte multiistanza non presenta molti problemi:

Esecuzione sincronizzazione della multiistanza

Vediamo che il risultato mostrato è il medesimo.

Andando ad analizzare il tutto, vediamo che le operazioni hanno sincronizzato le pagine, ma ho notato una cosa: La Homepage degli Space non viene sincronizzata.

Infatti Il mio space ‘sorgente’ ha questa homepage

Lo Space ‘Commerciale’
Lo space privato del mio utente, usato come Space destinazione

Osserviamo che per la Homepage non abbiamo a disposizione alcun menù che ci mostra lo stato della sincronizzazione. Mentre per le altre pagine abbiamo tale funzione disponibile.

La pagina con la dialog box indicante lo stato della sincronizzazione

La pagina con la Dialog box indicante lo stato della sincronizzazione

Vediamo la stessa pagina con la Dialog box sui due spazi distinti. Lo stesso risultato lo abbiamo anche quando usiamo la sincronizzazione su multistanza.

Risultato del test

Il risultato è sicuramente positivo ma ho notato alcune cose. Sono abbastanza sicuro del perché ci sia il comportamento che ho notato, ma voglio esserne sicuro e quindi lo evidenzio qui. Sono sicuro che gli autori dell’addon mi confermeranno le ipotesi.

  1. La Home page dello Space non risulta inclusa nella sincronizzazione.
  2. La sincronizzazione avviene copiando dallo Space origine verso lo Space destinazione
  3. Non vedo i log delle operazioni, sia quando sono in esecuzione sia quando sono concluse le operazioni di sincronizzazione

La Homepage non viene sincronizzata ma ho il dubbio che, per come è organizzato Confluence, l’addon non riesca ancora ad eseguire questa operazione.

Eseguire la sincronizzazione in una direzione piuttosto che in entrambe le direzioni non lo vedo come un problema. Nello scenario che ci siamo posti come obiettivo, non è affatto un problema in quanto prima di usa una delle due istanze come Disaster Recovery e di conseguenza la sincronizzazione è in una direzione. Solo dopo può essere necessario sincronizzare nella direzione inversa in quanto, nel caso in cui la produzione non risponde, allora serve la sincronizzazione per ripristinare la produzione.

Cosa più importante sono i LOG. Il fatto che non riesca a vederli durante l’esecuzione e poi a sincronizzazione eseguita, lo vedo come un problema. Nel caso di malfunzionamento, occorre sempre capire la causa e i LOG sono fondamentali. Di conseguenza questo punto deve essere visto dai produttori dell’addon in modo da renderlo disponibile sempre e anche facilmente consultabile.

Conclusione

Il mio giudizio è sempre positivo: abbiamo un addon molto interessante, anche se non riusciamo in pieno ad implementare la soluzione del Disaster recovery. Il fatto di non riuscire a copiare per intero la pagina iniziale dello Space, non è proprio il massimo, ma non ci scoraggiamo. Abbiamo uno strumento in più da poter usare per i nostri obiettivi. Non abbiamo uno strumento che esegue perfettamente la sincronizzazione come ci aspettiamo, ma riusciamo comunque ad avere un risultato che ci si avvicina. In aggiunta ci vedo un altro possibile utilizzo: quando gestiamo una documentazione e abbiamo un processo abbastanza complesso di approvazione delle modifiche, quello che possiamo fare è usare 2 space: uno per la documentazione ufficiale e uno per redigere le modifiche. Quando la modifica viene approvata, questa viene sincronizzata con lo Space ufficiale. Quindi, questo ci deve insegnare a non abbandonare un addon se non esegue proprio quello che ci interessa, ma semplicemente lo andiamo ad applicare ad altre situazioni

Reference

Maggiori informazioni sono disponibili alla pagina del Marketplace




De Automation Rules Eloquentia

Scrivo questo articolo quasi di getto e per rispondere alle ultime novità sul mondo delle Automazioni. Principalmente sulla parte Cloud di Jira. L’obiettivo è di fornire un quadro situazione per mostrare il funzionamento delle ultime novità e per indicare anche come poterle gestire correttamente. A tale proposito ho predisposto una regola di tipo didattico per descrivere meglio il funzionamento, ma andiamo con ordine.

Marzo 2023

Verso la fine del mese di marzo 2023 succedeva una cosa leggermente strana. Mi segnalavano che nelle istanze Cloud l’addon delle Automation risultava in TRIAL e sopratutto era ben staccato. Di conseguenza molti miei clienti si sono preoccupati (ma non solo loro).

Da un rapido controllo era emerso che Atlassian stava semplicemente integrando l’addon trasformandolo da addon esterno a addon di Sistema.

Infatti se andate a controllare, oggi lo troviamo come addon di sistema.

Quello che viene mostrato dalla sezione degli Addons-Apps

Fino a questo non ci sarebbe molto altro da dire… tuttavia abbiamo anche delle altre sorprese. L’integrazione si è portata dietro anche delle novità. Vediamole nel dettaglio:

Automation manuali

Una delle novità riguarda l’introduzione delle Automation manuali, ovvero richiamabili su richiesta dall’utente

Nuova funzionalità… ma…. 😮

Notiamo tuttavia una cosa molto molto … preoccupante. La combo che permette di richiamare questa nuova funzione è vicinissima alla combo del passaggio di stato. Molti mi hanno fatto notare (e sono perfettamente d’accordo) che la probabilità di selezionare la combo sbagliata è altissima. Devo riconoscere che la Atlassian ha introdotto una funzione importante, ma tempo che nella foga del momento non abbia ben calcolato dove inserire tale funzione, scegliendo una posizione infelice. Il mio suggerimento è di trattarla come le funzioni degli addon. Esiste la sezione dedicata alle Automation. Credo che sia meglio inserirla li

Notiamo che il messaggio ci da la ferale notizia

Non sono d’accordo con il messaggio. A mio giudizio questa sezione è quella ideale per gestire tale funzionalità.

Che altro?

Ci sono anche delle altre novità. Abbiamo a disposizione, sempre lato Automazioni, delle nuove funzionalità interne che ci permettono di poter gestire meglio delle …….. TABELLE DI LOOKUP

INTERESSANTE

Vedo che ho catturato la vostra attenzione. Andiamo subito al sodo. Se infatti ricerchiamo tra le possibili azioni, abbiamo la possibilità di poter creare questa tabella:

Siamo ancora alle prime armi, ma possiamo subito vedere che il potenziale ci sta tutto. Anche se limitato a 20 entry massimo, possiamo impostare una serie di corrispondenze che possiamo sfruttare a nostro vantaggio.

Per richiamare le corrispondenze abbiamo a disposizione un semplice metodo. Infatti questa tabella si definisce come uno Smart Value. Basta semplicemente usare:

{{Esempio.get(issue.summary)}}

per richiamare la corrispondenza. In questo esempio abbiamo la possibilità di poter sfruttare anche degli altri Smart Value. Cosa molto importante.

Finalmente non avremo dei cicli IF THEN ELSE infinitiiiiiiii

Risultato, Conclusioni?

Semplice: Abbiamo la possibilità di poter gestire queste regole in maniera molto più semplice, ci liberiamo dalla schiavitù di blocchi IF-THEN-ELSE potenzialmente infiniti e abbastanza difficili da gestire. Ci permette di dare un ordine non indifferente e, come vediamo, anche di gestire al meglio queste situazioni. Ripeto. Siamo alle prime armi. Le novità non sono sempre cattive, ma hanno sempre del potenziale. Dobbiamo sempre vedere il potenziale, senza mai perdere di vista i punti di attenzione.




Jira Cloud e i database – Una ipotesi di lavoro interessante

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.

Modalità sperimentatore Alchimista in azione

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

La scena è presa dal celebre film THE MASK, ma descrive bene come ci riduciamo

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.

Ok. Adesso vediamo quali precauzioni possiamo prendere

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.

Come dice la stessa immagine, e allora?

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:

Scheda su Marketplace Atlassia dell’addon

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

La configurazione che l’addon mette a disposizione quando si collega a Jira Cloud Stesso.

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

Un esempio di progetto a mo di Database

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.