C.2
Bakgrund och teori
I denna sektion presenteras en kort historisk översikt över versionshantering med fokus på Git och Github samt förklaring av de tre metoder som kommer undersökas: pull-baserad, centraliserad och merge-baserad.
C.2.1
Tidiga versionshanteringssystem
Versionshanteringssystem för mjukvara har funnits sedan tidigt 70-tal, ett tidigt exempel är SCCS utvecklat hos Bell Labs. [42] Många av dessa tidiga system använde mjukvarulås så att enbart en person kunde redigera en fil åt gången. Dessa system kommer inte behandlas mer i denna rapport.
C.2.2
Moderna centraliserade versionshanteringssystem
Eftersom tidiga system hade problemet att bara en person kunde redigera en fil i taget ut- vecklades system där källkoden huserades på en server som utvecklarna kunde ”checka ut”. Detta skapade en kopia på utvecklarens dator där utvecklaren kunde göra ändringar. Innan utvecklaren kunde spara sina ändringar på den centrala servern var utvecklaren tvungen att sammanfoga sina ändringar med eventuella ändringar som skett på servern under utveck- lingstiden. Utvecklaren kunde efter detta spara sina ändringar genom en commit.
Det är denna metod som kommer refereras till som centraliserad metod. Centralisering syftar på att det enbart finns ett repositorium.
C.2.3
Decentraliserade versionshanteringssystem
I början av 2000-talet kom de första decentraliserade versionshanteringssystemen. Dessa sy- stem har inget centralt repositorium i meningen att det bara finns ett repositorium på en server som utvecklarna enbart gör en grundkopia av. Fördelen med dessa system är att alla utvecklare har sitt eget repositorium. Detta betyder att utvecklaren inte behöver vara kopp- lad mot ett nätverk för att utför en commit. Detta tillåter också många funktioner att vara betydligt snabbare eftersom mjukvaran inte behöver vänta på ett svar från den centrala ser- vern.
En av dessa system är Git och det är enbart Git som kommer behandlas i denna rapport2. Git utvecklades för att hantera versionshanteringen av Linux, ett projekt med över 1 500 aktiva utvecklare. [43] Git kommer även användas för att hantera hela Windows operativsystemet. [44]
C.2.4
Git + webbhotell
Ett populärt sätt att använda Git är via webbhotell som Github. Github hade i april 2017 nästan 20 miljoner användare med 57 miljoner repositorier och 100 miljoner pull requests. [45] En pull request är en inbyggd funktion Github och många andra webbhotell har som tillåter en användare med en fork av ett repositorium att begära en annan användare som forkat samma repositorium att sammanfoga deras kodändringar.
Fördelen med denna metod är att den sänker tröskeln för kodbidrag eftersom det enda bi- dragsgivaren behöver ha är ett konto på webbhotellet. Webbhotellet sköter i sin tur gräns- snittet för kodsammanfogningen samt diskussion kring kodändringarna. Det finns även fler fördelar med denna metod som till exempel enkel integrering med automatiska kodtester, denna undersökning behandlar enbart själva versionshanteringen och arbetsflödet kring det.
C.3. Metod
Det är dock viktigt att ha dessa andra fördelar i åtanke när man undersöker hur metoden har adopterats i diverse mjukvaruprojekt.
Detta har blivit ett populärt sätt att hantera många open source-projekt. Det är även denna me- tod vi valde för att hantera projektet. Metoden benämns ofta pull-based development översatt till pull-baserad utveckling.
C.3
Metod
Denna undersökning kommer baseras på de erfarenheter jag själv hade som konfigurations- ansvarig samt hur de andra projektmedlemmarna uppfattade metoden jämfört med tidigare erfarenheter. För att samla de andra projektmedlemmarnas åsikter angående den använda metoden så används ett formulär som alla medlemmar förutom konfigurationsansvarig sva- rade på.
Formuläret bestod av följande ”ja/nej”-frågor:
1. Har du använt denna metoden av versionshantering tidigare?
2. Var dina tankar kring metoden positiva när konfigationsansvarig presenterade den? 3. Tycker du att metoden var enkel att lära sig?
4. Tycker du att latensen mellan skapad och sammanfogad PR var tillräckligt liten för att vara acceptabel?
5. Tycker du att metoden förenklade lösning av problem relaterade till sammanfogning (merge) av kod?
6. Tycker du att metoden var smidig att utföra? (Tidsmässigt, svårighetsgrad och så vida- re)
7. Tycker du att metoden gjorde samarbete med övriga gruppmedlemmar enklare? 8. Om du har använt centraliserad versionshantering tidigare (SVN till exempel): Tycker
du att pull-baserad versionshantering fungerade generellt bättre?
9. Om du har använt decentraliserad versionshantering tidigare fast med en annan metod: Tycker du att pull-baserad versionshantering fungerade generellt bättre?
10. Skulle du rekommendera att använda denna metod i framtiden i ett projekt av samma storlek som kandidatprojektet?
Detta ger en väldigt ungefärlig överblick över hur stor andel av projektgruppen som ansåg att metoden påverkade arbetsflödet positivt samt inkluderar tidigare erfarenheter. Formuläret existerar inte för att bevisa något utan bara för att fånga gruppens generella tankar.
Fråga 1 och 2 visar personens förutsättningar för hur de kommer ta emot metoden. Fråga 3 till 7 försöker ge en blick om det var någon del av metoden som inte fungerade bra. Fråga 8 och 9 jämför metoden med tidigare använda metoder. Fråga 10 visar om personen tyckte metoden var bra nog för att användas igen i ett annat projekt.
För att göra en bra jämförelse mot andra former av versionshantering kommer diverse ar- tiklar användas samt att jag kommer dra vissa slutsatser utifrån handlingar av företag och människor.
C.4. Resultat
C.4
Resultat
Resultaten sammanställs i tre delar: resultat från undersökning, resultat från egen erfarenhet och resultat från enkät besvarad av övriga projektmedlemmar.
C.4.1
Undersökning
Den största anledningen till att decentraliserade versionshanteringssytem har vuxit så snabbt är för att de tillåter utvecklare att enkelt jobba i mindre och sammanhängande branches. [46] Faktumet att systemet inte är centraliserat är alltså inte en anledning till att många väljer denna typ av system. Det visar sig till och med att många öppna mjukvaruprojekt väljer att använda decentraliserade versionshanteringssystem med ett centraliserat repositorie för att synkronisera utvecklingen. [46]
En av anledningar till att utvecklare föredrar utveckling med hjälp av branches är för att det förenklar kodsammanfogningar avsevärt. [40] Detta är naturligt eftersom varje branch har sin egen historia och syfte oberoende av andra aktiva branches. Sammanfogningen av dessa branches blir därav enklare eftersom varje branch försöker fylla sitt eget syfte. Decentralise- rade versionshanteringssystem som Git är även designade från grunden för att lösa problem med patchning tillskillnad från äldre system som enbart försökte lösa problem relaterade till filversionshistorik. [40]
En av de stora skillnaderna mellan pull-baserad utveckling och övriga metoder av versions- hantering är att pull-baserad utveckling kräver användadet av branches. [46] Detta sker an- tingen genom att deltagaren börjar med att förgrena ett centralt repositorium som deltagaren sedan jobbar mot eller genom att deltagaren klonar det centrala repositoriumt och skapar branches utifrån klonen. För att den sistnämnda metoden skall fungera krävs att deltagaren har skrivrättigheter till det centrala repositoriumt, något som sällan sker eftersom detta mås- te ges på en individuell nivå. Detta blir ett krav eftersom det är enbart på detta sätt man kan använda pull requests. Man kan även välja att ingen kod kan sammanfogas till det centrala repositoriumt utan att först gå igenom en godkänd pull request, något som behandlas i nästa del.
Merge-baserad versionshantering använder också branches flitigt, skillnaden mot pull- baserad hantering är att i den merge-baserade måste kodändringar och sammanfogning ske via en annan metod, till exempel: patch submissions, mejllistor och bugzilla3. [47] Den stora skillnaden mellan dessa två metoder är enbart vägen som kodändringarna tar innan de an- länder i repositoriumt. Det visar sig dock att användning av pull requests över mejlbaserad patchning leder till högre effektivitet, effektivitet i detta fallet är tiden mellan att en kodänd- ring görs och när den blir accepterad. [40]
Eftersom man använder Git på ett liknande sätt i både merge- och pull-baserad versions- hantering kan det vara svårt att bedöma fördelar/nackdelar strikt relaterade till versions- hantering. Pull-baserad utveckling leder naturligt till konversation angående kodändringar eftersom detta är integrerat i pull requests. Både merge- och pull-baserad utveckling kan välja att föra konversationen via annat medium, man kan därför se detta som en fördel för pull- baserad versionshantering då denna metod erbjuder mer alternativ. Detta kan dock också ses som en nackdel om deltagare anser att webbhotellets implementation av diskussion inte är till en fördel men att metoden påtvingar denna metod då den inte har något implementa- tionskrav för utvecklarna.
Anledningen till varför pull-baserad utveckling används över merge-baserad, utöver de funktioner som inte behandlas i denna undersökning, verkar främst vara att man inte be-
C.4. Resultat
höver ge alla utvecklare skrivrättigheter till det centrala repositoriumt. Trots det höjs inte tröskeln för kodbidrag som för den merge-baserade metoden. Det är alltså inte säkert att den- na metod skulle vara lika populär i mindre projekt där kommunikation och tillit behandlas på annat sätt än för öppna mjukvaruprojekt.
C.4.2
Egna erfarenheter
En av kraven i kandidatprojektet som denna rapport behandlar var att alla i projektgruppen skulle bli tilldelade en roll, bland dessa roller var konfigurationsansvarig (KA). KAs jobb var främst att skapa samt underhålla versionshantering av gruppens källkod och dokument. I projektgruppens falls blev KAs primära jobb att bestämma hur versionshantering av källkod skulle fungera samt utbilda resterande projektmedlemmar i detta. För att underlätta arbe- tet som KA föreslogs pull-baserad versionshantering som metod eftersom KA använt denna metod i ett flertal andra projekt. Denna metod såg ingen invändning från övriga projektmed- lemmar.
För att förenkla arbetet gjorde KA en Contributor’s Guide. Denna guide förklarade hur man kom igång med versionshanteringsmetoden och ett rekommenderat arbetsflöde. Detta ar- betsflöde beskrivs i figur C.1. Liknande flöde hade varit möjligt utan att tvinga utvecklaren att göra en fork av det centrala repositoriumt. En fördel med att detta är dock att varje ut- vecklare inte behöver skrivrättigheter till någon del av det centrala repositoriumt samt att utvecklaren inte behöver oroa sig över om deras utvecklingsbranch har samma namn som någon annans. Centralt repositorie Synkronisation Branch Pull request PR Merge Utvecklarens fork Commit
Figur C.1: Rekommenderat arbetsflöde
Från KAs perspektiv verkade det inte som att arbetsflödet eller den pull-baserade metoden var svår att lära sig. Över projektets gång accepterades över 150 pull requests, alltså cirka 1 pull request om dagen. Majoriteten av utveckling skedde dock under en period av 2 måna- der, alltså cirka 2.5 pull requests accepterad per dag. Eftersom projektgruppen bestod av sju medlemmar som arbetade cirka 20 timmar varje vecka samt att inte alla projektmedlemmar programmerade aktivt anser KA detta som att metoden inte orsakade några problem. Denna slutsats kan dras om man anser att en människa med 40 timmar per vecka i arbetstid ska medverka med en pull request om dagen i snitt.
För att förminska mängden kod av låg kvalité som sammanfogades med det centrala repo- sitoriumt behövde varje pull request även accepteras av en annan projektmedlem. Detta bör öka livslängden för en pull request, något som kan ses som negativt. [47] Detta är dock inget krav för pull-baserad versionshantering, men det är något som redan är implementerat och tillgängligt via de flesta webbhotells gränssnitt för pull requests.