SonarQube, continuous inspection, integracja z gitlabem.

Dzisiaj postaram się przybliżyć Wam narzędzie SonarQube, o którym może słyszeliście. W tym artykule opiszę czym jest, jak go skonfigurować, w jakim celu używać, co może zaoferować oraz czy tak naprawdę warto(?).

 

  1. Co to jest SonarQube?
    SonarQube to platforma open source, dzięki której możemy przeprowadzać automatycznie statyczną analizę kodu. Co to znaczy? Uruchamiając analizę za pomocą sonara, możemy sprawdzić kod pod względem błędów, konwencji kodowania (codesmells) oraz luk bezpieczeństwa. SonarQube może zbadać kod w ponad 20 językach programowania włączając Java, C#, JavaScript, TypeScript, PHP, C/C++.
  2.  Gdzie go używać?
    Sonara możemy używać na kilka różnych sposobów. Jeśli mamy projekt open source, możemy użyć platformy Sonar cloud łącząc ją na przykład ze swoim kontem na githubie. Jeśli projekt jest prywatny, także możemy skorzystać z chmury, jednak po 14 dniowym okresie próbnym, będziemy musieli zapłacić 10€ miesięcznie.Kolejnym miejscem gdzie możemy używać sonara, jest nasz edytor lub IDE. Ja osobiście używam PHPStorma, gdzie można zainstalować plugin sonarlint lub SonarQube. Obie wtyczki umożliwiają nam analizę bezpośrednio w środowisku, w którym tworzymy kod.Istnieje jeszcze jedna możliwość integracji tego narzędzia. Możemy z pomocą pluginu uruchamiać analizę na serwerze gdzie mamy projekt, łącząc go z hookami w naszym repozytorium. W moim przypadku połączyłem to z pushem do Gita i Gitlabem. W kolejnym akapicie pokażę jak można skonfigurować ten ostatni przypadek.
  3. Konfiguracja 
    W moim przypadku SonarQube jest używany dla analizy PHP i JavaScript. Używamy go w połączeniu z Gitlabem. Pierwszą rzeczą jaką musmy zrobić to zainstalowanie instancji SonarQube, która będzie gromadziła dane z analiz. Instalację przeprowadzamy zgodnie z instrukcją dostępną na stronie SonarQuba instalacja. Po zainstalowaniu będziemy mieli dostępne GUI narzędzia, do którego możemy się zalogować , dodać projekt oraz zarządzać regułami analizy. Więcej informacji znajdziecie w dokumentacji user guideKolejnym krokiem jest instalacja pluginu, który umożliwi nam integrację z Gitlabem. Plugin należy zainstalować na naszym środowisku conitnous integration (CI), tak aby możliwe było jego uruchomienie przez gitlaba. Plugin dostępy na githubie sonar-gitlab-pugin. Dokumentacja wtyczki jest bardzo dobra, zawiera opis co należy wykonać oraz przykłady konfiguracji dla różnych narzędzi.
    Skaner sonara ma możliwość komentowania analizowanego kodu co w łatwy sposób pokazuje, do których linii konkretnie zgłaszane są uwagi. Do tego celu będziemy potrzebować token usera z gitlaba. Możemy użyć istniejącego użytkownika, ale sugeruję utworzenie nowego o nazwie np. sonar i wygenerowania tokenu dla niego.

    Po instalacji pluginu, należy dodać plik z sonar.properties oraz stworzyć skrypty .sh, które wskażą odpowiednie pliki do przeanalizowania oraz umożliwią skanerowi dodawanie komentarzy w gitlabie.


    Sonar.projectKey definiujemy przy tworzeniu projektu w instancji sonarQube. Klucz występuje w formacie nazwaProjektu:nazwaBrancha -> exampleProject:master. Powyższe ustawienia są niezbędne do skanowania całego projektu, np. za pomocą Crona.

    Skrypty umieszczamy w gitlab-ci.yml:


    Tutaj zawartość sonar-scanner.sh

    Kilka słów wyjaśnienia co dzieje się w skryptach powyżej, w gitlab-ci.yml mamy zdefiniowane parametry dla sonar scanner, poniżej nich znajduje się sekcja z jobem scannera uruchamiana jako pipeline w gitlabie. Jak widać jest uruchamiany skrypt, który znajduje się w drugim pliku. W docelowym skrypcie bashowym do właściwej analizy musimy wskazać kilka elementów.

    SONAR_SOURCES – to lista zmodyfikowanych plików w aktualnym commicie
    $CI_COMMIT_SHA – to hash aktualnego commita
    $CI_COMMIT_REF_NAME – nazwa aktualnego brancha

    Te ustawienia pozwolą nam na uruchomienie analizy statycznej kodu, który zmodyfikowaliśmy w ramach naszego brancha. Zawsze brane pod uwagę są tylko zmiany z danego commita względem commita poprzedniego.


    Powyższa konfiguracja umożliwia nam sprawdzenie aktualnego, zmodyfikowanego fragmentu kodu, a co jeśli chcę sprawdzić cały projekt? Skrypt jest podobny,


    Raport z takiej globalnej analizy trafia do naszego SonarQuba zainstalowanego w kroku pierwszym.
    Przykładowe wyniki prezentują się w taki sposób:

  4. Co nam to daje?
    Oczywistą wartością jest raport odnośnie stanu naszego kodu. Dzięki regularnemu skanowaniu całego projektu SonarQube może przedstawić nam metryki, dzięki którym dowiemy się o kondycji naszej aplikacji. Dowiemy się jakiej wielkości mamy dług techniczny i przede wszystkim czy on rośnie czy maleje. Możemy sprawdzić na jakim poziomie mamy pokrycie utestami w naszym projekcie.
    Jendak to tylko suche dane, które przedstawione w raportach zbiorczych nie muszą wnosić niczego więcej oprócz, kolorowych wykresow i jakiś tam cyferek.
    To o co nam chodzi, to realny wpływ na wyłapywanie błędów, zagrożeń oraz nieprawidłowości w naszym kodzie na bieżąco.Dla mnie osobiście SonarQube, a zwłaszcza scanner sonara połączony z pushami to świetne narzędzie. Dzięki komentarzom jakie zostawia w gitlabie, mogę pochylić się nad usuwaniem uwag, dzięki czemu dług techniczny projektu maleje. Nie chodzi mi tutaj o jakiś wielki refactoring, tylko o poświęcenie kilku minut, aby poprawiać kod, który został skomentowany, poczynając od najmniejszych.
    Pracowałem w dużych projektach gdzie tych uwag było tysiące i jakby każdy programista usnął po dwie uwagi przy każdym merge requescie, to dług techniczny szybko by malał.Jest jeszcze jedna bardzo ważna rzecz, którą powinniśmy zyskać używając tego narzędzia. Zwracając uwagę na komentarze scannera, często udaje mi się spojrzeć na kod z innej perspektywy i skupić na rozwiązaniu (metodzie, petli, mapowaniu itp). Zamiast ślepo poprawiając uwagi, patrzę czy źródło problemu nie leży gdzieś głębiej. Taka refleksja nad kodem, który przecież jest nowy i powinien być czysty od wad.
  5. Czy warto?
    Na koniec czy warto, moim zdaniem owszem. Aby cokolwiek poprawiać, musimy się dowiedzieć jaki stan mamy teraz, a SonarQube właśnie to nam daje. Możemy robić analizę na bieżąco, czyli obniżać koszty utrzymania kodu w przyszłości.
    Jestem ogromnym zwolennikiem tego narzędzia lub podobnych, jednak to tylko narzędzie.
    Ono nic w sobie nie znaczy, ani nic nie da jeśli nie zmienimy swoich przyzwyczajeń, musimy (przyjamniej na początku) zmusić się do przejżenia tych komentarzy i zwracania na nie uwagi. Największym zagrożeniem są sami programiści, którzy ignorują reguły, a potem mają pretensje jak ten kod tak może wyglądać.
    Jeśli my sami nie zaczniemy wypuszczać lepszego kodu, żadne narzędzie za nas tego nie zrobi. Tutaj dostajemy informacje, że można coś poprawić, ale wszystko w naszych rękach, czy to zignorujemy, czy poświęcimy parę minut i usuniemy kilka błędów zależy tylko od nas.
0

Zostaw komentarz