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.
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.
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.
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:
git push origin HEAD:refs/for/release
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
Til git er jeg blevet frygteligt glad for at bruge tig som grafisk ud (det er et curses ui). Giver godt overblik og et drøn let at tilpasse med external commands osv.
At dets standard genveje lugter lidt af de velkendte fra Vim gør jo bare det hele lidt federe.
Til merge og diff kan jeg ikke leve uden beyond compare, ďe gør et 100 bedre job med at auto merge ændringer osv.
Kim Schulz
Virkelig interesant emne. Jeg synes det er lidt en udfordring/modstrid at have med komponentversionering og CI at gøre på en og samme tid - ligesom review bare altid er problematisk fordi det er en tung manuel arbejdsgang.
Atlassian's Stash (med Bamboo, Crusible, Fisheye og Jira integration) er iøvrigt et interesant alternativ til Git-Gerrit-Jenkins stak. Virkelig overlegent, at der er round-trip engineering så hvis du laver en feature branch der matcher en navnekonvention, så oprettes en Jira opgave, og sletter du den igen efter en merge, lukkes opgaven.
Skulle jeg igang med et startup, ville jeg nok bare købe hosted adgang hos Atlassian frem for at sætte infrastruktur op selv. Mht. det grafiske, så er Atlassians SourceTree guld værd, men den findes desværre ikke til Linux endnu.
btibucket/github og pullrequests løser mange af de udfordringer, og giver et udemærket (online) review tool
Jeg er meget enig i at Git / Gerrit / Jenikins er en MEGET stærk tool-chain.
Jeg har arbejdet med denne kombination i flere sammenhænge siden 2011 med meget positive erfaringer.
En af det helt store fordele ved Gerrit er at alle reviews er git branches. Det betyder at alle ændringer er i git fra første øjeblik, men isoleret fra din integration branch. Den kode bliver første merget ind i din integration branch når den er godkendt. Derfor bliver din integration branch ikke sandet tit.
For at slippe for den lidt specielle syntax når man vil sende kode til review opretter jeg næsten altid en remote i mit git repo som har en push regel ala: HEAD:refs/for/release. Så kan jeg nemlig pushe direkte til review fra enhver lokal branch med:
git push review
Hvis man altid har de samme personer til at reviewe sin kode kan man derudover tilføje dem til kommandline når man pusher. Det kan man så også ligge i sin push regel for sin remote og dermed behøver du ikke logge på gerrit for at tilføje reviewers.
så er Atlassians SourceTree guld værd, men den findes desværre ikke til Linux endnu.
Vi benytter Team City (betaling). Jeg har kun arbejdet med dette i lidt over 6 måneder og det er virkeligt godt.
Da vi er et ret lille udvikler sted er der ikke pt. brug for review endnu, men test er abeslut nødvendig i udrulning.
så vil egentlig gerne høre mere fra andre alternativer.
Da vi har en del test som er produceret at ikke SW udviklere er specflow (http://www.specflow.org/) også en god del at have inde over.
Vi er lidt i 2 lejre mht. koden. Den er fysik/matematik tung så der sættes disse test op i specflow og derved kan de sættes ind i test flowet. Der hvor vi finder kode fejl laves der Unit test og sættes ligeledes ind i flowet.
Team City reglerne mht. navngivning og branches gør det også enkelt at oprette nye release branches nedlægge dem igen.
Så pt. opretter man bare den næste branch i git og lægger ny kode ind. Så finder serveren selv ud af den nye branch er kommet til og køre test på denne.
Det kommer selvfølgelig alt samme anpå, om man stoler på andre til at opbevare ens kode. Men hvis man gør det, vil jeg sige at jeg at jeg synes Github i kombination med Travis CI, til kontinuert integrationstest, er en virkelig stærk kombi.
Der bliver automatisk kørt integrationstest på en pull request både ved oprettelse ved efterfølgende ændringer. Derudover, er (såvidt jeg kan se) en del af den andre der tidligere er snakket om også til stede der:
1) Alle PR's bliver automatisk til en gren, som man kan fortsætte med at committe til udfra review kommentarer.
2) Man kan se før man merger om testene er bestået
3) Fornuftigt webbaseret review tool
Hvad med Phabricator? Er der nogen der har erfaring med det?
Her er en (ældre) sammenligning mellem Phabricator, GitHub og Atlassian:
Vi bruger Github med CircleCI og det fungerer ret godt.
Jeg har prøvet Apache+git og Stash. De kan begge fortælle Jenkins når der er et nyt commit i et commit hook. Kan gerrit ikke gøre det samme?
Så kan Jenkins bygge med det samme i stedet for at vente op til 10 min.
Atlassian har en meget stærk combo af Jira (med Jira Agile), Stash (git repository manager + review system) og Bamboo(CI server).
Stash kan let sættes op så der kræves feature branches og alle pull requests skal godkendes af reviewer + bygget skal være grønt.
Stash og Jira er elegant integreret. Så man kan lave sin feature branch direkte fra Jira. Stash kan flytte Jira tickets på Scrum boardet tilbage til "In progress" hvis pull requesten bliver afvist og over i "ready for test" hvis den godkendes.
Stash og Bamboo arbejder også rigtigt godt sammen. Der bliver lavet en "branch build plan" så snart feature branchen bliver oprettet, den bygger automatisk og fortæller Stash om bygge resultatet uden man skal gøre noget.
Så er all information delt mellem alle serverne. F.eks. I Jira kan man se alle commits, branches og pull requests. I Stash kan man se byg og let lave drill down hvis en test er fejlet.
Opsætning er også ultra simpelt. Bamboo er f.eks. født med langt det meste du har brug for. Ingen grund til at jagte Jenkins plugins der måske er kompatibel med den Jenkins version du kører.
Det kom til at lyde som en salgstale for Atlassian :) Men det er nu bare fordi jeg har gode erfaringer med pakken. Selvom det selvfølgelig koster en del.
Skulle jeg igang med et startup, ville jeg nok bare købe hosted adgang hos Atlassian frem for at sætte infrastruktur op selv. Mht. det grafiske, så er Atlassians SourceTree guld værd, men den findes desværre ikke til Linux endnu.
Hvor kan man finde hosted Stash?
Bitbucket giver ikke helt det samme, den mangler vigtige features som f.eks. "Kræv et grønt build før et pull request kan merges".
Jo, som Peter Toft skriver: "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."
Det er måske lidt uklart men Gerrit melder til Jenkins hver gang der sker ændringer på et repository, og jenkins har herefter muligheder for at reagere på disse, eksempelvis ved at starte et job.
Det har længe været et ønske fra Jenkins folkene at komme ud over pull mekanismen, og komme over til push.
(Fra lead developer på Jenkins: http://kohsuke.org/2011/12/01/polling-must-die-triggering-jenkins-builds...)
Peter du efterspørger et grafisk merge tool. Jeg plejer at bruge egg til at løse merge-konflikter, hvor man også kan stage dele af en fil. - github.com/bogolisk/egg.git.
- Danmarks største job- og karrieresite for ingeniører og it-professionelle.
