streamalism.org

1. Oversikt

I denne artikkelen skal vi se på analyse av statisk kildekode med SonarQube - som er en åpen kildekodeplattform for å sikre kodekvalitet.

La oss starte med et kjernespørsmål - hvorfor analysere kildekoden i utgangspunktet? Veldig enkelt sagt for å sikre kvalitet, pålitelighet og vedlikeholdsevne i løpet av prosjektets levetid; en dårlig skrevet kodebase er alltid dyrere å vedlikeholde.

OK, la oss komme i gang med å laste ned den nyeste LTS-versjonen av SonarQube fra nedlastingssiden og sette opp vår lokale server som beskrevet i denne hurtigstartveiledningen.

2. Analyse av kildekode

Nå som vi er logget inn, må vi opprette et token ved å spesifisere et navn - som kan være vårt brukernavn eller et hvilket som helst annet navn du velger, og klikk på generer-knappen.

Vi bruker token senere når vi analyserer prosjektet (e) våre. Vi må også velge hovedspråket (Java) og byggteknologien til prosjektet (Maven).

La oss definere pluginet i pom.xml:

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

Den siste versjonen av pluginet er tilgjengelig her. Nå må vi utføre denne kommandoen fra roten til prosjektkatalogen vår for å skanne den:

mvn ekkolodd: ekkolodd -Dsonar.host.url = // localhost: 9000 -Dsonar.login = den-genererte-token

Vi må erstatte den-genererte-token med symbolet ovenfra.

Prosjektet som vi brukte i denne artikkelen er tilgjengelig her.

Vi spesifiserte URL-adressen til SonarQube-serveren og påloggingen (generert token) som parametere for Maven-pluginet.

Etter at kommandoen er utført, vil resultatene være tilgjengelige på prosjekt dashbordet - kl // lokal vert: 9000.

Det er andre parametere som vi kan overføre til Maven-pluginet eller til og med angi fra nettgrensesnittet; ekkolodd.host.url, sonar.projectKey, og ekkolodd.kilder er obligatoriske mens andre er valgfrie.

Andre analyseparametere og standardverdiene er her. Vær også oppmerksom på at hvert språk-plugin har regler for analyse av kompatibel kildekode.

3. Analyseresultat

Nå som vi har analysert vårt første prosjekt, kan vi gå til webgrensesnittet på // lokal vert: 9000 og oppdater siden.

Der får vi se sammendraget av rapporten:

Oppdagede problemer kan enten være en feil, sårbarhet, kodelukt, dekning eller duplisering. Hver kategori har et tilsvarende antall utgaver eller en prosentverdi.

Videre kan problemer ha ett av fem forskjellige alvorlighetsnivåer: blokkerer, kritisk, dur, mindre og info. Rett foran prosjektnavnet er det et ikon som viser Quality Gate-statusen - bestått (grønn) eller mislyktes (rød).

Ved å klikke på prosjektnavnet vil vi ta oss til et dedikert dashbord der vi kan utforske spørsmål som er spesielle for prosjektet i større detalj.

Vi kan se prosjektkoden, aktiviteten og utføre administrasjonsoppgaver fra prosjektets dashbord - hver tilgjengelig på en egen fane.

Selv om det er en global Problemer fanen Problemer fanen på prosjektets instrumentpanel viser problemer som er spesifikke for det aktuelle prosjektet alene:

Problemfanen viser alltid kategorien, alvorlighetsgraden, taggen (e) og den beregnede innsatsen (angående tid) det vil ta å rette opp et problem.

Fra fanen Problemer er det mulig å tilordne et problem til en annen bruker, kommentere det og endre alvorlighetsgraden. Ved å klikke på selve utgaven vises mer detaljer om problemet.

Utgavefanen kommer med sofistikerte filtre til venstre. Dette er bra for å finne problemer. Så hvordan kan man vite om kodebasen er sunn nok til distribusjon i produksjon? Det er det Quality Gate er for.

4. SonarQube Quality Gate

I denne delen skal vi se på en nøkkelfunksjon i SonarQube - Quality Gate. Så får vi se et eksempel på hvordan du setter opp en tilpasset.

4.1. Hva er en kvalitetsport?

En kvalitetsport er et sett med betingelser prosjektet må oppfylle før det kan kvalifisere for produksjonsutgivelse. Det svarer på et spørsmål: kan jeg skyve koden min til produksjon i sin nåværende tilstand eller ikke?

Å sikre kodekvaliteten til "ny" kode mens du fikser eksisterende er en god måte å opprettholde en god kodebase over tid. Quality Gate gjør det lettere å sette opp regler for validering av hver nye kode som legges til kodebasen ved senere analyse.

Betingelsene satt i Quality Gate påvirker fremdeles umodifiserte kodesegmenter. Hvis vi over tid kan forhindre at nye problemer oppstår, vil vi eliminere alle problemer.

Denne tilnærmingen er sammenlignbar med å fikse vannlekkasjen fra kilden. Dette bringer oss til et bestemt begrep - Lekkasjeperiode. Dette er perioden mellom to analyser / versjoner av prosjektet.

Hvis vi kjører analysen på nytt på samme prosjekt, vil oversiktsfanen på prosjektdashboardet vise resultater for lekkasjeperioden:

Fra webgrensesnittet er kategorien Quality Gates hvor vi får tilgang til alle de definerte kvalitetsportene. Som standard, SonarQube måte kom forhåndsinstallert med serveren.

Standardkonfigurasjonen for SonarQube måte flagger koden som mislykket hvis:

• dekningen på ny kode er mindre enn 80%
• prosentandelen av dupliserte linjer på ny kode er større enn 3
• vedlikehold, pålitelighet eller sikkerhetsvurdering er verre enn A.

Med denne forståelsen kan vi lage en tilpasset Quality Gate.

4.2. Legger til tilpasset kvalitetsport

Først må vi Klikk på Kvalitetsporter og klikk deretter på Skape knapp som er til venstre på siden. Vi må gi det et navn - baeldung.

Nå kan vi stille vilkårene vi ønsker:

Fra Legg til tilstand drop-down, la oss velge Blokkeringsproblemer; det vil umiddelbart vises på listen over forhold.

Vi spesifiserer er større enn som Operatør, sett null (0) for Feil kolonne og sjekk Over Leak Period kolonne:

Så klikker vi på Legge til for å utføre endringene. La oss legge til en annen tilstand ved å følge samme prosedyre som ovenfor.

Vi velger problemer fra Legg til tilstand fall nedog sjekk Over Leak Period kolonne.

Verdien av Operator kolonnen blir satt til “er mindre enn" og vi legger til en (1) som verdien for Feil kolonne. Dette betyr Hvis antall problemer i den nye koden som er lagt til er mindre enn 1, merker du Quality Gate som mislykket.

Jeg vet at dette ikke gir teknisk mening, men la oss bruke det for lærings skyld. Ikke glem å klikke på Legge til knappen for å lagre regelen.

Et siste trinn, vi må knytte et prosjekt til vår tilpassede Quality Gate. Vi kan gjøre det ved å bla nedover på siden til Prosjekt-delen.

Der må vi klikke på Alt og deretter merke vårt valgte prosjekt. Vi kan like godt sette det som standard Quality Gate fra øverst til høyre på siden.

Vi skanner prosjektets kildekode igjen, som vi gjorde før med Maven-kommandoen. Når det er gjort, går vi til prosjektfanen og oppdaterer.

Denne gangen vil ikke prosjektet oppfylle Quality Gate-kriteriene og vil mislykkes. Hvorfor? Fordi i en av reglene våre har vi spesifisert det, bør det mislykkes hvis det ikke er noen nye problemer.

La oss gå tilbake til Quality Gates-fanen og endre tilstanden for problemer til er større enn. Vi må klikke på oppdateringsknappen for å gjennomføre denne endringen.

En ny skanning av kildekoden vil passere denne gangen.

5. Integrering av SonarQube i et CI

Å gjøre SonarQube til en del av en kontinuerlig integrasjonsprosess er mulig. Dette vil automatisk mislykkes i byggingen hvis kodeanalysen ikke tilfredsstilte Quality Gate-tilstanden.

For at vi skal oppnå dette, skal vi bruke SonarCloud, som er den skyhostede versjonen av SonaQube-serveren. Vi kan opprette en konto her.

Fra Min konto> Organisasjoner kan vi se organisasjonsnøkkelen, og den vil vanligvis være i skjemaet xxxx-github eller xxxx-bitbøtte.

Også fra Min konto> Sikkerhet, kan vi generere et token som vi gjorde i den lokale forekomsten av serveren. Legg merke til både token og organisasjonsnøkkel for senere bruk.

I denne artikkelen bruker vi Travis CI, og vi oppretter en konto her med en eksisterende Github-profil. Den vil laste alle prosjektene våre, og vi kan slå bryteren på hvilken som helst for å aktivere Travis CI på den.

Vi må legge til token vi genererte på SonarCloud til Travis miljøvariabler. Vi kan gjøre dette ved å klikke på prosjektet vi har aktivert for CI.

Deretter klikker vi på "Flere alternativer"> "Innstillinger" og ruller deretter ned til "Miljøvariabler":

Vi legger til en ny oppføring med navnet SONAR_TOKEN og bruk det genererte tokenet på SonarCloud som verdien. Travis CI vil kryptere og skjule den fra offentlig visning:

Til slutt må vi legge til en .travis.yml fil til roten til prosjektet vårt med følgende innhold:

språk: java sudo: false install: true addons: sonarcloud: organization: "your_organization_key" token: secure: "$ SONAR_TOKEN" jdk: - oraclejdk8 script: - mvn clean org.jacoco: jacoco-maven-plugin: forbered agent agent sonar : ekkoloddbuffer: kataloger: - '$ HOME / .m2 / repository' - '$ HOME / .sonar / cache'

Husk å erstatte organisasjonsnøkkelen med organisasjonsnøkkelen beskrevet ovenfor. Å begå den nye koden og trykke på Github repo vil utløse Travis CI-bygging og i sin tur aktivere ekkoloddskanning også.

6. Konklusjon

I denne veiledningen har vi sett på hvordan du setter opp en SonarQube-server lokalt og hvordan du bruker Quality Gate til å definere kriteriene for egnetheten til et prosjekt for produksjonsutgivelse.

SonarQube-dokumentasjonen har mer informasjon om andre aspekter av plattformen.