Migració Jira de Server a Cloud

El problema del client

En el cas de Planeta s'havien de tenir en compte diversos factors:

• End of Life del Producte. Atlassian, al Febrer del 2024 deixarà de proporcionar suport a Jira Server.
• Excés de configuracions a mida i en conseqüència administració cada vegada més complexa.
• Tendència a la pèrdua de coneixement funcional a causa de la complexitat de la solució.
• Possible afectació a altres àrees en implementar noves funcionalitats. Probabilitat d ' issues en augment i en conseqüència una difícil gestió del canvi. 
• Intenció de reducció de costos:
  • En llicències: Tant d' usuaris com de manteniment d' instància i plugins. 
  • En infraestructura: Manteniment (IaaS)

Els objectius del client

El Departament d' IT de Planeta, plantejava diversos objectius:

• Canviar a una configuració diferent per tenir la capacitat d' escalar a diversos projectes resolutors des del mateix Portal Client.
• Tots els tiquets s'havien de migrar per poder mantenir un històric, estiguessin oberts o tancats.
• Implementar una CMDB per mantenir una gestió centralitzada de tots els canvis relacionats amb els seus serveis i aplicacions. Integrant-lo en els tiquets i els seus processos per a un major control i seguiment.
• Per agilitzar el treball dels agents de primer nivell als portals Service Management, es requeria també de l'automatització de tasques i notificacions sobre tots els tiquets enllaçats.

Repte principal a resoldre

Per entendre el repte principal, es partia d'una configuració basada en la replicació d'accions entre projectes tipus Service Management i Software. El canvi al nou model suposava transformar tot el flux de treball definit en els projectes, reestructurar el sistema de permisos i els grups d'usuaris involucrats.

Així doncs, no només s'havien de migrar més de 140000 tiquets, sinó que també s'havien de transformar al nou sistema Cloud aquells que estaven sense resoldre, per d'aquesta manera, poder seguir tramitant-los. 

A més, l'estructura de la CMDB (Configuration Management Database per al control d'actius) la tenien en un altre mitjà, per la qual cosa s'havia d'incorporar al nou sistema i integrar-lo amb els camps que ja usaven els seus tiquets. 

Pel que fa als usuaris, els que ja estaven donats d'alta a l'entorn Cloud, havien de recollir totes les dades que tenien als entorns Server. Tenien dominis diversos i correus repetits que dificulta la migració perquè a Cloud els correus han de ser únics i només els dominis reclamats per l'empresa poden ser gestionats pels administradors.

La solució

Per poder satisfer les necessitats del client pel que fa a l'administració i escalat de funcionalitats, es van implementar regles; fent servir una funcionalitat que ofereix Jira per defecte anomenada "Automations". Aquesta permet configurar accions automatitzades transparents per als usuaris, que s' activen segons la configuració que determinin els administradors. 

Durant la migració, es van crear regles que detectaven quan un tiquet migrat encara estava sense resoldre i ho replicava amb les noves configuracions vinculant-se a l'original per mantenir l'historial. 

A més, per minimitzar el temps en els escalats, es va automatitzar el procés de creació i de gestió. En la creació, es repliquen tots els camps amb valors importants i se li demana a l' usuari que especifiqui la mínima informació necessària, així el nou tiquet es crea amb els valors prèviament configurats. 

Addicionalment, durant la gestió del tiquet escalat, es van crear accions automàtiques que modifiquen la petició relacionada perquè així l'usuari només s'hagi de preocupar quan el tiquet està en certs estats. 

Altres accions dutes a terme

Pel que fa a l' ús de workflows genèrics i gestió de múltiples projectes, s' han refactoritzat tenint en compte i actualitzant els nous requisits. 

El resultat d' aquesta refacturació es reflecteix en projectes estancs amb la seva configuració específica de cada àrea. També es va tenir en compte en aquesta fase el replantejament de grups, rols i permisos, estandarditzant el model i així poder escalar d' una manera uniforme en el futur.

Relatiu als usuaris, per poder aprovisionar-los a l'aplicació i gestionar les seves credencials, es va implementar una nova connexió amb el Directori Actiu del client amb l'eina Atlassian Access. Per fer-ho vam haver de definir un domini únic per a l'empresa i així vam poder reclamar tots els usuaris registrats a Atlassian Cloud que tinguessin el correu corporatiu. 

Finalment, mitjançant la planificació del projecte establerta a l' inici i les reunions de seguiment periòdiques marcades, es va posar en producció la nova instància en la data desitjada.