JIRA Migráció: projektek migrálása éles rendszerbe

March 14, 2016
 JIRA Migráció: projektek migrálása éles rendszerbe

This post was last updated more than 1 year ago. Some content may be out of date.

JIRA Migráció

Ez a cikk egy olyan sorozat része, amelyet ügyfeleinknél végrehajtott projektek tapasztalataiból merítünk.

Egyik ügyfelünk (egy nagy európai logisztikai cég Magyarországi leányvállalata) több európai irodával van napi munkakapcsolatba. Az anyacégben cégben több JIRA rendszert is üzemeltetnek, de eltökélt szándékuk, hogy ezeket összevonják egy központi JIRA-ba.

Ennek a folyamatnak a részeként bíztak meg minket, hogy migráljunk egy francia JIRA rendszerből projekteket a központi JIRA-ba, amelyet ők üzemeltetnek. Azonnal látszott, hogy eljött az idő a Project Restore funkciójának éles bevetésére.

A helyzetet bonyolította, hogy a migrálandó JIRA egy JIRA Cloud volt, tehát először egy köztes JIRA rendszerbe történő áttöltés végrehajtása vált szükségessé. Ezt a folyamatot hamarosan egy külön posztban részletezzük.

Migrálási lehetőségek

Mivel a cél JIRA már éles használatban volt, nem volt lehetséges migrálandó JIRA rendszer teljes betöltése, habár ez lett volna a legegyszerűbb megoldás.

Egyértelmű volt, hogy a JIRA Project Restore funkcióját kell alkalmaznunk. Ha valaki megnézi ennek leírását, azonnal láthatja, hogy mennyire bonyolult tud lenni egy ilyen migráció ha sok projektet minden összetevőjével együtt kell átmozgatni. A dokumentáció szerint nagyon sok manuális munkával létre kell hozni minden elemet, sémát, mezőt stb az adatok áttöltése előtt.

A sok projekt és az addonokkal átszőtt workflowk, egyedi mezők több napnyi munkával kecsegtettek. Ezért keresni kezdtünk egy könnyebb utat, valamilyen megoldást, amely segítségünkre lehet, és végül megtaláltuk a Project Configurator nevű add-ont, amely nagyon hasznosnak bizonyult.

A migrálás lépései

Néhány próbálkozás után az alábbi lépések vezettek eredményre. Ezek a lépések feltételezik, hogy a forrás és cél JIRA ugyanolyan verziójú. Ha nem, frissítésekkel el kell érni ezt, ezzel is csökkentve az adatok betöltésének hibalehetőségeit.

Step 1 - Emailezés kikapcsolása a cél JIRA-ban

Mielőtt belefognánk a migrálásba, érdemes kikapcsolni az emailek fogadását és küldését a JIRA-ban. Ezt a legbiztonságosabban a setenv.sh/bat file-ban lehet megtenni, újraindítás szükséges lesz:

-Datlassian.mail.senddisabled=true
-Datlassian.mail.fetchdisabled=true
-Datlassian.mail.popdisabled=true

Step 2 - Add-onok

Ha a forrás JIRA-ban vannak olyan add-onok, amelyek a cél JIRA-ban nincsenek, vagy más a verziójuk, akkor telepíteni esetleg frissíteni kell őket a célrendszerben, mivel az átmozgatott metaadatok (pl workflow komponensek, egyedi mezők, stb) tartalmazhatnak elemeket ezekből az add-onokból. Ezért kritikus, hogy ezek a bővítmények elérhetők legyenek a migráláskor.

Fontos tudni, hogy a teljes export-importtal ellentétben a projektek migrálása nem fogja magával hozni a pluginek konfigurációs adatait. Ezeket kézzel kell reprodukálnunk a célrendszerben a migrálás előtt.

Step 3 - Metaadatok átmozgatása Project Configurator segítségével

Ez az add-on nagyon hasznosnak bizonyult, rengeteg időt, erőfeszítést megspórolt számunkra, de van néhány fontos dolog, amit tudni kell.

Az add-on használatának lépései:

Névütközések feloldása

A forrás és célrendszerben lehetnek azonos nevű elemek (jellemzően a Default sémák), amelyek beállításai különböznek. Ez nem jelent problémát a Project Configurator számára, mivel egyszerűen felülírja a célrendszer azonos nevű elemeit.

Ezt el kell kerülni, így a névütközéseket átnevezésekkel célszerű feloldani. Már a forrás rendszerben érdemes átnevezni minden érintett dashboardot, szűrőt, sémát, workflowt, egyedi mezőt.

Metaadatok exportálása

A Project Configurator adminisztrációs oldaláról lehet indítani:

ennek eredménye egy XML file lesz.

Adatok beöltése a célrendszerben

Betöltés előtt fontos, hogy legalább ezt az egy oldal elolvassuk és megértsük a Project Configurator dokumentációjában: https://awnaba.atlassian.net/wiki/x/KIAF

A Project Configurator lehetővé teszi adatok betöltését szimulációs üzemmódban. Ennek lényege, hogy minden módosítást egy tranzakcióban hajt végre, amelyet a betöltés végén visszaállít (rollback).

Fontos, hogy először szimulációval töltsük be az adatokat.

Ha hiba nélkül lement a szimuláció, indíthatjuk az éles betöltést az "Apply changes?" opció bekapcsolásával.

Fontos tudnivalók

Projekt komponensen és verziók:

  • A Project Configurator alapértelmezés szerint betölti az egyes projektek komponenseit és verzióit is. Azonban a betöltéskor megadhatjuk, hogy ezeket hagyja figyelmen kívül. Azért hasznos kihagyni a komponenseket és verziókat, mert a projekt adatainak betöltésekor (ld lejjebb), a JIRA félbeszakítja a betöltést, mivel a projektben már vannak verziók és komponensek. Folytatás előtt pedig ki kell majd törölni ezeket a projektekből. Emiatt hasznos már be sem tölteni őket.

Project Configurator a felhasználókat is átviszi, de fontos tudni:

  • Új jelszavak kerülnek létrehozásra, a felhasználóknak első bejelentkezéskor a jelszóemlékeztetőt kell használni a login képernyőn.
  • A felhasználók az első írható user directoryban jönnek létre, így a user directory-k sorrendjének beállítása migrálás előtt fontos lehet a célrendszerben.

Step 4 - Workflow-k átvitele

A Project Configurator legutóbbi verziója már támogatja a workflowkat, mi még a JIRA Workflow export/import funkcióját használtuk. Ez egy nagyon okos lehetőség, mert a workflow bundle magával viszi a workflow függőségeit is: transition view képernyőket, egyedi mezőket, állapotokat, add-onokból származő összetevőket (pl post-functionok). Ezért is fontos, hogy a célrendszerben az ad-onok elérhetőek legyenek a kiinduló JIRA-val azonos beállításokkal.

Az export részletes visszajelzést ad, az import pedig lehetővé teszi, hogy finomhangoljuk a betöltendő folyamatot. A Workflow export/import dokumentációja tartalmazza a részleteket.

Step 5 - Adatok betöltése

A Projektek áttöltéséhez teljes XML exportot kell végrehajtani a forrásrendszerben, majd a cél JIRA-ban a "Project Import" művelettel kell kezdeményezni a projektek egyesével való betöltését.

A projekt betöltésekor részletes jelentést kapunk a sikerességről és esetleges hibákról, amelyek javítása után megismételhető a betöltés.

Fontos

A Project restore funckó használatakor azt tapasztaltuk, hogy az egyes issue-k betöltésekor a Create tranzíció az érintett workflowban lefut, ellentétben a teljes XML export és import művelettel. Ezt fontos megjegyezni.

Emiatt ha a Create tranzíció olyan post-functionöket tartalmaz, amelyek inicializálják az issuet, akkor a végeredményként létrejövő betöltött issue-k különbözhetnek a forrásrendszerbeli párjuktól.

Például: ha egy post-function a Create tranzícióban beállítja a felelős személyt (Assignee), akkor pl a létrejövő issue más személyhez lesz rendelve, mint a forrásrendszerben. A MISC Workflow Extensions add-onnak vannak ilyen post-functionjei.

Az ilyen problémákat elkerülendő érdemes átnézni a migrálandó workflowkat, és az áttöltés előtt kivenni belőlük ezeket a post-funcionöket, mad a migrálás végeztével visszarakni őket.

Ezt legkönnyebben úgy oldhatjuk meg, hogy az érintett workflowkat lemásoljuk, majd a veszélyes post-funcionöket kivesszük az eredetiből. Migrálás után a másolat workflow-ra kicseréljük a módosítottakat az érintett workflow sémákban.

Step 6 - Mail Handlerek

Ha a forrásrendszerben voltak Mail Handlerek, ezeket fel kell venni az új JIRA-ban is, azonos tartalommal: Administration / System / Incoming Mail

Step 7 - Emailezés visszakapcsolása és újraindítás

Végül a setenv.sh/bat módosításával kapcsoljuk vissza az emailezést, és újraindítjuk, majd újraindexeljük a JIRA-t.

Backup stratégia

Javasolt minden fenti lépés előtt egy backupot készíteni mind a JIRA-ról, mind az adatbázisról. Ezáltal mindig lesz egy visszaállítási pont, ahonnan esetleges hibák után folytathatjuk a folyamatot. Ha virtuális szervereken futnak a rendszerek, akkor a snapshotok készítése egy gyors, kényelmes és megbízható módja a backupnak.

Tanulság

A JIRA bonyolult adatmodellje, a projektek minden aspektusával együtt megnehezíti éles rendszerben történő betöltésüket még akkor is, ha a Project Configurator segítségével jelentősen lecsökken a végrehajtás ideje. Ha azonban figyelmesen, és gondosan járunk el, akkor az időigény a fenti lépések fényében pontosabban tervezhető, és a folyamat gyorsabban vezet majd eredményre.

Author

Tibor Hegyi
Founder & co-CEO

Social Share Buttons

JIRA Migráció: projektek migrálása éles rendszerbe

March 14, 2016
 JIRA Migráció: projektek migrálása éles rendszerbe

Ez a bejegyzés több mint 1 éve frissült utoljára, a tartalom bizonyos elemei elavultak lehetnek.

JIRA Migráció

Ez a cikk egy olyan sorozat része, amelyet ügyfeleinknél végrehajtott projektek tapasztalataiból merítünk.

Egyik ügyfelünk (egy nagy európai logisztikai cég Magyarországi leányvállalata) több európai irodával van napi munkakapcsolatba. Az anyacégben cégben több JIRA rendszert is üzemeltetnek, de eltökélt szándékuk, hogy ezeket összevonják egy központi JIRA-ba.

Ennek a folyamatnak a részeként bíztak meg minket, hogy migráljunk egy francia JIRA rendszerből projekteket a központi JIRA-ba, amelyet ők üzemeltetnek. Azonnal látszott, hogy eljött az idő a Project Restore funkciójának éles bevetésére.

A helyzetet bonyolította, hogy a migrálandó JIRA egy JIRA Cloud volt, tehát először egy köztes JIRA rendszerbe történő áttöltés végrehajtása vált szükségessé. Ezt a folyamatot hamarosan egy külön posztban részletezzük.

Migrálási lehetőségek

Mivel a cél JIRA már éles használatban volt, nem volt lehetséges migrálandó JIRA rendszer teljes betöltése, habár ez lett volna a legegyszerűbb megoldás.

Egyértelmű volt, hogy a JIRA Project Restore funkcióját kell alkalmaznunk. Ha valaki megnézi ennek leírását, azonnal láthatja, hogy mennyire bonyolult tud lenni egy ilyen migráció ha sok projektet minden összetevőjével együtt kell átmozgatni. A dokumentáció szerint nagyon sok manuális munkával létre kell hozni minden elemet, sémát, mezőt stb az adatok áttöltése előtt.

A sok projekt és az addonokkal átszőtt workflowk, egyedi mezők több napnyi munkával kecsegtettek. Ezért keresni kezdtünk egy könnyebb utat, valamilyen megoldást, amely segítségünkre lehet, és végül megtaláltuk a Project Configurator nevű add-ont, amely nagyon hasznosnak bizonyult.

A migrálás lépései

Néhány próbálkozás után az alábbi lépések vezettek eredményre. Ezek a lépések feltételezik, hogy a forrás és cél JIRA ugyanolyan verziójú. Ha nem, frissítésekkel el kell érni ezt, ezzel is csökkentve az adatok betöltésének hibalehetőségeit.

Step 1 - Emailezés kikapcsolása a cél JIRA-ban

Mielőtt belefognánk a migrálásba, érdemes kikapcsolni az emailek fogadását és küldését a JIRA-ban. Ezt a legbiztonságosabban a setenv.sh/bat file-ban lehet megtenni, újraindítás szükséges lesz:

-Datlassian.mail.senddisabled=true
-Datlassian.mail.fetchdisabled=true
-Datlassian.mail.popdisabled=true

Step 2 - Add-onok

Ha a forrás JIRA-ban vannak olyan add-onok, amelyek a cél JIRA-ban nincsenek, vagy más a verziójuk, akkor telepíteni esetleg frissíteni kell őket a célrendszerben, mivel az átmozgatott metaadatok (pl workflow komponensek, egyedi mezők, stb) tartalmazhatnak elemeket ezekből az add-onokból. Ezért kritikus, hogy ezek a bővítmények elérhetők legyenek a migráláskor.

Fontos tudni, hogy a teljes export-importtal ellentétben a projektek migrálása nem fogja magával hozni a pluginek konfigurációs adatait. Ezeket kézzel kell reprodukálnunk a célrendszerben a migrálás előtt.

Step 3 - Metaadatok átmozgatása Project Configurator segítségével

Ez az add-on nagyon hasznosnak bizonyult, rengeteg időt, erőfeszítést megspórolt számunkra, de van néhány fontos dolog, amit tudni kell.

Az add-on használatának lépései:

Névütközések feloldása

A forrás és célrendszerben lehetnek azonos nevű elemek (jellemzően a Default sémák), amelyek beállításai különböznek. Ez nem jelent problémát a Project Configurator számára, mivel egyszerűen felülírja a célrendszer azonos nevű elemeit.

Ezt el kell kerülni, így a névütközéseket átnevezésekkel célszerű feloldani. Már a forrás rendszerben érdemes átnevezni minden érintett dashboardot, szűrőt, sémát, workflowt, egyedi mezőt.

Metaadatok exportálása

A Project Configurator adminisztrációs oldaláról lehet indítani:

ennek eredménye egy XML file lesz.

Adatok beöltése a célrendszerben

Betöltés előtt fontos, hogy legalább ezt az egy oldal elolvassuk és megértsük a Project Configurator dokumentációjában: https://awnaba.atlassian.net/wiki/x/KIAF

A Project Configurator lehetővé teszi adatok betöltését szimulációs üzemmódban. Ennek lényege, hogy minden módosítást egy tranzakcióban hajt végre, amelyet a betöltés végén visszaállít (rollback).

Fontos, hogy először szimulációval töltsük be az adatokat.

Ha hiba nélkül lement a szimuláció, indíthatjuk az éles betöltést az "Apply changes?" opció bekapcsolásával.

Fontos tudnivalók

Projekt komponensen és verziók:

  • A Project Configurator alapértelmezés szerint betölti az egyes projektek komponenseit és verzióit is. Azonban a betöltéskor megadhatjuk, hogy ezeket hagyja figyelmen kívül. Azért hasznos kihagyni a komponenseket és verziókat, mert a projekt adatainak betöltésekor (ld lejjebb), a JIRA félbeszakítja a betöltést, mivel a projektben már vannak verziók és komponensek. Folytatás előtt pedig ki kell majd törölni ezeket a projektekből. Emiatt hasznos már be sem tölteni őket.

Project Configurator a felhasználókat is átviszi, de fontos tudni:

  • Új jelszavak kerülnek létrehozásra, a felhasználóknak első bejelentkezéskor a jelszóemlékeztetőt kell használni a login képernyőn.
  • A felhasználók az első írható user directoryban jönnek létre, így a user directory-k sorrendjének beállítása migrálás előtt fontos lehet a célrendszerben.

Step 4 - Workflow-k átvitele

A Project Configurator legutóbbi verziója már támogatja a workflowkat, mi még a JIRA Workflow export/import funkcióját használtuk. Ez egy nagyon okos lehetőség, mert a workflow bundle magával viszi a workflow függőségeit is: transition view képernyőket, egyedi mezőket, állapotokat, add-onokból származő összetevőket (pl post-functionok). Ezért is fontos, hogy a célrendszerben az ad-onok elérhetőek legyenek a kiinduló JIRA-val azonos beállításokkal.

Az export részletes visszajelzést ad, az import pedig lehetővé teszi, hogy finomhangoljuk a betöltendő folyamatot. A Workflow export/import dokumentációja tartalmazza a részleteket.

Step 5 - Adatok betöltése

A Projektek áttöltéséhez teljes XML exportot kell végrehajtani a forrásrendszerben, majd a cél JIRA-ban a "Project Import" művelettel kell kezdeményezni a projektek egyesével való betöltését.

A projekt betöltésekor részletes jelentést kapunk a sikerességről és esetleges hibákról, amelyek javítása után megismételhető a betöltés.

Fontos

A Project restore funckó használatakor azt tapasztaltuk, hogy az egyes issue-k betöltésekor a Create tranzíció az érintett workflowban lefut, ellentétben a teljes XML export és import művelettel. Ezt fontos megjegyezni.

Emiatt ha a Create tranzíció olyan post-functionöket tartalmaz, amelyek inicializálják az issuet, akkor a végeredményként létrejövő betöltött issue-k különbözhetnek a forrásrendszerbeli párjuktól.

Például: ha egy post-function a Create tranzícióban beállítja a felelős személyt (Assignee), akkor pl a létrejövő issue más személyhez lesz rendelve, mint a forrásrendszerben. A MISC Workflow Extensions add-onnak vannak ilyen post-functionjei.

Az ilyen problémákat elkerülendő érdemes átnézni a migrálandó workflowkat, és az áttöltés előtt kivenni belőlük ezeket a post-funcionöket, mad a migrálás végeztével visszarakni őket.

Ezt legkönnyebben úgy oldhatjuk meg, hogy az érintett workflowkat lemásoljuk, majd a veszélyes post-funcionöket kivesszük az eredetiből. Migrálás után a másolat workflow-ra kicseréljük a módosítottakat az érintett workflow sémákban.

Step 6 - Mail Handlerek

Ha a forrásrendszerben voltak Mail Handlerek, ezeket fel kell venni az új JIRA-ban is, azonos tartalommal: Administration / System / Incoming Mail

Step 7 - Emailezés visszakapcsolása és újraindítás

Végül a setenv.sh/bat módosításával kapcsoljuk vissza az emailezést, és újraindítjuk, majd újraindexeljük a JIRA-t.

Backup stratégia

Javasolt minden fenti lépés előtt egy backupot készíteni mind a JIRA-ról, mind az adatbázisról. Ezáltal mindig lesz egy visszaállítási pont, ahonnan esetleges hibák után folytathatjuk a folyamatot. Ha virtuális szervereken futnak a rendszerek, akkor a snapshotok készítése egy gyors, kényelmes és megbízható módja a backupnak.

Tanulság

A JIRA bonyolult adatmodellje, a projektek minden aspektusával együtt megnehezíti éles rendszerben történő betöltésüket még akkor is, ha a Project Configurator segítségével jelentősen lecsökken a végrehajtás ideje. Ha azonban figyelmesen, és gondosan járunk el, akkor az időigény a fenti lépések fényében pontosabban tervezhető, és a folyamat gyorsabban vezet majd eredményre.

Szerző

Hegyi Tibor
Founder & co-CEO

Megosztás