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.
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.
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.
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
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.
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:
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.
A Project Configurator adminisztrációs oldaláról lehet indítani:
ennek eredménye egy XML file lesz.
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:
Project Configurator a felhasználókat is átviszi, de fontos tudni:
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.
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.
Ha a forrásrendszerben voltak Mail Handlerek, ezeket fel kell venni az új JIRA-ban is, azonos tartalommal: Administration / System / Incoming Mail
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.
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.
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.
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.
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.
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.
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
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.
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:
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.
A Project Configurator adminisztrációs oldaláról lehet indítani:
ennek eredménye egy XML file lesz.
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:
Project Configurator a felhasználókat is átviszi, de fontos tudni:
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.
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.
Ha a forrásrendszerben voltak Mail Handlerek, ezeket fel kell venni az új JIRA-ban is, azonos tartalommal: Administration / System / Incoming Mail
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.
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.
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.