Hur vi implementerade SonarQube och insåg dess stora potential

Vi vill dela med oss av vår erfarenhet av att implementera plattformen för kontinuerlig analys och mätning av kodkvalitet SonarQube i de befintliga utvecklingsprocesserna för DPO-systemet (komplettering till depå- och clearingredovisningssystemet "Alameda") vid den nationella avräkningsdeponeringen.

Den nationella avräkningsdeponeringen (gruppen av företag "Moskva-börsen") är ett av de nyckelföretag inom den finansiella infrastrukturen, som förvarar och redovisar värdepapper från ryska och utländska utgivare till ett värde av över 50 biljoner rubel. Det växande antalet transaktioner som systemet utför, samt den kontinuerliga utvecklingen av funktionalitet, kräver att vi upprätthåller en hög kodkvalitet i systemen. Ett av verktygen för att nå detta mål är den statiska kodanalysatorn SonarQube. I denna artikel kommer vi att beskriva vår framgångsrika erfarenhet av sömlös implementering av den statiska analysatorn SonarQube i de befintliga utvecklingsprocesserna i vår avdelning.

Kort om avdelningen

Våra kompetenser omfattar följande moduler: utbetalningar till NRD:s kunder, elektronisk dokumenthantering (EDO), behandling av meddelanden från handelsdepotet (registrering av OTC-transaktioner), elektroniska interaktionskanaler mellan kunder och NRD, och mycket mer. Sammanfattningsvis en stor mängd arbete med den tekniska sidan av den operationella verksamheten. Vi arbetar på begäran. Begärningar från operatörerna behandlas av analytiker: de samlar krav från kunden och presenterar sin vision för hur detta ska implementeras i programmet. Därefter följer en standardprocess: kodutveckling – testning – pilotdrift – leverans av koden till produktionsmiljön till den direkta beställaren.

Varför just SonarQube?

Det här är vår avdelnings första erfarenhet av att implementera en plattform för kodkvalitetskontroll – tidigare gjorde vi detta manuellt genom att enbart göra code review. Men den växande arbetsvolymen kräver automatisering av denna process. Dessutom finns det nyare medarbetare i teamet som inte är helt bekanta med interna utvecklingsregler och tenderar att göra fler misstag. För kodkvalitetskontroll har vi beslutat att införa en statisk analysator. Eftersom SonarQube redan använts i vissa system inom NDR, var det ingen lång valprocess. Tidigare har kollegor från andra avdelningar analyserat koden för mikrotjänster i systemet "Alameda" (NDR:s egen system för deponerings- och clearingredovisning), i CFT (informationssystem för bokföring, balansräkning, samt förberedelse av obligatoriska och interna rapporter), och i några andra system. För experimenten beslöt vi oss för att börja med den kostnadsfria versionen av SonarQube. Låt oss nu gå vidare till vårt fall.

Implementeringsprocess

Vi har:

• automatisk systemuppbyggnad i TeamCity;
• processen för att ladda upp kod via MergeRequest från feature-grenen till master-grenen i GitLab (utvecklingsprocess enligt GitHub Flow) är inställd;
• SonarQube, konfigurerat för att analysera koden för DPO-systemet enligt schema.

Vårt mål: införa automatiserad kodanalys i CI/CD-processerna för DPO.

Behöver ställas in: processen för automatisk kontroll av koden med den statiska analysatorn vid varje MergeRequest i huvudgrenen.

Det vill säga, den önskade bilden är följande: så snart en utvecklare laddar upp ändringar i feature-grenen, startar en automatisk kontroll för att upptäcka nya fel i koden. Om inga fel finns tillåts godkännande av ändringarna, annars måste felen åtgärdas. Redan i det tidiga skedet har vi kunnat identifiera ett visst antal fel i koden. Systemet har mycket flexibla inställningar: det kan anpassas så att det fungerar för specifika uppgifter, för varje system och programmeringsstil.

Inställning av QualityGate i SonarQube

Analys av QualityGate är något vi stötte på i djupet av internet. Ursprungligen använde vi en annan, mer komplicerad och på vissa sätt felaktig metod. Först körde vi en skanning genom SonarQube två gånger: vi skannade feature-grenen och grenen dit vi planerade att slå samman feature-grenen, och jämförde sedan antalet fel. Denna metod var inte stabil och gav inte alltid rätt resultat. Sedan fick vi veta att man istället för att köra SonarQube två gånger kan sätta en gräns för antal tillåtna fel (QualityGate) och analysera endast den gren som man laddar upp och jämför.

För närvarande använder vi fortfarande en ganska primitiv kodgranskning. Det bör noteras att SonarQube inte är kompatibelt med vissa programmeringsspråk, inklusive Delphi. För närvarande analyserar vi endast PLSql-kod för vårt system.

Det fungerar så här:

• Vi analyserar endast PL/SQL-kod för vårt projekt.
• QualityGate i SonarQube är inställt så att antalet fel inte ökar med varje commit.
• Antalet fel vid första körningen blev 229. Om antalet fel vid commit ökar, så tillåts inte sammanslagning.
• Vid åtgärdande av fel kan QualityGate ställas om.
• Det går också att lägga till nya punkter för analys, till exempel kodtäckning med tester osv.

Arbetsflöde:

I kommentarerna från skriptets arbete syns det att antalet fel i feature-grenen inte har ökat. Så allt är bra.

Knappen Merge blir tillgänglig.

I kommentarerna från skriptets arbete syns det att antalet fel i feature-grenen har blivit fler än tillåtet. Så det är dåligt.

Merge-knappen är röd. För närvarande finns det inget förbud mot att ladda upp ändringar med felaktig kod, men det görs på ansvarig utvecklares eget godtycke. I framtiden kan sådana commits förbjudas i huvudgrenen.

Självständigt arbete med felen

Det är nödvändigt att kontrollera alla fel som systemet identifierat, eftersom SonarQube analyserar efter sina strikta standarder. Det som anses vara ett fel av SonarQube, kan i verkligheten i vår kod såväl vara en icke-fråga. Därför måste vi kontrollera och notera om detta är ett verkligt fel, eller om det som vi har verkar vara i god ordning. På så sätt minskar vi antalet fel. Med tiden kommer systemet att lära sig att förstå dessa nyanser.

Vad har vi kommit fram till

Vårt mål var att förstå om det var rimligt att automatisera kodgranskning i vårt fall. Och resultatet har överträffat förväntningarna. SonarQube låter oss arbeta med de språk vi behöver, gör en ganska noggrann analys och har potentialen att lära sig av utvecklarnas tips. Sammanfattningsvis är vi nöjda med vår första erfarenhet av att använda SonarQube och planerar att fortsätta utvecklas inom detta område. Vi förväntar oss att vi i framtiden kommer att kunna spara mer tid och kraft på kodgranskning och göra den av högre kvalitet genom att eliminera den mänskliga faktorn. Kanske kommer vi under processen att upptäcka plattformens brister, eller å andra sidan, bli övertygade om att det verkligen är något bra med stor potential.

I denna översiktsartikel har vi berättat om vår bekantskap med den statiska analysatorn SonarQube. Om du har några frågor, skriv gärna i kommentarerna. Om du är intresserad av detta ämne, kommer vi i en ny publikation att mer detaljerat beskriva hur man korrekt ställer in allt och skriver kod för att göra en sådan kontroll.

Textens författare: atanya

Källa: habr.com