Atlassian Jira jako nástroj pro řízení úkolů je využívána ve více než 100 000 společnostech ve světě. Z tohoto důvodu není neobvyklé, že jedna společnost spravuje dvě nebo více instalací Jira. V rámci úspory nákladů může vzniknout požadavek na spojení těchto instalací do jedné. V následujících řádcích popíšeme, jak jsme postupovali při konsolidaci Jira instancí pro jednoho z našich klientů.
O klientovi
Naším klientem v tomto projektu byla společnost, která je světovým lídrem na trhu s technologií měření dynamického tlaku, síly, točivého momentu a zrychlení. Jedinečná senzorová technologie od této vlastníkem řízené švýcarské korporace pomáhá formovat budoucí inovace nejen ve vývoji automobilů a průmyslové automatizace, ale také v mnoha nově vznikajících sektorech. Samotná korporace má pobočky na 60 místech po celém světě.
Výzva – spojení dvou Jira prostředí do jednoho
Výše zmíněná korporace koupila menší německou společnost. Obě společnosti používaly Jiru jako nástroj pro správu vývoje. Z vedení společnosti vzešlo rozhodnutí sloučit obě instalace Jiry do jedné. Cílem se stala instalace spravovaná korporací. Požadavek zahrnoval převod všech projektů Jira včetně nastavení (pracovní postupy, pole, obrazovky…). Projekty bylo třeba přenést také spolu s úkoly, přílohami, vykazovaným časem na úkolech. Samozřejmě musela být zachována uživatelská oprávnění k jednotlivým projektům.
Zdroj Jira sloužil mimo jiné k zadávání zákaznických incidentů do systému Jira Service Management (JSM). Cílová Jira neobsahovala Jira Service Management, takže bylo nutné přidat a nakonfigurovat JSM stejným způsobem jako ve zdrojové Jira.
Analýza
Před samotnou migrací bylo nutné provést důkladnou analýzu.
V prvním kroku byla analyzována správa uživatelů, aby bylo možné zajistit stejné přihlašovací údaje pro uživatele. V našem případě zdrojová Jira načítala uživatele z adresáře Active directory (AD), takže bylo nutné přenést nastavení připojení k AD i do cílového prostředí.
Další důležitou součástí analýzy byla analýza aplikací. Bylo třeba zjistit, která rozšíření se aktivně používají ve zdrojové instalaci, a poté určit možnost jejich nahrazení v cílovém prostředí. Pokud některou aplikaci nebylo možné nahradit, bylo nutné ji v cílovém prostředí Jira nainstalovat.
K přenosu aktuálních dat (projektů, úkolů, příloh…) jsme se rozhodli použít rozšíření Configuration manager for Jira. Toto rozšíření dokáže zachytit všechny konfigurační prvky projektu Jira a následně je exportovat do snímku. V nastavení exportu je možné určit:
- exportované projekty
- exportovat také úkoly projektu
- exportovat i s přílohami
Rozšíření musí být nainstalováno v obou instancích.
Výhodou rozšíření je možnost zakoupit jej pouze na 30 dní (místo tradičního 1 roku) a ušetřit tak peníze sponzora.
Později jsme vybrali 3 konkrétní projekty Jira, které byly v rámci testování převedeny do testovacího prostředí a jejichž funkčnost byla následně otestována. Jednalo se o projekty různých typů (týmový projekt s interními úkoly, vývojový projekt rovněž se scrum boardem a projekt JSM rovněž s formuláři na portálu), aby byla pokryta co největší část funkcionality. Projekty byly vybrány ve spolupráci se zadavateli.
Akvizitorem byla německá společnost, takže se používala přednastavená pole (např. Epic name, Epic Status atd.) v němčině a akvizitér, který je globální korporací, používá tato pole v angličtině. Protože správce konfigurace by přepsal názvy podle toho, jak je to ve zdrojovém systému Jira, bylo nutné tato pole přejmenovat.
Další důležitou věcí bylo zkontrolovat, zda se používají stejné názvy schémat (schéma oprávnění, schéma oznámení…). Pokud by se schémata jmenovala stejně a byla nakonfigurována jinak, v cílové Jira by se schéma s tímto názvem přepsalo podle konfigurace ve zdrojové Jira. V našem případě jsme ve zdrojové Jira přejmenovali jedno schéma oznámení a jedno schéma oprávnění.
Samotná migrace
Před vlastní migrací jsme importovali 3 projekty do testovacího prostředí, které bylo totožné s cílovým produkčním prostředím. Během importu jsme ladili proces vlastní migrace do produkčního prostředí. Jak už to u migrací bývá, migrační nástroj nepřenese vše na 100 % a po importu bylo nutné provést některé ruční zásahy do konfigurace přenesených projektů. V našem případě se jednalo o postfunkce (funkce publikování) z rozšíření, které nebylo podporováno nástrojem Configuration Manager.
Vlastní migrace probíhala v následujících krocích:
- export dat ze zdrojového prostředí
- přenos dat ze zdrojového serveru Jira na cílový server Jira
- příprava cílového prostředí (instalace rozšíření, nastavení připojení k AD, instalace správy služeb Jira )
- import dat do cílového prostředí
- provedení nastavení u projektů, které správce konfigurace nemůže přenést
- testování funkčnosti
Před zahájením migrace byla samozřejmě v cílovém prostředí vytvořena záloha. Celkově se nám podařilo konsolidovat prostředí Jira během jednoho víkendu.
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ť.
Kontaktujte nás
