DEIF er med over 600 medarbejdere, heraf 400 i hovedsædet, Skives største private arbejdsplads. Grundlagt som Dansk Elektro Instrument Fabrik i 1933 og i dag en global virksomhed på markedet for high-end-styring og regulering af decentral energiproduktion med specialkompetencer inden for dieselgeneratorer.
Omkring 100 medarbejdere i R OG D står for udvikling af avanceret mekanik, hardware og software, som tidligere udelukkende var embedded, men som i de senere år har bevæget sig op gennem lagene med introduktion af Linux som OS, udvikling af applikationer på Linux og stadig flere løsninger med grafiske brugergrænseflader.
– Vi er skarpe på de meget avancerede styringsløsninger til energiproduktion, specielt hvor mange anlæg skal arbejde sammen, fortæller Mikkel Lund, projektleder i R OG D.
Bare et enkelt eksempel på, hvilken størrelse og kompleksitet vi taler om: Efter katastrofen på det japanske atomkraftværk Fukushima i 2011 var det DEIF, der leverede nødstrømsanlægget til genetablering af strømforsyningen i området omkring anlægget.
Solgt ind som kvalitetssikring
Det klart største projekt i R OG D har de seneste cirka fem år været udviklingen af en ny produktplatform med flere processorer og avancerede grænseflader. En hovedprocessor, der kører Linux, og en række I/O-kort med mikro-controllere er hovedkomponenterne i enheden.
– For at sikre kvaliteten i så stor en udviklingsopgave med omkring 35 udviklere involveret har vi været nødt til at implementere flere nye processer. Vi har ikke som sådan solgt det ind i organisationen som Continuous Integration eller Continuous Delivery, men snarere talt om det som kvalitetssikring gennem automatiserede testforløb, fortæller Mikkel Lund.
Fra tidligere projekter havde man erfaring med smerten ved et traditionelt forløb, hvor man på et tidspunkt låser en release og så bruger de næste mange uger eller måneder på at teste.
– Når man finder en fejl i et traditionelt test-releaseforløb, bliver man ofte nødt til at tage en ledelsesbeslutning om, hvor meget man skal teste rundt om rettelsen. Tit føler man, at man går på kompromis og bliver derfor usikker på resten af koden, som man måske ikke får testet. Så konklusionen var, at vi blev nødt til at være mere agile og arbejde i mindre isolerede områder, hvor vi løbende testede det hele så automatiseret som muligt, fortæller Mikkel Lund.
Test-setuppet en stor opgave
Konkret betyder det, at udviklingen brydes ned i små opgaver, og når udvikleren committer ny kode, trigges kompileringen inklusive unit tests, og hvis det går godt, trigges en række automatiserede testforløb op mod simulerede generatorer og motorer. Værktøjerne er Git eller SVN (Apache Subversion) til versionsstyring og Jenkins som automatiseringsplatform. Selve de automatiserede tests har man selv udviklet i Ruby, da der på det tidspunkt, hvor man skulle i gang, ikke fandtes egnede test-frameworks. Der trigges ikke nødvendigvis en test for hver commit, da nogle af dem er meget små og derfor bliver bundlet med andre. Men typisk kører der som minimum en fuld test i døgnet.
Udviklingen af de automatiserede tests viste sig at blive en større opgave end forventet, fortæller Per Christensen, softwarearkitekt og teamleder.
– Forestillingen om, at vi kunne lave et automatiseret test-setup på et par uger, måtte vi hurtigt erkende, var urealistisk. I det hele taget har opbygningen af de automatiserede tests været klart den største udfordring og investering i hele det her forløb, siger han.
Ifølge Mikkel Lund har investeringen dog været det hele værd.
– Jeg kan helt kategorisk sige, at vi aldrig var kommet igennem med projektet, hvis vi ikke havde implementeret en ny måde at arbejde på. Vi har lavet fire releases siden sommerferien med en meget lille indsats i forhold til tidligere. Vi finder flere fejl tidligere end før, hvor vi risikerede at skulle rejse ud på fjerne destinationer og rette dem hos kunden, siger han.
Giver udviklerne ro i maven
For den enkelte udvikler har det også været en fordel. Tobias Bøge Christensen startede hos DEIF i 2012 som nybagt Electronic Design Engineer fra AU-HIH i Herning.
– Jeg synes, det er dejligt at arbejde på den her måde. Det giver mere ro i maven, når man committer noget, fordi man ved, at hvis der er fejl i koden, så bliver det fanget, og man kan rette det med det samme, siger han og tilføjer:
– Det kan virke lidt banalt, men det giver faktisk en ro og tilfredsstillelse, når man ser en grøn cirkel og en sol i Jenkins ud for den udviklingsopgave, man har arbejdet med. Så ved man, det er i orden i forhold til den Defintion of Done, man er blevet enig om.
Han ser på ingen måde implementeringen af Jenkins og planlægningen af de små udviklingsopgaver som en spændetrøje.
– Som jeg ser det, handler det i høj grad om at aflaste udviklerne, så vi kan bruge vores tid på det, der virkelig giver mening, nemlig at lave noget nyt, som giver værdi, siger han.
Systemarkitekturen på den nye platform er modulorienteret, og selvom man oprindelig regnede med at genbruge en vis del af noget eksisterende kode, er man reelt startet forfra.
– I dag arbejder vi objektorienteret og er gode til at skille tingene ad og genbruge moduler. Men vi har levet med en monolitisk struktur og kender udmærket til den smerte, fortæller Mikkel Lund.
Unit tests en udfordring
Det eneste område, hvor der blandt udviklerne har været forbehold, har været i forhold til unit tests.
– Vi havde nogle udfordringer med at sælge de automatiserede tests til udviklerne, da det betød, at de skulle inkludere unit tests i deres kode. Det var en lidt ny og måske svær disciplin, men efterhånden kom de gode ahaoplevelser, når man fangede en fejl, som tidligere først ville være fanget af kunden, fortæller Mikkel Lund, der dog også maner til forsigtighed:
– Vi har nu inkorporeret vores automatiske testprocedurer, vi har krav til line coverage, det vil sige procentdel kodelinjer, der er testet, og vi har systemer til at måle på det. Men risikoen er selvfølgelig altid, at man får en falsk tryghed, for eksempel fordi det kan være de ”nemme” ting, man kører igennem de automatiserede tests.
Løbende anerkendelse vigtig
Rundt om i virksomheden er der skærme, som viser status på udviklings- og testprocesserne. Og netop muligheden for løbende at følge udviklingen er et vigtigt element ifølge Mikkel Lund.
– Det er vigtig løbende at få de små tegn på anerkendelse for sin indsats, og de enkelte teams går op i, at den bare skal være grøn i Jenkins. På den måde bliver det hele også mere selvregulerende, end hvis det er en projektleder, der skal rende og prikke folk på skulderen.
Han tilføjer, at rent ledelsesmæssigt er overblikket i Jenkins også med til at give mere ro i maven – eller ej.
– Man kan umiddelbart se, hvis det trækker op til en tordensky i Jenkins, og så har man jo muligheden for lige at spørge til det i teamet.
Mere automatisering på vej
Hvis man kigger på definitionerne på henholdsvis Continuous Integration og Continuous Delivery, er man hos DEIF stadigvæk et sted midt imellem, da genereringen af den release, der skal køre i produktion, endnu ikke er automatiseret.
– Lige nu er det en relativt manuel process at samle sammen til en release til produktionen, men der er meget, der reelt er maskinelt arbejde, og som derfor godt kunne automatiseres. Det er helt sikkert noget, vi vil arbejde hen imod, siger Per Christensen.
