Migraatioprosessia käytetään uusien tietojärjestelmien tai uusien tietojärjestelmäversioiden käyttöönotossa – vanhan tietojärjestelmän edelleen tärkeät osat viedään osaksi uutta järjestelmää. Käyttöönotto on kriittinen vaihe ohjelmistoprosessissa, sillä hyvänkin kehitystyön tulos saadaan näyttämään huonolta epäonnistuneen käyttöönoton myötä.
Pahimmillaan koko käyttöönotto epäonnistuu tai sitä joudutaan siirtämään. Juuri tästä syystä ohjelmistokehityksessä on pidemmän aikaa pyritty siirtymään jatkuvaan jakeluun (Continuous Delivery), jonka tarkoituksena on harjoitella jokaista prosessin vaihetta jatkuvasti. Tällöin viimeinenkin – kriittinen – käyttöönottovaihe tulee varmaksi suoritukseksi.
Ohjelmiston jakelussa, integraatiovaiheessa käännetyt ja yhteen pakettiin kerätyt tiedostot julkaistaan suoritusympäristöönsä. Staattisen paketin jakelu on verrattain nopeaa, eikä se aiheuta monimutkaisissakaan palvelinympäristöissä pitkiä käyttökatkoksia. Jakelun automatisointi on toivottavaa, sillä inhimillisiä jakeluvirheitä voidaan minimoida jatkuvalla automatisoidun prosessin kehityksellä. Jakelu voidaan tuoda osaksi jatkuvaa integraatiota (Continuous Integration).
Jakelu + automaatio = ongelma?
Automaattista jakelua pelätään helposti, koska sen jälkeen havaitaan usein ongelmia. Ongelmat ovat harvoin osa jakelua, vaan liittyvät muihin käyttöönottovaiheisiin. Jakelun yhteydessä julkaistaan tietoa, jota aiemmin kehitysprosessissa toimivaksi todettu toiminnallisuus käyttää. Yleensä tämä tarkoittaa dynaamisten tietokantojen, palvelurajapintojen tai staattisten tiedostojen käyttöönottoa.
Rajapinta, mallit ja tietueiden merkitykset
Kaikella tiedolla on sovittu malli eli rajapinta, jolla ohjelmisto tuntee tiedon. Malli on usein tuotu osaksi ohjelmiston versiointia jo kehitysvaiheessa, jolloin oikean version julkaisu kulkee ohjelmiston mukana ongelmitta. Mallin takana on kuitenkin siihen sovitettu tieto, joka voi poiketa kehitysvaiheessa käytetystä: yleensä määrän, mutta pahimmillaan myös sisällön ja merkitysten osalta. Tähän on syynä tiedon versioimattomuus: mallin käyttämät tietokantamallit (Database Schemas), mallin kuvaamat tietueiden merkitykset (Data Descriptions) tai kuvausten väärinkäyttö esim. palvelurajapinnan toimesta. Jakelu ei siis ollutkaan aiemmin testattu kokonaisuus, vaan viime hetkellä integroitu uusi järjestelmä. Tästä syystä koko jaeltavaa järjestelmää tulisi käsitellä eheänä versiona, jonka julkaisua voidaan harjoitella.
Jokainen tietomalleihin tai niiden käyttöön liittyvä muutos voi siis aikaansaada migraatiotarpeen, myös kesken järjestelmäversion kehityksen. Migraatio onkin tuotava jatkuvaksi osaksi ohjelmistokehitystä, jotta siihen liittyvät tuotokset kyetään verifioimaan jatkuvan jakelun yhteydessä.
Tiedon ja toiminnallisuuden migraatio
Kehittäjien toteuttaman toiminnallisuuden julkaisua ei usein haluta tai voida hidastaa, jotta jatkuvan jakelun verifiointi onnistuu. Käytännössä kaikki jakeluun liittyvä migraatio on sitä hitaampaa, mitä enemmän tietoa järjestelmään liittyy. Mallin uusiminen nopeasti on mahdollista vain, jos sitä laajennetaan, ilman muiden osien käyttöönottamatta laajennuksia. Mikäli kehittäjä tai toteutus käyttöönottaa laajennuksia, täytyy infrastruktuurin ja tiedon muuttua mukana, jotta yhtenäinen versio säilytetään. Vastaavasti infrastruktuurin tai tiedon muuttuessa, täytyy kehittäjien ja toteutuksen seurata. Tiedon ja toiminnallisuuden migraatioita kehitetään tyypillisesti erillään, eikä niitä käyttöönoteta ennen molempien valmistumista. Tästä johtuen muutosten on hyvä pysyä pieninä, jotta jakelu on edelleen jatkuvaa. Toteutusten valmistuttua voitaan toteutus käyttöönottaa nopeasti, mutta suurten tietomäärien migraatio on hidasta, jolloin jatkuva verifiointi on jälleen vaarassa.
Kolme ratkaisumallia
Jatkuvan jakelun takaamiseksi voidaan harkita kolmea eri ratkaisumallia: osittainen tietosisältö, kehityksen haarautuminen tai hybridiversiot. Kaikki nämä ratkaisumallit tarvitsevat myös tietomallimigraation, johon voidaan soveltaa työkaluja kuten Flyaway ja Liquibase.
Osittainen tietosisältö on selkeä ratkaisumalli, sillä sen valmistuminen hyvin on ennakoitavaa, eikä se sisällä toisten migraatioversioiden tietoja. Ongelma on, ettei kaikkea tietoa ole verifioitavissa. Usein verifiointi onkin tällöin mahdotonta, jos migroitua tietosisältöä ei onnistuttu ennakoimaan hyvin verifiointiin sopivaksi. Lisäksi tämä jakelu sellaisenaan kelvoton tuotantokäyttöön, koska sen sisältö on vaillinainen.
Kehityksen haarautuminen on mahdollinen ratkaisu, jos migraation verifiointi ei ole kriittistä tai on muita sitä kriittisempiä vaiheita. Ongelmana on tietomallin erkaantuminen toiminnallisuudesta, josta seuraa riskialttiita väliaikaisratkaisuja. Kun kokonainen jakelu vihdoin voidaan jaella, väliaikaisratkaisujen ja kehityshaarojen yhteenliittäminen aiheuttaa uusia riskejä ja hitautta. Tämä jakelu on kelvollinen tuotantoon, mikäli verifiointi onnistuu.
Hybridiversiot aiheutuvat ratkaisuista, jossa jakelu ja käyttöönotto tehdään välittömästi ilman kokonaista tietosisältöä, jota kasvatetaan jakelun vanhetessa. Ongelma on, ettei täyden jakelun valmistuminen ole hyvin ennakoitavissa ja verifiointi voi joutua odottamaan tarpeellista tietosisältöä. Lisähaasteena on rinnakkainen käyttö ja tietomigraatio, joka tuo mukanaan teknisiä haasteita, kuten transaktiohallinnan ja hakuindeksoinnin. Tämä jakelu on valmistuttuaan kelvollinen tuotantoon, mikäli verifiointi onnistuu.
Yhteenvetona voidaan todeta:
- Jatkuva migraatio tähtää eheiden läpi-arkkitehtuurin-jakeluiden verifiointiin.
- Suurin este jatkuvalle migraatiolle on siihen kuluva aika, joka hidastaa jatkuvaa jakelua.
- Jatkuvaan migraatioon ei ole yhtä oikeaa ratkaisumallia, vaan ratkaisumalli on valittava hetkeen sopivaksi.
- Jatkuva määrittely- ja hallintotyö on tarpeen ratkaisumallien verifiointiin ja valintaan, jossa voidaan hyödyntää työkaluja kuten Pentaho.
- Ratkaisumallin valinta on aina kompromissi projektinjohtamisen ja teknologian välillä.
- Kokonaiseen tietosisältöön tähtäävät ratkaisumallit tulisi pitää etusijalla, sillä sama jakelu voidaan siirtää pienin riskein tuotantokäyttöön.
- Jatkuva migraatio on eteenpäin tähtäävä prosessi, joka ei ota kantaa vanhojen versioiden jakeluun, jonka johdosta on suositeltavaa valita uusia suuntia kuin palata takaisin.
