Kelionė
1) Pavyzdinio OpenEdge projekto generavimas su DI
Pradžiai paprašiau DI sugeneruoti nedidelį OpenEdge projektą su apie dešimt failų. Projektą sudarė paprasta meniu naudotojo sąsaja, kiek failų įvesties ir išvesties operacijų bei baziniai skaičiavimai.
DI uždavė kelis patikslinančius klausimus ir tuomet pateikė ZIP failą su instrukcijomis.
Pirmoji versija nesikompiliavo. Kompiliatoriaus klaidas nukopijavau atgal DI ir kartojau procesą, kol projektas pagaliau pradėjo veikti. DI taip pat įterpė komentarus tose vietose, kur sąmoningai įvedė netinkamas kodavimo praktikas. Tai vėliau palengvino pasirinktinių taisyklių testavimą.
2) SonarQube paleidimas „Docker“ aplinkoje
Toliau įsidiegiau „Docker Desktop“ sistemai „Windows“ ir paleidau oficialų SonarQube atvaizdą (image) iš „Docker Hub“.
Iš pradžių palikau prievado nustatymą kaip 0, kad „Docker“ jį priskirtų automatiškai. Tai pasirodė esąs klaidingas sprendimas. Kiekvieną kartą perkrovus konteinerį, prievadas pasikeisdavo, todėl man nuolat tekdavo atnaujinti URL ir konfigūraciją.
Sprendimas buvo paprastas: pririšti SonarQube prie statinio prievado.
3) Projekto struktūra ir sonar-project.properties
Projekto šaknyje sukūriau minimalų properties failą sonar-project.properties (rnd2 buvo mano OpenEdge projekto pavadinimas):
.png)
Tokia buvo mano projekto failų struktūra (src įtrauktas į PROPATH):
4) Pirmas prisijungimas, papildiniai ir ankstyvos klaidos
Paleidęs SonarQube, prisijungiau ir sukūriau naują projektą.
Iš pradžių sekiau DI sugeneruotas instrukcijas, kaip įdiegti su OpenEdge susijusius papildinius (plugins). Šis būdas pasirodė esąs klaidinantis.
Praleidau du svarbius elementus:
- ANT / PCT konfigūraciją;
- CABL licenciją.
Pagrindinė kliūtis buvo trūkstama CABL licencija. Kai sekiau oficialią „Riverside“ dokumentaciją ir įdiegiau jų OpenEdge papildinio JAR failus iš „Riverside“ SonarQube OpenEdge papildinio leidinių, viskas pradėjo veikti taip, kaip tikėtasi.
Įdomu tai, kad skenavimai veikė ir be ANT bei PCT. Manau, kad taip yra todėl, jog DI sugeneruotas projektas naudojo paprastus kelius ir standartinę struktūrą.
5) Papildinio JAR failų įdiegimas „Docker“ konteinerio viduje
Iš pradžių nesukonfigūravau bind mount nuorodos. Naudojau „Docker Desktop“ → Files skirtuką, kad įkelčiau aplanką į /tmp, tada atidariau root apvalkalą (shell) ir perkėliau JAR failus:
„Sonarqube“ yra konteinerio pavadinimas. Root naudotojas geriausiai tinka failams nukopijuoti į įprastą vietą.
Iš „Windows“ terminalo:
docker exec -it --user root sonarqube /bin/bash
mv /tmp/plugins/ * /opt/sonarqube/plėtiniai/atsisiuntimai/
Tada perkroviau konteinerį, kad SonarQube įdiegtų papildinius paleidimo metu. (Geriau naudoti bind mount nuorodą, bet tai veikė, kol eksperimentavau.)
6) SonarScanner paleidimas „Windows“ aplinkoje
Toliau atsisiunčiau „Windows x64“ SonarScanner versiją, ją išskleidžiau ir sugeneravau naudotojo žetoną (token) SonarQube aplinkoje. Dėl ankstesnės prievado 0 klaidos man teko atnaujinti URL po kiekvieno perkrovimo. Tai buvo dar viena priežastis nuo pat pradžių laikytis 9000 prievado. Štai kaip atrodė mano properties failas:
Įdiegęs papildinius, paleidau komandą iš savo OpenEdge projekto aplanko:
<.. >\ sonar-skaitytuvas-8.0.1.6346-windows-x64\ bin\ sonar-scanner.bat
Užbaigus skenavimą, atnaujinau projekto puslapį SonarQube aplinkoje, kad pamatyčiau rezultatus.
Iš pradžių turėjau tam tikrų problemų su:
- kokybės vartais (quality gates);
- taisyklių profiliais (rule profiles);
- taisyklių įjungimu.
Pagrindinė priežastis vėl buvo trūkstama CABL licencija. Tai išsprendus, OpenEdge taisyklės veikė įprastai.
Pirmasis sėkmingas skenavimas jau aptiko keletą problemų kodo bazėje. Tai reiškė, kad aplinka pagaliau buvo pasiruošusi pasirinktinėms taisyklėms. Skenerį galite atsisiųsti iš SonarScanner CLI dokumentacijos.
7) Pasirinktinės taisyklės kūrimas (šablonas + DI)
Kai skenavimo procesas pradėjo veikti, perėjau prie pasirinktinės taisyklės kūrimo. Atsisiunčiau „Riverside“ rules-plugin-template šabloną ir peržiūrėjau jų skaidrių rinkinį, paaiškinantį architektūrą.
Tuomet paprašiau DI sugeneruoti Java taisyklę ir įdėjau ją į šabloną. Užregistravau ją AcmeRulesDefinition.java faile (dviejose vietose), sekdamas NoOpRule ir TooManyParameters pavyzdžiais.
Pažiūrėkite, kur patalpinau Java taisyklę:
Sugeneruotas taisyklės kodas:
Registracija AcmeRulesDefinition.java faile:
Svarbu paminėti, kad prieš kurdamas pirmąją taisyklę atsisiunčiau „Riverside“ rules plugin šabloną ir peržiūrėjau SonarQube pasirinktinių taisyklių kūrimo dokumentaciją.
8) Papildinio sukūrimas ir taisyklės aktyvavimas
Norėdamas sukompiliuoti taisyklės papildinį, įsidiegiau Maven ir sukūriau šablono projektą.
Iš projekto šaknies:
<.. >/apache-maven-3.9.12/bin/mvn švarus paketas
Maven sėkmingai sugeneravo papildinio JAR failą. Tada nukopijavau JAR failą į SonarQube konteinerį naudodamas tą patį rankinį metodą kaip anksčiau ir perkroviau konteinerį. Po perkrovimo nauja taisyklė atsirado SonarQube sąsajoje. Pagal numatytuosius nustatymus ji buvo išjungta, todėl ją įjungiau taisyklių profilyje.
Paleidus skenerį dar kartą, gautas pirmasis rezultatas. Ataskaitoje buvo paryškintos kodo vietos, kuriose buvo naudojami MESSAGE sakiniai. Pirmoji pasirinktinė taisyklė veikė.
9) Taisyklių plėtimas
Po pirmos sėkmės eksperimentavau su papildomomis taisyklėmis. Vienas pavyzdys buvo StreamsMustBeClosedRule. Šis etapas atnešė keletą naujų iššūkių:
- Maven kompiliavimo klaidos, kilusios dėl neteisingų importų.
- Taisyklės užsikraudavo, bet neatsirasdavo sąsajoje.
- Taisyklės atsiranda, bet neaptinka problemų.
To buvo tikimasi. DI naudingas generuojant pradinius taškus, tačiau gautas rezultatas vis tiek reikalauja žmogaus patikrinimo ir teisingos integracijos. 2026 metais būtų neįprasta nenaudoti DI. Tačiau sugeneruotas turinys yra tik pradinis taškas. Jam vis tiek reikia žmogaus sprendimo ir tinkamos integracijos.
Ką šis eksperimentas išmokė: pagrindinės įžvalgos
Šis eksperimentas padėjo suprasti, kaip visa SonarQube konfigūracija veikia praktikoje. SonarQube paleidimas „Docker“ aplinkoje, SonarScanner konfigūravimas, OpenEdge papildinio diegimas ir CABL licencijos tvarkymas – visi šie žingsniai buvo svarbūs. Smulkūs konfigūracijos pasirinkimai, tokie kaip dinaminio „Docker“ prievado naudojimas, gali greitai sukurti nereikalingų problemų.
DI buvo naudingas generuojant pavyzdinį OpenEdge projektą ir formuluojant taisyklių idėjas, tačiau tai – tik pradinis taškas. Sugeneruotam kodui vis tiek reikia žmogaus sprendimo, patikrinimo ir tinkamos integracijos. Kai aplinka sukonfigūruota teisingai, pasirinktinių taisyklių kūrimas ir testavimas tampa žymiai paprastesnis. Tokie įrankiai kaip SonarQube gali atlikti svarbų vaidmenį palaikant kodo kokybę ilgalaikėse arba senose (legacy) sistemose.
Dažniausiai užduodami klausimai
Kodėl SonarQube OpenEdge taisyklės iš pradžių neveikė?
Pagrindinė priežastis buvo trūkstama CABL licencija. Be jos, kokybės vartai, taisyklių profiliai ir taisyklių įjungimas neveikė tinkamai. Šią problemą išsprendus pagal oficialią „Riverside“ dokumentaciją, OpenEdge taisyklės pradėjo veikti įprastai.
Kodėl svarbu naudoti statinį, o ne dinaminį Docker prievadą?
Naudojant dinaminį prievadą (nustatytą kaip 0), kiekvienas konteinerio perkrovimas pakeičia prievado numerį, todėl tenka nuolat atnaujinti URL ir konfigūraciją. Statinis prievadas (pvz., 9000) šios problemos išvengia.
Kaip pradėti kurti pasirinktinę OpenEdge taisyklę SonarQube aplinkoje?
Reikia atsisiųsti „Riverside“ rules-plugin-template šabloną, sukurti Java taisyklę, ją užregistruoti AcmeRulesDefinition.java faile, sukompiliuoti papildinį naudojant Maven, įdiegti sugeneruotą JAR failą į SonarQube konteinerį ir įjungti taisyklę taisyklių profilyje.
Ar DI gali pilnai automatizuoti pasirinktinių SonarQube taisyklių kūrimą?
Ne. DI naudingas generuojant pradinius taškus – pavyzdinius projektus ar taisyklių kodą, tačiau gautas rezultatas visada reikalauja žmogaus patikrinimo, klaidų taisymo ir teisingos integracijos į veikiančią sistemą.
