DevOps (automatisoidut IT-palvelut) tarjoaa monia hyötyjä järjestelmäprojekteissa, mutta kiteyttäen se varmistaa, että uusia toiminnallisuuksia saadaan tuotantoon nopeasti niin kehitys- kuin ylläpitovaiheessa. Malli säästää ennen kaikkea liiketoiminnan aikaa. Keskustelimme asiantuntijoidemme, Janne Takalan ja Jussi Kauhasen, kanssa DevOpsin hyödyistä.
Ketterästi kehittäen
– DevOpsin tärkein hyöty on ketteryys ja nopeus, jota se tarjoaa. Siinä ei ole perinteistä byrokratiaa, jossa kehittäjät kehittävät toiminnallisuuksia, minkä jälkeen ne menevät jonkin putken kautta jollekulle, joka varmistaa laadun. Mallissa samat henkilöt kehittävät ja asentavat toiminnallisuuksia, ja parhaimmillaan asiat toimivat nappia painamalla ja niihin voidaan reagoida nopeasti, kertoo Jussi.
Asiakkaan näkökulmasta DevOps mahdollistaa uusien toiminnallisuuksien tehokkaan tuomisen testaukseen tai ylläpitovaiheessa tuotantoon.
– Tuotantoon voidaan päivittää jatkuvasti virheenkorjauksia tai tuoda uusia toiminnallisuuksia eikä siinä mene kuukausia tai pahimmissa tapauksissa useita vuosia. Kehitysprojektissa asiakkaalle saadaan ensimmäinen demo julkaistua jo muutamassa viikossa, jatkaa Janne.
Pipeline pilvessä: enemmän automatisaatiota, vähemmän virheitä
Pilvi mahdollistaa ympäristöjen automaattisen perustamisen. Esimerkiksi uusi testiympäristö saadaan käyttöön minuuteissa ilman fyysisiä asennuksia. Eteneminen on flow-tyyppistä, julkaisuja tehdään jatkuvasti automatisoituna. Kun päivitykset tuotantoon tehdään automaattisesti, minimoidaan samalla virheet.
– Laatu voidaan varmistaa monin keinoin, mutta se myös maksaa. Automaattitestauksen avulla hoidamme asioita, jotka olisivat muuten testaajan työlistalla. Tämä tuo myös työhön mielekkyyttä, kun samoja regressiotestejä ei tehdä käsin uudelleen ja uudelleen, sanoo Jussi.
Laadukasta koodia
DevOps tarkoittaa myös automatisoitua julkaisuputkea kehittäjän työpöydältä tuotantoon. Kun tiimissä tehdään koodiin muutoksia, tehdään julkaisuputkessa aina koodikatselmointi ja staattinen analyysi sekä ajetaan yksikkötestit.
– Kehittäjän tekemät muutokset katselmoidaan aina vähintään kahden muun kehittäjän toimesta, minkä jälkeen ne viedään testiympäristöön ja ajetaan integraatiotestit. Vasta tämän jälkeen muutokset julkaistaan eteenpäin, selventää Janne.
– Ajamme samat testit kaikissa ympäristöissä. ”Putki” ohjaa työtä ja koko prosessi on pitkälle automatisoitu, minkä avulla inhimilliset virheet voidaan välttää. Meillä on työkalut automaattiseen laadunvarmistukseen ja automaattitestit käytössä. Pysymme koko ajan kartalla siitä mikä toimii, ja että kaikki toimii oikein. Asiakkaan liiketoimintaosaajien aikaa ei tarvitse käyttää testaukseen, sillä automaattitestaus estää regressiot, summaa Jussi.
Paraneeko vaihtamalla? Jos sen tekee harkitun vertailun ja asiaansa palvelevan kriteeristön mukaan, niin kyllä. Tämän huomasivat Profit Loans & Collaterals -tiimissä nykyaikaista antolainausratkaisua yritysrahoituksen tarpeisiin kehittävät koodarit. Tärkeä osa kehitystyötä on ratkaisun käyttöliittymän end-to-end-testaaminen, jota tehdään omassa testausympäristössään. Tiimissä kaikki kehittäjät ovat moniosaajia, jotka tekevät joustavasti kaikkia kehitysvaiheen eri tehtäviä, joten myös testaaminen kuuluu jokaisen pöydälle.
— Testausautomaatioon olemme aiemmin käyttäneet Robot Frameworkia, joka ajaa automaattisia robottitestejä. Huomasimme kuitenkin, että testit hajoilivat satunnaisesti. Kun jokainen kehittäjä sitten joutuu painimaan testien selvittelyiden kanssa vuoron perään, tähän menee aika paljon aikaa, kertoo kehittäjänä työskentelevä Timi Voutilainen.
Tiimin kehittämän ratkaisun vaatima testimassa on suuri, koska testattavia ominaisuuksia on paljon. Yhden testiajon ajamiseen kuluu aikaa keskimäärin 40–60 minuuttia. Kahden vuoden aikana tiimissä on ajettu automaatiotestejä yli 5000 kertaa. Kun testimäärät ovat suuret ja niihin kuluu aikaa, on tärkeää, että testit ovat luotettavia.
Uutta työkalua lähdettiin etsimään tunnettujen ja laajasti käytössä olevien ratkaisuiden kautta. Testien luotettavuus oli tärkein kriteeri. Robot Frameworkin kanssa toimittaessa onnistumisprosentti saattoi olla mitä vain 90 ja 97 prosentin välillä – tämän luvun oli noustava. Toinen kriteeri oli se, että testaustyökalun käyttö olisi mahdollista TypeScriptillä, jota käyttöliittymätoteutuksessa käytetään – tämä helpottaa kehittäjän työtä, kun testaustyökalua varten ei tarvitse vaihtaa käytettävää kieltä toiseen.
Myös se painoi vaakakupissa, että testaustyökalun ominaisuudet ovat monipuoliset ja mahdollistavat esimerkiksi ongelmatilanteiden imitoinnin siten, että testaaja näkee, mitä http-kutsuja käyttöliittymältä lähtee. Niin ikään tyypitetyn kielen käyttö, esimerkiksi rajapintatyypitykset, olivat kriteeri bugien vähentämiseksi.
— Päädyimme lopulta Cypressiin, joka on suosittu testaustyökalu maailmalla. Huomasimme nopeasti, että se täyttää kriteerimme ja tarpeemme, ja näin ollen helpottaa ja nopeuttaa kehitystyötä, Timi kertoo.
— Se, että voimme tehdä testejä samalla kielellä, jolla työskentelemme muunkin kehityksen parissa, auttaa selkeän arkkitehtuurin rakentamisessa ja ylipäätään sujuvoittaa tekemistä, Timi jatkaa.
Cypressin monipuoliset ominaisuudet mahdollistavat esimerkiksi paremmat debuggaus-ominaisuudet, jokaisen vaiheen yksityiskohtaisen erittelyn käyttöliittymältä ja jopa suoran tuen videolle ongelmatilanteiden eri vaiheiden selvittämiseksi, mikä ei aina pelkkää kuvaa katsomalla ole niin yksiselitteistä.
— Virheiden löytäminen on Cypressissä ylipäätään helpompaa, Timi toteaa.
— Tulokset, joita testien ajo tuottaa, osoittaa meille hyödyn työkalun vaihdosta. Lisäarvo asiakkaalle on laadukas tuote, joka toimii luotettavasti.
Lue myös muita blogejamme Profit Loans & Collaterals -tiimin työskentelystä:
https://profitsoftware.com/sovellusarkkitehti-jussi-profit-softwarella-kehittajat-jotka-kehittavat-omaa-tekemistaan-eivat-voi-muuta-kuin-onnistua/
https://profitsoftware.com/hyvat-sprinttirutiinit-helpottavat-projektissa-aloittamista/
https://profitsoftware.com/devaajan-paiva/
Järjestelmäprojekti vaatii onnistuakseen jatkuvaa testausta. Sprinteissä kehitettävässä projektissa toiminnallisuuksia testataan sitä mukaa, kun toteutus etenee. Käytännössä lähes kaikki testit ovat automatisoituja ja tiimin on helppo havaita tilanteet, joissa uusi toiminnallisuus rikkoisi jotakin toimivaa.
Toimimme luottamusbisneksessä. Lähtökohtaisesti se tarkoittaa, että lähes kaikissa projekteissa toimimme tahojen kanssa, jotka noudattavat omassa toiminnassaan tietosuojaan liittyviä lakeja ja velvoitteita, esimerkiksi pankkisalaisuutta*. Pankkisalaisuus tarkoittaa, että kaikki asiakasta koskevat tiedot ovat luottamuksellisia.
Miten luottamus ja testaus liittyvät toisiinsa?
Testidatan pseudoanonymisointi käytännössä
Testaukseen tarvitaan testiaineistoa ja paras testiaineisto olisi tuotantoympäristön oikea data. Sitä ei kuitenkaan voida jakaa testaukseen, sillä tieto on salassa pidettävää eli tiedonkäsittelyyn vaikuttaa aina rooli – kenen on oleellista käsitellä dataa. Data tulee siis pseudoanonymisoida** ennen kuin sitä aletaan testaamaan. Miten tämä käytännössä tehdään?
-Oikeita nimiä tai henkilötunnuksia ei saa olla, mutta voimme käyttää nimi- ja osoiteyhdistelmää, joka pysyy aina samana. Pääperiaatteina ovat yksisuuntaisuus ja toistettavuus. Toistettavuus on sitä, että nimi tulee joka kerta samanlaisena (esim. Yritys X on joka testikerralla Yritys A). Yksisuuntaisuus taas viittaa siihen, ettei testaajan ole mahdollista päätellä Yritys A:n oikeaa nimeä, kertoo Profit Softwaren kehittäjä Henrika Hannula.
Testidata pitää siis nimetä. Mieluiten loogisesti, sillä kehitysympäristössä voi olla niin asiakkaan liiketoiminnan asiantuntijoita kuin Profit Softwaren kehittäjiä. Miten data nimettiin Valtiokonttorin vakuushallintaprojektissa?
-Lähdin testausaineiston nimeämisessä siitä, että tarvitsen 100 etunimeä, 100 sukunimeä, 100 paikannimeä ja 100 toimialaa. Innoittajina toimivat esimerkiksi julkisuudesta tutut henkilöt. Lieksan Ananasfarmi Oy, Ylihärmän Kasvihotelli Oy tai Frida Lipsanen ovat esimerkkejä keksimistäni yhdistelmistä, sanoo Hannula.
Moniulotteisen järjestelmän testauksessa on useita eri tasoja, yksikkötesteistä kokonaisuuden testaukseen. Projektissa kehittäjät ovat vastanneet myös testauksesta. Näin pystytään toimimaan, sillä Profit Softwaren liiketoimintaymmärrys finanssialasta on erittäin hyvä. Laadusta ja lopputuloksesta on Valtiokonttorin projektissa vastannut koko tiimi.
Haluatko lukea projektista lisää? Tutustu:
Profit Software teki minkä lupasi – Valtiokonttorin vakuushallinta reaaliaikaan
Case Valtiokonttori: Uuden vakuushallintajärjestelmän kehitys ketterin menetelmin
