Wat is "version control" en welke voordelen heeft het voor jou?
Simple steps towards FAIR code and software
Dit is de tweede blog in de serie Simple steps towards FAIR code and software. In deze blog vertelt Stefano Rapisarda waarom version control zo belangrijk is en hoe je ervan profiteert. Stefano is één van de adviseurs bij RDM Support.
Computers hebben altijd in mijn huis gestaan voor zolang als ik me kan herinneren. Dit maakte me geen Bill Gates, maar het vulde mijn jeugd zeker met allerlei elektronische ‘beesten’. Ik herinner me de kleurrijke lichten en het lage-frequentie elektrische gezoem van een grote aluminium doos, een onverstoorbare accu die mijn vader een maandsalaris had gekost. Die doos had één taak en dat was ook zijn enige taak: voorkomen dat mijn vader ging vloeken zoals alleen een Italiaanse vader dat kan als mijn moeder haar haar droogde, terwijl de wasmachine draaide en er iets in de oven stond, waardoor ons stroomnet overbelast werd. Als dat gebeurde, ging het grote rode licht op de doos branden, nam het gezoem toe en gingen alle interne batterijen stroom leveren, waardoor de computer van mijn vader lang genoeg aan bleef staan om al zijn werk van de afgelopen uren te redden van de cybernetische vergetelheid.
Iets anders dat ik me duidelijk herinner waren de bergen floppy disks die verspreid lagen over zijn studio, soms georganiseerd in bakken of meestal opgestapeld in instabiele jenga-achtige torens. “proj1”, “ver1”, “ver1b”, “ver1_1992”, “ver1_ultimate”, “ver1_ultimate_better”, etc, namen netjes geschreven op papieren etiketten of grof geschreven op het ruwe plastic. Deze disks werden voortdurend opgepakt, in de computer gestopt, dan eruit geduwd (“uitgeworpen”) en bovenop een willekeurige stapel teruggelegd.
Dit alles gaf mijn vader een warm gevoel van veiligheid, het bewustzijn dat, ongeacht wat voor natuurramp er kwam of wat voor nieuw keukenapparaat op het stroomnet werd aangesloten, hij het werk waar hij mee bezig was niet zou verliezen.
Ik begreep al deze moeite toen niet, maar zo'n dertig jaar later, tijdens het schrijven van software voor mijn onderzoek, ging ik ook op zoek naar datzelfde gevoel van veiligheid. Als dit alles voor jou ook onbegrijpelijk is, wacht dan nog een aantal regels, want vandaag gaan we het hebben over version control voor onderzoekssoftware. Wat is het? Hoe werkt het? En waarom is het goed voor zowel de ontwikkelaar die er soms mee werkt als de getrainde wetenschapper?
Dit alles gaf mijn vader een warm gevoel van veiligheid, het bewustzijn dat, ongeacht wat voor natuurramp er kwam of wat voor nieuw keukenapparaat op het stroomnet werd aangesloten, hij het werk waar hij mee bezig was niet zou verliezen.
Wat is version control?
In informatica is version control elk soort systeem waarmee je wijzigingen in bestanden, software, een website of elk ander digitaal object dat informatie bevat kunt volgen en vastleggen. Terwijl je omgaat met software ben je vast weleens extra labels tegengekomen zoals “V1.0”, “beta” of simpelweg “2.3”. Deze nummers en letters geven de softwareversie aan, oftewel, ze identificeren een specifieke uitgave van de software. Wat is een software-uitgave? Om het simpel uit te drukken, het punt waar software-ontwikkelaars “goed genoeg” zeggen en beslissen dat hun software klaar is om gedeeld te worden met het publiek. Het klinkt allemaal heel technisch, maar nu software steeds meer wordt geïntegreerd in de gepubliceerde onderzoeksoutput van onderzoeksprojecten is het iets waar onderzoekers ook op moeten letten.
Waarom heb ik version control nodig?
Je hebt je het misschien niet gerealiseerd, maar de meeste verwerkingsprogramma's die je dagelijks gebruikt, voeren al automatisch een soort version control uit: elke keer dat je op de knop “ongedaan maken” klikt, krijg je toegang tot eerder opgeslagen versies van je code of document. Dat wil zeggen, je gaat terug naar vorige versies ervan. Meer expliciete version control wordt bijna een “must” als je aan een groot project wilt gaan werken, als je je software openbaar wilt maken en als je de code ontwikkelt met andere mensen.
Op het meest basale niveau helpen version control-systemen je om het overzicht van wijzigingen in je code te volgen (development history). Deze wijzigingen worden meestal vastgelegd, zodat je altijd kan achterhalen wanneer, waar en waarom je je software had gewijzigd. Moderne version control-systemen kunnen ook samenwerken met clouddiensten, zodat je vooruitgang wordt opgeslagen op je computer en in de cloud.
Het is ook essentieel om de versiegeschiedenis van software te kennen als deze wordt vrijgegeven voor het publiek. Computerprogramma's zijn inderdaad dynamisch: ze veranderen voortdurend terwijl ze zich aanpassen aan de behoeften van hun gebruikers en aan nieuwe hardware. Software die zonder problemen werkt in een vijf jaar oude computer werkt misschien niet op een recentere machine (en vice versa). Het is daarom essentieel om te weten welke softwareversie je gaat gebruiken voor je werk en hoe het verschilt van eerdere versies.
Version control wordt een echte redder in nood als je samenwerkt met andere mensen. Stel je een groep onderzoekers en ontwikkelaars voor die tegelijkertijd aan dezelfde code werken, waarbij iedereen dezelfde bestanden repareert, uitbreidt en wijzigt. Het maakt niet uit of één van hen alles wist of de code volledig verprutst, met version control kun je altijd teruggaan naar het punt waar je software perfect functioneerde en vanaf daar opnieuw beginnen.
De meeste verwerkingsprogramma's die je dagelijks gebruikt voeren al een soort version control uit.
Hoe werkt version control?
Er zijn verschillende version control-systemen verkrijgbaar, maar het meest prominente is Git. Met Git kun je op commando “snapshots” maken van de software die je aan het ontwikkelen bent. Elke keer dat je denkt dat je significante wijzigingen hebt gemaakt in een bestand, maak je er een snapshot van. Als je echt heel zeker bent van de veranderingen “commit” je dat (een git-specifieke actie die je kunt zien als “wijzigingen bevestigen”), waarmee je dat snapshot officieel opslaat in de wijzigingsgeschiedenis van dat bestand. Vanaf nu, ongeacht wat er met dat bestand gebeurt, kun je er altijd een eerder snapshot van terughalen, deze vergelijken met je huidige versie en uiteindelijk weer vanaf dat punt gaan werken. Git is ook verbonden met een cloudservice (GitHub) waarmee je bestanden kunt delen (documenten, software, websites, etc) met andere gebruikers en om ze op te slaan in de cloud. Bekijk de GitHub-omgeving van de Universiteit Utrecht.
Zoals ik eerder had gezegd, wordt werken met Git onmisbaar als meerdere mensen tegelijk aan dezelfde software werken. Git laat elke persoon werken aan een andere “tak” van de code, oftewel een kopie ervan. Je maakt snapshots en commits zoals je zou doen als je alleen werkt, maar als je denkt dat het tijd is om je vooruitgang te delen, dien je een verzoek in voor “merging”. Op dat punt inspecteren je collega's de verschillen tussen jouw versie en de originele, en ga je uiteindelijk wijzigingen voorstellen. Als het wordt goedgekeurd, wordt je code opgenomen in de hoofdcode en wordt het officieel een onderdeel van de geschiedenis ervan.
Op een individueler niveau, wanneer ik software schrijf, denk ik altijd aan mijn belangrijkste samenwerkingspartner: mijn toekomstige ik.
Ik ben onderzoeker, geen ontwikkelaar. Waarom zou ik iets geven om version control?
In het verleden hoefden onderzoekers zich bij het delen van wetenschappelijke resultaten alleen druk te maken om een artikel. We naderen nu het tijdperk waarin alle mogelijke onderzoeks-outputproducten van een project gedeeld gaan worden, inclusief data en software. Als wetenschapper moet je het principe volgen dat wetenschappelijke resultaten gedeeld moeten worden, zodat andere wetenschappers je resultaten kunnen reproduceren. In deze context is het delen van data en software in een openbare gegevensbank vaak niet genoeg om de reproduceerbaarheid van wetenschappelijke resultaten te garanderen. Data en software kunnen een hoog niveau van complexiteit hebben, maar zijn vaak een rommeltje omdat ze organisatiecriteria volgen die (in het beste geval!) alleen duidelijk zijn voor leden van je onderzoeksgroep. Data-analyse wordt meestal uitgevoerd met een specifieke softwareversie zodat, in feite, analyseresultaten ook afhankelijk kunnen zijn van de softwareversie (vooral als de software een bug heeft!). Met het delen van een goed vastgelegde softwaregeschiedenis kunnen je collega's achterhalen waar je code vandaan komt en met welke versie data-analyse is uitgevoerd. Verder maakt het uploaden van je software op platforms zoals GitHub je software vooral gemakkelijk te vinden en te downloaden. Met andere woorden, het gebruiken van version control draagt bij aan het meer FAIR maken van je onderzoeksproducten.
Het gebruik van Git en GitHub is niet verplicht (hoewel sommige geldschieters expliciet kunnen vragen om openbare gegevensbanken). Maar meer dan 150 Git- en GitHub-gebruikers hebben momenteel banden met de Universiteit Utrecht, en leveren meer dan 800 onderzoeksscripts en -software. Deze aantallen nemen alleen maar toe als we kijken naar het nationale en internationale niveau. Dit betekent ook dat Git en GitHub kunnen rekenen op een zeer groot aantal (onderzoeks)gebruikers en, in feite, worden ze de dominante tool voor het delen van je software met de wetenschappelijke gemeenschap.
Mijn toekomstige ik
Op een individueler niveau, als ik software schrijf, denk ik altijd aan mijn belangrijkste samenwerkingspartner: mijn toekomstige ik. Deze persoon is een oudere, tragere, ietwat dikkere versie van mij die alles is vergeten over het project waar ik nu aan werk. Nou is deze persoon in de toekomst meestal ontroerd als hij ziet dat zijn vroegere ik (dat wil zeggen, mijn hedendaagse ik) uitstekend werk heeft gedaan met het goed vastleggen van alle levenscycli van mijn software.
Tenslotte is het delen van je software op GitHub (of welk ander openbaar platform dan ook) een kans om je werk te delen en de kwaliteit ervan te laten zien. Laten zien waar je aan hebt gewerkt en hoe je eraan hebt gewerkt is fundamenteel onafhankelijk van elke carrière die je nastreeft.
Oké, ik snap het! Waar moet ik beginnen?
Bekijk deze korte animatie en begin vandaag met het gebruiken van Git en GitHub, en bekijk de Git-documentatie. Voel je je geïntimideerd door het onderwerp of heb je hulp van mensen nodig? Kom naar ons Programming Café; het zit vol met Git-gebruikers die klaarstaan om hun enthousiasme voor version control te delen. We gaan nieuwe data delen in het agenda-overzicht na de zomervakantie.
RDM Support beantwoord graag al jouw vragen over version control. Neem contact op met ons via ons e-mailadres en abonneer je op onze nieuwsbrief, die je allebei kunt vinden op onze contactpagina. We zijn hier om je te helpen. Waar je ook begint, begin gewoon met version control. Je toekomstige ik zal je voor altijd dankbaar zijn.