streamalism.org

1. Oversigt

I denne artikel vil vi se på statisk kildekodeanalyse med SonarQube - som er en open source-platform til sikring af kodekvalitet.

Lad os starte med et kernespørgsmål - hvorfor analysere kildekoden i første omgang? Meget simpelt for at sikre kvalitet, pålidelighed og vedligeholdelse i løbet af projektets levetid; en dårligt skrevet kodebase er altid dyrere at vedligeholde.

Okay, lad os nu komme i gang ved at downloade den nyeste LTS-version af SonarQube fra download-siden og opsætte vores lokale server som beskrevet i denne hurtigstartsvejledning.

2. Analyse af kildekode

Nu hvor vi er logget ind, skal vi oprette et token ved at angive et navn - som kan være vores brugernavn eller ethvert andet navn, du vælger, og klik på knappen generer.

Vi bruger token senere ved analysen af ​​vores (e) projekt (er). Vi har også brug for at vælge det primære sprog (Java) og bygningsteknologien til projektet (Maven).

Lad os definere pluginet i pom.xml:

    org.sonarsource.scanner.maven sonar-maven-plugin 3.4.0.905 

Den seneste version af pluginet er tilgængelig her. Nu skal vi udføre denne kommando fra roden til vores projektmappe for at scanne den:

mvn ekkolod: ekkolod -Dsonar.host.url = // localhost: 9000 -Dsonar.login = -genereret-token

Vi er nødt til at udskifte det-genererede-token med symbolet ovenfra.

Det projekt, vi brugte i denne artikel, er tilgængeligt her.

Vi specificerede værts-URL'en på SonarQube-serveren og login (genereret token) som parametre for Maven-pluginet.

Efter udførelse af kommandoen vil resultaterne være tilgængelige på dashboardet Projekter - kl // localhost: 9000.

Der er andre parametre, som vi kan overføre til Maven-pluginet eller endda indstille fra webgrænsefladen; ekkolod. vært.url, sonar.projectKeyog ekkolod. kilder er obligatoriske, mens andre er valgfri.

Andre analyseparametre og deres standardværdier er her. Bemærk også, at hvert sprog-plugin har regler til analyse af kompatibel kildekode.

3. Analyseresultat

Nu hvor vi har analyseret vores første projekt, kan vi gå til webgrænsefladen på // localhost: 9000 og opdater siden.

Der ser vi rapportoversigten:

Opdagede problemer kan enten være en fejl, sårbarhed, kodelugt, dækning eller duplikering. Hver kategori har et tilsvarende antal udgaver eller en procentværdi.

Desuden kan problemer have et af fem forskellige sværhedsgrader: blokering, kritisk, større, mindre og info. Lige foran projektnavnet er der et ikon, der viser Quality Gate-status - bestået (grøn) eller mislykket (rød).

Klik på projektnavnet fører os til et dedikeret dashboard, hvor vi kan udforske emner, der er specifikke for projektet mere detaljeret.

Vi kan se projektkoden, aktiviteten og udføre administrationsopgaver fra projektets dashboard - hver tilgængelig på en separat fane.

Selvom der er en global Problemer fanen Problemer fanen på projektets instrumentbræt viser spørgsmål, der er specifikke for det pågældende projekt alene:

Fanen Problemer viser altid kategori, sværhedsgrad, tag (er) og den beregnede indsats (med hensyn til tid), det tager at rette et problem.

Fra fanen problemer er det muligt at tildele et problem til en anden bruger, kommentere det og ændre dets sværhedsgrad. Hvis du klikker på selve emnet, vises flere detaljer om emnet.

Fanen Problem kommer med sofistikerede filtre til venstre. Disse er gode til at identificere problemer. Så hvordan kan man vide, om kodebasen er sund nok til implementering i produktion? Det er, hvad Quality Gate er til.

4. SonarQube kvalitetsport

I dette afsnit vil vi se på et nøglefunktion i SonarQube - Quality Gate. Så ser vi et eksempel på, hvordan man opretter en brugerdefineret.

4.1. Hvad er en kvalitetsport?

En Quality Gate er et sæt betingelser, som projektet skal opfylde, før det kan kvalificere sig til produktionsudgivelse. Det svarer på et spørgsmål: kan jeg skubbe min kode til produktion i sin nuværende tilstand eller ej?

Det er en god måde at opretholde en god codebase over tid at sikre "ny" kode kodekvalitet, mens man løser eksisterende. Quality Gate letter opsætning af regler til validering af hver ny kode, der føjes til kodebasen ved efterfølgende analyse.

Betingelserne i Quality Gate påvirker stadig umodificerede kodesegmenter. Hvis vi over tid kan forhindre nye problemer, fjerner vi alle problemer.

Denne tilgang er sammenlignelig med at rette vandlækage fra kilden. Dette bringer os til et bestemt begreb - Lækageperiode. Dette er perioden mellem to analyser / versioner af projektet.

Hvis vi kører analysen igen på det samme projekt, viser oversigtsfanen på projektdashboardet resultaterne for lækageperioden:

Fra webgrænsefladen er fanen Quality Gates, hvor vi kan få adgang til alle de definerede kvalitetsporte. Som standard, SonarQube måde kom forudinstalleret med serveren.

Standardkonfigurationen for SonarQube måde markerer koden som mislykket, hvis:

• dækningen på ny kode er mindre end 80%
• procentdelen af ​​duplikerede linjer på den nye kode er større end 3
• vedligeholdelsesevne, pålidelighed eller sikkerhedsvurdering er dårligere end A

Med denne forståelse kan vi oprette en brugerdefineret Quality Gate.

4.2. Tilføjelse af brugerdefineret kvalitetsport

Først skal vi klik på Kvalitetsporte fanen, og klik derefter på skab knap som er til venstre på siden. Vi bliver nødt til at give det et navn - baeldung.

Nu kan vi indstille de betingelser, vi ønsker:

Fra Tilføj betingelse drop-down, lad os vælge Problemer med blokeringen; det vises straks på listen over betingelser.

Vi specificerer er større end som den Operatør, indstil nul (0) for Fejl kolonne og tjek Over lækage periode kolonne:

Så klikker vi på Tilføje for at foretage ændringerne. Lad os tilføje en anden betingelse efter samme procedure som ovenfor.

Vi vælger problemer fra Tilføj betingelse drop-downog tjek Over lækage periode kolonne.

Værdien af ​​Operator kolonne indstilles til “er mindre end" og vi tilføjer en (1) som værdien for Fejl kolonne. Det betyder hvis antallet af problemer i den nye tilføjede kode er mindre end 1, skal du markere Quality Gate som mislykket.

Jeg ved, at dette ikke giver teknisk mening, men lad os bruge det til lærings skyld. Glem ikke at klikke på Tilføje knappen for at gemme reglen.

Et sidste trin, vi er nødt til at vedhæfte et projekt til vores brugerdefinerede Quality Gate. Det kan vi gøre ved at rulle ned på siden til afsnittet Projekter.

Der skal vi klikke på Alle og derefter markere vores valgte projekt. Vi kan lige så godt indstille det som standard Quality Gate fra øverste højre hjørne af siden.

Vi scanner projektets kildekode igen, som vi gjorde før med Maven-kommandoen. Når det er gjort, går vi til projektfanen og opdaterer.

Denne gang opfylder projektet ikke Quality Gate-kriterierne og mislykkes. Hvorfor? Fordi i en af ​​vores regler har vi specificeret det, skal det mislykkes, hvis der ikke er nye problemer.

Lad os gå tilbage til fanen Quality Gates og ændre betingelsen for problemer til er større end. Vi er nødt til at klikke på opdateringsknappen for at foretage denne ændring.

En ny scanning af kildekoden vil passere denne gang.

5. Integrering af SonarQube i et CI

Det er muligt at gøre SonarQube til en del af en kontinuerlig integrationsproces. Dette mislykkes automatisk bygningen, hvis kodeanalysen ikke opfyldte Quality Gate-betingelsen.

For at vi kan opnå dette, skal vi bruge SonarCloud, som er den cloudhostede version af SonaQube-serveren. Vi kan oprette en konto her.

Fra Min konto> Organisationer kan vi se organisationsnøglen, og den vil normalt være i form xxxx-github eller xxxx-bitbucket.

Også fra Min konto> Sikkerhed, kan vi generere et token som vi gjorde i den lokale forekomst af serveren. Vær opmærksom på både token og organisationsnøgle til senere brug.

I denne artikel bruger vi Travis CI, og vi opretter en konto her med en eksisterende Github-profil. Det indlæser alle vores projekter, og vi kan vende kontakten på en hvilken som helst for at aktivere Travis CI på den.

Vi er nødt til at tilføje det token, vi genererede på SonarCloud til Travis-miljøvariabler. Vi kan gøre dette ved at klikke på det projekt, vi har aktiveret for CI.

Derefter klikker vi på "Flere indstillinger"> "Indstillinger" og ruller derefter ned til "Miljøvariabler":

Vi tilføjer en ny post med navnet SONAR_TOKEN og brug det genererede token på SonarCloud som værdi. Travis CI krypterer og skjuler det fra den offentlige visning:

Endelig skal vi tilføje en .travis.yml fil til roden af ​​vores projekt med følgende indhold:

sprog: java sudo: false installation: true addons: sonarcloud: organisation: "your_organization_key" token: sikker: "$ SONAR_TOKEN" jdk: - oraclejdk8 script: - mvn ren org.jacoco: jacoco-maven-plugin: forbered agent agent sonar : ekkolods cache: kataloger: - '$ HOME / .m2 / repository' - '$ HOME / .sonar / cache'

Husk at erstatte din organisationsnøgle med organisationsnøglen beskrevet ovenfor. Forpligtelse af den nye kode og skubbe til Github repo vil udløse Travis CI-opbygning og til gengæld også aktivere sonarscanning.

6. Konklusion

I denne vejledning har vi set på, hvordan man opretter en SonarQube-server lokalt, og hvordan man bruger Quality Gate til at definere kriterierne for et projekts egnethed til produktionsudgivelse.

SonarQube-dokumentationen har flere oplysninger om andre aspekter af platformen.