Hva er versjonskontroll?

Versjonskontroll er noe av det mest grunnleggende i moderne programvareutvikling, men også noe av det som sjelden blir forklart for den som bestiller. Det er verdt å forstå, for det henger direkte sammen med et av de viktigste spørsmålene av alle: Eier dere virkelig koden deres? Nedenfor forklarer vi hva det betyr.

Definisjonen

Versjonskontroll er systemet som lagrer hver endring i koden til et prosjekt, med informasjon om hvem som gjorde den, når og hvorfor. I stedet for at koden bare finnes i én tilstand som stadig endres, bygges det opp en fullstendig historikk der hvert steg er bevart og kan gjenopprettes.

Det løser to problemer på én gang. For det første kan man alltid gå tilbake til en tidligere tilstand hvis noe går galt. Det fungerer som en angrefunksjon, bare uendelig mye kraftigere. For det andre kan mange utviklere jobbe parallelt i samme kodebase uten å overskrive hverandres arbeid fordi systemet holder styr på endringene og fletter dem sammen.

Git er standarden

I praksis betyr versjonskontroll i dag nesten alltid Git. Det er verktøyet som tar seg av selve historikken, og det har blitt så dominerende at det er den selvsagte standarden i så godt som alle profesjonelle utviklingsteam.

Oppå Git ligger tjenester som GitHub og GitLab. De lagrer koden sentralt på et sikkert sted og legger til alt som gjør lagarbeid smidig: kodegjennomgang, tilgangsstyring, oppgavehåndtering og automatiske tester. Git er motoren under panseret, mens GitHub og GitLab er plattformene der teamet samles rundt koden. Forskjellen er verdt å kjenne til, for det er på plattformen tilgangen din som kunde ligger.

To begreper: commit og branch

To ord dukker stadig opp, og de er enklere enn de høres ut.

En commit er en lagret endring. Hver gang en utvikler har fullført et arbeidsmoment, lagres resultatet som en commit: et navngitt punkt i historikken med en kort beskrivelse av hva som ble gjort. Det er som å sette et bokmerke etter hvert fullført steg slik at man alltid finner tilbake.

En branch, eller gren på norsk, er en parallell arbeidskopi av koden. Der kan en utvikler bygge noe nytt eller prøve ut en idé uten å røre koden som fungerer og allerede er i drift. Når arbeidet er ferdig og testet, flettes grenen sammen med hovedgrenen. Det er grenene som gjør at flere personer kan bygge ulike ting samtidig uten å gå i veien for hverandre.

Kundeperspektivet: Krev tilgang til repoet

Her blir det forretningskritisk. All kode i et prosjekt bør ligge i et versjonskontrollert repository (et repo), og det avgjørende er hvem som har tilgang til det.

Ligger koden i et repo som dere som kunde eier og har full tilgang til, har dere kontroll. Dere kan når som helst gå gjennom det som er bygget og hente inn en annen leverandør som fortsetter der den forrige slapp. Dere kan også være trygge på at hele historikken er bevart. Ligger koden derimot bare hos leverandøren, sitter dere fast: Dere er avhengige av leverandørens velvilje for å få tilgang til et system dere selv eier, og et avsluttet samarbeid kan bli svært dyrt.

Kravet er enkelt å stille og bør stilles tidlig: All kode skal ligge i et versjonskontrollert repo som organisasjonen deres eier eller har administratortilgang til. Det er en av de billigste forsikringene mot leverandørinnlåsing som finnes. Vi i Weapp ser det som en selvfølge at kunden eier koden sin. Det er tross alt dere som har betalt for den.

Slik bruker du dette

Du trenger ikke å kunne Git for å stille de riktige kravene. Spør hvor koden lagres og om den er versjonskontrollert, og sørg for at dere står som eier eller administrator på plattformen, ikke bare som invitert gjest. Da har dere både historikken og kontrollen over systemet deres, uansett hvordan samarbeidet utvikler seg. Vil dere ha hjelp til å finne ut hvordan koden deres håndteres i dag? Ta kontakt.