– Det sker forbløffende mange gange, at folk ude i virksomhederne kan nikke genkendende til situationen, hvor de har fikset en bug, og to måneder senere dukker den så op igen.
Lars Bendix er Configuration Management Researcher ved Lund Universitet, hvor han forsker og underviser i konfigurationsstyring, ligesom han er initiativtager til Scandinavian Network of Excellence in Software Configuration Management. Selvom versionskontrol traditionelt ikke spiller den store rolle i konfigurationsstyring, ser Lars Bendix anvendelsen af versionskontrolsystemer som en central del af moderne konfigurationsstyring. Derfor følger han nøje med i, hvordan virksomheder anvender versionskontrolsystemer til softwareudvikling.
Versionsstyring fundamental
Lars Bendix underviser også studerende i anvendelsen af versionstyringsværktøjer som Git, men selvom værktøjerne i sig selv kan være interessante, mener Lars Bendix, at det er vigtigere at se på, hvordan værktøjerne anvendes. Ofte har de studerende allerede erfaring med Git, men når Git bliver sat ind i en konfigurationsstyringsmæssig kontekst, begynder de at se Git i et helt andet lys.
– De simple ting som pull og push kan de godt finde ud af, men de mere avancerede ting og en forståelse for, hvad der egentlig foregår, kniber det med. Når de har været igennem lab'et, siger de, at de kan se, at de ikke rigtigt kendte Git, fortæller Lars Bendix.
Gammelkendte problemer
Det er også værd at forstå den historiske baggrund for konfigurationsstyring og de tanker, som konfigurationsstyringseksperter allerede gjorde sig for mange år siden. Eksempelvis er problemet med genopståede softwarefejl beskrevet i bogen ”Software Configuration Management: Coordination for Team Productivity” fra 1986. Her beskriver Wayne Babich tre grundlæggende problemer, som kan opstå, når arbejdet i et projektteam skal koordineres, nemlig: Shared data, simultaneous update og double maintenance.
Shared data-problematikken opstår, når andre projektdeltagere ændrer data, som vi bruger, uden at vi er klar over, at der er foretaget ændringer. Ved simultaneous update overskrives eller ændres en projektdeltageres rettelser ved en fejltagelse. Double maintenance opstår, når vi kopierer noget kode. Hvis vi foretager ændringer et sted, bliver vi også nødt til også at lave ændringerne i kopierne.
Versionskontrolsystemerne i sig selv er ikke en garanti for, at problemerne aldrig vil opstå.
– Jeg har ikke set noget værktøj, der eliminerer de problemer. Du kan anvende værktøjer som Git og Mercurial på en dum måde, så de tre problemer opstår. Derfor skal man kende til problemerne og være opmærksom på, hvordan man arbejder på en god måde, så problemerne undgås, siger Lars Bendix.
Konflikt: Deres eller dine rettelser
Den genopstandne softwarefejl skyldes simultaneous update-problematikken, hvor den koderettelse, som eliminerede fejlen, senere bliver fjernet fra repository'et. Selvom et versionskontrolsystem i princippet skulle forhindre den slags, så vil en forkert anvendelse af systemet resultere i en genopstanden bug.
– Når du merger mine ændringer ind i dit workspace, så sker det nogle gange, at der er en merge-konflikt. En hurtig, enkel - og dum - måde at løse den konflikt på er at smide mine ændringer væk og beholde dine egne. Hvis du til slut committer dit workspace, så mangler mine ændringer – som havde bug-rettelsen. Der er selvfølgelig mulighed for at anvende versionskontrolsystemets historik til at gå tilbage og finde koderettelsen, der fjernede fejlen, men det kan i sig selv være en opgave, siger Lars Bendix.
De geniale distribuerede systemer
Via sit forskningsarbejde har Lars Bendix undersøgt, hvordan konfigurationsstyringsteknikker kan anvendes til at holde styr på distribueret softwareudvikling. Blandt andet har han arbejdet sammen med Sony Mobile og fulgt virksomhedens måde at anvende versionskontrol på.
- De har anvendt Clearcase i lang tid, men mere og mere lægges over i Git. Google anvender Git til Android, så hvis en mobilvirksomhed ikke anvender Git, får den problemer, siger han.
Selvom han understreger vigtigheden af at have veldefinerede processer, så spiller værktøjerne også en rolle.
– Selvfølgelig er værktøjerne vigtige, og distribuerede versioneringsværktøjer som Git og Mercurial har åbnet en helt ny boldgade, som giver os mulighed for at have nogle processer, som var ret besværlige at lave tidligere, siger han.
Eksempelvis vil det være besværligt at pille en gammel fejlbehæftet feature ud af et centralt repository.
– Hvis vi arbejder med Subversion, og du har fået din nye feature ind på hovedlinjen, på mainbranch, og vi så fire-fem commits senere opdager, at din nye feature egentlig ikke fungerer, så vil vi gerne pille den feature ud igen. Med Subversion er det ikke ligetil. Hvis du derimod har en changeset-model, så piller du den bare ud, siger Lars Bendix og fortsætter efter en lille pause:
– I teorien piller man den bare ud. Du skal stadig krydse fingre og håbe, at det går.
Lær af branching-mønstre
For at få en forståelse for kompleksiteten i versionskontrol og mulighederne for at håndtere den anbefaler Lars Bendix artiklen ”Branching Patterns for Parallel Software Development”. Her beskriver Brad Appleton og hans tre medforfattere mere end 50 forskellige branching patterns.
Det lyder umiddelbart overvældende, men en virksomhed som Sony Mobile kan godt få brug for en stor del af branching pattern-arsenalet, når virksomhedens kode skal konfigureres til low- og highend-mobiler til forskellige slags kunder i forskellige lande. Ligesom design patterns kan hjælpe udviklere med at finde inspiration fra generelle designmønstre til at løse et konkret problem, kan branching-mønstre inspirere til at løse versionskontroludfordringer.
– Det er en kogebog, som kan anvendes til at finde mønstre, der passer til en virksomheds virkelighed, siger Lars Bendix.
En virkelighed, der helst ikke skal hjemsøges af genopstandne bugs.
