Ohjelmistokehitykseen tueksi on tarjolla useita erilaisia työkaluja tiimin sisäiseen työnjakoon. Suosituin niistä on Jira, mutta käytössä on toki muitakin, esim. avoimen lähdekoodin Trac tai Microsoftin Team Foundation Server (TFS). Aika ajoin saamme yhteydenottoja asiakkailta, jotka haluavat ottaa käyttöön Jiran ja siirtää muista järjestelmistään tiedot sinne. Tässä blogipostauksessa käyn läpi, miten siirtymä käy Tracin osalta.

Jira itsessään sisältää toiminnallisuudet migraatioihin yleisimmin käytetyistä järjestelmistä. Tracista saadaan siirrettyä lähes kaikki sen sisältämät tiedot suhteellisen helposti. Sinällään se ei ole ihme, koska Tracin tietomalli on yksinkertainen ja sisältää lähes samat perustiedot tiketistä kuin Jirakin. Esim. tiketin tyyppi-, tila-, prioriteetti- ja ratkaisutiedot avainsanojen lisäksi ovat yleisesti käytettyjä ja esiintyvät lähes joka tiketinhallintajärjestelmissä. Lisäksi molemmissa järjestelmissä tikettejä voidaan kategorisoida komponenttien ja julkaisuversioiden mukaan.

Siirtymän kompastuskiviä

Kuten monissa muissakin asioissa, yksityiskohdissa piilevät kompastuskivet aiheuttavat mutkia matkaan. Siirtymä Tracista Jiraan ei suju nappia painamalla, vaikka dokumentaatiota seuraten vastaavuudet Tracin ja Jiran tietokenttien välillä olisi mietitty ennalta valmiiksi. Jiran itsessään tarjoamassa migraatio-opastuksessa tai dokumentaatiossa ei ole mitään vikaa, ne ovat päinvastoin hyvin kattavat ja helposti seurattavia.

Migraation alussa Jiraan ladataan Tracin ympäristöstä tehty zip-tiedosto, joka sisältää myös määrittelyt Tracin tietokantayhteydelle. Latauksen jälkeen migraatio käynnistyy – ja hajoaa. Mikäli Tracissa tiketin vastuuhenkilöksi tai raportoijaksi on merkitty useampi henkilö, Jira ei osaa käsitellä niitä oikein. Tracin tietokannasta pitää siis poistaa kaikki ”ylimääräiset” raportoijat ja vastuuhenkilöt, jotta tiketit saa ylipäätään siirrettyä. Sen jälkeen siirto voidaan käynnistää uudelleen ja nyt siirron pitäisi valmistua ilman vakavia virheilmoituksia. Kun siirrettyjä tikettejä sitten katsoo tarkemmin, huomaa epäjohdonmukaisuuksia: tiketeille, joille ei ole määritelty vastuuhenkilöä, Jira luo anonymous-käyttäjän ja merkitsee vastuuhenkilöksi tämän. Toisaalta tiketeille, joilla ei ole Tracissa raportoijaa, raportoija-kenttä jää tyhjäksi. Lisäksi komponenttien vetäjäksi merkitään ”anonymous”, vaikka kentän sisältö voisi hyvin olla sen sijaan tyhjä.

Nämä ovat toki pieniä virheitä, mutta yllättävää on se, ettei virheitä ole korjattu, vaikka ne ovat vuoden vanhoja (1 ja 2). Tyypillistä Atlassianin tuotteissa onkin, että joitakin asioita ei korjata ellei käyttäjäkunta ole tarpeeksi äänekäs (esim. syötettäessä tikettiin sprinttitietoa, Jira ehdottaa edelleen sprinttejä koko Jiran laajuudelta, vaikka siihen on toivottu muutosta jo kolme vuotta). Tai sitten käy niin, että joku kolmas osapuoli ehtii tehdä lisäosan, joka toteuttaa tarpeellisen toiminnallisuuden tuotteeseen ja jonka luulisi tulevan osaksi varsinaista tuotetta (esimerkkinä vaikkapa Confluencelle mukautettavan ulkoasun mahdollistava RefinedTheme), mutta näin ei kuitenkaan käy.

Entä sprintit?

Tracissa milestone-kenttää voi käyttää monella tavalla, mutta yksi yleinen tapa ketterässä kehityksessä on säilyttää kentässä tietoa sprintistä. Mikäli sprinttitiedot halutaan siirtää Jiraan, ei Jira tarjoa toiminnallisuutta siihen. Käytännössä tämä vaihe on työläin vaihe migraatiossa. Milestone-tiedot on vietävä ulos Tracin kannasta, jonka jälkeen tietoja voi käyttää sprinttien luomiseen Jirassa esim. REST-rajapinnan avulla. Sprinttien luomisen jälkeen niihin tiketteihin, joissa on sprinttiä vastaava milestone, merkitään tieto sprintistä. Luodut sprintit jäävät kuitenkin oletuksena future-tilaan. Siirtymää varten vanhat sprintit halutaan luonnollisesti sulkea. Jotta vanhat sprintit voidaan sulkea, on ne ensin asetettava aktiiviseen tilaan ja vasta sitten suljettava. Huomattakoon että Jira asettaa sprintin valmistumisajankohdaksi automaattisesti senhetkisen ajan, mikä lienee järkevää myös korjata. Tämä on tehtävä suoraan tietokantaan ja vaatii Jiran uudelleenkäynnistyksen.

Loppu hyvin kaikki hyvin

Operaatioon kannattaa varata riittävästi aikaa, mutta helpoin tapa on ottaa avuksi osaava kumppani, joka tuntee tuotteet sekä niiden puutteet.

Pieniä kompastuskiviä ja työtä siis riittää, jotta haluttu tieto saadaan siis siirrettyä onnistuneesti Tracista Jiraan. Operaatioon kannattaa varata riittävästi aikaa, mutta helpoin tapa on ottaa avuksi tässäkin tapauksessa osaava kumppani, joka tuntee tuotteet sekä niiden puutteet.

PS. Kun migraatio on sitten ohi, saattaa Jiran puolelta huomata useamman samannimisen External issue id -kentän, jonka Jira on luonut siirron yhteydessä. Jos olet kokeillut siirtoa useamman kerran, Jira on luonut jokaisella kerralla uudet External issue id -kentät.

PPS. Tästäkin on ollut auki tiketti pari vuotta.