Versionskontrol i undervisningen

På DIKU er inddragelsen sparsom og dækkes på projektforløbet på 2. semester i form af en forelæsning og instruktorernes frie fortolkninger til øvetimerne. Selve projektforløbet giver dog optimale rammer til at afprøve al mulig slags configuration management, hvis den enkelte gruppe formår at undersøge det.

Der er muligvis et argument for at det er alt, der er på programmet på DIKU - det er trods alt ikke kun en uddannelse i softwareudvikling - og man kunne forvente (håbe) at det er mere udbredt på fx datamatiker-skoler og på ITU og DTU, som har ordet "software" tættere på uddannelsernes beskrivelse, selvom der trods alt eksisterer et vist overlap i alle jobprofilerne.

Peter Toft skrev i sit blogindlæg i januar at der var 11 af 413 (3%) af dem som udfyldte hans spørgeskema, som sagde at de ikke brugte versionskontrol, men at de burde gøre det. Selvom antallet muligvis er biased, er det nok ikke nogens overraskelse at det forekommer som et kritisk værktøj.

Personligt kan jeg ikke undvære versionskontrol - om jeg skal skrive en rapport eller lave en hurtig rettelse i nogle web-filer, som ikke indgår i et større projekt, ryger det lige en tur igennem git init. Så har jeg som minimum git diff og en historik over mine rettelser.

Fordi versionskontrol er så generelt anvendeligt, selv som enkeltperson, synes jeg det er ærgerligt at studerende ikke bruger det i mere udbredt grad på 2. og 3. år på bacheloren. Der gik en del tid før jeg lærte mig selv at bruge det, så med lidt flere skub i den rigtige retning...

Bør it-studerende lære at bruge versionskontrol i løbet af deres grunduddannelse, eller er det noget man lige lærer hurtigt de første dage på jobbet? I hvor stor grad inddrages det / bør det inddrages på landets it-uddannelser? Bruger studentermedhjælperne på jeres arbejdspladser versionskontrol?

Simon Shines billede
Simon er tidligere studieblogger på Version2, har læst datalogi på DIKU og et enkelt år økonomi. Han arbejder som FinTech-udvikler og er ved at starte et detektivbureau. Han kan godt lide funktionsprogrammering, oversættere, webudvikling og brætspil.

Kommentarer (17)

Robert Larsen

Jeg selv blev uddannet som datamatiker for en 15 år siden, og dengang blev versionsstyring hurtigt nævnt som en smart måde at lave backup på.
Datamatiker uddannelsen er efterfølgende fået et ekstra semester, som gennemføres som en praktikperiode i et firma, og der lærer de helt sikkert at bruge nogle af de værktøjer, som man bruger i erhvervslivet. Bl.a. versionsstyring, debuggere, profilere, netværkssniffere, buildværktøjer og andet godt.

Jeg så gerne, at man lærte at bruge disse (og sikkert andre) på uddannelsen, men i hvert fald datamatikeruddannelsen har nok ikke mulighed for at presse mere ind uden at forlænge uddannelsen.

Casper Thomsen

Jeg husker at have afholdt et 1-ECTS-kursus i form af en "EDB-introduktion" med 5 kursusgange, hvoraf den tredje havde titlen "Versionsstyring" og bl.a. indeholdt basal SVN og Darcs. Det var tilbage før Git tog førertrøjen. Valget af VCS er underordnet, men overblik over som minimum ét distribueret VCS er vel et rimeligt krav af sådan et "værktøjskursus".

Selv fik jeg introduceret CVS da jeg startede. En introduktion må forventes at være rigeligt til at sætte i gang. Det er trods alt ikke rocket science.

Henrik B. Sørensen

Er desværre, at det ikke lige har den højeste prioritet for IT-admin / undervisere. Kan huske at under min egen studietid, var det vores VHDL lærer, som også var IT-admin for afdelingen. Som om den stakkels fyr ikke havde nok at tage sig til med den slags ( forfærdelige ) elever, han var udsat for. Kim, hvis du læser med : Undskyld, det med at fylde dit kontor med får...

Anyhoo, det er lidt trist, at der ikke er mere fokus på generelle teknikker på studierne. Jeg husker en masse forskellige ting, jeg aldrig har haft brug for, fra mit studie, men til gengæld var det igang med at lære versionskontrol, bugtracking, fejlsøgning etc. by doing.

Desværre er tempoet visse steder skruet så højt op i dag, at vi har udfordringer omkring at få nyuddannede ind. Enter : Mentoring.
Vi har så gjort det, at alle nyansatte får en mentor ( er selv mentor ), som skal træne dem i værktøjer og teknikker - uden for normal arbejdstid.
Men desværre har vi i perioder måtte afvise folk grundet manglende erfaring i værktøjer, hvilket er trist.

Jacob Bang

Jeg tror det kommer meget an på den enkelte uddannelsesinstitution og måden der arbejdes på her. På Aalborg Universitet er der stort fokus på gruppearbejde og projektarbejde og her kan du ikke undgå allerede ved 1. semester at møde versionskontrol af både kildekoden men også rapporten (og LaTeX) når det drejer sig softwareingeniør uddannelsen jeg selv er fra.

De studerende lærer hurtigt at hvis det skal være muligt at arbejde 6 personer sammen om rapport og kildekoden i et helt semester så nytter det ikke noget med en delt Dropbox mappe eller lignende alternativer (og hvis de gør det så er det i hvert fald kun et semester de laver den fejl). Der bliver ikke engang undervist i dette eftersom det er noget du enten selv sætter dig ind i eller får en vejleder der sparker dig i gang med at bruge versionskontrol.

Hvis de studerende ikke bliver udsat for forhold hvor versionsstyring virkelig gør en forskel så kan det være svært at få dem til at bruge det bare ud fra "det er smart at kunne" princippet.

Min erfaring er dog at versionskontrol gavner mange andre end bare it-uddannelser men det er desværre kun it-uddannelser hvor de studerende finder frem til brugen af disse redskaber. Jeg har set flere tilfælde af humanister der ikke engang brugte Dropbox eller Google Docs men delte rapporten som word dokumenter igennem usb-pen, mails og lignende (du bliver hurtig populær når du viser dem Dropbox og Google Docs).

Versionskontrol og deling af data mellem studerende er noget alle får brug for og ikke bare it-studerende. Hvornår vi får kommunikeret det ud til alle er så et godt spørgsmål (og det er nok heller ikke alle der skal bruge de samme værktøjer). :)

Claus Gårde Henriksen

Q: Bør it-studerende lære at bruge versionskontrol i løbet af deres grunduddannelse, eller er det noget man lige lærer hurtigt de første dage på jobbet?

A: Ja. Det giver dem en produktions-modenhed, der gør de ikke spilder tiden. Det at kunne {indchecke, reverte til en tidligere godkendt, branche en, tagge/release en} version af kodebasen er noget alle skal have på rygraden.

Q: I hvor stor grad inddrages det / bør det inddrages på landets it-uddannelser?
A: Obligatorisk kursus. Toolvalg er underordnet, men GoogleDocs er nok ikke helt tilstrækkelig :-) Hvis et stykke kode/dokument i et projektarbejde ikke er versionskontrolleret burde det tælle ned. Samme gælder hvis de ikke bruger et make-script værktøj.

Q: Bruger studentermedhjælperne på jeres arbejdspladser versionskontrol?
A: Ja, ellers kan de ikke bidrage med noget.

Poul-Henning Kamp Blogger

At rode med kildetekst, næsten uanset hvad man gør ved den, er et håndværk, en teknik og en videnskab.

Den primære grund at DIKU aldrig har tiltalt mig var at de kun fokuserede på videnskaben og lod hånt om teknikken og i stort omfang også håndværket.

Sune Marcher

...det gælder om at få hamret nogle gode vaner ind i hovedet på folk så tidligt som muligt, så ja - det burde være obligatorisk. Man behøver ikke bruge flere uger på et versionskontrols-forløb, men der bør som minimum være en introduktion til det basale, forskellen på centraliseret og distribueret, og og hvorfor det er en god idé - hovedargumentet skal helst ikke være "det er en god backup!", der skal fokuseres på samarbejde og sporbarhed, og fx teknikker til at finde ud af hvornår fejl er introduceret.

Det vigtigste er koncepterne, men man kan lige så godt være lidt praktisk, og tage udgangspunkt i subversion og Git. Og så bør uddannelsesinstituionen stille repository-plads til rådighed.

På datamatikeruddannelsen på Erhvervsakademi Aarhus (2010 og frem) var der ikke noget af den slags, men jeg fik heldigvis overbevist mine forskellige gruppemedlemmer om at bruge subversion (omend desværre ikke tex/docbook/markdown/whatever - dokumentation var en-fil-per-kapitel.doc), hvor nogle af de andre grupper rodede rundt med usb-nøgler.

Jeg synes egentligt at det er ligegyldigt om vi snakke datamatiker, it-ingeniør eller datalog - revisionsstyring er ekstremt vigtigt i den virkelig verden. Selvom folk har hobbykodet før deres uddannelse, er det ikke sikkert de har forståelse for alle de gode ting ("det er jo kun mig der sidder med koden, og jeg har backups"), med mindre de har været involveret i opensource.

Troels Henriksen

Hvorfor ikke stille krav om brug af versionsstyring, og dokumentering af samme i rapporten, i kurser der alligevel handler om projektudvikling? Min erfaring er at hvis man vil sikre sig at studerende lærer et givent emne, så er man nødt til at stille opgaver i det.

Den primære grund at DIKU aldrig har tiltalt mig var at de kun fokuserede på videnskaben og lod hånt om teknikken og i stort omfang også håndværket.

Det er rigtigt at der er et håndværksmæssigt underskud (der er desværre grænser for hvad kan nåes på fem år, og hvis man tilføjer noget ét sted, så må man fjerne noget andet), men teknisk synes jeg nu DIKU har været godt med, i hvert fald siden midt/slutningen af 90'erne hvor de teknisk implementeringstunge kurser så vidt jeg kan se blev indført.

Jens Jensen

Det er ikke på alle IT-uddannelser hvor det mangler.
Jeg læste datalogi i århus for over 10 år siden.
Der fik vi en kort introduktion til CVS, som jo var det der nu var dengang. Da Subversion kom skiftede vi selv dertil.
På datalogistudiet gør man normalt ikke meget i at lære folk teknikken. Programmeringssprog, versionsstyring og lign. er ting man forventes selv at sætte sig ind efter en kort intro. Og det kræves for bare nogenlunde at kunne løse de mange opgaver man bliver stillet senere.

Det er dog med stor forundring at jeg nu sidder i "den virkelige verden", specifikt finanssektoren, og jeg er endnu ikke stødt på et fornuftigt versionsstyringssystem. Jo, vi fik da lov til at bruge CVS, til nogle småting, dengang da Subversion allerede havde været standard i mange år.

Lige nu skulle vi forestille at have et system, men i praksis er det blot tjek-in/ud, så man sikrer at ingen arbejder på den samme fil.
Problemet er at man altid vælger løsninger fra IBM, SAS og andre etablerede firmaer. Open source dur jo ikke hvis man vil have nogen at slå i hovedet når noget går galt.
Oftest er scenariet at det etablerede firmar da har en versionsstyring... men den virker så ikke lige sammen med det setup man skal bruge det i, osv. osv.

Så ender man med en specialløsning, bygget på det muliges kunst.
Vores nuværende løsning til deployment af SAS-kode, kræver 2-3 timers arbejdstid for at "deploye" hvilket vil sige: Flyt EN fil fra EN mappe til en anden. Der er ingen versionering at hente, bortset fra en log bagud hvor man... vha. en række telefonopkald til de rigtige personer måske kan trylle en tidligere udgave frem.

Og så er det evige problem med at dem som bestemmer, ikke er dem som bruger værktøjerne. Hvad tjener vi på at implementere et ordenligt versionsstyringssystem? Fra en leders synspunkt: Intet!
Og derfor bliver det aldrig prioriteret særligt højt.

Det er derfor ikke skolerne, eller de nyansattes, fejl at der ikke bruges versionsstyring. Det er udvalget af IKKE-opensource løsninger som er for ringe, sammen med at virksomhedernes ledelser er for sløve på dette punkt.

Kristian Rastrup

En del af PHK's angreb mod IBM Mainframes gik på versionskontrol. Jeg troede dog ikke det stod så galt til.
At en leder ikke kan se og måle den tydelige nedgang i mængden af bugs ved indførelse af versionskontrol, specielt gentagelse af fejl der en gang er rettet viser et stort element af Dilberts princip. Rettelse af bugs i produktion er noget han burde kende prisen på.

Generelt råd hvis man arbejder med kode og ikke har versionskontrol er: "Step away from the keyboard". Udover en editor er det det mest basale værktøj for softwareudvikling.

PS.: Sig til chefen at en TFS server fra Microsoft er bedre end ingen versionskontrol og sæt den så op til at køre Git. Så har han nogen at slå i hovedet og du har det bedste fra OSS samtidig.

Lars Bendix

Min erfaring er dog at versionskontrol gavner mange andre end bare it-uddannelser men det er desværre kun it-uddannelser hvor de studerende finder frem til brugen af disse redskaber. Jeg har set flere tilfælde af humanister der ikke engang brugte Dropbox eller Google Docs men delte rapporten som word dokumenter igennem usb-pen, mails og lignende (du bliver hurtig populær når du viser dem Dropbox og Google Docs).

Jeg mener - som underviser i configuration management - klart at alle som samarbejder om noget har brug for at kende til de mest basale principper for versionskontrol. Som minimum Babich' tre problemer - og helst også nogle af de ting man kan gøre for at håndtere dem.

For vores egne studerende her i Lund kan jeg se at på det første gruppeprojekt de har, så er der vel over 90% som ikke bruger "versioneringstingene" i det VCS de anvender (svn/git). For dem er det udelukkende et mergeværktøj - og et meget højt elsket sådant (i hvert fald henad vejen).

Men der er jo meget mere i versionskontrol end merge - og meget, meget mere i configuration management end "bare" versionskontrol. Det går op for en del af dem og gør dem meget motiverede for at investere 200 timer i mit kursus i configuration management. Hvor de kan fordybe sig i principper og teknikker som kan hjælpe dem til at opleve mindre kaos på deres fremtidige projekter og forberede dem til det de kommer til at møde derude i det virkelige liv. Et kursus som i slutningen af næste måned også starter op på IT Universitetet.

Jeg møder også mange studerende (bl. a. en stor den af dem der følger mit kursus) som selv har samlet et VCS op og er begyndt at bruge det på egen hånd. Ofte minder disse "selvlærte" studerende mig om Henry fra gymnasiet - vi var alle pissemisundelige over at han fik lov til at ræse rundt i et lig af en bil ude på faderens marker - lige indtil han dumpede de første tre gange han gik til køreprøve fordi det ikke lige var den måde den motorsagkyndige mente der skulle køres på på offentlig vej. Under de tool labs de har på kurset går det op for mange studerende at der var meget de stadig havde at lære - og en del ting som de direkte havde misforstået (og så kan vi også få os nogle mere "kvalificerede" diskussioner omkring DVCS.

Men for at komme i gang med "samarbejdet" så burde det, selv for humanister, være nok med to timers introduktion til Babich og to timers tool lab. Så ville verden nok se meget bedre ud ;-)

Allan Ellegaard

Jeg har fornylig afsluttet datamatiker uddannelsen og kan melde det stadig "bare" bliver nævnt som noget man bør bruge og det findes i mange udgaver. Det er ikke noget der bliver snakket/undervist mere i.

Fair nok man selv skal lære en del og derved blive bedre til at lære mange andre nye ting.
Men jeg mener også det er vitalt at dette skal der undervises i fra starten af så det hænger fast og det bliver rutine at bruge versionsstyring.

Janus Knudsen

Forholder det sig virkelig sådan at man intet selv kan når man tager en uddannelse?
Er det i virkeligheden uddannelsen der er problemet her?

Jeg ser altså ikke den store forskel på om nyuddannede skal lære at bruge versionsstyring eller om de skal til at lære at programmere når de har afsluttet uddannelsen.

En "leder" som ikke kan se vigtigheden i versionsstyring bør måske overveje sin stilling en ekstra gang... er det lederens ansvar at tage den slags beslutninger?
- Naturligvis ikke, "ledere" skal få teamet til at fungere og sørge for at virksomhedens retningslinjer overholdes, ikke beskæftige sig med detaljer vedkommende ikke forstår sig på alligevel. Den slags lederadfærd trætter dels teamet og dels giver fornemmelsen af hierakisk forskel imellem udvikler og "leder", det vil kun medføre dårlig karma på arbejdspladsen.

Martin Bøgelund

Lige nu skulle vi forestille at have et system, men i praksis er det blot tjek-in/ud, så man sikrer at ingen arbejder på den samme fil.
Problemet er at man altid vælger løsninger fra IBM, SAS og andre etablerede firmaer.

I disse situationer er jeg helt enig. Jeg ser 2 udfordringer:
1) Bevægelse fra programmering i tekst/kildekode, til peg-og-klik "programmering": I SAS som du nævner, har jeg oplevet en bevægelse fra god gammeldags kodning i SAS BASE (og SCL), til noget peg-og-klik, som ikke altid genererer kildekode som kan håndteres i versionsstyring.
2) Proprietære deployment og promotion løsninger: I stedet for at give mulighed for at systemer interagerer med et (tredjeparts-) versionsstyringssystem, så laver man sin egen lukkede løsning, som i bedste fald kun er halvgod, og sjældent passer til de processer man har i virksomheden mht deployment/promotion.

Hvis udbyderne af softwareløsninger tænkte interaktion med versionsstyringssystemer ind fra starten, med så minimalt et interface som muligt (f.eks dump af programtekst mv til tekstfiler), og så lod brugerne selv vælge versionsstyringssystem til håndtering af disse tekstfiler, ville meget være vundet.

Det jeg oplever med de udviklingsmiljøer jeg kender, er at kildekode og kompileret program æltes sammen i én og samme fysiske fil som er temmelig snusket at lave versionsstyring på. Og så skal man "bare" flytte nogle af disse fil-pakker mellem sine miljøer, huske at lægge dem i en mappe som kan være repository, og så lige genstarte servicen for at de nye pakker importeres.

Janus Knudsen

@Martin Bøgelund: peg og klik laver da også kode af en art, formentligt mere i retning af konfigfiler/ xml, men det er ikke sådan at der ikke dannes noget. At det så kan synes lidt underligt at blande både GUI og et action lignende xml sammen er en anden snak, men det kan stadig versioneres.

Jeg tror nærmere du mener "merges" hvis flere teammembers arbejder på samme "peg og klik" projekt? og det kan være at sandt mareridt = tæt på umuligt at gøre med sådan noget :)

Pkt 2, forstår jeg ikke? Hvem laver egne lukkede versionsstyringer? lyder da egentligt lidt interessant :)

Kildekode og kompileret program æltes sammen? Der skal som udgangspunkt kun være versionsstyring på kildekoden.
Lyder som om du refererer til noget meget specifikt, hvilken platform taler vi om?

Martin Bøgelund

@Martin Bøgelund: peg og klik laver da også kode af en art, formentligt mere i retning af konfigfiler/ xml, men det er ikke sådan at der ikke dannes noget. At det så kan synes lidt underligt at blande både GUI og et action lignende xml sammen er en anden snak, men det kan stadig versioneres.

Humlen er, hvorvidt denne "kode" er tilgængelig overhovedet, og hvis ja, hvor nemt eller svært det er at få ud i filsystemet til versionsstyringen.

Og bemærk jeg skrev "til noget peg-og-klik, som ikke altid genererer kildekode". Det er jo specifikt for det enkelte løsnings-miljø/IDE, og derfor kan man ikke sige noget generelt om det. Min erfaring er, at peg og klik genererede "programmer" ofte mangler en let tilgængelig 1-1 mapning mellem egentlig programkode og peg-og-klik-miljø.

Jeg tror nærmere du mener "merges" hvis flere teammembers arbejder på samme "peg og klik" projekt? og det kan være at sandt mareridt = tæt på umuligt at gøre med sådan noget :)

Jeg har bygget løsninger i peg-og-klik interfaces, som ikke umiddelbart kunne transformeres til og fra kildekode i filsystemet, som et versionsstyringssystem kunne få fat på og håndtere hensigtsmæssigt.

Pkt 2, forstår jeg ikke? Hvem laver egne lukkede versionsstyringer? lyder da egentligt lidt interessant :)

Jamen så skal du bare læse løs: http://www2.sas.com/proceedings/sugi31/009-31.pdf
Jeg brugte det ikke selv, men byggede i stedet min egen løsning, og kørte den med CVS til versionsstyring.

Kildekode og kompileret program æltes sammen? Der skal som udgangspunkt kun være versionsstyring på kildekoden.
Lyder som om du refererer til noget meget specifikt, hvilken platform taler vi om?

Ja, det er specifikt (som sagt) - f.eks. for SAS SCL. Så vidt jeg kan se er der også binært fnidder i TM1 Turbointegrator processers filer, men det er noget jeg først lige er begyndt at kigge på.

I SAS har man mulighed for at kode i et sprog der hedder SAS/SCL (det er depricated nu, men jeg kodede meget i det engang). Disse SAS/SCL entries er placeret i såkaldte SAS Catalogs. Inde i SAS IDE'et fremstår et SAS Catalog som en folder, men ude i filsystemet er det en (binær) fil, og da et SAS Catalog kan indeholde mange SCL entries (som enten er kompilerede eller ukompilerede), og SAS Cataloget derudover kan indeholde andre typer entries (SAS/AF frame entries, jpg billeder, SAS BASE kode, og what-not), så har du en stor klump sammenfiltret binær/ikke-binær smøre inde i en enkelt SAS Catalog fil, som er temmelig snusket at lave versionsstyring på. Og selv hvis det lykkedes dig at isolere den specifikke stump SCL inde i den binære hob i SAS Catalog-filen, så var der som sagt filtret noget binært stads ind i den specifikke SCL entry, som (sikkert) kom fra kompileringen.

Peter Stricker

Inde i SAS IDE'et fremstår et SAS Catalog som en folder, men ude i filsystemet er det en (binær) fil, og da et SAS Catalog kan indeholde mange SCL entries (som enten er kompilerede eller ukompilerede), og SAS Cataloget derudover kan indeholde andre typer entries (SAS/AF frame entries, jpg billeder, SAS BASE kode, og what-not), så har du en stor klump sammenfiltret binær/ikke-binær smøre inde i en enkelt SAS Catalog fil, som er temmelig snusket at lave versionsstyring på.


Yuck, det lyder rigtig ubehageligt.

Et andet eksempel er Smalltalk, hvor man gemmer hele det kørende program som en stor imagefil. Næste gang man starter dette image op i VM'en, har man så al koden, men også alle værdier fra sidste kørsel. Her ligger versionshistorikken så også inde i det samme image.

Smalltalk har stået fadder til mange gode ideer indenfor (især objektorienteret) programmering. Dette er ikke en af dem.

I en anden boldgade har vi de to store dokumentformater ODF og OOXML, som gemmer alt ned i en enkelt zip-fil bestående af en hel masse filer, der bestemmer indhold og udseende af dokumentet. Det kræver nogle krumspring at diffe mellem to versioner af sådan et dokument.

Log ind eller opret en konto for at skrive kommentarer