Da Hipchat & Stride … verso Slack

In questo post andremo a raccontare meglio questi fatti e di come ho eseguito la migrazionen verso Slack. Questo è sicuramente interessante per definire i prossimi passi per impostare una chat di connessione delle nostre istanze (cloud o server) Atlassian.

Storia

Partiamo dalla storia, ovvero dall’annuncio in cui Atlassian comunica che cosa è successo.

Il tutto è partito da questo annuncio, riportato nel blog di Atlassian, dove si annunciava la nuova partnership.

Di conseguenza, si segnalava che le installazioni in essere dovevano essere migrate mentre le nuove avrebbero dovuto essere eseguite sotto Slack.

Passiamo a Slack

In questo post andremo a mostrare come ho eseguito il passaggio da Hipchat Cloud a Slack. Posso solo dire che la guida che Atlassian mette a disposizione è completa e sufficiente e non c’è molto di più da fare :). Spero che questa mia descrizione sia utile per aiutare chi è meno pratico nell’eseguire queste operazioni.

Immagine correlata

Vediamo quindi i vari step.

1. Creare il backup da HipChat

Come prima cosa, eseguiamo la login al nostro sistema HipChat (nel nostro caso si tratta della versione Cloud).

Selezioniamo, nella sezione di amministrazione, Data Export  e ….

… eseguiamo il backup di tutte le nostre room e chat. Quindi eseguiamo il download di questo file. 

2. Creiamo il nostro Slack

Abbiamo già creato il nostro Workplace Slack selezionando un piano di nostro gradimento, per spiegare un altro argomento, Quindi procediamo ad eseguire il login

Posizioniamoci nella sezione di amministrazione di Slack (Selezioniamo in alto a sinistra, dove abbiamo il nome Artigianodelsoftware, dove abbiamo scelto di poter 

3. Restore del backup

Selezioniamo Import/Export Datas , il bottone in alto a destra mostrato nella figura successiva:

quindi selezioniamo la sorgente da dove importare i dati. Dalla seguente figura vediamo che abbiamo alcune scelte:

Scegliamo quindi HipChat …

seguiamo i vari passi. Abbiamo anche un richiamo alla documentazione ufficiale per eseguire la migrazione. Difficoltà abbastanza ridotta.

4. Risultati?

abbiamo caricato i dati su Slack e siamo pronti a lavorarci subito. In aggiunta…

…. lo abbiamo guà connesso alla nostra istanca di Jira Cloud, ma questo lo abbiamo vedremo in altro post. Possiamo subito iniziare a lavorarci.

Conclusioni

Lato mio la mia migrazione è stata abbastanza indolore. Da come ho visto organizzato il tutto, mi sembra abbastanza lineare, ma non escludo che altri gruppi di lavoro possano avere dei problemi. Cercherò, nei prossimi post, di dare un possibile elenco di anomalie e di soluzioni/workaround, in modo da poter mettere  a disposizione ulteriori indicazioni.

Likes(0)Dislikes(0)

Migrazione – Un argomento interessante

Migrazione

In questo post iniziamo ad affrontare un argomento molto tosto: La MIGRAZIONE :-P. Croce e delizia di ogni sistemista, per quanto difficile, una volta tenuto d’acconto di alcuni punti cardine, possiamo affrontarla senza alcun problema. Iniziamo questo piccolo viaggio 🙂

Una piccola premessa

Prima di entrare nel dettaglio, andiamo a fare alcune elucubrazioni preliminari.

La prima cosa da tenere sempre a mente è da dove partiamo e dove arriviamo. Cercate sempre di avere sempre la situazione sotto controllo.

Come parti fondamentali, consiglio di tenere sotto controllo:

  • Database utilizzato. Questo ci aiuta a capire se è compatibile con il nuovo sistema oppure no o se ci sono delle limitazioni di cui tenere conto.
  • Sistema installato sulla nostra rete o in hosting su di un sistema cloud. Questo ci dice come possiamo reperire le informazioni. Se stiamo utilizzano un sistema server nella nostra rete, siamo molto avvantaggiati. Se ci dobbiamo interfacciare su di un sistema cloud, possiamo avere delle limitazioni.
  • Usiamo un LDAP oppure no. Qui dobbiamo prestare attenzione: Se lo utilizziamo ci possono essere dei problemi a livello di licenza.
  • SSO (Single Sign-On) presente?
  • Mole di utenti, per capire se le nuove versioni hanno un aggravio di costo oppure no ed anche …. se abbiamo bisogno di fare pulizia. Per i prodotti Atlassian (e qui lo scrivo in maniera molto semplice) DOVETE FARE ATTENZIONE. Lo spiegherò meglio dopo, ma non possiamo cancellare a cuor leggero.

Per i prodotti Atlassian

I casi di migrazione che possiamo affrontare sono i seguenti:

  • Migrazione di versione  (Ad esempio: da JIRA 6 a JIRA 7)
  • Migrazione di versione e di installazione (Ad esempio: da JIRA 6 Server a JIRA 7 cloud)
  • Migrazione di installazione (Ad esempio: da JIRA Cloud a JIRA Server).

Per tutte le situazioni tenere sempre a mente i seguenti punti:

  • Utenti: Prestare attenzione massima. Non possiamo rimuovere un utente a cuor leggero, in quanto ogni singola operazione viene tracciata ed assegnata ad ogni utente, anche quelli non pi attivi. Quindi, quando viene fatta la migrazione, ce li ritroveremo nuovamente.
  • Addons: Ci possono essere problemi di compatibilità. Per le versioni successive potremmo non avere a disposizione alcuni addon, semplicemente perché il produttore …. non ha avuto il tempo di crearlo :-). Aggiungiamo che, un piccolo dettaglio che nella mia esperienza ho riscontrato, si presenta un problema contabile: Da una certa versione gli addon possono diventare a pagamento. Questo non ci aiuta di certo. :-O.
  • Cloud Vs Server: Se si passa da Server a Cloud, abbiamo un altro piccolo problema: Non tutti gli addon sono disponibili per cloud. Anche qui occorre prestare molta attenzione. Se si passa alla versione cloud, occorre essere ben coscienti che non si possono trovare tutto ciò che ci serve, ma non disperate: Il numero di addon per la versione Cloud è in aumento :-).
  • JIRA 7: Dato che nella ultima pacchettizzazione abbiamo delle piccole differenze, occorre tenere presente questo fatto e capire quale è la nuova versione da installare.

Conclusioni

Concludiamo questo post con le considerazioni fornite. Nei prossimi post andremo ad esaminare un semplice esempio di migrazione.

Likes(0)Dislikes(0)

Exporter issue per JIRA CLOUD

Exporter issue per JIRA CLOUD

In questo post andremo ad esaminare un addon molto imortante per JIRA. Si tratta di Exporter issue per JIRA CLOUD.

Di cosa si occupa?

Fondamentalmente si occupa di esportare/importare le Issue dei nostri progetti presenti sulle istanze di JIRA CLOUD. In questo modo abbiamo un ulteriore strumento che aiuta nella nostra gestione es amministrazione dei nostri progetti.

Consente di eseguire delle esportazioni su formato CVS e permette di poter successivamente reimportare il tutto sia sulle nostre istanze Cloud, che nelle nostre istanze Server. Questo diventa quindi un valido strumento per le migrazioni 🙂

Il formato con cui viene eseguita l’esportazione è simile a quello che la stessa Atlassian mette a disposizione di JIRA. Quindi non abbiamo stravolgimenti che ci fanno ammattire, ma uno strumento che ci aiuta e ci mette a disposizione le informazioni esattamente come ci aspettiamo.

Possiamo anche vedere il transaction log, come mostrato in figura. L’esportazione risulta decisamente completa.

Considerazioni

Faccio alcune considerazioni sull’addon. Si tratta di un addon che colpisce nel punto giusto: le migrazioni e le esportazioni dati da e per i prodotti della Atlassian sono sempre stati una croce ed una delizia di ogni amministratore dei prodotti della Atlassian.

Avere a disposizione uno strumento completo che permette di poter, aggiungo io Finalmente, trattare l’argomento in maniera semplice e senza dover ammattire, è un vantaggio enorme.

Conclusioni

Abbiamo visionato un addon che ci aiuta nel nostro lavoro. Nei prossimi post andremo a fare le prove su campo di questo addon. Tenteremo di migrare un JIRA e ne valuteremo le potenzialità, limiti e prestazioni.

Reference

Likes(0)Dislikes(0)