Som en del av Agile utveckling har många företag länge integrerat kontinuerligt , men jag tror att vi måste vidta ytterligare åtgärder för att säkra kvaliteten på de förändringar som vi gör under utveckling fram till leverans.

Med verktyg som GIT för versionshantering , Gerrit för kodgranskning och Jenkins som integration, test och driftsättningsmotor kan man komma mycket längre med en liten ansträngning än vad som var möjligt för några år sedan

Nedan beskriver jag hur Purple Scout AB har genomfört, som en del av sin kvalitetssäkringsprocess, en kontinuerlig driftsättning i ett projekt .  Som ett exempel kommer jag att använda webbplatsen planteratillsammans.se, en  webbplats som kvalitetssäkrades med Selenium och de ovan listade verktygen . Genomförandet som Purple Scout AB gjorde innefattar både en webbserver och en databas samt kommunikation med flera andra system bland annat Facebook , SMS – betalningssystem och kortbetalningssystem.

Kodgranskning har flera fördelar.  Redan på 70-talet gjordes stora insatser för förbättra kvaliteten med olika processer, bland annat genom kodgranskning .Ur min synvinkel är det viktigt att förstå skillnaderna i förutsättningar mellan nu och då. Idag har vi editorer som kontinuerligt belyser eller till och med korrigera syntaxfel och är ett hjälpmedel när du skriver koden , men för inte så länge sedan skrevs kod genom stansning av hålkort. Du sorterade hålkorten i rätt ordning för att sätta ihop ditt program . Dessutom fick vi då resultatet av syntaxkontroll, kompilering, länkning och exekvering dagen efter att du hade överlämnade kortleken med hålkort till datacentralen.

Alltför länge har historien jagat oss med processer som är anpassade till dessa förhållanden . Naturligtvis var det nödvändigt att kontrollera koden mycket noga innan den överlämnas till datacentralen eftersom ett saknat semikolon , till exempel, skulle kunna generera ett kompileringsfel. Du förlorade då direkt 24 timmars kalendertid samtidigt som leveransdatumen kom allt närmare.

Med hjälp av Gerrit som ett verktyg för att hantera kodgranskningar ges alla i projektet, och naturligtvis andra intressenter en möjlighet att följa utvecklingen av projektet. Dessutom kommuniceras  information enkelt inom ditt projekt och ni kan hjälpa varandra i tidigt utvecklingsprocessen. Jämfört med den gamla skolan  då kodgranskning gjordes precis innan den levererades  till den gemensamma leveransgrenen ger detta helt andra möjligheter att styra projektet.

Gerrit + Jenkins

En annan fördel med Gerrit är att du kan koppla ihop verktyget med Jenkins. Datorer är bättre än människor på att kontrollera triviala saker som ett saknat semikolon , validering av kodningsregler etc. När vi lägger upp några ändringar i Gerrit låter vi Jenkins kompilera, bygga och köra olika analysverktyg som kontrollerar Java-koden . Resultatet av dessa olika verktyg matas sedan tillbaka till granskningen i Gerrit och på det viset avlastar man granskarna. De kan koncentrera sig på andra aspekter som är svårt för en dator att bedöma.

Om ett kodgranskningsverktyg finner några problem kan den blockera integrationen allt efter önskemål. Utvecklaren måste sedan uppdatera källkoden och börjar om granskningsprocessen. När alla automatiska kontroller godkänner uppdateringen bjuder utvecklaren in andra till att granska ändringarna. Som projektledare eller annan intressent kan man alltid bjuda in sig själv eller göra det obligatoriskt, genom automatik, att bjuda in vissa personer. Vidare går det att bestämma vilka personer som har rättigheter att godkänna en ändringen och vilka som bara kan ge synpunkter. Gerrit ger en god överblick över pågående arbete och även över alla ändringar som har godkänt och som nu finns med i produkten.

Automatisk enhetstestning

När du har genomfört automatisering av bygget är nästa steg oftast att lägga till enhetstester med t ex JUnit som en del av integrationsprocessen , för att kontrollera att förändringen inte bara bygger, utan också att det inte införs nya fel i produkten. Ramverket JUnit är lätt att integrera i Jenkins och om du har haft problem med föråldrade JUnit testfall , t.ex. utvecklarna inte uppdatera dem när de gör kodändringar, kommer automatisering av JUnit med jenkins att genomdriva en bättre beteende. Naturligtvis säkerställer vi på detta sätt också att alla testfall utförs automatiskt och överbelastade utvecklare har en sak mindre att tänka på.

Fortsättning följer