Etikettarkiv: continuous integration

SonarQube ger dig koll på kvaliteten i ditt projekt

Det lönar sig att hålla en hög kvalitet på koden i projekt men det kan vara svårt att bibehålla den när projektet växer och kraven blir mer komplexa. Ett projekt med bra kodkvalitet är lättare att förvalta, har färre buggar och kommer att kosta mindre. Det finns många verktyg som kan hjälpa till att analysera koden och hitta problemområden såsom verktyg för statisk kodanalys, test coverage, kod-duplicering m.m. Dessa verktyg har ett stort värde i sig själva men det kan vara svårt att få en helhetsuppfattning. SonarQube hjälper till att samla in information från de olika verktygen och sammanställer en rapport som ger ett värde på hur mycket teknisk skuld som finns i systemet. SonarQube hjälper även till med att planera arbetet för att åtgärda kvalitetsbrister.

Genom att kontinuerligt analysera koden så kan SonarQube visa hur kvaliteten i projektet utvecklats över tid. Det går att bygga upp egna översiktsvyer med de värden man är intresserad av. Dessa översiktsvyer är ett bra sätt att visualisera den tekniska skulden i ett system. Det är enkelt att från översikten komma ned på detaljnivå och tillbaka.

 

Översiktsvy över teknisk skuld
Översiktsvy som visar vilken teknisk skuld som finns i systemet.

 

Detaljvy över problem
Detaljvy som visar vilka problem som hittats i projektet.

Det är viktigt att konfigurera SonarQube att analysera rätt saker. Om resultaten är för omfattande med irrelevant information så kommer utvecklare att tröttna. Se till att ta bort analys av tredjepartskod som du inte har möjlighet att påverka. En del automatgenererad kod följer inte alltid namngivningsregler (exempelvis en del händelsehanterare i .NET som har understreck i namnen). Det kan vara svårt att undanta automatgenererad från analys men man kan manuellt tala om att dessa händelsehanterare ska undantas från analys.

Mest nytta får man om man integrerar SonarQube med en ”Continuous Integration”-lösning. Continuous Integration är ett utmärkt sätt att kontinuerligt bygga, testa och analysera kod. SonarQube går att integrera med TeamCity, Jenkins m.fl.

Översiktsvy med förändringar
Översiktsvy som visar förändringar från föregående analys.

SonarQube är Open Source. Även om verktyget är baserat på Java så kan det användas för att analysera andra språk som C#, PHP, C/C++ m.fl. Det kan även analysera andra former av resurser som CSS, XML, HTML m.m. Det finns många plugins till systemet. De flesta är GPL-licensierade och därmed fria. Det finns dock några som har en kommersiell licens. Det framgår dock tydligt vilken licens som används av olika plugins.

Installationen av SonarQube är enkel. Du måste ha Java installerat och sedan packar du bara upp zip-filen på önskat ställe. Som standard används en inbyggd databas HSQL som fungerar bra för att testa och lära sig SonarQube men den rekommenderas inte för en skarp installation. Då måste man använda en riktig databas.

Ladda ned SonarQube

Automatisera från dag ett

Automatisering är ett bra sätt att minska tid och resurser som behövs för felsökning. En automatiserad process görs alltid på samma sätt och inga steg kommer att missas. Dessutom frigörs resurser till att göra viktigare saker då de slipper göra en massa manuella steg om och om igen. Ju tidigare man börjar automatisera desto bättre. Ju senare man börjar desto svårare kommer det att bli att eftersom de processer som skapats inte har designats för att automatiseras.

Automatiserade enhetstester

Om man inte har några enhetstester måste man testa koden genom att starta hela systemet och köra igenom olika testfall manuellt. Dels tar det tid att hela tiden starta systemet för att testa, stänga av systemet för att rätta eventuella fel, kompilera om och starta systemet igen och testa om. Då det blir för komplext och trögt att testa så kommer det inte att göras och eventuella fel upptäcks långt efteråt vid systemtestning. Dessutom finns en stor risk för att man glömmer något test eller inte utför det på exakt samma sätt som föregående körningar.

Automatiserade enhetstester kräver inte att systemet körs och kan ofta köras igång direkt från utvecklingsmiljön genom att trycka på en knapp. Testerna kommer alltid att köras på samma sätt och blir det fel så får man direkt feedback och kan rätta och köra om samtliga tester igen. På detta sätt så tar man effektivt bort småfel som annars skulle slippa igenom till systemtestning.

Enhetstester måste skrivas från dag ett i projektet. Att försöka skriva enhetstester i efterhand är komplext eftersom koden oftast inte skrivits på ett sätt som gör att den är testbar.

Blir det inte dyrt att lägga tid på att skriva automatiserade tester? Det är väl bättre att utvecklarna skriver ny funktionalitet? Automatiserade tester kräver naturligtvis en del tid att skriva men det är tid som sparas i senare steg genom att vi slipper lägga tid och resurser på komplex felsökning. Dessutom är det ett utmärkt verktyg att ha när systemet ska vidareutvecklas eftersom det också fungerar som regressionstest.

Automatiserat bygge

Att bygge ett system som består av flera olika moduler är en komplex uppgift. Om det dessutom är ett större utvecklingsteam som arbetar på olika delar av systemet så finns en risk att problem uppstår när de olika delarna ska integreras.

Det finns en hel del verktyg för att automatisera byggandet av system (ant, maven, msbuild o.s.v.). Det blir då enkelt att schemalägga byggen så att man bygger hela systemet åtminstone en gång per dygn och kör samtliga automatiserade tester för att fånga upp problem. Störst nytta får man dock om man dessutom använder en contiuous integration server som bygger systemet och kör alla enhetstester så fort en incheckning sker i versionshanteringssystemet. Då fångas eventuella integrationsproblem upp direkt.

Automatiserad deploy

När det närmar sig driftsättning av system så brukar det vara febril aktivitet. Det skrivs checklistor och planer för utrullning. Det bokas resurser som ska genomföra installationerna och testresurser som ska verifiera att allt ser bra ut. Nödvändig infrastruktur införskaffas och konfigureras.

I en del fall är driftsättning något som sker utan någon som helst generalrepetition för systemadministratörer och it-tekniker. Det är lite konstigt att ta en sådan risk med tanke på alla resurser lagts ned på att utveckla systemet. Även om det har funnits tillfälle att öva på processen i en produktionslik miljö så finns risken att man missar viktiga moment om det är mycket som ska göras.

Ju längre man väntar med att automatisera deployment och konfiguration av system desto svårare blir det att göra. Genom att redan från första dagen i projektet automatisera deployment processen så hinner man köra igenom den flera gånger under projektets gång. Målet bör vara att en driftsättning är så enkel att man bara trycker på en knapp för att genomföra det. Fördelen är att processen alltid kommer att genomföras på samma sätt vilket eliminerar att något steg missas och risken minskar för en misslyckad driftsättning. Dessutom är det ett utmärkt sätt att säkerställa att man kan återställa ett system vid en eventuell katastrof.

Rekommenderad bok: TeamCity 7 Continuous Integration Essentials

Denna bok är bra för dig som vill komma igång med Continuous Integration i TeamCity. TeamCity är en CI-server från ett företag som heter JetBrains. Den är relativt enkel att komma igång med och har olika licensiering beroende på vilka behov man har. Det finns naturligtvis flera andra alternativ som Jenkins, CruiseControl, Team Foundation Server m.fl. som kan göra liknande saker.

Boken ger en grundläggande introduktion till hur du kommer igång med TeamCity. Den är skriven på ett rakt och enkelt sätt och det är lätt att följa med i exemplen. Boken ger också en snabb introduktion till Continuous Integration men jag rekommenderar att läsa kompletterande litteratur som behandlar ämnet djupare.

Det finns mycket information på nätet om TeamCity men boken ger en röd tråd som kan vara svår att få genom information på nätet. Jag tycker att boken är något dyr i förhållande till innehållet men den håller hög kvalitet och innehåller inte en massa utfyllnad vilket kan vara fallet med en del böcker.

TeamCity 7 Continuous Integration Essentials

Att använda MSTest med Continuous Integration

I Visual Studio ingår ett testramverk kallat MSTest. Det har ungefär samma struktur som andra testramverk som t.ex. NUnit. Det finns dock en skillnad mellan ramverken när man vill köra tester på en byggagent via Continuous Integration. För NUnit lägger man oftast in dll:en för NUnit tillsammans med sin kod och pekar sedan ut den i bygget.

MSTest kan inte packas in som en del av koden utan måste man installera Visual Studio på byggagenten. Det är oftast något som åtminstone jag vill undvika. Att ha IDE installerat på byggagenten ökar risken att få med sig IDE-specifika beroenden som man inte vill ha. Från och med Visual Studio 2010 finns ett paket kallat Visual Studio Agents. Detta kan man installera på noder som ska köra automatiserade tester. Det känns som en bättre lösning än att installera hela Visual Studio.

Själv föredrar jag att använda NUnit i mina projekt eftersom det känns mer lättviktigt och portabelt. Om jag ändå måste köra MSTest så använder jag Visual Studio Agents.