Wij willen onze ervaring delen met de implementatie van het platform voor continue analyse en kwaliteitsmeting van code, SonarQube, in de bestaande ontwikkelingsprocessen van het DPO-systeem (aanvulling op het depot- en clearingaccount-systeem "Alameda") van het Nationaal Rekening Depot.
Het Nationaal Rekening Depot (groep van bedrijven "Moscow Exchange") is een van de sleutelfirma's in de financiële infrastructuur en beheert en houdt de effecten van Russische en buitenlandse emittenten bij ter waarde van meer dan 50 biljoen roebel. Het groeiende volume van de transacties die door het systeem worden uitgevoerd, evenals de voortdurende uitbreiding van functionaliteit, vereisen het handhaven van een hoge kwaliteit van de broncode van systemen. Een van de instrumenten om dit doel te bereiken, is de statische analizer SonarQube. In dit artikel zullen we onze succesvolle ervaring beschrijven met de naadloze implementatie van de statische analizer SonarQube in de bestaande ontwikkelingsprocessen van onze afdeling.
Kort over de afdeling
Onze competentie omvat de volgende modules: betalingen aan klanten van het NRD, elektronische documentstromen (EDO), verwerking van berichten van de handelsdepot (registratie van niet-beurs transacties), kanalen voor elektronische interactie tussen klanten en het NRD en nog veel meer. Kortom, een grote hoeveelheid werk aan de technische kant van de operationele activiteiten. We werken op basis van aanvragen. Aanvragen van operationele medewerkers worden behandeld door analisten: zij verzamelen de eisen van de klant en presenteren ons hun visie op hoe dit in het programma moet worden verwerkt. Vervolgens geldt het standaard schema: code-ontwikkeling – testen – proefbedrijf – levering van de code aan de productieve omgeving aan de directe klant.
Waarom juist SonarQube?
Dit is de eerste ervaring van onze afdeling met de implementatie van een platform voor kwaliteitscontrole van code - eerder deden we dit handmatig en voerden we alleen code reviews uit. Maar het groeiende werkvolume vereist automatisering van dit proces. Daarnaast zijn er in het team ook onervaren medewerkers, die niet volledig bekend zijn met de interne ontwikkelingsprocedures en geneigd zijn meer fouten te maken. Voor de kwaliteitscontrole van de code was besloten om een statische analyzer te implementeren. Aangezien SonarQube al in sommige systemen van NDC werd gebruikt, was de keuze snel gemaakt. Eerdere collega’s uit andere afdelingen analyseerden hiermee de code van microservices in het systeem 'Alemada' (het eigen systeem voor depot- en clearingboekhouding van NDC), in CFT (informatie systeem voor het bijhouden van boekhouding, balans, en voorbereiding van verplichte en interne rapportages), en in enkele andere systemen. Voor de experimenten besloten we te beginnen met de gratis versie van SonarQube. Laten we nu naar onze casus gaan.
Implementatieproces
Wij hebben:
- automatische systeemassemblage in TeamCity;
- het proces voor het uploaden van code via MergeRequest van de feature-branch naar de master-branch in GitLab is ingesteld (ontwikkelingsproces volgens GitHub Flow);
- SonarQube, ingesteld op het analyseren van code voor het DP-systeem volgens schema.
Ons doel: automatische code-analyse integreren in de CI/CD-processen van het DP.
Moet worden ingesteld: het proces voor de automatische controle van de code door de statische analyzer bij elke MergeRequest naar de hoofdbranch.
Dat wil zeggen, het doel is als volgt: zodra een ontwikkelaar wijzigingen in de feature-branch uploadt, wordt er automatisch gecontroleerd op nieuwe fouten in de code. Als er geen fouten zijn, mogen de wijzigingen worden geaccepteerd, anders moeten de fouten worden gecorrigeerd. Al in de beginfase hebben we een aantal fouten in de code kunnen identificeren. Het systeem heeft zeer flexibele instellingen: het kan zo worden ingesteld dat het werkt voor specifieke taken van ontwikkelaars, voor elk systeem en programmeerstijl.
Instelling van QualityGate in SonarQube
De analyse van QualityGate is iets dat we hebben ontdekt in de diepere uithoeken van het internet. Aanvankelijk gebruikten we een andere aanpak, die ingewikkelder was en op sommige punten niet helemaal correct. We voerden eerst twee keer een scan uit via SonarQube: we scanden de feature-tak en de tak waarin we de feature-tak zouden integreren, en vergeleken vervolgens het aantal fouten. Deze methode was niet stabiel en gaf niet altijd de juiste resultaten. Toen ontdekten we dat we in plaats van dubbele scans via SonarQube een limiet op het aantal toegestane fouten (QualityGate) kunnen instellen en alleen de tak kunnen analyseren die je toevoegt en vergelijkt.
Voorlopig gebruiken we nog een vrij primitieve codecontrole. Het is vermeldenswaard dat SonarQube incompatibel is met enkele programmeertalen, waaronder Delphi. Op dit moment analyseren we alleen PLSql-code voor ons systeem.
Dit werkt zo:
- We analyseren voor ons project alleen PL/SQL-code.
- In SonarQube is QualityGate zo ingesteld dat het aantal fouten niet toeneemt met een commit.
- Bij de eerste scan kregen we 229 fouten. Als het aantal fouten bij een commit toeneemt, wordt de merge niet toegestaan.
- Bij correctie van fouten kan QualityGate verder opnieuw worden ingesteld.
- Daarnaast kunnen er nieuwe punten voor analyse worden toegevoegd, zoals codecoverage door tests, enz.
Werkwijze:
In de opmerkingen van het script is te zien dat het aantal fouten in de feature-tak niet is gestegen. Dat betekent dat alles O.K. is.
De Merge-knop wordt beschikbaar.
In de opmerkingen van het script is te zien dat het aantal fouten in de feature-tak de toegestane limiet heeft overschreden. Dat betekent dat alles SLECHT is.
De Merge-knop is rood. Momenteel is er geen verbod om wijzigingen in foutieve code door te voeren, maar dit wordt gedaan naar eigen inzicht van de verantwoordelijke ontwikkelaar. In de toekomst kan het verboden worden om dergelijke commits in de hoofdtaak te plaatsen.
Zelfstandig werken aan fouten
Vervolgens moeten alle door het systeem opgespoorde fouten worden gecontroleerd, omdat SonarQube analyseert volgens zijn strenge normen. Wat hij als een fout beschouwt, hoeft in onze code niet per se een fout te zijn. Daarom is het nodig om te controleren en aan te geven of dit echt een fout is, of dat er in onze situatie geen noodzaak is om dit te corrigeren. Op deze manier verminderen we het aantal fouten. Na verloop van tijd leert het systeem deze nuances te begrijpen.
Waar zijn we gekomen
Ons doel was om te begrijpen of het in ons geval zinvol zou zijn om de codecontrole te automatiseren. En het resultaat voldeed aan de verwachtingen. SonarQube stelt ons in staat om met de benodigde talen te werken, biedt een behoorlijk goede analyse en heeft het potentieel om te leren van de suggesties van ontwikkelaars. Al met al zijn we tevreden met onze eerste ervaring met SonarQube en plannen we om ons verder in deze richting te ontwikkelen. We verwachten dat we in de toekomst meer tijd en moeite kunnen besparen op codecontrole en deze kwalitatief beter kunnen maken door de menselijke factor uit te schakelen. Misschien ontdekken we tijdens het proces tekortkomingen van het platform of, omgekeerd, bevestigen we nogmaals dat dit een geweldig hulpmiddel is met veel potentieel.
In dit overzichtsartikel delen we onze kennismaking met de statische analyse-tool SonarQube. Als je vragen hebt, laat het ons weten in de reacties. Als je geïnteresseerd bent in dit onderwerp, zullen we in een nieuwe publicatie uitgebreider beschrijven hoe je alles goed kunt instellen en de code kunt schrijven om dergelijke controles uit te voeren.
Auteur van de tekst:
Bron: habr.com
