streamalism.org

1. Áttekintés

Ebben a cikkben statikus forráskód-elemzést fogunk megvizsgálni a SonarQube segítségével - amely egy nyílt forráskódú platform a kódminőség biztosításához.

Kezdjük egy alapvető kérdéssel - miért elemezzük elsősorban a forráskódot? Nagyon egyszerűen: a minőség, a megbízhatóság és a karbantarthatóság biztosítása a projekt élettartama alatt; a rosszul megírt kódbázis fenntartása mindig drágább.

Rendben, most kezdjük azzal, hogy letöltjük a SonarQube legújabb LTS verzióját a letöltési oldalról, és beállítjuk helyi szerverünket a jelen gyors útmutatóban leírtak szerint.

2. Forráskód elemzése

Most, hogy be vagyunk jelentkezve, létre kell hoznunk egy tokent egy név megadásával - amely lehet a felhasználónevünk vagy bármely más választott név, majd kattintson a generálás gombra.

A tokent később, a projekt (ek) elemzésénél használjuk. Ki kell választanunk a projekt elsődleges nyelvét (Java) és a gyártási technológiát (Maven) is.

Határozzuk meg a plugint a pom.xml:

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

A bővítmény legújabb verziója itt érhető el. Most ezt a parancsot a projektkönyvtárunk gyökeréből kell végrehajtanunk a beolvasáshoz:

mvn szonár: szonár -Dsonar.host.url = // localhost: 9000 -Dsonar.login = a létrehozott token

Ki kell cserélnünk a létrehozott-token felülről a jelzővel.

A cikkben használt projekt itt érhető el.

Megadtuk a SonarQube kiszolgáló gazdagép URL-jét és a bejelentkezést (létrehozott tokent) a Maven plugin paramétereként.

A parancs végrehajtása után az eredmények elérhetők lesznek a Projektek irányítópultján - // localhost: 9000.

Vannak más paraméterek, amelyeket átadhatunk a Maven beépülő modulnak, vagy akár a webes felületről is beállíthatjuk őket; szonár.igazgató.URL, szonár.projectKey, és szonár.források kötelezőek, míg mások nem kötelezőek.

További elemzési paraméterek és alapértelmezett értékeik itt találhatók. Vegye figyelembe azt is, hogy minden nyelvi plugin rendelkezik szabályokkal a kompatibilis forráskód elemzésére.

3. Elemzés eredménye

Most, hogy elemeztük az első projektünket, a webes felületre léphetünk a címen // localhost: 9000 és frissítse az oldalt.

Itt láthatjuk a jelentés összefoglalóját:

A felfedezett problémák lehetnek hibák, biztonsági rések, kódszagok, lefedettség vagy másolatok. Minden kategóriának megfelelő számú kibocsátása vagy százalékos értéke van.

Sőt, a kérdéseknek öt különböző súlyossági szintje lehet: blokkoló, kritikus, őrnagy, kiskorú és info. A projekt neve előtt egy ikon látható, amely a Minőségi kapu állapotát jelzi - át (zöld) vagy sikertelen (piros).

A projekt nevére kattintva egy dedikált irányítópultra jutunk, ahol részletesebben megvizsgálhatjuk a projekthez kapcsolódó kérdéseket.

A projekt irányítópultjáról láthatjuk a projekt kódját, tevékenységét és elvégezhetjük az adminisztrációs feladatokat - mindegyik külön fülön érhető el.

Bár van egy globális Problémák fülre, a Problémák fül a projekt irányítópultján egyedül az adott projektre vonatkozó kérdéseket jelenít meg:

A problémák lapon mindig megjelenik a kategória, a súlyosság szintje, a címkék és címkék, valamint a számítások (az idő függvényében), amelyek a probléma kijavításához szükségesek.

A kérdések lapról lehetőség van egy probléma hozzárendeléséhez egy másik felhasználóhoz, véleményezéshez és súlyosságának megváltoztatásához. Magára a kérdésre kattintva további részletek láthatók a kérdésről.

A Kiadás lap kifinomult szűrőkkel érkezik balra. Ezek jók a problémák pontos meghatározására. Tehát honnan lehet tudni, hogy a kódbázis elég egészséges-e a gyártásba történő telepítéshez? Erre szolgál a Minőségi kapu.

4. SonarQube minőségi kapu

Ebben a részben megvizsgáljuk a SonarQube egyik fő jellemzőjét - a Minőségi kaput. Ezután látunk egy példát az egyéni beállítására.

4.1. Mi az a minőségi kapu?

A minőségi kapu olyan feltételek összessége, amelynek a projektnek meg kell felelnie, mielőtt jogosult lenne a gyártás kiadására. Egy kérdésre ad választ: a kódot a jelenlegi állapotában tudok-e produkcióba állítani vagy sem?

Az „új” kód minőségének biztosítása a meglévők javításával egy jó módszer a jó kódbázis időbeli fenntartására. A minőségi kapu megkönnyíti a szabályok felállítását a kódalapba felvett minden új kód hitelesítésére a későbbi elemzés során.

A minőségi kapuban meghatározott feltételek továbbra is befolyásolják a módosítatlan kódszegmenseket. Ha idővel megakadályozhatjuk az új problémák felmerülését, minden problémát megszüntetünk.

Ez a megközelítés összehasonlítható a forrás szivárgásának megszüntetésével. Ez egy adott kifejezéshez vezet - Szivárgási periódus. Ez a projekt két elemzése / változata közötti időszak.

Ha újra elvégezzük az elemzést, ugyanazon projekten a projekt irányítópultjának áttekintő lapján láthatók a szivárgási időszak eredményei:

A webes felületről a Minőségi kapuk fülön érhetjük el az összes meghatározott minőségi kaput. Alapértelmezés szerint, SonarQube módon a szerverrel előre telepítve lett.

A. Alapértelmezett konfigurációja SonarQube módon meghiúsultként jelöli a kódot, ha:

• az új kód lefedettsége kevesebb, mint 80%
• Az új kód duplikált sorainak százaléka nagyobb, mint 3
• a karbantarthatóság, a megbízhatóság vagy a biztonsági besorolás rosszabb, mint az A

Ezzel a megértéssel létrehozhatunk egy egyedi minőségi kaput.

4.2. Custom Quality Gate hozzáadása

Először is meg kell kattintson a Minőségi kapuk fülre, majd kattintson a Teremt gomb amely az oldal bal oldalán található. Nevet kell adnunk neki - baeldung.

Most beállíthatjuk a kívánt feltételeket:

Tól Feltétel hozzáadása legördülő menüből válasszunk Blokkoló kérdések; azonnal feltűnik a feltételek listáján.

Pontosítjuk nagyobb, mint mint a Operátor, állítson nulla (0) értéket a Hiba oszlopot és ellenőrizze Szivárgási időszak alatt oszlop:

Akkor rákattintunk a Hozzáadás gombot a változtatások végrehajtásához. Vegyünk fel egy másik feltételt a fenti eljárással összhangban.

Kiválasztjuk problémák tól Feltétel hozzáadása ledobés ellenőrizze Szivárgási időszak alatt oszlop.

Az O értékeperator oszlop értéke „kevesebb mint" és hozzáadunk egy (1) értéket a Hiba oszlop. Ez azt jelenti, hogy ha a hozzáadott új kódban szereplő problémák száma kevesebb, mint 1, jelölje meg a minőségi kaput sikertelennek.

Tudom, hogy ennek nincs technikai értelme, de használjuk a tanulás kedvéért. Ne felejtsen el kattintani a gombra Hozzáadás gombra a szabály mentéséhez.

Egy utolsó lépésként csatolnunk kell egy projektet az egyedi Minőségi kapuinkhoz. Megtehetjük, ha lefelé görgetjük a Projektek részt.

Kattintson az Összes gombra, majd jelölje meg a kiválasztott projektünket. Azt is beállíthatjuk, mint az alapértelmezett Minőségi kaput az oldal jobb felső sarkából.

Ismét átvizsgáljuk a projekt forráskódját, mint korábban a Maven paranccsal. Ha ez megtörtént, a Projektek fülre megyünk, és frissítünk.

Ezúttal a projekt nem fog megfelelni a minőségi kapu kritériumainak, és kudarcot vall. Miért? Mivel az egyik szabályunkban ezt meghatároztuk, meg kell buknia, ha nincsenek új kérdések.

Térjünk vissza a Minőségi kapuk fülre, és változtassuk meg a feltételét problémák nak nek nagyobb, mint. A változás végrehajtásához kattintson a Frissítés gombra.

Ezúttal a forráskód új vizsgálata fog végbemenni.

5. A SonarQube integrálása a CI-be

Lehetséges, hogy a SonarQube a folyamatos integrációs folyamat részévé váljon. Ez automatikusan meghiúsítja az összeállítást, ha a kódelemzés nem felel meg a Quality Gate feltételnek.

Ennek elérése érdekében a SonarCloud-ot fogjuk használni, amely a SonaQube szerver felhő által üzemeltetett verziója. Itt létrehozhatunk egy fiókot.

A Saját fiók> Szervezetek menüpontban láthatjuk a szervezeti kulcsot, amely általában formában jelenik meg xxxx-github vagy xxxx-bitbucket.

-Tól is Saját fiók> Biztonság, akkor létrehozhatunk egy tokent, ahogy a szerver helyi példányában tettük. Vegye figyelembe a tokent és a szervezeti kulcsot későbbi felhasználás céljából.

Ebben a cikkben a Travis CI-t fogjuk használni, és itt létrehozunk egy fiókot egy meglévő Github-profillal. Minden projektünket betölti, és bármelyik kapcsolót megfordíthatjuk, hogy aktiválhassuk rajta a Travis CI-t.

Hozzá kell adnunk a SonarCloudon létrehozott tokent a Travis környezeti változókhoz. Ehhez kattintson a projektre, amelyet aktiváltunk a CI számára.

Ezután kattintson a „További lehetőségek”> „Beállítások” elemre, majd görgessen le a „Környezeti változók” részhez:

Hozzáadunk egy új bejegyzést a névvel SONAR_TOKEN és használja a SonarCloudon létrehozott tokent értékként. A Travis CI titkosítja és elrejti a nyilvánosság elől:

Végül hozzá kell adnunk a .travis.yml fájl a projektünk gyökeréig a következő tartalommal:

nyelv: java sudo: false install: true addons: sonarcloud: organization: "your_organization_key" token: biztonságos: "$ SONAR_TOKEN" jdk: - oraclejdk8 szkript: - mvn clean org.jacoco: jacoco-maven-plugin: Prepar-agent csomag szonár : szonár gyorsítótár: könyvtárak: - '$ HOME / .m2 / repository' - '$ HOME / .sonar / cache'

Ne felejtse el cserélni a szervezeti kulcsot a fent leírt szervezeti kulccsal. Az új kód elkötelezése és a Github repo-ra való áthelyezés elindítja a Travis CI felépítését, és ezzel aktiválja a szonár szkennelését is.

6. Következtetés

Ebben az oktatóanyagban megvizsgáltuk, hogyan lehet helyileg beállítani a SonarQube kiszolgálót, és hogyan lehet a Quality Gate használatával meghatározni a projekt megfelelőségének kritériumait a gyártási kiadáshoz.

A SonarQube dokumentációja további információkat tartalmaz a platform egyéb aspektusairól.