Vi skulle vilja dela med oss av vår erfarenhet av att implementera en plattform för kontinuerlig analys och mätning av kvaliteten på SonarQube-koden i de befintliga processerna för utveckling av DPO-systemet (ett tillägg till Alamedas förvarings- och clearingredovisningssystem) för National Settlement Depository.
National Settlement Depository (Moscow Exchange Group of Companies) är ett av de viktigaste finansiella infrastrukturföretagen som lagrar och registrerar värdepapper från ryska och utländska emittenter värda mer än 50 biljoner rubel. Den växande volymen av operationer som utförs av systemet, såväl som den kontinuerliga ökningen av funktionalitet, kräver att den höga kvaliteten på systemens källkod upprätthålls. Ett av verktygen för att uppnå detta mål är SonarQube statiska analysator. I den här artikeln beskriver vi den framgångsrika erfarenheten av att sömlöst implementera SonarQube statiska analysator i de befintliga utvecklingsprocesserna på vår avdelning.
Kort om avdelningen
Vår kompetens omfattar följande moduler: betalningar till NSD-kunder, elektronisk dokumenthantering (EDF), behandling av transaktionsförvarsmeddelanden (registrering av transaktioner utanför börsen), elektroniska interaktionskanaler mellan kunder och NSD och mycket mer. I allmänhet ett stort lager av arbete på den tekniska sidan av verksamheten. Vi arbetar utifrån ansökningar. Ansökningar från rösträknare behandlas av analytiker: de samlar in kundkrav och presenterar sin vision om hur det ska passa in i programmet. Vidare, standardschemat: kodutveckling - testning - provdrift - leverans av koden till den produktiva kretsen till den direkta kunden.
Varför SonarQube?
Detta är vår avdelnings första erfarenhet av att implementera en plattform för kodkvalitetskontroll - tidigare gjorde vi det manuellt, endast kodgranskning. Men den växande arbetsvolymen kräver automatisering av denna process. Dessutom finns det även oerfarna medarbetare i teamet som inte är helt insatta i interna utvecklingsregler och tenderar att göra fler misstag. För att kontrollera kvaliteten på koden beslutades det att implementera en statisk analysator. Eftersom SonarQube redan har använts i vissa NSD-system tog det inte lång tid att välja. Tidigare har kollegor från andra divisioner använt det för att analysera koden för mikrotjänster i Alameda-systemet (NSD:s eget depå- och clearingredovisningssystem), i CFT (informationssystem för redovisning, balans, upprättande av obligatorisk och intern rapportering), i vissa andra system . För att experimentera bestämde vi oss för att börja med gratisversionen av SonarQube. Så låt oss gå vidare till vårt fall.
Implementeringsprocess
Vi har:
- automatisk montering av systemet i TeamCity;
- ställ in processen att ladda upp kod via MergeRequest från en funktionsgren till huvudgrenen i GitLab (utvecklingsprocess enligt GitHub Flow);
- SonarQube konfigurerad för att analysera koden för DPO-systemet enligt schema.
Vårt mål: implementera automatisk kodanalys i CI/CD-processer av AVE.
Behöver anpassa: processen att automatiskt kontrollera koden av en statisk analysator med varje MergeRequest till huvudgrenen.
De där. målbilden är följande: så snart utvecklaren laddar upp ändringar till funktionsgrenen startar en automatisk kontroll efter nya fel i koden. Om det inte finns några fel får ändringarna accepteras, annars måste felen rättas till. Redan i det inledande skedet kunde vi identifiera ett visst antal fel i koden. Systemet har mycket flexibla inställningar: det kan konfigureras på ett sådant sätt att det fungerar för specifika uppgifter för utvecklare, för varje system och programmeringsstil.
Konfigurera QualityGate i SonarQube
QualityGate-analysen är en sak som vi läser i inälvorna på Internet. Till en början använde vi ett annat tillvägagångssätt, mer komplext och på något sätt inte helt korrekt. Först körde vi genomsökningen genom SonarQube två gånger: vi skannade funktionsgrenen och grenen där vi skulle slå samman funktionsgrenen, och sedan jämförde vi antalet fel. Denna metod var inte stabil och gav inte alltid rätt resultat. Och sedan lärde vi oss att istället för att köra SonarQube två gånger, kan du sätta en gräns för antalet fel som görs (QualityGate) och analysera endast grenen som du laddar upp och jämför.
För närvarande använder vi fortfarande en ganska primitiv kodkontroll. Det bör noteras att SonarQube inte är kompatibel med vissa programmeringsspråk, inklusive Delphi. För tillfället, för vårt system, analyserar vi endast PLSql-kod.
Det fungerar så här:
- Vi analyserar endast PL/SQL-kod för vårt projekt.
- QualityGate är konfigurerat i SonarQube så att antalet fel inte ökar med commit.
- Antalet fel vid den första körningen var 229. Om det finns fler fel under commit, är sammanslagning inte tillåten.
- Vidare, med förbehåll för korrigering av fel, kommer det att vara möjligt att omkonfigurera QualityGate.
- Du kan också lägga till nya objekt för analys, till exempel kodtäckning med tester, etc.
Arbetsschema:
I kommentarerna till skriptet kan du se att antalet fel i funktionsgrenen inte har ökat. Så allt är okej.
Knappen Sammanfoga blir tillgänglig.
I kommentarerna till skriptet kan du se att antalet fel i funktionsgrenen har blivit fler än tillåtet. Så allt är DÅLIGT.
Slå samman-knappen är röd. För närvarande finns det inget förbud mot att ladda upp ändringar av felaktig kod, men detta görs efter ansvarig utvecklares gottfinnande. I framtiden kan du förhindra att sådana åtaganden görs till huvudgrenen.
Självhantering med buggar
Därefter måste du kontrollera alla fel som upptäckts av systemet, eftersom SonarQube analyserar enligt dess strikta standarder. Det han anser vara ett fel kanske inte är ett i vår kod. Därför måste du kontrollera och notera om detta verkligen är ett misstag, eller om det inte finns något behov av att redigera i våra villkor. Därmed 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 är ändamålsenligt i vårt fall att överföra kodverifiering till automatisering. Och resultatet levde upp till förväntningarna. SonarQube låter oss arbeta med de språk vi behöver, gör ganska kompetenta analyser och har potential att lära av utvecklartips. I allmänhet är vi nöjda med vår första erfarenhet av SonarQube och planerar att utvecklas ytterligare i denna riktning. Vi förväntar oss att vi i framtiden kommer att kunna spara mer tid och ansträngning på kodgranskning och göra det bättre genom att eliminera den mänskliga faktorn. Kanske kommer vi i processen att upptäcka plattformens brister, eller tvärtom, vi kommer återigen att se till att detta är en cool grej med stor potential.
I den här översiktsartikeln pratade vi om vår bekantskap med SonarQube statiska analysator. Om du har frågor, skriv gärna i kommentarerna. Om du är intresserad av detta ämne kommer vi i den nya publikationen att beskriva mer i detalj hur du ställer in allt korrekt och skriver kod för att göra en sådan kontroll.
Textförfattare:
Källa: will.com