E-NN. xx-xx

Transkript

1 Navn: Fødselsdato: Skole: Fag: Dato for prøveaflæggelse: E-NN xx-xx-98 EUC Nordvestsjælland Stud.pro, Større skr. opg (4937--)

2 Titelblad til SRP opgaveformulering Elev: E-NN Klasse: 3.? Studieretningsfag på A-niveau: Andet fag og niveau: Teknologi A ITK B Georg Strøm Erik Lund Vejleder Opgaveformulering Titel: Open Source softwareudvikling - central og decentral versionskontrol Der ønskes en undersøgelse af fordele og ulemper, når udviklingen af software går fra centraliseret til decentraliseret versionsstyring. Når softwareudvikling går Open Source skaber det nogle udfordringer med hensyn til at styre udviklingsprocessen og især styringen af, hvilke versioner der er aktuelle, hvilke der ikke er og hvilke, der afhænger af ændringer andre steder i softwaren. Disse problemer er ikke de samme, når udviklingen foregår inden for en traditionel, hierarkisk organiseret virksomhed, hvor styringen kan være mere centraliseret. Der skal laves en IT baseret teknisk gennemgang af de principper for source management, der anvendes i de analyserede systemer til versionskontrol, herunder en analyse af de fejl der kan opstå i forbindelse med revisionskontrol, risikoen for dem og håndteringen af dem ved central og decentral versionskontrol i de analyserede systemer. Der skal laves en teknologianalyse, som sammenligner mindst et system til central versionskontrol med mindst et system til decentral versionskontrol. Analysen skal omfatte en beskrivelse af ligheder og forskelle i produktet eller resultatet af de to typer af revisionskontrol. Til slut skal det diskuteres og konkluderes, på hvilke måder overgangen fra centraliseret til decentraliseret revisionskontrol kan øge eller mindske hastigheden og antallet af fejl ved udvikling af software, og hvilken perspektiver det kan have for Open Source softwareudvikling. Det centrale system til versionskontrol Apache Subversion og det decentrale system Git Hub kan bruges som case eller eksempler til belysning af problemformuleringen. Forventet omfang Evt. fordybelsesfag Evt. note til bedømmere Omfang svarende til A4 sider (2.400 anslag pr. side) ekskl. forside, indholdsfortegnelse, fodnoter, litteraturfortegnelse og bilag samt eventuelle tabeller eller illustrationer, uanset om disse er placeret i selve teksten. Opgavebesvarelsen afleveres senest d. 21. december kl i "Netprøver.dk". Opgaveformuleringen (hele denne side) indsættes forrest i besvarelsen.

3 Elias Z. Jørgensen 3z SRP Teknologi A og ITK B 21/ Open Source Softwareudvikling Central og Decentral Versionskontrol Slotshaven Gymnasium Teknologi A: Georg Strøm ITK B: Erik Lund Anslag: E-NN 21/ kl. 10:00 SRP Teknologi A og ITK 2/14 B

4 Kommentarer til opgavebeskrivelsen I opgaveformuleringen står der at det decentrale system Git Hub kan bruges, hvilket er ukorrekt. Git Hub, eller GitHub som det staves korrekt, er en platform til at opbevare, dele og administrere kildekoden til software projekter. Git derimod, er det decentrale versionskontrolsystem, som er hvad min vejleder må have ment. Abstract This report examines the use of centralised and decentralised version control models used in the software industry and Open Source software development. It will explain why version control is being used, how it works, and how the two models differentiate, using the popular Subversion and Git version control systems as an example. This will be followed by an explanation and analysis of common Source Management principles used in software development, and how they solve common problems. Thereafter it showcases a comparative technology analysis of the two version control models, again using Subversion and Git as examples, which will determine the strengths and weaknesses of each model. Lastly it will discuss and conclude, how the transition from a central to a decentral version control model can impact the speed and amount of errors in software development, along with a view of the two models seen from the Open Source perspective, using Linux as an example.

5 Indholdsfortegnelse 1. Afgrænsning Indledning Redegørelse af versionskontrolsystemer Centraliseret versionskontrol - Apache Subversion Decentraliseret versionskontrol - Git Source Management Atomiske Operationer Fil låsning Version Merging Tags Mulige fejl og håndtering deraf Teknologianalyse af versionskontrolsystemer Apache Subversion Viden Organisation Teknik Produkt Git Viden Organisation Teknik Produkt Centraliseret kontra Decentraliseret versionskontrol Overgangen fra Centraliseret til Decentraliseret Konklusion Litteraturliste... 13

6 1. Afgrænsning Jeg vil i denne rapport fokusere på versionskontrolsystemer der bruges til at administrere softwareprojekter, og ikke andre typer af versionskontrol der f.eks. bruges til at holde styr på forskellige versioner af dokumenter, rapporter, billeder, osv. Jeg vil fokusere på de to mest brugte versionskontrolsystemer Subversion (Apache, 2016) og Git (Git, 2016), i min redegørelse og analyse. Dette har jeg valgt eftersom at det er dem der bedst afspejler brugen af versionskontrol i softwareindustrien, og samtidig repræsenterer både de centrale og de decentrale versionskontrolsystemer. Da målet med denne rapport er, at være forståelig for både tekniske og mindre tekniske personer, vil jeg ikke gå i dybden med de mere avancerede dele af versionskontrolsystemer, såsom rebasing, da det ville gøre mere skade end gavn, og samtidig ikke er behøvet viden, for at kunne sammenligne de to forskellige typer af arkitekture. 2. Indledning Når en gruppe af mennesker har brug for at udvikle på samme softwareprojekt, så er der nogle forskellige måder at gøre det på. Én måde man kunne gøre det på ville være, at alle udviklere skiftedes til at redigere i projektet. Det fører dog til, at alle skal vente til at det bliver deres tur, hvilket spilder en masse dyr udvikler tid. En anden måde at gøre det på er, at alle har en kopi af projektet, og indbyrdes blev enige om hvilke filer, man hver især måtte redigere i. Det skaber dog problemer, når de skal til manuelt at stykke al koden sammen igen, og senere når de begynder at have forskellige versioner af projektet, og måske ikke kan blive enige om, hvem det er, der har den nyeste version. En bedre løsning kunne derfor være at bruge et versionskontrolsystem. Det sparer udviklerne for en masse unødvendige frustrationer og øger effektiviteten, da det gør det muligt for alle udviklerne at redigere i projektet på samme tid, og slippe for at have forskelige mapper liggende med forskellige versioner af projektet. Versionskontrol gør det derudover muligt for udviklerne at have forskellige versioner af et projekt uden obskure mappestrukturer, der øger chancen for fejlhåndtering (Git-Tower, 2016). I denne rapport vil jeg diskutere hvordan overgangen fra centraliseret til decentraliseret versionskontrol har påvirket effektiviteten for softwareudvikling, i lukket såvel som Open Source software. Der vil derudover indgå en komparativ teknologianalyse af de to versionskontrolsystemer Subversion og Git samt en teknisk gennemgang med udgangspunkt i analysen. 3. Redegørelse af versionskontrolsystemer Det underliggende mål med versionskontrolsystemer er, at tillade udviklerhold at have en komplet historie af alle ændringer, der er blevet foretaget, og på samme tid gøre det muligt at arbejde på forskellige versioner samtidig og uafhængig af hinanden. 1/14

7 Det opnår versionskontrolsystemer ved at opbevare projektet i en grafstruktur (Wikipedia, 2016). Grafen er opbygget som et omvendt træ med sammensættelige grene. Til højre ses et eksempel. I midten af træet har vi stammen, markeret med grøn, som er standard grenen i versionskontrolsystemer. Man kalder den stammen, fordi det er den del af grafen, man oftest forgrener ud fra. Hver gang en udvikler har lavet et sæt ændringer, laver personen et commit (markeret med gul), som er en samling af ændringer, ved hjælp af versionskontrolsystemet. Derfor indeholder et commit kun de ændringer som udvikleren har lavet og ikke alle de forskellige filer i projektet. Alle commits får en unik identifikator, ofte i form af en såkaldt hash af commitet. En hash er en funktion, der transformerer en mængde data om til et unikt hexadecimal tal, der repræsenterer al indholdet i dataen (Wikipedia, 2016). I eksemplet til højre bruges der dog små hele tal, for at hjælpe med forståelsen af strukturen. Når en udvikler har lavet et commit, indsætter versionskontrolsystemet det som en node i grafen. Grene laves for at undgå konflikter, som der opstår hvis flere forskellige udviklere har lavet ændringer det samme sted i kodebasen. De laves også for at tillade udviklere at arbejde på nye features, bugfixes (rettelse af fejl), eller andet, der er/skal være isoleret fra resten af projektudviklingen, så de ikke skal tænke på hvordan de andre udvikleres Figur 1 - Eksempel på en historiegraf af et projekt, der gør brug af versionskontrol (Wikipedia, 2016). ændringer påvirker deres egne. Når man er færdig med sin gren, kan man merge med en anden gren eller stammen, for at forene ens gren med den anden gren. Et eksempel på dette ses også til højre, hvor at commit nr. 2 er forgrenet ud fra commit nr. 1, commit nr. 3 forlænger grenen som commit nr. 2 dannede og commit nr. 4 indeholder alle ændringerne fra grenen, som commit nr. 2 startede. Når udviklerholdet så er færdig med alt, der skal laves til en ny version af deres projekt, kan de lave et tag, kendt i dagligdags tale som en udgivelse. Et tag opfører sig lidt som en gren, med den undtagelse at den aldrig ændrer sig. Man kan se på det som at være en mærkat, der fortæller hvilken version man er nået til, på det givne sted i projektets historik. Ved at versionskontrolsystemet holder styr på ændringer i projektet på denne måde, gør den det muligt at spole tilbage i projektets historie, hvis en udvikler får lavet et forkert commit, eller hvis udviklergruppen bliver enige om at de er gået i den forkerte retning med projektet. For at det er muligt for et udviklerhold at arbejde på deres projekt samtidig ved hjælp af et versionkontrolsystem, er der dog brug for en måde for udviklerne at dele deres ændringer med resten af holdet. Derfor gik man fra at bruge lokal versionskontrol, hvor at versionkontrolsystemet opbevarede al 2/14

8 dataen på den individuelle udviklers system, til at bruge netværksopkoblede versionskontrolsystemer. Iblandt disse er Subversion og Git. 3.1 Centraliseret versionskontrol - Apache Subversion Subversion blev udgivet i 2004, som en efterfølger til det populære centraliserede versionskontrolsystem CVS (Wikipedia, 2016). Subversion blev udviklet for at rette de fejl som CVS havde, og for at tilføje nogle at de funktioner som det manglede. I november 2009 tog Apache projektet under deres vinger, hvor fra det er blevet videreudviklet og vedligeholdt lige siden. Med centraliseret versionskontrol har man en enkelt server, der indeholder versionskontrolsystemet, samt alle ændringer, grene ol. som udviklerne laver. Dertil har hver udvikler et program på deres system, en versionskontrol klient, der kan kommunikere med serveren (Git, 2016). Her kan udviklerne igennem deres klient hente den nuværende version af projektet, på den givne gren. Når de så skal lave et commit, bruger de deres klient til at sende det til serveren, som tilføjer det til historie-grafen. Herefter kan en anden udvikler bruge sin klient til at synkronisere med serveren, for at få de nyeste ændringer ned på hans eget system, så han kan arbejde videre med dem der. Centraliserede versionskontrolsystemer, som Subversion, bliver ofte brugt i større softwarefirmaer, der typisk følger en lidt mere lineær udviklingsproces. Til højre ses et eksempel på dette, hvor både Computer A og Computer B kan hente de samme filer fra en fælles versionskontrol server. Denne struktur har en masse fordele. Blandt andet giver den et overblik over, hvad udviklerne hver især arbejder på, hvilket gør det nemt for administratorerne at have fin kontrol med projektet. Figur 2 - Eksempel på strukturen i et centraliseret versionskontrolsystem. Derudover er det langt nemmere at administrere et centraliseret versionskontrolsystem end at administrere lokale versionskontrolsystemer på alle udviklernes systemer (Git, 2016). Der er dog også visse ulemper, såsom at man med et centraliseret versionskontrolsystem har ét enkelt punkt, hvor, hvis der er noget galt, så er hele udviklerholdet ude af stand til at arbejde, før problemet er løst. Hvis serveren er nede i en time, er udviklerne ikke i stand til at gemme ændringer hele den time, og hvis harddisken, der ligger på serveren, bliver korrupt eller går ned, og man ikke har et ordentligt backup system sat på plads, så mister man al den data som serveren indeholdte (Git, 2016). Der er også den ulempe at man typisk har en administrator ansat til at administrere ens versionskontrolserver, da det ikke er muligt for udviklerne at udrede potentielle problemer, f.eks. ved at sende ændringer, fra deres eget system. Et andet typisk problem er hastigheden, da udviklerens system skal vente på at serveren bliver færdig med hvad den laver, før den kan sende et commit afsted. 3/14

9 3.2 Decentraliseret versionskontrol - Git Git blev udgivet i år 2005 og blev udviklet af Linux Torvalds (Wikipedia, 2016), til brug under videreudviklingen af Linux (Wikipedia, 2016). Git blev udviklet, da BitKeeper (Wikipedia, 2016), versionskontrolsystemet der førhen blev brugt til videreudviklingen af Linux, stoppede med at tilbyde en gratis licens til ikke-kommerciel brug, hvilket resulterede i at mange af de frivillige udviklere måtte stoppe med at bidrage til projektet. Med den decentraliserede versionskontrol model som Git bruger, har man ofte en server, der indeholder al versionskontrol dataen fra ens projekt dette er dog ikke påkrævet. Forskellen på Subversion er dog her, at udviklerne, i stedet for at hente de filer som Subversion laver ud fra historiegrafen, henter al versionskontrol dataen ned på deres eget system (Git, 2016). Dette har nogle umiddelbare fordele ved, at hvis serveren dør, så har alle udviklerne en komplet kopi af hele projektets historik, som de kan bruge til at sætte en ny server op. Det er derudover markant hurtigere at lave et commit, da det bliver lavet direkte på udviklerens system, og ikke skal sendes til den centrale server. I stedet kan udvikleren lave en serie af commits, og sende dem til serveren på én gang, når han er færdig. En anden fordel er, at udviklerne ikke kun kan sende commits til den centrale server, men også til hinanden. Dette tillader udviklerholdet at opsætte udviklings workflows, som ikke er mulige med centraliserede versionskontrolsystemer (Git, 2016). Et berømt eksempel på en sådanne type af workflow er Dictator and Lieutenants modellen, som bliver brugt til videreudviklingen af Linux (Git, 2016). Denne fleksibilitet har resulteret i at Git er blevet et utroligt populært værktøj, især i Open Source verdenen. En undersøgelse fra 2015, udført af Stack Overflow, har vist at 69% af softwareudviklere bruger Git (Stack Overflow, 2015). Figur 3 - Eksempel på strukturen i et decentraliseret versionskontrolsystem. 4/14

10 4. Source Management For at sikre sig at udviklingen af et stykke software forløber med en minimal mængde af problemer, har man igennem tiden udviklet en serie af principper og teknikker, der kan hjælpe et udviklerhold med at opnå dette (Wikipedia, 2016). 4.1 Atomiske Operationer Atomiske operationer er en velkendt teknik der bliver gjort brug af alle steder i softwareindustrien, for at sikre sig at et givent projekts historik er klar, kortfattet, og overskuelig. Teknikken går ud på at alle udviklere skal bygge deres ændringer op omkring atomiske ændringer. En atomisk ændring er en ændring, der kun drejer sig omkring én enkelt opgave, som at rette en fejl i koden, eller lave en ændring i et layout på en brugergrænseflade. Man kalder disse ændringer atomiske, da det ikke er muligt at splitte ændringen ud i flere forskellige ændringer, da ændringen kun berør en enkelt del af systemet (Wikipedia, 2016). Dette tillader udviklere at gå tilbage i projektets historik uden at påvirke andre ændringer, samtidig med at det gør det lettere at merge funktioner, og andre ændringer, med andre grene. 4.2 Fil låsning Fil låsning er en funktion der oftest findes i centraliserede versionskontrolsystemer som Subversion, hvor at forgrening er mindre normalt. Fil låsning bliver brugt til at begrænse adgangen til at ændre i en given fil, til én udvikler ad gangen (Wikipedia, 2016). Grunden til at dette bliver gjort, er for at sikre sig at det ikke er muligt, at én udvikler gemmer en ændring i en fil, som en anden udvikler senere overskrider. Dette gøres muligt, ved at versionskontrolsystemet går ned på et filsystem niveau og markerer filerne som read-only. Hvis en udvikler ønsker at lave en ændring i en fil, bliver den givne udvikler nødt til at udføre en unlock operation. Indtil at udvikleren er færdig med sine ændringer, eller beslutter at han ikke vil lave en ændring i filen alligevel og gør filen tilgængelig igen, er det ikke muligt for de andre udviklere at lave ændringer i filen. 4.3 Version Merging Version merging er en teknik, der er indbygget i de fleste moderne versionskontrolsystemer. Som navnet fortæller går teknikken ud på, at udføre en merge operation på forskellige versioner, af en given fil (Wikipedia, 2016). Teknikken eksisterer for at tillade udviklere at samle flere forskellige versioner af en fil, til en fil der indeholder ændringerne fra de givne versioner. Hvis en udvikler laver ændringer i en fil og sender dem til den centrale server, eller en anden udvikler, som i den samme fil har ændringer, som udvikleren ikke havde, vil der være et problem med modstridende versioner af filen. Her kan udvikleren igennem versionskontrolsystemet udføre et merge af de modstridende filer, for at samle dem. 5/14

11 Der vil dog opstå det man kalder konflikter, hvis de forskellige versioner har introduceret ændringer de samme steder i koden. Her er det udviklerens opgave at bestemme hvilke ændringer der skal være i den endelige version af filen, for at sikre at softwaren virker efter hensigten. 4.4 Tags I løbet af (videre)udviklingsforløbet af et stykke software, er det meget normalt at have et behov for at udgive nye versioner, til f.eks. retning af fejl eller nye funktioner. Til dette har de fleste moderne versionskontrolsystemer en tag funktion, der tillader udviklere at markere en specifik version af projektet (Wikipedia, 2016). Denne funktion findes også under andre navne, heriblandt baseline og label. Dette opnår udvikleren, ved at udføre tag operationen, og fortælle versionskontrolsystemet hvilket commit, det skal sætte tagget fast på. Ved at gøre det på denne måde, ved versionskontrolsystemet at det givne tag er resultatet af det givne commit, samt alle foregående commits. Efter at denne operation er udført, er det muligt at eksportere denne version fra versionskontrolsystemet, som man derefter kan distribuere til sine brugere. 4.5 Mulige fejl og håndtering deraf Som med alle andre avancerede værktøjer, er der et utal af ting der kan gå galt, hvis ikke man passer på. Og som med alle andre avancerede værktøjer, er størstedelen af disse menneskelige fejl, der opstår når brugeren ikke er tilstrækkeligt uddannet i brugen af værktøjet. Man skulle tro at centraliserede versionskontrolsystemer som Subversion var den største synder her, da alt hvad udviklerne gør gennem deres klient, har en effekt på den centrale server. Men, da Subversion er bygget op omkring ideen af udviklere og administratorer, er der ikke meget en udvikler kan gøre, som administratoren ikke kan lave om. Dette sikkerhedsnet findes dog ikke for administratoren, hvor det er forventet at man ved præcis hvad ens aktioner har, af konsekvenser. Et eksempel på dette kunne være, hvis en udvikler har set sig sur på deres chef, og beslutter sig for at lave et commit, hvor at personen sletter alle filerne i kodebasen. Da alle commits bliver opbevaret i en historie graf, kan administratoren fikse problemet, ved at spole tilbage på historie grafen, til før udviklerens commit blev lavet. Vælger administratoren at lave om på historikken, og sletter commitet i stedet, kan en del af projektets historik gå tabt, hvis administratoren ved et uheld kommer til at slette mere end det enkelte commit. Her er Gits decentraliserede model dog farligere, da det spreder ansvaret ud kollektivt blandt udviklerne, hvilket betyder at alle har mulighed for at skrive historien om, hvis de ønsker det. Den decentraliserede model løser dog selv samme problem, da alle udviklerne har en komplet lokal kopi af historien, hvilket betyder at hvis én udvikler får omskrevet historien i projektet, kan en anden udvikler rette det, relativt smertefrit. Som nævnt tidligere, opstår størstedelen af disse problemer dog oftest, på grund af manglende viden. Derfor er det selvfølgelig i alles interesse, hvis nye udviklere sætter sig godt ind i brugen af systemet, før de begynder at have med den rigtige kodebase at gøre. 6/14

12 5. Teknologianalyse af versionskontrolsystemer I denne analyse vil jeg anvende puslespilsmodellen, da det er den bedst passende model, fra Teknologi A faget. 5.1 Apache Subversion Viden Viden omkring brug af Subversion Viden omkring administration af Subversion Teknik Server software (Subversion) Klient software Server maskine Backup system Organisation Administrator(er) Udviklere IT-folk Produkt Centraliseret struktur Lineære udviklingsworkflow Single point of failure For ufleksibelt til store Open Source projekter Jeg vil tage udgangspunkt i et softwarefirma, da brugen af Subversion i Open Source verdenen er minimal Viden For at være i stand til at bruge Subversion er der et behov for, at alle ens udviklere er i stand til at udnytte systemet. Dette kan betyde, at hvis man har udviklere der ikke har erfaring med Subversion, bliver de nødt til at blive uddannet i det. Hertil har fællesskabet omkring Subversion kreeret en bog, som blandt andet har en gratis e-bog version, til at uddanne nykommere såvel som erfarne brugere, omkring alle Subversions funktioner, samt brug af dem (Pilato, Collins-Sussman, & Fitzpatrick, Version Control with Subversion: Next Generation Open Source Version Control, 2008). Det er dog ikke kun udviklerne, der har behov for en hvis viden, firmaets Subversion administrator bliver nødt til at være en ekspert i de værktøjer som Subversion stiller til rådighed, for at sikre at firmaets software forbliver i god stand, og for at hjælpe udviklere med at udrede de problemer, der kan opstå i løbet af et udviklingsforløb (Pilato, Collins-Sussman, & Fitzpatrick, Repository Maintenance, 2008) Organisation Ved at bruge Subversion på en større skala er det en præmisse for firmaet at ansætte mindst en administrator til at administrere Subversion systemet. Der er derudover brug for en IT-afdeling, hvis firmaet ønsker at have Subversion serveren internt i firmaet. De fleste større softwarefirmaer har dog en IT-afdeling i forvejen, så det er ikke sikkert, at dette er en ekstra udgift. Der findes dog også firmaer der tilbyder infrastruktur til Subversion, hvis man ikke ønsker at investere i den nødvendige hardware. En af de store distributører er Assembla, som adskillige softwaregiganter gør brug af (Assembla, 2016). Hvad der giver mest mening, intern eller ekstern infrastruktur, afhænger af det individuelle firmas krav til sikkerhed, tilpasning og service. Til sidst er der brug for udviklere med kompetencer indenfor Subversion, for at kunne gøre brug af versionskontrolsystemet i udviklingsprocessen. 7/14

13 5.1.3 Teknik For at indføre Subversion i et firma, er der nogle essentielle ting som man bliver nødt til at indføre, på managementsiden, såvel som udviklersiden. Som der blev nævnt tidligere, er det muligt at leje serverplads, hvorpå at Subversion er præ-installeret, hos blandt andet Assembla. Hvis man ønsker at have en intern løsning, er det muligt at hente Subversion fra Apaches hjemmeside, som man kan installere direkte på en server (Apache, 2016). Administrerings værktøjer er indbygget i Subversion installationen i form af en serie af kommando værktøjer, ønskes der dog en løsning med en grafisk brugerflade findes der adskillige løsninger, lavet af fællesskabet omkring Subversion, samt kommercielle løsninger. Et aktivt backup system er yderst vigtigt, for at sikre sig at man ikke mister data fra Subversion. Grundet Subversions centraliserede natur er dette essentielt, da det er muligt at miste historikken fra alle de projekter der ligger i systemet, i tilfælde af harddisk korruption eller at serveren dør. Bruger man en ekstern service som Assembla, er dette allerede gjort for en. Uden en Subversion klient er det ikke muligt for udviklerne at interagere med Subversion serveren. Subversion klienter findes i mange former både kommando baserede og med grafiske brugerflader, gratis og kommercielle. Der er ikke et rigtigt svar på, hvad man skal bruge. Det er op til den individuelle virksomhed at tage en beslutning i samarbejde med deres udviklere Produkt Subversion bruges bredt i softwarefirmaer, der gør brug af et centraliseret versionskontrol workflow. Det gør brug af en striks centraliseret model, hvilket har den fordel, at alt kan findes ét sted. Det har dog også nogle store ulemper, da det ikke er muligt for udviklerne at hente/sende commits, medmindre de er koblet på internettet, og at Subversion serveren kører uden problemer. Her er det som udgangspunkt vitalt for firmaet at tage regelmæssige backups for at sikre, at de ikke mister værdifuld software historik. Subversion passer bedst ind i virksomheder med lineære udviklingsprocesser i form af f.eks. vandfaldsmodellen (Wikipedia, 2016), grundet dens ufleksible natur, der spænder ben for eksperimentering og udvikling i regioner med suboptimal internetopkobling. Af denne grund bliver Subversion sjældent brugt til Open Source projekter, da de kræver langt større fleksibilitet og skalerbarhed, da det som Figur 4 - Vandfalds modellen (Wikipedia, 2016) udgangspunkt skal være muligt for alle at foreslå ændringer i projektets kildekode, uden at lave ændringer direkte i projektets historie (Samsung Open Source Group, 2016). 8/14

14 5.2 Git Viden Viden omkring brug af Git Teknik Versionskontrol software (Git) Valgfri Server maskine Valgfrit Backup system Organisation Udviklere Valgfri IT folk Produkt Fleksibel Decentraliseret/Distribueret struktur Bred mulighed for udviklingsworkflow Hastighed Jeg vil tage udgangspunkt i et generelt udviklerhold, da brugen af Git er populær i softwarefirmaer, såvel som Open Source verdenen Viden For at et udviklerhold kan tage Git i brug, har de brug for uddanne sig i brugen af det, hvis ikke de har tidligere erfaring med det. Git har en officiel bog, der er gratis tilgængeligt på deres hjemmeside, som alle kan læse for at få en forståelse omkring brugen af Git og dets mange muligheder (Chacon & Straub, 2014). Git er dog det mest populære versionskontrolsystem i softwareindustrien, hvilket resultere i at det er hvad de fleste udviklere lærer at bruge, på deres første udviklerjob Organisation Grundet Gits decentraliserede natur er der ikke behov for administratorer til Git servere, da al dataen afspejles på alle udviklernes maskiner, hvilket gør det til et fælles ansvar blandt udviklerne at have orden i projektets historik. I tilfælde af Open Source projekter, der gør brug af Git, vil man typisk have brug for et sted at opbevare sin kode. Det er for at give nye udviklere et bedre overblik og for at fremvise sit projekt til omverdenen, dertil fungerer det som en backup. Til det formål er der services som GitHub, der både giver udviklere mulighed for at skabe et image i Open Source verdenen, og samtidig tillader det virksomheder at opbevare deres kode et sikkert sted, kun tilgængeligt for ansatte (GitHub, 2016). GitHub tilbyder derudover en business løsning, der lader firmaer have en version af GitHub kørende på egne servere. I tilfælde af at en løsning som GitHub køres på egne servere, er der typisk behov for en systemadministrator til at vedligeholde serverne GitHub kører på. Dette skal dog ikke forveksles med vedligeholdelse af GitHub som produkt, da det vedligeholdes af firmaet af samme navn Teknik Det eneste, der skal bruges for at komme i gang med Git, er Git i sig selv. Da Git er decentraliseret, kan det bruges på en server på samme måde, som det kan bruges lokalt på en udviklers computer. Dette tillader udviklere at dele deres lokale projekthistorik direkte med andre udviklere, uden at være tvunget til at bruge en central server. Grundet Gits store fleksibilitet er det også muligt at have en server, der kan bruges til at have en autoritær version af projektets historik, samtidig med at virke som et fælles adgangspunkt for projektet. 9/14

15 Et backup system er valgfrit, dog altid en god ide, når man bruger Git. Grunden til dette er, at alle udviklere på et projekt har en fuldstændig kopi af dataen, hvilket gør det muligt at hente dataen fra en anden udvikler i tilfælde af at man mister sig egen kopi Produkt Grundet Gits store fleksibilitet passer det perfekt til Open Source verdenen. Med Git er det muligt for udviklere at udføre operationer gennem versionskontrolsystemet på trods af mangel på internetforbindelse, og helt uden en central server, hvis man ikke har brug for det. Git brillerer især på sin hastighed, som det opnår ved at have en lokal kopi af al dataen, hvilket medfører at det slipper for at sende ændringer over netværket for at lave ændringer i historikken, som er utroligt tidskrævende for systemet. Gits hastighed er essentiel for blandt andet Linux, hvor en rapport fra 2012 viser, at Linux i gennemsnit har fået tilføjet 3509 linjer kode om dagen, i løbet af projektets levetid (Pingdom, 2012). Git passer ind i de fleste projekter, Open Source såvel som lukkede, som resultat af dets fleksible struktur. Git er lige så komplekst som man har brug for, hvilket betyder at man kan opnå et workflow med det, som passer perfekt ind i ens udviklingsproces. Et godt eksempel på dette er den førnævnte Dictator and Lieutenants model, som folkene bag Linux udnytter, hvilket gjorde det muligt, at der i 2013 var omkring forskellige individer, der hjalp til med at videreudvikle Linux (The Linux Foundation, 2013). Figur 5 Dictator and Lieutenants modellen. Dog er det stadig muligt at bruge en centraliseret struktur, hvis det bedre passer til ens behov. 5.3 Centraliseret kontra Decentraliseret versionskontrol Gits decentraliserede model gør det langt mere fleksibelt end Subversions strikte centraliserede model, hvilket har den betydning for en udviklergruppe at de kan tilpasse det til, hvordan de arbejder bedst. Derudover opbevarer Git en kopi af al dataen, hvilket gør det muligt for Git at være langt hurtigere end Subversion, som har kæmpe betydning for hold der arbejder med store kodebaser. Samtidig med dette, er det muligt at arbejde uden internetadgang, hvilket Subversion ellers kræver. Da Git overdrager alt ansvar til udviklerne, er der her ikke et behov for at have en administrator. Det er derudover heller ikke et krav at opbevare dataen på en server, da Git gør det muligt at dele dataen direkte mellem udviklerne. Det vil sige, at Git kan spare et firma/udviklerhold for en ekstra person, samt server infrastruktur, hvilket hurtigt kan spare dem en masse penge. 10/14

16 Alt dette gør, at Git er langt mere attraktivt for store Open Source projekter, der kræver fleksibilitet og hastighed, samt lave omkostninger. Den decentrale model gør dog Git mere kompliceret end Subversion, hvilket kan føre til menneskefejl hos især nye udviklere. Dette gør Gits fleksibilitet dog delvist op med, da det også er muligt at sætte en centraliseret workflow op, hvilket gør det nemmere for nye udviklere, samtidig med at virke bekendt for tidligere Subversion brugere. Alt dette viser at Git har langt flere fordele end Subversion, som kun er mere attraktivt på sin simplicitet. Git kan bruges i samme scenarier som Subversion tidligere er blevet brugt, dog med en højere hastighed og mulighed for at arbejde offline, samtidig med at være utrolig attraktiv for Open Source verdenen, der her behov for alternative workflows. Dette bekræfter Google Trends, der viser at interessen i Git har været højere end Subversion siden oktober 2011, og har vokset i takt med at interessen i Subversion har faldet (Google, 2016). 6. Overgangen fra Centraliseret til Decentraliseret Når man går fra at bruge en centraliseret versionskontrolmodel til at bruge en decentral, er der adskillige faktorer der kan spille ind, for at bestemme hvordan udviklingshastigheden, kodens kvalitet og mængden af fejl bliver påvirket. En undersøgelse fra Oregon State University fra 2014 viste, at udviklere der gjorde brug af et decentralt versionssystem i gennemsnit producerede commits med ¾ af størrelsen af commits produceret af udviklere der gjorde brug af et centraliseret versionskontrolsystem (Brindescu, Codoban, Shmarkatiuk, & Dig, 2014). Dette tyder på at udviklere der gør brug af et decentraliseret versionskontrolsystem er bedre til at følge princippet for atomiske operationer, hvilket kan stamme fra, at de ikke er nødt til at vente på den centrale server hver gang at de laver et commit, men kan gå direkte videre til næste opgave. Ventetiden som disse udviklere slipper for, kan også påvirke deres produktivitet positivt, da de ikke mister fokus, i den tid der bruges på at vente på den centrale server. Her er det også muligt at antallet af fejl bliver gjort mindre, da man må gå ud fra at udviklere producere kode af højere kvalitet, når de holder fokus. Store softwarefirmaer, der før i tiden typisk har gjort gavn af den centraliserede model, kan også have set muligheden for større produktivitet, og derved udviklingshastighed. Dette kan være grundlag nok i sig selv, for at skifte, da den decentraliserede model bedre skalerer sig ud til mange udviklere, ved hjælp af modellens mere udbredte brug af forgrening, der formindsker chancen for at udviklere skal vente på at kunne danne deres commits og dele dem med resten af gruppen. Overgangen fra centraliseret til decentraliseret versionskontrol har haft kæmpe betydning for store Open Source projekter som Linux, der ikke ville have muligheden for at operere på deres kæmpe skala, hvis ikke det var for den decentrale models fleksible natur. Set fra Linux perspektiv ville det heller ikke have været muligt på samme måde, for nye udviklere at komme til uden at kende nogen der i forvejen bidragede til projektet, ved brug af et versionskontrolsystem som Subversion. Dette har kunnet være tilfældet, da den individuelle udvikler ville blive nødt til at blive godkendt af Subversion administratoren, for at kunne hente og sende 11/14

17 ændringer til Linux kodebase. Hvis dette var realiteten, ville det nok ikke være muligt for Linux at blive så stort som det er i dag. 7. Konklusion De decentrale versionskontrolsystemer har taget software verdenen med storm, set fra både den kommercielle industri og Open Source bevægelsen. De tillader udviklere at arbejde hurtigere og med større sikkerhed end nogensinde før, samtidig med at de tillader udviklere fra hele verdenen at arbejde sammen om kæmpe projekter som Linux, der er vitale for internettet, smartphones, og dagligdagen som vi kender den. 12/14

18 8. Litteraturliste Apache. (2016). Apache Subversion. Retrieved from Apache Subversion: Apache. (2016). Download Apache Subversion. Retrieved from Download Apache Subversion: Assembla. (2016). Assembla - Subversion. Retrieved from Assembla: Brindescu, C., Codoban, M., Shmarkatiuk, S., & Dig, D. (2014, May). How Do Centralized and Distributed Version Control. Hyderabad, Telangana, India: Oregon State University. Chacon, S., & Straub, B. (2014). Pro Git. Apress. Retrieved from Git. (2016). Git. Retrieved from Git: Git. (2016, December 18). Git - About Version Control. Retrieved from Git: Git. (2016, December 18). Git - Distributed Workflows. Retrieved from Git - Distributed Workflows: GitHub. (2016). How People Build Software - GitHub. Retrieved from GitHub: Git-Tower. (2016, December 16). Why use version control? Retrieved from Why Use a Version Control System?: Google. (2016, December 20). Google Trends - Git, Apache Subversion. Retrieved from Google Trends - Git, Apache Subversion: =en-us&tz&tz Pilato, C. M., Collins-Sussman, B., & Fitzpatrick, B. W. (2008). Repository Maintenance. Retrieved from SVN Repository Maintenance: Pilato, C. M., Collins-Sussman, B., & Fitzpatrick, B. W. (2008). Version Control with Subversion: Next Generation Open Source Version Control. O'Reilly. Pingdom. (2012, April 16). Linux Kernel development by the numbers. Retrieved from Linux Kernel development by the numbers: Samsung Open Source Group. (2016, March 2016). An Introduction to the Open Source Development Model - Samsung Open Source Group Blog. Retrieved from An Introduction to the Open Source Development Model - Samsung Open Source Group Blog: 13/14

19 Stack Overflow. (2015). Stack Overflow Developer Survery Retrieved from Stack Overflow Developer Survery 2015: Stack Overflow Developer Survery 2015 The Linux Foundation. (2013). Linux Kernel Development. Retrieved from Linux Com: Wikipedia. (2016, November 30). Apache Subversion. Retrieved from Apache Subversion: Wikipedia. (2016, October 23). Atomic commit. Retrieved from Atomic commit: Wikipedia. (2016, November 7). BitKeeper. Retrieved from BitKeeper: Wikipedia. (2016, November 12). File Locking. Retrieved from File Locking: Wikipedia. (2016, December 18). Git. Retrieved from Git: Wikipedia. (2016, December 17). Hash function. Retrieved from Hash function: Wikipedia. (2016, December 16). Linux. Retrieved from Linux: Wikipedia. (2016, September 17). Revision tag. Retrieved from Revision tag: Wikipedia. (2016, December 1). Version Control - Graph Structure. Retrieved from Version Control: Wikipedia. (2016, December 1). Version Control - Wikipedia. Retrieved from Version Control: Wikipedia. (2016, December 18). Waterfall Model. Retrieved from Waterfall Model: 14/14