6.6 Versjoner og versjonskontroll

Slik ser oppgavetavla ut når alle medlemmene er ferdige med oppgavene sine.

SPRINTGJENNOMGANGEN

På torsdagen møtes medlemmene hjemme hos Christine klokken 10. Alle er heldigvis ferdige med oppgavene sine. De gjennomfører alle testene de har skrevet, for å se at produktet virker som det skal.

Klokken 13 møter alle opp på Dunken. De viser frem programmet slik det ser ut nå. Det består av tre sider, som vises som følgende punkt i navigasjonsmenyen:

•Forsiden: Denne siden vises når man går til Dunkens domene. Her vises arrangementslisten som en kronologisk liste. • Book lokalet: Dette er siden som private arrangører trykker på. Her står det litt om hvor mye det koster å leie lokalet, hvilke tjenester de tilbyr, og hvordan man tar kontakt. • Opptre hos oss? Dette er siden som promotører trykker på. Her dukker e-postadressen og telefonnummeret til daglig leder opp.

Abdi får en ekstra gjennomgang av dataformatet han må legge inn arrangementene med, og teamet demonstrerer hvordan han laster opp bilder. Dette er han sikker på at han klarer. Han skulle ønske at det var et skjema på bookingsiden. Ofte oppgir ikke private arrangører alle de nødvendige opplysningene når de skriver til ham, og det blir mye frem og tilbake.

Jenny er fornøyd, men hun skulle ønske at det var mulig å trykke på et arrangement for å lese mer om det. Informasjonen på forsiden er litt for intetsigende til at hun blir interessert i konsertene. Hun skulle også ønske at det var en kalendervisning av arrangementene i tillegg til listen, slik at det var lettere å huske datoen for de ulike arrangementene.

Alice omprioriterer backloggen. De blir enige om at de i neste sprint bør jobbe med to brukerhistorier, én som handler om å lage en side med informasjon for hvert arrangement, og én som handler om å lage et skjema som private arrangører kan bruke til å ta kontakt.

RETROSPEKTIV

Teamet møtes hjemme hos Bob. De har bestemt seg for å bruke retrospektivmetoden DAKI.

DAKI er en retrospektivmetode og står for følgende kategorier

• Drop – vaner eller tiltak man vil slutte med • Add – vaner eller tiltak man vil legge til • Keep – vaner eller tiltak man vil holde på • Improve – vaner eller tiltak man vil forbedre

Hvert medlem bruker ti minutter på å skrive ned tanker om hver kategori på forskjellige post-it-lapper. Etterpå går de gjennom lappene sine sammen mens de fester dem på en korktavle. Til slutt ender teamet opp med følgende lapper innenfor de ulike kategoriene:

• • Drop: «Sprintlengde på én uke. Det ble for stressende.» Add: «Hvis dette skal være verdt å drive med, bør vi ha minst én kunde til. Ellers kan vi like godt ta en vanlig jobb og tjene mer penger.» «Brukergrensesnitt for å legge inn arrangementer: De færreste kunder kan skrive kode selv. Vi kan lage vårt eget brukergrensesnitt, men vi kan sannsynligvis spare mye tid på å bruke et forhåndslaget brukergrensesnitt for å styre innholdet på hjemmesiden (et såkalt innholdsstyringssystem).» • • Keep: «Alice som produkteier. Hun gjør en kjempejobb.» Improve: «Mer brukerinnsikt. Vi bruker for mye tid på å lage produktet og for lite på å sjekke om vi faktisk lager det riktige produktet.»

Med utgangspunkt i det de har kommet frem til, bestemmer de seg for at de skal gjøre følgende på fredag:

• • Alice skal be Abdi om en lengre sprintlengde i neste omgang. Christine skal ringe rundt til konsertscener i nabobygdene for å høre om de er interessert i å kjøpe en tilsvarende hjemmeside. • Bob skal utforske løsninger for innholdsstyringssystemer over helgen. Han har blant annet hørt mye bra om det norskproduserte Sanity.io.

På fredag ettermiddag bruker Alice det de har funnet ut til å prioritere backloggen. På mandag starter de neste sprint med sprintplanlegging.

VERSJONER

Som vi sa i starten av kapittelet, er det vanlig å oppdatere IT-produkter etter hvert som tiden går. Vi bruker ordet versjon for å vise til hvordan et produkt var på et visst tidspunkt. Når vi gir ut en oppdatering, sier vi at vi gir ut en ny versjon av produktet.

Når vi oppdaterer apper i operativsystemet iOS, får vi se hvilken versjon vi oppdaterer til, og en beskrivelse av hva som er nytt.

VERSJONSKONTROLL

EKSTRASTOFF

Versjonsnummerering

Det er vanlig å vise til en versjon med tre tall atskilt av punktum, et såkalt versjonsnummer. Vi starter på versjon 1.0.0 eller 0.0.0 og øker de ulike tallene ut fra hva slags endringer som kommer i den nye versjonen. Versjonsnummeret endrer seg ofte etter følgende mønster: «(økes ved store endringer).(økes ved mindre endringer).(økes ved feilrettinger)». Tallene som kommer etter det tallet vi øker, stilles alltid tilbake til 0. Hvis man gjør en stor endring, øker man det første tallet og stiller de to påfølgende tallene tilbake til 0, selv om man også la til funksjoner eller rettet opp feil. Dersom vi for eksempel er på versjon 12.3.0 og skal gi ut en ny versjon, kan vi nummerere slik: • Hvis den nye versjonen bare inneholder kodeendringer som retter opp i små feil, øker vi bare det siste tallet: 12.3.1. • Hvis den nye versjonen inneholder nye funksjoner, kaller vi den nye versjonen 12.4.0. • Hvis den nye versjonen inneholder store endringer, kaller vi den nye versjonen 13.0.0. Selv om dette er den vanligste måten å vise til versjonene på, finnes det mange alternativer. De fleste appene i listen over oppdateringer i iOS til venstre, følger dette mønsteret. Appene Google Chrome og IMDb følger et annet mønster.

Versjonskontroll er en type programvare som holder styr på hvordan filene i en mappe så ut på ulike tidspunkt. Programmet kan også brukes dersom flere som samarbeider om et prosjekt, ønsker å dele en prosjektmappe.

Du har kanskje brukt fildelingstjenester som Dropbox, Onedrive eller Google Disk når du har samarbeidet med andre om prosjekter. Fildelingstjenester er ikke det samme som versjonskontroll, men gir omtrent de samme fordelene. Alle gruppemedlemmer har tilgang til de nyeste versjonene av prosjektfilene. Hvis datamaskinen til et gruppemedlem krasjer, har man en sikkerhetskopi i skyen. Hvis noen sletter en fil eller noe av innholdet i en fil, kan man se på og gjenopprette tidligere versjoner av filen.

Med I fildelingstjenester som Dropbox kan vi dele en mappe med flere personer. Da lagres en sikkerhetskopi i skyen. Vi kan også gå tilbake til tidligere versjoner av enkelte filer.

Fildelingsprogrammer som brukes utenfor IT-bransjen, har som sagt mange likheter med versjonskontrollprogrammer og gir mange av de samme fordelene: sikkerhetskopiering, deling og historikk. Versjonskontrollprogrammene er imidlertid er tilpasset måten man jobber sammen på innenfor IT. Det mest populære versjonskontrollprogrammet som brukes i dag, heter Git. To andre kjente alternativer er Mercurial og SVN.

VERSJONSKONTROLL ER ØYEBLIKKSBILDER AV KODEBASEN

Den viktigste forskjellen på et versjonskontrollprogram og et fildelingsprogram er at versjonskontrollprogrammet lager et bilde av hele mappen når det sikkerhetskopierer prosjektet. Fordi filene i et IT-prosjekt nesten alltid er avhengige av hverandre for å fungere, gir det ikke mening å tilbakestille bare én fil til en tidligere versjon. Hele mappen må tilbakestilles til slik den var på et visst tidspunkt for at produktet skal fungere slik det gjorde på det tidspunktet.

De som lager Svelte, bruker versjonskontrollprogrammet Git. På https://github.com/ sveltejs/svelte/commits/ master kan vi se de nyeste endringene som en liste. Der ser vi blant annet når endringen skjedde, hvem som utførte den, og en beskrivelse av hva som ble endret.

For at versjonshistorikken ikke skal inneholde støy (for eksempel kode som ikke fungerte), må de enkelte utviklerne gi versjonskontrollprogrammet beskjed når det skal ta et øyeblikksbilde (fildelingstjeneste tar øyeblikksbilder hver gang man lagrer en fil). Først da tar programmet et øyeblikksbilde av prosjektmappen og legger det til i historikken. Så lenge utviklerne vet at en fil eller kodelinje ligger lagret i et tidligere øyeblikksbilde, kan de redigere eller slette den med god samvittighet. Dersom de angrer kan de alltid bla tilbake til tidligere øyeblikksbilder og hente tilbake igjen det man endret.

Det er vanlig å ta mange øyeblikksbilder underveis og ikke bare når man utgir en ny versjon, selv om betegnelsen versjonskontroll får det til å høres ut som om man bare tar et øyeblikksbilde når man har en fullstendig versjon klar. Mellom to versjoner blir det som regel tatt mange øyeblikksbilder som bare representerer steg på veien fra én versjon til den neste. Når man gir ut en ny versjon som brukerne skal ta i bruk, sier man fra til versjonskontrollprogrammet om hvilket øyeblikksbilde som representerer den nye versjonen.

Når utviklere lagrer kodebasen i skyen og bruker versjonskontroll, har da alltid en sikkerhetskopi av koden. Det blir også lett å samarbeide om koden.

BLA GJENNOM OG SAMMENLIGNE ØYEBLIKKSBILDER

Vi kan bruke versjonskontrollprogrammet for å bla frem og tilbake mellom øyeblikksbildene, nesten som om vi blar gjennom polaroidbilder eller papirark som ligger etter hverandre i en oppbevaringsboks. Hvis vi for eksempel gir programmet en kommando som git checkout v12.3.0, vil mappen på datamaskinen noen sekunder etterpå se ut akkurat som da versjon 12.3.0 ble gitt ut.

Vi kan også be programmet om å visualisere hvilke linjer som ble endret fra ett øyeblikksbilde til et annet, slik at vi slipper å lete etter orskjellen selv.

SAMARBEIDE MED VERSJONSKONTROLL

Det er vanlig å lagre en sikkerhetskopi av kodebasen i skyen, slik at kodebasen ikke blir borte dersom datamaskinen til en utvikler krasjer. Når kodebasen først er lagret i skyen, blir det mulig for flere utviklere å jobbe med den samme kodebasen samtidig.

Felles kopi av kodebasen i skyen

Alices datamaskin Bobs datamaskin Christines datamaskin

Github, som eies av Microsoft, er den mest brukte skytjenesten for dem som samarbeider om en kodebase med Git. Hvis du har brukt fildelingssprogrammer som lagrer filer i skyen før, har du kanskje opplevd at to personer endrer den samme filen samtidig. Da får vi ofte to forskjellige versjoner av en fil som vi er nødt til å sy sammen selv. Det samme skjer ofte når vi bruker versjonskontroll i et prosjekt, men versjonskontrollprogrammet klarer ofte å sy sammen endringene automatisk. Når programmet ikke klarer det, sier det fra om hvilke kodelinjer og filer det er i tvil om, slik at utvikleren kan bruke sin egen dømmekraft til å sy sammen de ulike endringene. Nedenfor ser du hvordan programmet ville markert en endring det ikke klarte å fikse automatisk, i en fil som heter eksempel.txt.

1

2

3

4

5

6

7

8

9

10 Disse linjene i starten av filen var enten uendret, eller så klarte versjonskontrollprogrammet å sy dem sammen av seg selv. <<<<<<< yours:eksempel.txt Denne linjen endret Alice på sin maskin ======= Disse linjene endret Bob på sin maskin >>>>>>> theirs:eksempel.txt Disse linjene var også problemfrie for versjonskontrollprogrammet.

Github er den mest populære skytjenesten for dem som samarbeider og bruker versjonskontrollprogrammet Git. Andre alternativer er Gitlab og Bitbucket. Hvis du vil programmere mye i fremtiden, er versjonskontroll en av de nyttigste tingene du kan lære deg. Dessverre er ikke versjonskontrollprogrammene spesielt begynnervennlige. Det tar tid å beherske dem godt. Før vi behersker dem, er det lett å gjøre feil som vi ikke har forutsetning for å rette opp i.