CONTINUOUS INTEGRATION – GRØN BØLGE FOR DIN SOFTWAREUDVIKLING

Brug 10 til 15 procent af din arbejdstid i et halvt år på Continuous Integration. Den investering vil hurtigt give bonus: Med kontinuerlig, automatiseret test af nyskrevet kode kan du rette eventuelle fejl her og nu, i stedet for at bruge masser af tid på dem, når de dukker op på et senere tidspunkt.

Embedded software udvikler Mads Andreasen arbejder lige nu i et udviklerteam hos en af TechPeoples kunder. I det seneste halve år har det 15 mand store team brugt ressourcer svarende til trekvart medarbejder på Continuous Integration. Blandt andet har teamet – på eget initiativ – nu monteret et ”trafiklys” på udvikler-gangen: Når det lyser grønt er alle dagens automatiske tests gået godt. Når det lyser rødt er der noget galt.

– Når man går ud og henter kaffe opdager man, at der er problemer, og så skal det bare fikses med det samme. Hvis du er heldig, så når chefen ikke at se det røde lys, inden du retter den fejlbehæftede kode og lyset skifter til grønt igen, griner Mads.

Test hele tiden

– Continuous Integration er meget oppe i tiden og jeg ved, at mange efterspørger viden om det. Jeg kan kun anbefale at man går i gang. Man skal bare være klar over, at det kræver en investering. I starten skal du bruge 10-15 procent af afdelingens arbejdstid på det. Når du har fået sat dit testmiljø op, begynder det til gengæld at give tilbage ret hurtigt.

Ifølge Mads er automatiserede tests vejen frem, ikke mindst fordi manuelle tests er tidskrævende og derfor dyre. Desuden er der altid en risiko for at man overser en fejl i et stykke kode. Alle udviklere vil på et tidspunkt komme til at springe et test-skridt over, og kan derfor overse fejl i systemet.

– Continuous Integration er en måde, hvorpå vi hele tiden kan teste det vi laver. Det fungerer sådan, at hver gang vi har lavet et lille stykke udvikling og lagt det i vores Git Repository, får vi det testet med det samme. Dermed fanger vi de fejl, som måske først dukker op langt senere, og som derfor er langt sværere at rette op på. Det er jo ikke sjældent at bruge en uge på at finde en fejl der er introduceret ét år tidligere.

Det gode testmiljø

Mads understreger, at det gode og effektive testmiljø ikke kommer af sig selv.

– Det er ret komplekst at lave et godt testmiljø, og det er bestemt heller ikke gratis at bygge det op. Men på den lange bane vinder man rigtig meget på at arbejde seriøst med Continuous Integration.

– I min afdeling begyndte vi i foråret med et internt kursus i at skrive tests og at skrive kode, der er testbar. Derefter begyndte vi at skrive forskellige test på forskellige niveauer, både modul test, unit test og test, der kører på den rigtige hardware. Det kræver noget omstilling for de fleste udviklere. Man ved jo godt man skal skrive test, men får det ikke rigtig gjort. Man tænker, at ”nu virker den kode jeg har skrevet” og desuden har man travlt. Der er stramme deadlines, og der er altid et produkt, der skal ud af døren i morgen osv.

Små skridt

Heldigvis kan man tage små skridt ad gangen, når man indfører Continuous Integration. Man kan starte med kun at bygge, så man ikke publicerer noget kode, der ikke bygger hos ens kollegaer. Hvis det sker får man omgående en advarsel fra systemet.

Næste trin er at køre nogle automatiske unit test, hver gang der kommer ny kode ind i kodebasen. Så får man sikkerhed for, at den nye software opfører sig korrekt efter specifikationerne.

– Når man har sin unit test på plads i systemet, så kan man gå skridtet videre og begynde at teste på det konkrete apparat softwaren skal køre på, forklarer Mads.

– Dermed får du testet det færdige system, således at du hele tiden har styr på din softwareopdatering.

– Testsystemet bruger Jenkins, en Open Source server-applikation man typisk installerer på en Linux-maskine. Man opretter ”jobs”, der overvåger den software du udvikler. Systemet kan også udføre langvarige tests. I vores team har vi f.eks. et testsystem, der hver nat tester, om de nye ændringer vi har lavet fungerer på det apparat softwaren skal køre på.

 

Ro i maven

Efter et halvt års arbejde er Mads og hans kolleger nu nået så langt med indførelsen af Continuous Integration, at de har ”ro i maven”, når trafiklyset ude på gangen lyser grønt.

– Det begynder at hjælpe. I indkøringsfasen var der meget, der fejlede. Men nu føler vi, at der er styr på tingene.

– Samtidig er det vigtigt at huske på, at kvaliteten af dit testmiljø er afgørende. Det grønne lys betyder sådan set bare, at de tests systemet udfører går godt. Har du kun skrevet en enkelt lille test, så vil den lyse grønt hele tiden. Men har du skrevet mange test på mange forskellige niveauer, så har du en god test-dækning og du får et mere retvisende billede af systemet. Det er for øvrigt også noget man skal forbedre hele tiden.

Kom godt i gang

For at komme godt i gang med Continuous Integration anbefaler Mads tre ”baby steps”:

– Trin 1 er at etablere en Jenkins server og sætte den op til at få kode ud af sin kode-database. Derefter beder man den om at bygge det, så man får sikkerhed for at man kan kompilere sine ting hele tiden. Dermed undgår man at lave fejl, således at ens kode ikke kan kompilere .

–  Trin 2 er at begynde at køre sine unit tests automatisk og begynde at køre sin kode igennem testen hver gang

–  Trin 3 vil være at sætte et testmiljø op, så man kan teste på sit rigtige hardware.

Og undervejs skal man huske på, at den tid man investerer i Continuous Integration kommer igen på lang sigt. Man fanger fejl i, der ville have taget uger at finde og rette, hvis de havde fået lov til at overleve uopdaget i det færdige produkt. Når man så endelig finder fejlen kan man tit se, at en test ville have fanget den med det samme.

Jeg kan kun anbefale at man går i gang. Man skal bare være klar over, at det kræver en investering.

Mads Andreasen