Atlassian Jira ako nástroj pre riadenie úloh je využívaná vo viac ako 100 000 spoločnostiach vo svete. Z tohto dôvodu nie je nezvyčajné, že jedna spoločnosť spravuje dve alebo viac inštalácií Jira. V rámci úspory nákladov môže vzniknúť požiadavka na spojenie týchto inštalácií do jednej. V nasledujúcich riadkoch popíšeme, ako sme postupovali pri konsolidácii Jira inštancií pre jedného z našich klientov.
O klientovi
Naším klientom v tomto projekte bola spoločnosť, ktorá je svetovým lídrom na trhu s technológiou merania dynamického tlaku, sily, krútiaceho momentu a zrýchlenia. Jedinečná senzorová technológia od tejto vlastníkom riadenej švajčiarskej korporácie pomáha formovať budúce inovácie nielen vo vývoji automobilov a priemyselnej automatizácie, ale aj v mnohých novovznikajúcich sektoroch. Samotná korporácia má pobočky na 60 miestach po celom svete.
Výzva – spojenie dvoch Jira prostredí do jedného
Spomenutá korporácia akvirovala menšiu nemeckú spoločnosť. V oboch spoločnostiach používali Jiru ako nástroj na riadenie vývoja. Z manažmentu prišlo rozhodnutie spojiť dve Jira inštalácie do jednej. Cieľovou sa stala inštalácia, ktorú spravovala korporácia. Požiadavka zahŕňala prenos všetkých Jira projektov aj s nastaveniami (pracovné postupy, polia, obrazovky…). Projekty bolo treba preniesť aj spolu s úlohami, prílohami, vykázaným časom na úlohách. Samozrejmosťou bolo zachovanie oprávnení používateľov na jednotlivých projektoch.
Zdrojová Jira sa okrem iného využívala aj na zadávanie incidentov od zákazníkov do Jira Service Management (JSM). Cieľová Jira neobsahovala Jira Service Management, preto bolo nevyhnutné JSM doplniť a nastaviť rovnako ako v zdrojovej Jira.
Analýza
Pred samotnou migráciou bolo treba urobiť dôkladnú analýzu.
V prvom kroku sa analyzovala správa používateľov, aby sme zabezpečili, rovnaké prihlasovacie údaje pre používateľov. V našom prípade sa v zdrojovej Jira čítali používatelia z Active directory (AD), takže bolo potrebné preniesť nastavenie spojenia s AD aj do cieľového prostredia.
Ďalšou dôležitou časťou analýzy bolo analyzovanie aplikácií. Potrebovali sme zistiť, ktoré rozšírenia sa aktívne používajú v zdrojovej inštalácii a následne zistiť možnosti ich nahradenia v cieľovej. Ak sa aplikácia nedala nahradiť, bolo ju treba nainštalovať do cieľovej Jira.
Na prenos samotných dát (projektov, úloh, príloh…) sme sa rozhodli využiť rozšírenie
Configuration manager for Jira. Toto rozšírenie dokáže zachytiť všetky elementy konfigurácie Jira projektu a následne ich exportovať do snapshotu. V nastaveniach exportu je možné určiť:
- exportované projekty
- exportovať aj tasky projektu
- exportovať aj s prílohami
Rozšírenie je potrebné nainštalovať do oboch inštancií.
Výhodou rozšírenia je možnosť kupíť si ho len na dobu 30dní (namiesto tradičného 1 roka) a tým šetriť peňažné prostriedky zadávateľa.
Neskôr sme vytipovali 3 konkrétne Jira projekty, ktoré boli v rámci testovania migrované do testovacieho prostredia a ktorých funkcionalita sa následne testovala. Projekty boli rôzneho typu (tímový projekt s internými úlohami, projekt na vývoj aj so scrum boardom a JSM projekt aj s formulármi na portáli), aby pokryli čo najväčšiu časť funkcionality. Vytipovanie projektov prebiehalo v spolupráci so zadávateľmi.
Akvirovaná spoločnosť bola z Nemecka, preto využívala prednastavené polia (ako napr. Epic name, Epic Status atď.) v nemeckom jazyku a akvizitér, keďže je to korporácia pôsobiaca celosvetovo, využíva tieto polia v angličtine. Kedže Configuration manager by názvy prepísal podľa toho, ako je to v zdrojovej Jira, museli byť tieto polia premenované.
Ďalšou dôležitou vecou bolo preveriť, či sa nepoužívajú rovnaké mená schém (schéma oprávnení, notifikačná schéma…). Ak sú schémy rovnako pomenované a rôzne nakonfigorované, v cieľovej Jira by sa schéma s týmto menom prepísala podľa konfigurácie v zdrojovej Jira. V našom prípade sme premenovali jednu notifikačnú a jednu schému oprávnení v zdrojovej Jira.
Samotná migrácia
Pred samotnou migráciou sme robili import spomínaných 3 projektov do testovacieho prostredia, ktoré bolo totožné s produkčným cieľovým prostredím. Počas importov sme si odladili postup samotnej migrácie do produkčného prostredia. Tak ako to pri migráciách býva, migračný nástroj neprenesie všetko na 100% a po importe bolo nutné urobiť niekoľko manuálnych zásahov do konfigurácie prenesených projektov. V našom prípade to boli post funkcie (funkcie uverejnenia) z rozšírenia, ktoré nebolo podporované Configuration Managerom.
Samotná migrácia prebiehala v nasledujúcich krokoch:
- export údajov zo zdrojového prostredia
- prenos dát zo servera zdrojovej Jira na server cieľovej Jira
- príprava cieľového prostredia (inštalácia rozšírení, nastavenie spojenia s AD, inštalácia Jira Service Management )
- import dát do cieľového prostredia
- vykonanie nastavení na projektoch, ktoré Configuration manager nevie preniesť
- test funkčnosti
Samozrejmosťou bolo vytvorenie zálohy v cieľovom prostredí pred začiatkom migrácie. Celkovo sme boli schopní za jeden víkend skonsolidovať Jira prostredia.
Výhody
Hlavnou výhodou konsolidácie je, že všetci zamestnanci pracujú v jednej inštalácii Jira. Ďalším krokom bude zjednotenie procesov korporácie a akvirovanej spoločnosti – v jednej inštalácii je takýto proces jednoduchší. Pre používateľov z akvirovanej spoločnosti sa zmenila len URL systému.
Ušetrenie nákladov na réžiu a licencovanie dvoch Jira prostredí – ušetrí sa čas na optimalizáciu Jira
Zlepšenie kolaborácie zamestnancov – zamestnanec sa nemusí prepínať medzi 2 prostrediami, ale všetko vie nájsť v jednej Jira.
Toto spojenie dvoch rôznych inštancií sme zvládli za 2 mesiace.
Ak potrebujete pomoc od expertov so zavedením či nastavením Jira, alebo poradiť ako ju čo najefektívnejšie využiť vo vašej firme, tak nás neváhajte kontaktovať.
Naše Atlassian riešenia
