Martin Astradsson er systemarkitekt og softwareudvikler i den danske afdeling af YXLON, der udvikler high-end-røntgenudstyr til eksempelvis inspektion af svejsninger i olierørledninger. Han har erfaring med både traditionelle softwareudviklingsmodeller og de mere agile metoder, hvor der også har været fokus på automatisering af både bygge- og testflows. Så da han skulle stå i spidsen for udviklingen af softwaren til et nyt stort røntgensystem, stod det helt klart, i hvilken retning den fremtidige udvikling skulle gå.
– Udviklingsprojektet var stort og komplekst, og der skulle hyres flere konsulenter ind til udviklingsarbejdet. Baseret på tidligere erfaringer var Continuous Integration og Continuous Delivery det oplagte valg af udviklingsparadigme med henblik på, at det skulle være muligt at videreudvikle og vedligeholde systemet efterfølgende med kun få ressourcer. Derudover var det målet at få en styret forbedring af softwarekvaliteten ved at indføre ”quality gates” som en del af de automatiserede software-pipelines, siger han.
Assistance udefra
Ud fra princippet om at man skal fokusere på det, man er god til, valgte han at hyre assistance udefra til opsætning af CI/CD-infrastrukturen og de frameworks, der skulle bruges til at få automatiseret store dele af processerne lige fra byg, test på forskellige niveauer til deployment. Resultatet blev et setup med Git som versionskontrolsystem og Jenkins som automatiseringsplatform. Ruby blev valgt som scriptsprog til at køre en stor del af de automatiserede testscenarier på systemniveau. Google Test og Google Mock kom på banen til unit testene, og et framework til automatisering af UI-tests blev udviklet.
Hvert hardware-modul i løsningen har sin tilhørende software-pipeline i Jenkins med forskellige automatiske kvalitetstjek – lige fra tjek af kompilering af koden til den endelige release af software til de enkelte moduler. Hver gang, der pushes ny kode til Git, detekterer Jenkins det og trigger de automatiske jobs i de forskellige software-pipelines.
Når der på systemets software-pipeline, som binder de enkelte modul-releases sammen, ligger en release-kandidat, kan der frigives en system-release ved et manuelt tryk på ”knappen”. Det er en manuel proces, da det ikke er sikkert, at alle kandidater, som pushes til produktionen, skal ophøjes til releases. Når der er frigivet en ny release, kan folkene med ansvar for produktionssystemerne umiddelbart se det. De installerer softwaren på systemniveau via Jenkins, som sørger for, at det altid er den senest godkendte og frigivede software, der installeres.
Vigtigt med det rigtige mindset
Automatiseringen er ikke endnu helt realiseret på systemintegrationsniveau. De automatiserede tests inkluderer indtil videre kun de forskellige undermoduler i løsningen, men der kan køres i en simuleret system-mode ved hjælp af indbyggede software-emuleringer af de fysiske røntgenrør samt ved hjælp af et UI-test-framework, der kan simulere al brugeradfærd.
– Nogle af de fysiske enheder, der skal testes på, som for eksempel røntgenrør, er rigtigt dyre og kræver meget af omgivelserne – for eksempel blyafskærmning. Så lige nu har vi dem ikke til rådighed i det automatiske 24/7 test-setup. Derudover inkluderer release-testen også manuelle operatørtests, fortæller Martin Astradsson.
Der er ingen tvivl om, at graden af automatisering skal øges over tid.
– Der er jo til hver en tid krav om nye features og desværre også stadig brug for bug fixes, og det må man jo tage med i betragtning, når man overvejer at bruge ressourcer på at forbedre automatiseringen. Men der er ingen tvivl om, at investeringen i automatisering på lidt længere sigt altid vil kunne betale sig, siger han og giver følgende råd til andre, der overvejer at gå samme vej:
– Det er vigtigt at have folk om bord med det rigtige mindset, så man ikke skal diskutere, om det her er den rigtige måde at gøre det på – det er nok det vigtigste. Medmindre man er en meget stor organisation, bør man også hyre folk ind, der har specialkompetencer i opsætning af den tool stack, der driver automatiseringen.
