Näin asiantuntijat hallitsevat testiautomaation riippuvuuksia pienellä vaivalla

Jos et kuitenkaan päivitä riippuvuuksiasi säännöllisesti, menetät hyödyllisiä ominaisuuksia ja altistat pipelinesi tietoturvariskeille. Tässä kirjoituksessa tarkastelemme modernia tapaa hallita Robot Framework -riippuvuuksia: automaatiota.

Riippuvuuksien perushallinta

Ensinnäkin paras tapa hallita Robot Framework -riippuvuuksia on koota ne kaikki yhteen requirements.txt-tiedostoon. 

robotframework==3.0.4

junitparser==1.2.2

requests==2.27.1

PyYAML==3.13

Esimerkki neljästä riippuvuudesta, joiden versionumerot on kiinnitetty (pää-, sivu- ja korjausversio)

Semanttisessa versioinnissa versionumeron kahden ensimmäisen numeron tulisi viitata pää- ja sivuversioon. 

Nämä versiot eivät saa olla jokerimerkkejä (*) kehitys- tai päähaarassasi, sillä niihin tehdyt muutokset voivat rikkoa CI/CD-putkesi. Toisin sanoen versiot tulisi kiinnittää. 

Jokerimerkin käyttö korjausversioissa on yleensä turvallista, mutta kehittäjät tulkitsevat semanttista versiointia usein eri tavoin. Päivitys, jonka yksi kehittäjä arvioi merkityksettömäksi korjausjulkaisuksi, saattaa silti rikkoa pipelinesi. 

Toisaalta jokerimerkin käyttämättä jättäminen korjausversioissa voi olla vielä riskialttiimpaa. Ilman jokerimerkkiä sinun on muistettava seurata korjausjulkaisuja ja päivittää ne manuaalisesti. Jos (kun) lopulta unohdat tehdä tämän, altistat pipelinesi jälleen tietoturvaloukkauksille.

Kaksi tapaamme versioida riippuvuuksia

Me Eficodella käytämme kahta erilaista lähestymistapaa. Toinen on manuaalisempi ja toinen automatisoidumpi.

Pää- ja sivuversioiden kiinnittäminen ja manuaalinen päivittäminen

Ensimmäisessä lähestymistavassa kiinnität riippuvuuksien pää- ja sivuversiot requirements.txt-tiedostoon ja päivität ne manuaalisesti säännöllisin väliajoin – yleensä parin kuukauden välein. 

Nyrkkisääntönä tämä toimii erittäin hyvin projekteissa, joissa riippuvuudet ovat monimutkaisia: pää- tai sivuversioiden päivitykset edellyttävät yleensä joka tapauksessa jonkin verran manuaalista työtä testikehyksen parissa. 

Koko version kiinnittäminen ja pipelinen automatisointi

Suhteellisen yksinkertaisissa riippuvuuksissa – erityisesti tietoturvan kannalta kriittisissä – suosittelemme kiinnittämään koko version (pää-, sivu- ja korjausversion) ja käyttämään automatisoitua pipelinea. 

Määritä pipeline päivittämään riippuvuudet puolestasi viikoittain ja raportoimaan, voidaanko uudet versiot päivittää helposti vai rikkooko päivitys jotain. Pipeline voi esimerkiksi raportoida suoraan Slackiisi, jolloin et jää ilman raporttia.

Tällaisen pipelinen voi toteuttaa miljoonalla tavalla, mutta tässä on esimerkki yksinkertaisesta toteutuksesta:

Katso esimerkin loppuosa post_to_slack.py-skriptistä

Kun ajastus on määritetty suorittamaan työ esimerkiksi viikoittain, tiimi saa seuraavan viestin työn onnistuessa:

Tiimi voi sitten päivittää riippuvuudet manuaalisesti. 

Voisit toki tehdä pipelinesta vielä monipuolisemman siten, että se avaa automaattisesti merge requestin kiinnitettyjen riippuvuuksien uusilla versioilla. Haluamme esimerkillämme vain osoittaa, että suhteellisen yksinkertainenkin ratkaisu voi tehdä riippuvuuksien päivittämisestä vaivatonta.

Yhteenvetona: ”lagom” on paras

Testiautomaation tehokas ylläpito edellyttää myös sen käyttämien riippuvuuksien ylläpitoa. Älä anna riippuvuuksien jatkuvien päivitysten keskeyttää varsinaista arvokasta työtäsi tai rikkoa pipelineasi. Niitä on kuitenkin päivitettävä säännöllisesti, jotta pipeline pysyy vähintäänkin tietoturvallisena.

Kuten monissa asioissa elämässä, ruotsalainen lagom-käsite osoittautuu hyödylliseksi (kiitos ruotsalaisille kollegoillemme). Sille ei ole suoraa suomenkielistä vastinetta, mutta se tarkoittaa suunnilleen: ”oikea määrä on paras”.