Aktuelt

Lesetid: 3 minutter

Raskere til mål med Ruter

God flyt er viktig, både i utviklingsprosessen og i trafikkbildet. Hvordan etablerer Ruter god testautomatisering?

SOCO’er Geir Maurud er i nystartet prosjekt hos Ruter. Her er fokus å generere fleksibel, rask og strømlinjeformet automatisering av backend. Vi har tatt en prat med Geir for å høre mer om fremgangsmåten. 

Geir, fortell litt om prosjektet du er i nå  

Team tjenestebestilling er et ledd i det å tilby mer helhetlige tilbud til alle Ruters brukere, med hovedfokus på alternative transportmetoder ofte klassifisert som mikromobilitet. Det kan være for eksempel sparkesykler, bysykler, selvkjørende biler og annet som kan være med å skreddersy en reise fra A til Å. Det leddet teamet mitt leverer er backend-støtte for appen, hvor vi blant annet implementerer ekstern kommunikasjonen med tredje part. 

Hvilken teknologi bruker dere, og hva gjorde at dere landet på den?  

Vi er en del av Ruters nye plattform, og forvalter noen mikrotjenester i en større helhetlig arkitektur. For intern dataflyt brukes Kafka, som kjører på Amazon Kubernetes i skyen. Så bruker vi Gitlab til å strømlinjeforme prosessen fra kode til produksjon, og Datadog til monitorering og logging. Vi har endel likheter med andre team, og det har vært mulig å arve nyttige tjenester som vi har gjort til våre egne. Blant annet en selvutviklet test-tjeneste hvor vi kan styre hvilke tester som skal kjøres for gitt applikasjon ved kodeendring. Som en del av pipelinen kan vi sette regler som at applikasjon kjøres videre automatisk til neste miljø dersom alle tester er godkjente.  

Det er en kunst å være smart i utvalget av hva som skal bli faste tester, og hva som kastes.

Hvordan går dere frem med å planlegge og designe automatiseringen nå som dere er et relativt nytt team som er i etablering?  

Målet er at alle tester kodes og automatiseres, og ønsket er at vi fra starten har en god base med enhetstester, som er supplert med noen integrasjonstester. Enhetstestene er integrert og kjører som en del av byggeprosessen, mens integrasjonstestene er en egen applikasjon som kjører som en del av pipelinen eller ved behov. Planlegging og design av test skjer så tidlig som mulig, og inkluderer det å skrive test-cases for å dekke hovedfunksjonalitet og happy cases, og noen sannsynlige feilscenarier. Kommunikasjonen foregår på en generalisert strøm av data fra system til system, så testene består hovedsakelig av enkel input – output og er veldig egnet for automasjon.  

Er det noen lessons learned du kan dele med andre som skal i gang med å automatisere for å strømlinjeforme leveransene?  

I prosessen med å skrive testene som skal bli automatiske regresjonstester, pleier jeg å leke litt med input for å trigge litt forskjellig oppførsel. Det er en kunst å være smart i utvalget av hva som skal bli faste tester, og hva som kastes. Jeg er nok ikke helt i boks med å finne den balansegangen enda, men er bevisst på at porteføljen med tester ikke blir for stor, slik at det er overveldende mye å holde styr på. 

Mange gode innspill her, Geir! Takk for praten!