Ryhtiä analytiikka-alustan kehitykseen DevOpsilla

Analytiikka-alusta ei tule kerralla valmiiksi vaan vaatii kehittämistä aktiivisen elinkaarensa ajan. Lue, miten kehitystä voidaan tehdä ketterästi DevOps-käytäntöjä hyödyntäen.

Analytiikka-alusta sisältää palveluita ja prosesseja, joilla tallennetaan, siirretään, käsitellään, jaetaan ja analysoidaan dataa. Alusta ei kuitenkaan tule kerralla valmiiksi, vaan sitä kehitetään edelleen käytännössä koko aktiivisen elinkaarensa ajan. Aiemmissa kirjoituksissa olen käsitellyt analytiikka-alustan ja tietovaraston osa-alueita ja kehittämistä, kuten Perinteinen vs. moderni tietovarastointi  ja Mitä liiketoimintapäättäjän tulisi tietää analytiikka-alustasta?  

Kun uuden version julkaisu tuotantoon tulee ajankohtaiseksi, versioiden sisältämät muutokset pitää saada paketoitua ja testattua siten, että julkaisun versio asentuu helposti, se ei tuhoa mitään dataa kohteessa ja sen koodi toimii kohdeympäristössä yhdessä siellä olevan datan kanssa. Versiopäivitys ei saisi vaarantaa tuotantokäyttöä.  

Tämä kaikki ei toimi manuaalisilla ja usein henkilösidonnaisilla villin lännen menetelmillä, vaan vaatii määritellyt kehittämisen, testaamisen ja tuotantoon siirron käytännöt tuekseen. Tämä on sitä tärkeämpää, mitä enemmän kehittäjiä alustan parissa on ja mitä laajempi kokonaisuus on. Analytiikka-alustallakaan ei ole varaa siihen, että kehittäjät noudattavat omia käytäntöjään, vaan siiloutuminen tulee estää yhteisesti hyväksytyillä käytännöillä.

Näin sovellat DevOps-käytäntöjä analytiikka-alustan kehityksessä

DevOps on joukko ketterää kehittämistapaa tukevia käytäntöjä, joiden avulla voidaan automatisoida ja yhdistää käytäntöjä, joilla muutoksia ja tuotoksia siirretään kehityksestä testaukseen ja edelleen tuotantoon. Sovelluskoodi tallennetaan versionhallintaan, jota koko kehitystiimi käyttää. Julkaisut testaukseen tai tuotantoon toteutetaan DevOpsissa automaattisesti tai manuaalisesti käynnistettävinä pipelineina. 

Kun DevOps -käytäntöjä sovelletaan analytiikassa, tietovarastoissa ja muilla dataan perustuvilla sovellusalueilla, pitää huomioida sovelluskoodin ja datan tiukka liitto. Testauksessa ei riitä pelkän koodin testaus vaan se pitää aina yhdistää ko. ympäristön dataan.  

Käytännön toimenpiteenä kaikki kehitystyö ja tuotokset pyritään tallentamaan tiedostoina ja koodina, jota voi versioida. Kaikki kehittäjät käyttävät versionhallintaa. Yksittäinenkin muutos, kuten taulun rakenteen muutos, usein tarkoittaa muutosta monella eri tasolla koko analytiikka-alustalla, jonka vuoksi kaikki osa-alueet tulisi saada versionhallinnan piiriin.  

Analytiikka-alustalla versionhallintaan viedään lähes kaikki muu paitsi data ja dokumentaatio. Sinne viedään integraatioon liittyvät tiedostot, tietokantaobjektit tiedostoina ja raportoinnin tietomallit ja raporttiasettelut. Pilvialustalla myös resurssien ja palveluiden luonti ja hallinta on mahdollista tallentaa konfigurointitiedostoina tai koodina ja viedä versionhallintaan. 

Analytiikka-alustalla pitää olla useampia rinnakkaisia ympäristöjä, yleensä vähintään kehitys, testi ja tuotanto. Koska jokainen ympäristö on erillinen kokonaisuutensa, kaikki ympäristökohtaiset asiat parametroidaan. Näitä ovat mm. osoitteet, resurssien ja palveluiden nimet, tunnustiedot ja avaimet. Tavoite on se, että mitään ei tarvitse manuaalisesti julkaisun aikana lähteä muokkaamaan.  

Lopuksi toteutetaan jatkuvan integraation (CI, continuous integration) ja jatkuvan toimituksen (CD, continuous delivery) paketit, jonka avulla muutokset validoidaan ja julkaistaan haluttuun kohdeympäristöön. Paketti siirtyy ja asentuu kohteeseen tarvittaessa ilman manuaalisia vaiheita. Release pipeline on toistettavissa oleva ja dokumentoitu prosessi, joka suorittamiseen ei tarvita erikoisosaamista.  

DevOpsin käytäntöjen käyttöönotto analytiikka-alustalla on ryhtiliike, joka vaatii kehitys- ja ylläpitotiimiltä yhtenäisten kehitys- ja julkaisukäytäntöjen käyttöönottoa. Koska julkaisu on kohtalaisen yksinkertainen toimenpide, voidaan pienetkin korjaukset viedä hallitusti ja ennustettavasti tuotantoon kehityksen ja testin kautta ilman, että tuotantokäyttö vaaraantuu. Versiopäivityksen ei tule olla sykkeen nostava jännitysnäytelmä, jonka suorittaa asiaan vihkiytynyt erikoisosaaja yön pikkutunneilla vaan aivan normaali ja arkipäiväinen toimenpide.