Så hanterar experter beroenden inom testautomatisering med minimal insats

Om du däremot inte uppdaterar dina beroenden regelbundet går du miste om användbara funktioner och utsätter din pipeline för säkerhetsrisker. I det här inlägget tittar vi på ett modernt sätt att hantera dina Robot Framework-beroenden: automatisering.

Grundläggande beroendehantering

Det bästa sättet att kontrollera dina Robot Framework-beroenden är först och främst att samla dem i en enda requirements.txt-fil. 

robotframework==3.0.4

junitparser==1.2.2

requests==2.27.1

PyYAML==3.13

Ett exempel med fyra beroenden och fastlåsta versionsnummer (huvud-, under- och patchversion)

I semantisk versionshantering avser de två första siffrorna i ett versionsnummer huvud- respektive underversion. 

Dessa versioner bör inte vara jokertecken (*) i din utvecklings- eller huvudgren, eftersom ändringar i dem kan göra att din CI-pipeline slutar fungera. Med andra ord bör versionerna vara fastlåsta. 

Det är oftast säkert att använda ett jokertecken för patchversioner, men utvecklare tolkar ofta semantisk versionshantering på olika sätt. En uppdatering som en utvecklare ser som en obetydlig patchrelease kan ändå göra att din pipeline slutar fungera. 

Å andra sidan kan det vara ännu mer riskfyllt att inte använda ett jokertecken för patchversioner. Utan jokertecken måste du komma ihåg att följa patchreleaserna och uppdatera dem manuellt. Om – eller snarare när – du till slut glömmer detta utsätter du återigen din pipeline för säkerhetsintrång.

Våra två sätt att versionshantera beroenden

På Eficode använder vi två olika metoder. Den ena är mer manuell och den andra mer automatiserad.

Lås huvud- och underversioner och uppdatera dem manuellt

I den första metoden låser du huvud- och underversioner för beroenden i en requirements.txt-fil och uppdaterar dem manuellt med jämna mellanrum – vanligtvis varannan månad. 

Som tumregel fungerar detta mycket bra i projekt med komplexa beroenden: uppdateringar av huvud- eller underversioner kräver vanligtvis ändå en del manuellt arbete med testmiljön. 

Lås hela versionen och automatisera pipelinen

För relativt okomplicerade beroenden – särskilt säkerhetskritiska sådana – rekommenderar vi att låsa hela versionen (huvud-, under- och patchversion) och använda en automatiserad pipeline. 

Konfigurera pipelinen så att den uppdaterar beroendena åt dig varje vecka och rapporterar om nya versioner är enkla att uppdatera eller om uppdateringen riskerar att orsaka problem. Pipelinen kan till exempel rapportera direkt till Slack, så att du inte missar rapporten.

Det finns förstås många sätt att skapa en sådan pipeline, men här är ett exempel på en enkel implementation:

Se skriptet post_to_slack.py för resten av exemplet

När jobbet har schemalagts att köras exempelvis varje vecka får teamet följande meddelande om jobbet lyckas:

Teamet kan sedan uppdatera beroendena manuellt. 

Du kan naturligtvis göra pipelinen ännu mer avancerad genom att låta den automatiskt öppna en merge request med nya versioner för fastlåsta beroenden. Med vårt exempel vill vi bara visa att även en relativt enkel lösning kan göra det mycket smidigare att uppdatera beroenden.

Sammanfattningsvis: ”lagom” är bäst

För att underhålla din testautomatisering på ett effektivt sätt behöver du också underhålla de beroenden den använder. Låt inte ständiga uppdateringar av beroenden störa ditt faktiska, värdefulla arbete och få din pipeline att sluta fungera. Men du behöver uppdatera dem med viss regelbundenhet för att åtminstone hålla pipelinen säker.

Precis som med många saker i livet är det svenska begreppet lagom användbart (tack, svenska kollegor). Det finns ingen direkt engelsk motsvarighet, men det kan ungefär översättas med ”rätt mängd är bäst”.