Näin onnistut Redmine-migraatiossa Jiraan

1. Miksi siirtyä Redminesta Jiraan?

Jiralla on Redmineen verrattuna etuja, jotka tuodaan esiin myös Atlassianin omassa vertailussa näiden kahden työkalun välillä:

• Jira tukee Scrumia täysin ja sisältää sprinttien boardit ja tilastot. Sprinttien kesto voidaan määrittää vapaasti viikkoina, ja jokaisen tiimin jäsenen työmäärä on helppo nähdä kussakin sprintissä.

• Työnkulut voidaan mukauttaa helposti yrityksen vaatimuksiin. Voidaan esimerkiksi määrittää, että issue käy läpi kaikki eri vaiheet ennen kuin se voidaan sulkea. Toisin kuin Redminessa, Jirassa työnkulku voidaan määrittää myös projektikohtaisesti. Redminessa työnkulku ja tilat ovat yhteisiä kaikille projekteille.

• Työnkulut tukevat validaattoreita, ehtoja ja jälkitoimintoja, joiden avulla prosesseja voidaan automatisoida. Jiran vakioasennuksessa on joitakin työnkulkuun sovellettavia ehtovaihtoehtoja.

• Issueiden tiloja näyttäviä boardeja voidaan mukauttaa erittäin yksityiskohtaisesti. Jirassa voidaan määrittää päivittäisiin Scrum-palavereihin sopivia kyselyitä, joten on helppo nähdä, mitä kukin on tehnyt edellisenä päivänä. Redminessa nämä suodattimet on määritettävä joka päivä.

• Kenttäkonfiguraatioskeemat ovat joustavia, ja niiden avulla voidaan määrittää, mitkä kentät ovat pakollisia tietyssä projektissa ja tietyille issuetyypeille.

Redmine ei tue Scrumia täysin, vaan se on suunnattu enemmän Kanban-tyyppiseen työskentelyyn. Redminessa ei ole epicejä, vaan storyja, bugeja ja alitehtäviä. Jira sisältää epicit, storyt, alitehtävät ja bugit.

Lisäksi Jirassa on kahdenlaisia boardeja: toinen Scrum- ja toinen Kanban-työskentelyyn. Molemmat boardit voidaan määrittää kyselyillä, jolloin yleisiä hakuja ei tarvitse toistaa.

Redminella on pari etua

Redmine tarjoaa työajanseurantamoduulin, joka on yksityiskohtaisempi kuin Jiran oletuksena tarjoama toiminnallisuus. Redminessa on käytetyn ajan ja kommenttikenttien lisäksi erillinen aktiviteettikenttä.

Redmine on myös avoimen lähdekoodin ohjelmisto, joten se ei vaadi lisenssejä. Tämä voi olla syy jatkaa Redminen käyttöä, sillä projektia ylläpidetään edelleen aktiivisesti.

2. Datan vienti ja muuntaminen

Redminesta Jiraan siirtyminen edellyttää, että kaikki nykyinen työ siirretään järjestelmästä toiseen. Migraatio koostuu seuraavista vaiheista:

1. Datan vienti

2. Datan muuntaminen

3. Datan tuonti

4. Näkymien mukauttaminen Jirassa

Migraatio voidaan toteuttaa muutamalla eri tavalla, mutta näkymien mukauttamisvaihe on pitkälti sama valitusta menetelmästä riippumatta.

Ennen Jira 8.4:ää

Jira 8.3:een asti Atlassian tarjosi tuonnin useista kolmannen osapuolen työkaluista, kuten Redminesta, Tracista ja Trellosta. Nämä työkalut sisältyvät Jiran oletusasennukseen. Tämä vaihtoehto hoitaa käytännössä kolme edellä mainittua migraation ensimmäistä vaihetta.

Kun tunnistetiedot on syötetty, järjestelmä pyytää valitsemaan tuotavat projektit ja niiden kohdeprojektit Jirassa sekä määrittämään, miten mukautetut kentät yhdistetään ja miten linkit luodaan.

Valitettavasti Atlassian lopetti automaattisten tuontiplugineiden tuen Jira 8.4:stä alkaen, joten tuonti on mahdollista vain CSV- tai JSON-muodossa.

Päätimme käyttää automatisoituja työkaluja. Tuontityökalu huolehtii asioista, jotka vaatisivat JSON-tuonnissa enemmän harkintaa, mutta se on myös vähemmän joustava.

Kun Jiraan luodaan projekti, on valittava projektimalli, joka määrittää työnkulun ja käytettävissä olevat tilat. Migraatiota varten käytimme erillistä projektimallia Redminen tilojen kuvaamiseen Jirassa.

Redmine-projekteissa oli valittavana enemmän tiloja kuin Jiran oletusprojektimallit tarjosivat. Siksi Jiraa piti mukauttaa vastaamaan Redminen tiloja.

Meidän tapauksessamme projektimallia piti muokata, jotta tilojen vastaavuus saatiin määritettyä oikein. Projektimalleja voidaan muokata siten, että niihin sisällytetään tiloja, joihin ei voi siirtyä, mutta joita tarvitaan jälkikäsittelyssä, jotta tiimit voivat itse valita, mistä tilasta tiketyt siirretään. Useampi Redminen tila saattoi vastata yhtä Jiran tilaa, mutta koska se olisi tarkoittanut oletusten tekemistä muiden puolesta, päätimme jättää osan tiloista väliaikaisesti ennalleen. Osa keltaisista tiloista palvelee samaa tarkoitusta. On mahdollista, että In Test -tilassa olevien tikettien pitäisi olla In Progress -tilassa, ja tällöin ne on helppo siirtää joukkona. Tämä olisi mahdotonta, jos oletuksia olisi tehty tuonnin aikana.

Tuontityökaluun liittyvät ongelmat

Joka kerta, kun tuot uuden projektin, luodaan uusi mukautettu kenttä, joka yhdistää vanhan järjestelmän tiedot Jiraan. Kenttää käytetään estämään samojen tikettien tuominen uudelleen. Tämä tarkoittaa kuitenkin myös sitä, että kenttiä on yhdistettävä lisää. ScriptRunnerissa on toiminto, jolla tällaiset kentät voidaan ennalta määritetyn suodattimen perusteella yhdistää yhdeksi mukautetuksi kentäksi. Mukautettujen kenttien luettelo kasvaa sitä mukaa, kun projekteja tuodaan lisää, joten kokonaiskuva on helppo menettää. Jirassa voit mukauttaa, miten tikettien tiedot esitetään, joten yhden kentän käyttäminen helpottaa myös näkymän mukauttamista. Näin on myös helppo lähettää asianomaisille tiimeille ohjeet vanhojen tikettien hakemiseen. Huomaa, että kun lisäät kentän näkymänäyttöön, nimi ja arvo näkyvät vain, jos kentällä on arvo.

Ratkaisutiloja ei yhdistetty oikein. Migraatiotyökalu toi Jiraan ratkaisutilan ”1”, joka ei kuvaa, miten tiketti ratkaistiin. Asiakas ei ollut erityisen kiinnostunut vanhoista, jo ratkaistuista tiketeistä, joten ratkaisutila poistettiin ratkaisunäkymän vaihtoehdoista. Näin uusia tikettejä ei ratkaista käyttämällä merkityksetöntä ratkaisutilaa. Työnkulussa voidaan määrittää siirtymälle tiettyjä ominaisuuksia, jotka vaikuttavat ratkaisunäkymään. Käytännössä projekteissa on edelleen tämä erikoinen ratkaisutila, mutta uusissa tiketeissä ratkaisutilaa ei voi asettaa tähän arvoon.

Tuontityökalun määrittämät tikettinumerot, esimerkiksi PROJ-1234, ovat satunnaisia, joten kasvava tikettinumero ei vastaa tiketin luontipäivää.

Tuontityökalu ei tuo kaikkia olennaisia tietoja. Redmine-projekteille, joissa oli aliprojekteja, loimme Jiraan komponentin, jolla oli sama nimi kuin Redminen aliprojektilla. Jiran komponentit ovat joustavampia kuin Redminen aliprojektit, sillä niille voidaan määrittää tikettien oletusvastuuhenkilö. Meidän tapauksessamme piti määrittää Story points -arvo, tikettien kiinteät versiot (eli releaset) sekä komponentti projekteille, joissa oli aliprojekteja. Kävimme yksinkertaisesti läpi olennaisten parametrien luettelon ja teimme sitten REST API -kutsut jokaiselle tiketille. netrc-tiedosto sisältää käyttäjän Jira-todennukseen tarvittavat tunnistetiedot.

Jirassa on useita mukautettuja kenttiä, jotka voidaan asettaa, jos niiden konteksti on määritetty projektille. Mukautettu kenttä 10006 on Story points -kenttä. Mukautettujen kenttien tunnukset löytyvät Jiran hallinnasta. Huomaa, että jos aiot käyttää migraatiossa muita Jiran mukautettuja kenttiä, kentälle on määritettävä konteksti, jotta sen voi asettaa projektille. Muutoin REST API -kutsu epäonnistuu varoitukseen, jonka mukaan kenttää ei voi asettaa tiketille.

Jira 8.4 ja uudemmat

Atlassian ilmoitti, että tuontipluginit eivät ole enää saatavilla Jira 8.4:stä alkaen. JSON- tai CSV-tiedostoja voi kuitenkin edelleen tuoda. Tämä vaatii luonnollisesti enemmän työtä, sillä kaikki olennaiset tiedot on poimittava REST API:n kautta työkalusta, josta ollaan siirtymässä pois. Joissakin työkaluissa ei välttämättä ole REST API:a, tai REST-päätepisteet eivät tarjoa kaikkia tietoja, joita haluat hakea. Jos käytössäsi on Jira 8.4 tai uudempi ja haluat siirtyä vanhasta järjestelmästä, Atlassianilla on yksityiskohtainen dokumentaatio tuonnissa käytettävästä muodosta. CSV on todennäköisesti hyvä valinta vain silloin, kun tietojoukko on melko pieni ja sisältää tiketeistä vain hyvin perustason tietoja. CSV on paljon tiiviimpi kuin JSON, koska jokaisesta tiketistä on vain yksi rivi. JSONin avulla tietoja on helpompi tarkastella ja hakea esimerkiksi jq:lla, mikä helpottaa tietojen muokkaamista ja analysointia.

Redminessa on REST API, joka tukee tarvittavien tietojen poimintaa. Se kattaa käyttäjät, tiketyt metatietoineen (kommentit, suhteet, releaset) ja projektit. Joitakin tietoja, kuten projektin releasejen päivämääriä, ei voi poimia REST API:n kautta, vaan ne on poimittava manuaalisesti Redminen käyttöliittymästä.

Meillä ei ollut valmista muunnosskriptiä. Meidän piti kuitenkin kirjoittaa Python-koodia, joka tuottaa JSONia alitehtävälinkkien tuomiseksi oikein. Skriptin laajentaminen sisältämään käyttäjät, projektit ja tiketyt – myös liitteineen – vaikuttaa toteuttamiskelpoiselta. Hylkäämme copied_to-linkit, koska tuontiplugin oli jo käsitellyt ne.

Skripti käyttää Python 3.6:ssa käyttöön otettuja f-stringejä. Skripti voidaan suorittaa komennolla:python import-links.py <Jira project key>

Esitystavan mukauttaminen Jirassa

Vaikka päätimme tuoda ja muuntaa tiedot tuontipluginien avulla, migraation jälkeen on huomioitava joitakin asioita. Jirassa on eri tikettityypeille näyttöjä, jotka voivat olla joko yksittäisen projektin omia tai useiden projektien yhteisiä. Jokaisella tikettityypillä on kolme näyttöä:

• Näkymänäyttö

• Luontinäyttö

• Päivitysnäyttö

Näkymänäyttöön kannattaa lisätä Redmine-ongelman tunniste. Vastaavasti ulkoinen ongelma kannattaa jättää pois päivitys- ja luontinäytöiltä. Komponentti- ja korjausversioattribuutit on jo määritetty oletusarvoisesti kaikille kolmelle näytölle.

Redminessä ei ole tauluja, joten eri projekteille luotiin kaksi taulua: Scrum-taulu ja Kanban-taulu. Taulut on määritetty sisältämään sarakkeet Undecided (tarvitaan lisätietoja), ToDo, In Progress, Verification ja Done. Järjestelmänvalvoja voi muuttaa, mitkä ongelmat näkyvät eri sarakkeissa. Lisäksi järjestelmänvalvoja voi lisätä pikasuodattimia. Loimme muutamia pikasuodattimia eri tiimin jäsenten ongelmille sekä komponenteille, koska Jira ei listaa komponentteja backlog-näkymän vasemmalla puolella. Epicseille ja versioille on omat välilehtensä, joten niiden perusteella on helppo suodattaa ja siirtää ongelmia sprinttiin. Komponenttien olisi pitänyt olla vaihtoehtona epicien alla, kohdistimen kohdalla.

3. Ongelmia valmiissa ratkaisussa? Näin me toimimme.

Teimme migraation importer-lisäosien avulla, mutta menetelmästä riippumatta on aina asioita, jotka on otettava huomioon.

Millaista dataa haluat tuoda?

REST API ei mahdollista kaikkien Jira-tietojen muokkaamista. Esimerkiksi sprintin päättymispäivää ei voi määrittää REST API:n kautta, joten sprintin tilastot menetetään. Tämä onnistuu kuitenkin ScriptRunner-lisäosan avulla. Jos lisäosaa ei ole järjestelmässäsi, sinun on pärjättävä ilman sitä.

Kommentit voidaan tuoda ilman oikeaa käyttäjää

Kun tuonti tehdään lisäosatyökalulla, kyseisten projektien käyttäjät tuodaan mukana. Jos käyttäjä on kirjoittanut kommentin, Jira kohdistaa sen oikein. Jos käyttäjää ei kuitenkaan tuoda jonkin ongelman vuoksi – todennäköisesti siksi, että käyttäjä on deaktivoitu – kommentin tekijäksi merkitään henkilö, joka suorittaa tuonnin Jirassa. Tällaisissa tapauksissa ScriptRunnerista oli apua: sillä kommentti voitiin poistaa ja luoda uudelleen oikealla tekijällä.

Jos ScriptRunner ei ole käytettävissä, importer voidaan ajaa uudelleen sen jälkeen, kun on poistettu ongelmat, joissa kommentin tekijänä on tuonnin suorittanut henkilö. Käyttäjä on luotava manuaalisesti Jiraan samalla käyttäjätunnuksella ennen importerin ajamista uudelleen. Muista, että käyttäjän tulee olla passiivinen ja sähköpostiosoitteena voi käyttää keksittyä osoitetta. Importer käyttää ulkoisen ongelman tunnistetta määrittääkseen, mitkä ongelmat on jo tuotu. Mukautettua kenttää ei voi nimetä uudelleen migraation aikana, koska tällöin luodaan uusi mukautettu kenttä ja kaikki ongelmat tuodaan uudelleen, mikä käytännössä monistaa kaikki tiedot.

Importer-lisäosan virheet

Jirassa alitehtävien kirjatut työtunnit kootaan päästorylle, joten käytetty kokonaisaika on helppo nähdä. Ongelmana oli, että importer ei luonut oikeita linkkejä alitehtäville, mikä vääristi käytetyn ajan laskelmat.

Ratkaisimme ongelman kirjoittamalla pienen Python-skriptin, joka tuotti JSONia linkkien tuomiseksi oikein. Python-skripti näkyy yllä. Tämä Python-funktio lataa Redmine-ongelman kaikentyyppiset suhteet, kuten copied_to-suhteen, joka vastaa Jiran cloners- tai duplicate-suhteita.

Redminen REST API:n rajoitukset

Redmine ei tarjoa REST API:n kautta releasen päivämääriä eikä avattu/suljettu-tilaa. Päivämäärät olivat saatavilla vain verkkosivujen kautta. Kirjoitimme myös pienen Python-skriptin, joka poimi päivämäärät HTML-sivuilta, jotta ne voitiin asettaa REST API:n avulla.

Importer-lisäosat eivät toimi parhaalla mahdollisella tavalla.

Olemme kohdanneet importer-lisäosissa joitakin ongelmia, jotka on nostettu esiin yllä olevassa tekstissä. Useimmille tiimeille tavoitteena oli päästä työskentelemään Jirassa, joten historiallinen data saattoi näkyä hieman eri tavalla kuin migroidussa työkalussa.

Skriptien kirjoittaminen datan poimimiseksi Jira 8.4:stä (ja myös Jira 7:stä) eteenpäin on hyvä investointi, koska niiden avulla datan tuontia on helpompi hallita. Redminessä ei ole Jiran creator- ja reporter-käsitteitä. Ihannetilanteessa kaikilla tuoduilla tiketeillä olisi samat arvot creator- ja reporter-kentissä. Importer kuitenkin asettaa creatoriksi henkilön, joka suorittaa tuonnin. Tästä voi olla hyötyä, sillä näin on helppo tunnistaa, että tiketit ovat peräisin kolmannen osapuolen järjestelmästä.

Tuotujen ongelmien ratkaisupäivämäärät

ScriptRunner sisältää myös toimintoja, esimerkiksi sellaisen, joka korjaa tehtävän ratkaisutilan. Se ei kuitenkaan säilytä ratkaisupäivämäärää ja tukee vain yli 1 000 ongelman joukkotoimintoja kerralla. Ratkaisupäivämäärää tarvitaan erilaisiin tilastoihin ja kaavioihin. Atlassian asettaa 1 000 ongelman rajan, kun joukkokäsittely tehdään käyttöliittymän kautta. Sisäänrakennetun skriptin ratkaisupäivämääräongelma voidaan korjata kirjoittamalla oma skripti. Sellainen löytyy code-utils-repositorystamme.

Useita ulkoisen ongelman tunnisteen mukautettuja kenttiä

Kun tuodaan useita erillisiä projekteja, jokaiselle tuodulle projektille luodaan oma ulkoisen ongelman tunnisteen mukautettu kenttä. Emme olleet täysin tietoisia tästä toiminnasta ennen kuin muutama projekti oli tuotu ja luotu. Useiden ulkoisen ongelman tunnisteen mukautettujen kenttien ongelmana on, että eri projekteissa olevien ongelmien välisiä linkkejä ei luoda.

Yksi mahdollinen ratkaisu on käyttää väliprojektia, johon kaikki Redminen ongelmat tuodaan – mahdollisesti erissä – ja siirtää ne sitten joukkotoimintona uusiin projekteihin. Ratkaisun pitäisi toimia kummallakin ongelmien tuontitavalla.

Kun kaikki on tuotu Jiraan, voit käyttää edellä kuvattua skriptiä eri projekteissa olevien ongelmien välisten linkkien luomiseen. Sillä ei ole merkitystä, vaikka osa linkeistä olisi jo olemassa.

4. Lopputulos ja pohdintoja.

Työnkulun muutokset

Jos vanhoja projekteja tuodaan olemassa olevaan Jira-instanssiin, kannattaa arvioida, miten kahta työkalua on käytetty. Jira määrittää työnkulkujen avulla, miten issueita voidaan siirtää vaiheesta toiseen ja onko niiden käytävä läpi kaikki vaiheet ennen sulkemista.

ScriptRunner

Kuten edellä kuvattiin, ScriptRunner voi auttaa muokkaamaan dataa Jira-tuonnin jälkeen. Sitä pyydettiin alun perin vain tuodun datan jälkikäsittelyyn, mutta siitä oli hyötyä myös työnkulkujen siirtymien ehtojen ja jälkitoimintojen määrittämisessä. Ehtojen ja validaattorien avulla voidaan estää esimerkiksi tilanteet, joissa suljetulla tarinalla on avoimia alitehtäviä. Tämä on yksi ScriptRunnerin mukana toimitettavista skripteistä. Käytettävissä on myös jälkitoimintoina toimivia funktioita, kuten emätarinan sulkeminen, kun kaikki alitehtävät on suljettu. Koska ScriptRunner tarjoaa käyttöön Jiran koko sisäisen plugin API:n eikä vain REST API:a, voit kirjoittaa funktioita, jotka vastaavat täsmälleen työskentelytapojasi.

Harkitse ScriptRunneriin investoimista

Ennen kuin aloitat migraation kolmannen osapuolen työkalusta, kannattaa harkita ScriptRunner-laajennuksen hankkimista, sillä se tarjoaa konsolin kautta käyttöön koko Jiran API:n. REST API:ssa on tiettyjä rajoituksia, esimerkiksi sprinttien osalta kaikkea metadataa ei voi muokata. ScriptRunner on tehokas työkalu tuodun datan jälkikäsittelyyn. Verkosta löytyy runsaasti koodiesimerkkejä, joita voi muokata ja sovittaa omiin tarpeisiin, jos sinulla on ohjelmointikokemusta. Konsoli tarjoaa koodin automaattisen täydennyksen. Työnkuluissa ja jälkikäsittelyssä käyttämämme ScriptRunner-koodiesimerkit ovat avointa lähdekoodia, ja ne löytyvät Praqman code-utils-repositoriosta. Seuraavaa koodiesimerkkiä voidaan käyttää ratkaisemissiirtymän ehtona, jotta avoimia alitehtäviä sisältäviä tarinoita ei suljeta. Adaptavistilla on hyvä ohje mukautettujen ehtojen kirjoittamiseen siirtymälle.

Vaikka et suunnittelisi käyttäväsi skriptikonsolia kuin muutaman kerran, käytettävissä on JQL-funktioita, joita voi hyödyntää issueita haettaessa. Sillä voi myös luoda uusia mukautettuja JQL-funktioita.

Yhteenveto

Migraatioprosessissa päädyimme yksinkertaistamaan nykyisiä työnkulkuja, jotta kaikki tiimit käyttivät samaa työnkulkua.

Tiimit alkoivat hyödyntää täysimääräisesti Atlassianin Scrum-ominaisuuksia, kuten eepoksia ja sprinttejä, Jiran tukeman Scrum-menetelmän mukaisesti.

Jos tekisimme tämän uudelleen, harkitsisimme tuontiplugineja tarkemmin. Ne toimivat kohtuullisen hyvin, mutta vaativat aikaa sellaisten skriptien kirjoittamiseen, joilla varmistetaan, että data on todella tuotu oikein. Ne voivat kuitenkin jättää jälkeensä siivottavaa, mikä voidaan välttää käyttämällä enemmän aikaa datan poiminta- ja muokkausskriptien kirjoittamiseen. Dokumentaatio kuvaa tarkasti, miten kentät yhdistetään, kun käytät tuontityökalua.

Alkuperäinen numerointijärjestelmä eli ulkoinen issue ID on tärkeä muutamasta syystä. Se estää saman issuen tuonnin kahdesti ja toimii linkkinä Jiran ja Redminen välillä. Kun käytössä on vain yksi mukautettu ulkoisen issue ID:n kenttä, myös eri projekteihin kuuluvien issueiden väliset linkit voidaan säilyttää.

ScriptRunner osoittautui erittäin hyödylliseksi sekä siivouksessa että sen mukana toimitettavien JQL-funktioiden ansiosta. Näitä voidaan käyttää taulujen kyselyihin ja issueiden hakemiseen. Lisäksi olemme käyttäneet sitä työnkulkujen muuttamiseen.