Toteutimme Hankenin datamigraation osa 1: Laatuvaatimuksista kohti toimintaa

Alkuvuodesta tuoteomistajamme Eeva kertoi Hankenin Oodi–Sisu-migraatioiden olevan yhden kehitystiimimme tärkeintä hommaa. Hankenin datamigraatio olikin ensimmäinen, jonka toteutimme asiakaskorkeakoulullemme. Hanken otti Sisun onnistuneesti käyttöön helmikuussa, ja migraatiotyö on jatkunut myös käyttöönoton jälkeen. Käymme seuraavaksi läpi migraation perusperiaatteita ja hyötyjä.

Funidatan toteuttaman datamigraation edut

Yksi toteuttamamme datamigraation eduista oli ehdottomasti se, että meillä oli käytössä useita työkaluja, joita muiden korkeakoulujen migraatioprojekteilla ei ollut. Pystyimme esimerkiksi kehittämään migraatioita paikalliseen Sisu-instanssiin, jolloin meillä oli yksinkertainen tapa validoida migraation tuloksia. Meidän oli tarvittaessa mahdollista palata migraatiota edeltävään pisteeseen ja testata muutosten jälkeen uudestaan. Samalla pystyimme tarkistamaan validaatioita ja mahdollisia virheitä migroidussa datassa suoraan Sisun logeista ja lähdekoodista.

Toinen etu oli, että me tunnemme Sisun ja sen tietorakenteen valmiiksi. Tällöin meidän oli sisäistettävä ainoastaan lähdejärjestelmän tietomalli ja miten se saadaan sovellettua Sisun tietorakenteeseen sopivaksi. Porukastamme löytyy myös ihmisiä, jotka ovat työskennelleet lähdejärjestelmän kanssa ja tuntevat sen tietokantamallin, mikä teki migroitavan datan löytämisestä jouhevampaa.

Ohjelmistotuotannon perusta

Hoidimme migraation täysin Sisun rajapintoja hyödyntäen ja edellisten migraatioiden päälle rakentaen. Suunnittelimme migraatiota yhdessä Hankenin kanssa, jolloin heidän toiveensa oli helpompi kirjoittaa tekniseen speksaukseen. Samalla saimme kiinni virheitä ennen kuin suunnitelmia siirrettiin toteutukseen.

Noudatimme seuraavia ohjelmistotuotannon käytäntöjä, joiden avulla olemme ylläpitäneet migraatioiden laatua:

• Toteutukseen siirtyvät tehtävät vastaavat DEEP-määritelmää (Detailed appropriately, Estimated, Emergent, Prioritized)
• Backlogia huolletaan ja ylläpidetään aktiivisesti nykyisen tiedon perusteella
• Migraatiot testataan automaattisin testein
• Toinen kehittäjä vertaiskatselmoi ja testaa migraatiokoodin
• Kaikki kehittäminen tapahtuu asiakkaan kanssa sovitussa järjestyksessä versionhallintaa hyödyntäen

Jokaisella kehittäjällämme on käytössä identtinen lokaali ympäristö, joka on rakennettu peilaamaan asiakkaan ympäristöjä. Tämä tarkoittaa Dockerilla pystytettyä tietokantaa, josta löytyy asiakkaan sekoitettu data, Sisu sekä mockattu AWS S3. Suunnittelimme, dokumentoimme ja testasimme migraatiot erikseen, jolloin ne eivät ole yhden ihmisen tiedon takana. Testeillä voimme todistaa, että migraatiot ovat toistettavia ja ettei mikään muutos ole rikkonut olemassa olevia migraatioita.

Modulaarisuus ja lähtödatan validointi

Migraatiot toteutettiin modulaarisella sovelluskoodilla ohjelmistotuotantomallin mukaisesti, joka on mahdollistanut koodin uusiokäytön. Jaettu lähdekoodi mahdollistaa uusien migraatioiden kirjoittamisen nopeasti, koska moni migraatio rakentaa olemassa olevien palasten päälle. Modulaarista toteutusta on helppo ylläpitää ja tarvittaessa korjata. Migraation toteutustavan ansiosta olemme voineet rakentaa lähdejärjestelmän datan automaattisia validointeja. Näin olemme saaneet datasta kiinni virheitä ja Hanken on voinut korjata niitä, jotta migraation lopputulos olisi halutunlainen.

Migraatioiden deterministisyys

Olemme pitäneet vahvasti kiinni periaatteesta, että Sisuun siirretyn datan on oltava sellaisessa muodossa, että sen vastaava data on tunnistettavissa lähdejärjestelmästä esimerkiksi sisällyttämällä lähdejärjestelmän ID-kenttä Sisuun luotavaan ID-kenttään. On tärkeää, että jokainen Sisuun generoitu ID-kenttä on sama riippumatta lähdedatan määrästä, muutoksista tai siitä, milloin ja mihin Sisun instanssiin dataa migroidaan. Olemme voineet esimerkiksi hyödyntää Hankenin raportoimia tuotannon ID:itä päästäksemme staging-ympäristössä käsiksi tuotantoympäristössä ilmenneisiin ongelmiin.

Luotettavuus ja läpinäkyvyys

Meidän on yksinkertaista seurata migraatioon tehtyjen muutosten vaikutuksia dataan, sillä jokainen migraatiokokonaisuus sisältää kattavan logituksen ja analytiikan. Tiedämme esimerkiksi, kuinka monta uutta opiskeluoikeutta on syntynyt jokaisesta migraation ajosta ja jos edelliseen ajoon verrattuna jokin opiskeluoikeus ei enää muodostu. Tiedämme myöskin, mistä lähdejärjestelmän tietokantariveistä jokainen opiskeluoikeus koostuu.

Ennen masterin vaihtoa ideologiamme oli, että Hankenin määrittelemien tietueiden osalta lähdejärjestelmän muutokset korvaavat Sisussa tehdyt muutokset. Kun Hanken otti Sisun käyttöön master-järjestelmänään, muutimme migraation toimintamallia osittain: Sisussa tehdyt muutokset huomioidaan, ja siksi muokataan ainoastaan sellaisia tietueita, joissa edellinen muokkaaja on migraation integraatiotunnus. Näin master-järjestelmän integriteetti säilyy, mutta voimme edelleen täydentää Sisuun sellaista edellisen järjestelmään dataa, jota ei ole aiemmin migroitu.

Adaptiivisuus ja tietoturva

Ennen masterin vaihtoa noudatimme eräänlaista continuous release -mallia, joka mahdollisti joustavan käyttöönottomallin asiakkaalle. Hanken pystyi pyytämään meiltä muutoksia tai vaihtaa asioiden prioriteetteja, jolloin toimitimme nopeasti juuri sitä, mitä Hankenilta oli toivottu. Kun uusi migraatio oli toteutettu, pystyimme viemään sen erikseen testi- ja demoympäristöihin ja tuotantoon sitten, kun asiakas oli sen testannut.

Olemme huomioineet henkilödatan käsittelyyn liittyviä rajoitteita ja tietoturvaseikkoja käsitellessämme asiakkaan dataa. Olemme esimerkiksi sekoittaneet lokaalikehityksessä olevan datan sellaiselle tasolle, että opiskelijan tunnistaminen on mahdotonta ilman pääsyä alkuperäiseen dataan. Olemme huolehtineet migraatioputken sisäisesti siitä, että datan liikkuminen verkossa on kryptattua ja datan tallennus on toteutettu kryptattuun AWS-ympäristöön. Ainoastaan niillä henkilöillä, joiden tulee virhetilanteissa päästä tutkimaan sekoittamatonta dataa vaikkapa asiakkaan pyynnöstä, on pääsy siihen.

Kerromme tarkemmin Hankenin datamigraation teknisestä toteutuksesta tässä blogikirjoituksessamme.