Viime viikolla kerroimme SoMe postauksessa Canary testauksesta ja siitä, miten hiilikaivosmiehet käyttivät Kanarialintuja testatakseen kaivoksen myrkkykaasujen tasoa. Kanarialintu päästettiin kaivokseen ja jos se kuoli, kaivosmiehet tiesivät, että kaivoksen myrkkykaasut ovat nousseet vaaralliselle tasolle. Nykyajan Canary testaus (Canary testing) ei ole ihan näin radikaalia. Nykypäivän testauksessa Canary testaus antaa testaajalle aikaisen varoituksen, jos jokin on menossa pieleen. Oheisessa blogissa avaamme aihetta hieman enemmän.
Canary Deployment/Release on julkaisuprosessi, jossa hyödynnetään Canary testausta osana päätelmää oliko julkaisu hyvä tai huono. Canary testauksen pyrkimyksenä on vähentää riskiä ja validoida uusi ohjelmisto julkaisemalla se pienelle osalle käyttäjiä.
Ohjelmistotestauksessa Canary testauksen ideana on siis julkaista ohjelmointikoodimuutoksia pienelle ryhmälle loppukäyttäjiä, jotka eivät yleensä tiedä saavansa uutta koodia, poikkeuksena erilaiset betajulkaisut. Vain pienelle käyttäjämäärälle julkaistaessa, Canary testauksen vaikutus on suhteellisen pieni ja muutokset voidaan peruuttaa nopeasti, jos uusi koodi osoittautuu olevan täynnä bugeja. Canary testaus siis mahdollistaa uuden koodin tai ominaisuuksien julkaisemisen pienelle käyttäjien alaryhmälle, jotta kehitystiimi voi monitoroinnin avulla tarkistaa, toimiiko koodi virheettä tai halutulla tavalla, ennen kuin ne julkaistaan suuremmalle yleisölle. Rajoittamalla uuden ominaisuuden vain tietylle yleisölle, kehitystiimit voivat vahvistaa toiminnallisuuden ja suorituskyvyn ennen käyttöönottoa kaikille käyttäjille.
Kun ohjelmistotestauksessa tehdään lisäkoodimuutoksia Canary testausta apuna käyttäen, se antaa kehitystiimille mahdollisuuden nopeasti arvioida, tuottaako koodin julkaisu halutun tuloksen. Canary testit, jotka ovat usein automatisoituja, suoritetaan sen jälkeen, kun testaus on suoritettu hiekkalaatikkoympäristössä. Toinen syy tehdä Canary testejä on se, että usein ympäristöt, joissa kehitystä tehdään eivät täsmälleen vastaa tuotantoympäristöjä ja testaamalla pienen prosenttiosuuden tuotannon käyttäjistä (usein kutsutaan tuotannon testaukseksi) voi havaita ongelmia, joita ei ehkä löydy lavastus- tai kehitysympäristöissä.
Kuinka Canary testausta tehdään?
Canary testejä voidaan tehdä käyttämällä BlueGreenDeploymentia liikenteen jakamiseen palvelintasolla, jotta liikenne siirtyy hitaasti sovelluksen yhdestä versiosta uudempaan sovelluksen versioon käyttämällä palvelintason liikennereititintä.
BlueGreenDeploymentia käytettäessä liikennettä voidaan jakaa sovellusversion mukaan tai se voidaan tehdä yksityiskohtaisemmin ominaisuustasolla käyttämällä ominaisuuslippuja, jotta tietty prosenttiosuus loppukäyttäjiä saataisiin käyttökokemuksen uuteen versioon.
Canary testaus ja Feature flagit
Canary testaus voidaan tehdä käyttämällä Feature flageja, joiden avulla ryhmät voivat erottaa koodin vapautuksen ominaisuuksien käyttöönotosta ja kytkeä ominaisuudet päälle ja pois päältä etänä tietyille ryhmille, käyttäjien prosenttiosuuksille tai kaikille käyttäjille. Feature flageja käyttämällä tiimit voivat rajoittaa julkaisun vain 1 prosenttiin käyttäjistä, seurata tärkeimpiä mittareita, kuten virhetasoja, viiveitä ja liiketoimintatietoja, jotta uudella ominaisuudella ei ole kielteisiä vaikutuksia.
Jos Canary testi havaitsee ongelman käyttöönottoprosessin aikana, uusi ominaisuus tai koodi on helppo poistaa käytöstä poistamalla ominaisuuslippu käytöstä. Canary julkaisut voivat auttaa estämään suuria seisokkeja, menetettyjä tuloja tai negatiivisia asiakasmieltymyksiä tarjoamalla nopeita tietoja uuden ominaisuuden suorituskyvystä ja rajoittamalla samalla niitä.
Canary testaus ja jatkuva kehitys
Canary testauksen etuihin kuuluu se, että jos uusi ominaisuus ei läpäise valvontatarkistusta, kun se on otettu käyttöön tietylle käyttäjäryhmälle, se palautuu automaattisesti takaisin. Canary testauksen avulla kehitystiimi tiimi voi turvallisemmin julkaista uusia toimintoja ja koodimuutoksia laajassa mittakaavassa.