Git, Gerrit og Jenkins - en fantastisk trio for SW udviklere
Jeg har brugt en hel del tid de sidste par måneder på Git, Gerrit og Jenkins.
Som software-udvikler er det noget noget af den bedste tools-investering jeg har været med til længe.
Jeg vil her dele lidt af min erfaring og især gerne høre jeres.
Versions-kontrolsystem
Mht. valg af versionskontrolsystem, så er der mange alternativer og der er efter min mening to store stjerner - Git og Mercurial. Begge er glimrende, og udviklingsmæssigt ligger de ikke langt fra hinanden. Begge fungerer fint på Linux og Windows. En stor forskel er at commit-numre ikke findes i Git, mens Mercurial har både unikke SHA værdier og commit-numre. Når jeg debugger med Git, så savner jeg jævnligt commit-numre, men udover det er jeg ekstremt tilfreds med Git. Merge-systemet i Git er rigtig godt, men jeg leder stadig efter mere effektive grafiske Linux værktøjer ala gitk og gitg. Begge er ok til at skabe overblik, men især ved "unclean" merges savner jeg noget bedre.
Men alt andet lige i forhold til CVS og SVN er min produktivitet markant højere med Git - fedt system.
Jenkins
Hvis man har SW, der skal testes med de samme tests igen og igen, så er Jenkins værd at investere tid i. Det er en (gratis)
open source continuous integration server af meget høj kvalitet. Det er snyde nemt at installere på Linux hhv. Windows, og administration foregår nemt via en webside fra Jenkins-serveren. Det er også populært - der er nu over 100.000 installationer.
På billedet ses den hjemmeside, hvor man nemt kan ses status for hver af de test. Er den runde bold blå er seneste test gået godt, er den rød er testen fejlet.
Til højre for den runde bold ses en "vejr"-status, som indikerer om der har være fejl på nogle af de tidligere tests. Glimrende UI-design.
Git (eller Mercurial) er ikke understøttet i Jenkins, men Jenkins har et meget veludviklet plugin-system, hvor bl.a. et Git plugin nemt kan installeres. Der er over tusind forskellige plugins til Jenkins, så det er værd at kigge efter om andre allerede har løst de problemer, man selv bikser med.
Jeg har til en del Linux-tests brugt makefile-baserede tests, som jeg kan køre på kommando-linien. Jeg laver mine tests så exit-koden kun sættes til nul, hvor test går fint, og med dette er det nemt at skrive de make kommandoer, som definerer testen ind, og køre den f.eks. hver time (Build periodically) og/eller bygge hver gang nogen har lavet pushet en commit (Poll SCM). På billedet er vist hvordan jeg poller ca. hver 10. minut.
Fordelen med at indføre Jenkins er at man får en automatiseret server til at udføre de kedelige tests, som oftest bliver glemt eller negligeret.
Gerrit
Det tredje ben, jeg lige vil nævne er Gerrit, som er en Git-server med to funktioner, der er guld værd.
Gerrit er et web-baseret kode-review-system, som f.eks. kan sættes på på nogle beskyttede branches.
Øvrige branches kan holdes åbne (dvs. som en normal åben Git-server).
På det beskyttede branches kan/bør/skal brugere (alt efter den politik man vælger) sende kode til review. Er "release" branches lukkes, skal man dog bruge en lidt speciel syntax:
Det er flere detaljer på denne URL.
Laver man git push til en beskyttet branch får man en hjemmeside med en kodereview. Man vælger hvem af ens kolleger, der bør reviewe kodeændringen.
Kollegerne får derefter mail til samme review-hjemmeside. Er der enighed om at kodeændringen er god kan man "approve" ændringen, og først der er kodeændringen gjort tilgængelig på den beskyttede branch.
Det jeg er helt vild glad for med Gerrit er muligheden for at koble Gerrit med Jenkins. Et Gerrit-review på et Git repository, kan direkte starte et eller flere test-jobs på Jenkins-serveren. På Gerrit-serveren vises med det samme hvilke Jenkins jobs, som er startet, og tilsvarende vises resultater i Gerrit-hjemmesiden når Jenkins-testene er fuldført. Det gør det meget nemmere at overholde fælles regler for f.eks. compiler-advarsler. Findes der en Jenkins-test for et givet problem, som fejler bliver dette direkte vist for reviewerne.
Den følgende illustration fra CollabNet illustrerer udviklingsflowet godt.
En bruger tager A1 koden hjem, retter koden til C2, sender denne ind til via Gerrit og en Jenkins-test fejler. Brugeren sender derefter en rettet version ind (C2*) til samme review, som nu går fint i Jenkins-testen, og en reviewer sender koden ud på "master" branches, så alle kan få kode-ændringen.
Har du erfaring med Git, Gerrit og Jenkins er du meget velkommen til at skrive om erfaringer nedenfor. Kender I til andre test og udviklings-flows, der ligner ovenstående, så skriv også meget gerne om dette nedenfor.
/pto
