Wdrożenie SonarQube na przykładzie mojego projektu

Cześć. Dzisiejszy wpis będzie niejako kontynuacją poprzedniego. Zademonstruję jak wdrożyć SonarQube do projektu. Pokażę to, jak wspomniałem, na przykładzie mojego projektu – My Coach. Nad tym, czym jest SonarQube, nie będę się rozwodzić. Jest to opisane w poprzednim poście. Pokażę natomiast podstawowe funkcjonalności aplikacji dla zintegrowanego już projektu oraz opiszę w uproszczeniu projekt do którego to będziemy wdrażać oraz, oczywiście, sam etap wdrażania. Na koniec zostawiłem mały bonus dla ludzi korzystających z IntelliJ.

My Coach – co to jest?

Myślę, iż My Coach to dość interesujący projekt.. Rozwijany jest on typowo pod moje potrzeby, ale konkurs Daj się poznać przekonał mnie na “zopensouce’owanie się” i wzięcie udziału w nim. Czym jest ten My Coach? Tłumaczenie może być nie do końca trafne więc uściślę…:) Jest to aplikacja, która składa się z 4 głównych funkcjonalności:

• pomiary – w łatwy sposób możemy zapisywać tutaj swoje pomiary wag z danych dni. Ponadto, mamy możliwość podejrzenia naszych zmian na wykresach, tworzonych z pomocą JavaScriptowej biblioteki – chart.js. W dalszej wersji planuję również dodawać pomiary poszczególnych części ciała, np. obwód w pasie, bicepsie itd.
• trening – prawdziwy rdzeń aplikacji. Możemy tutaj łatwo definiować nowe cykle treningowe (czyli okres czasu w jakim trenujemy danymi zestawami ćwiczeń, zwykle 2-3 miesiące). Każdy z nich składa się zwykle z zestawów (setów) ćwiczeń. Trenujemy różnymi systemami, ale zakładam, iż wykonujemy tych samych kilka (jeden?) setów w obrębie cyklu. Możemy dodawać do tych setów treningi i zapisywać obciążenia oraz ilości powtórzeń z jakimi wykonywaliśmy dane ćwiczenie na konkretnym treningu
• ceny żywności – cóż, to funkcjonalność zrobiona typowo na moje potrzeby, ale o ile jesteś człowiekiem skrupulatnie pilnującym finansów i chcącym monitorować różne rzeczy to ta część aplikacji mogłaby mieć i u Ciebie zastosowanie. Tutaj możemy łatwo dodawać produkty żywnościowe, jakie zakupiliśmy. Oczywiście, ich cena może się znacznie zmieniać w zależności od pory roku (szczególnie warzywa i owoce) oraz miejsca w którym kupujemy. Możesz łatwo monitorować ceny tych produktów, dodawać nowe ceny, a choćby i całą listę zakupów. Jest to pokazane dzięki kart póki co, ale w przyszłości planuję lepsze porównywanie między produktami, sklepami itd
• raporty – w tym miejscu możemy pisać raporty z danych okresów. Tygodnie treningowe mogą być różne, zawsze można wyciągnąć wnioski. Może jakaś nowa bariera złamana? Tu możemy to zapisać. Planuję dodać możliwość zdefiniowania trenera. o ile posiadasz takiego (ale prawdziwego :)) to prawdopodobnie chciałby widzieć tego typu notatki, a po co go dręczyć swoją osobą i kopiować wszystko jak można to zapisać dla siebie i automatycznie mu to udostępniać?

To tyle o ile chodzi o funkcjonalności. o ile chodzi o technologię to na pewno Ciebie to bardziej zainteresuje. Część front-endowa nie będzie dla Ciebie w perspektywie wdrażania SonarQube istotna. Poznaję lepiej Angulara 2 od dłuższego czasu, więc jak nie być coraz lepszym w danej technologii jak nie poprzez pisanie własnego projektu z jej użyciem? Natomiast część back-endowa będzie miała spore znaczenie. Projekt jest tworzony w Javie, z użyciem w dużej mierze Springa i wielu różnych ciekawych technologii (o których wspomnę na pewno prędzej czy później i spróbuję Ciebie czegoś praktycznego w związku z nimi nauczyć).

Kluczowy w tym przypadku jest system buildów z jakich korzystam. Jest to coraz bardziej popularny Gradle. Pozwala on na łatwe tworzenie nowych tasków, które automatyzują procesy. Owszem, możemy użyć do tego prostych poleceń i wpisywać je w terminal, ale po co jak możemy skonfigurować wszystko raz, a potem dzięki jednego polecenia lub kliknięcia w naszym ulubionym IDE robić całą analizę naszego kodu?

Co będzie Ci potrzebne?

Bez wątpienia będziemy potrzebować w tym celu paru rzeczy:

• SonarQube – jego instalację pokazałem ostatnio. o ile Sonar działa to na pewno potrzebne będą nam dane użytkownika takie jak login i hasło (często domyślnie początkowy to “admin” z hasłem “admin”, ale chyba nie muszę wspominać Ci, iż warto to zmienić?) oraz adres Sonara (jeżeli stoi na tej samej maszynie co będziemy wykonywać analizę to można przyjąć adres jako adres “localhost”:SONAR_PORT (domyślny 9000), ale lepiej wpisać dokładny bo co jak będziemy chcieli uruchomić to z innego urządzenia w sieci?)
• Java – w zależności od projektu i jego zaawansowania mogą być różne wersje. Preferowana jednak jest najnowsza, wersja 8.
• Gradle – może nie tyle Gradle, co sam wrapper, którym będziemy mogli uruchamiać taski gradle’owe. Często generowane projekty posiadają wrappera i można go łatwo uruchomić. O samym Gradle’u opowiem na pewno niedługo.
• Projekt – jakiś projekt trzeba przeanalizować, prawda? o ile nie masz żadnego i chciałbyś tylko taką konfigurację zobaczyć to cały kod będzie dostępny na moim repozytorium z projektem My Coach, etap końcowy konfiguracji będzie wyszczególniony na tym branchu. Od czasu utworzenia tego wpisu projekt może się zmienić. Nie sugeruj się commitem tam, część rzeczy już była stworzona wcześniej, więc zmiany wprowadzone do kodu nie będa do końca pokrywać się z tymi tutaj. Jeszcze jest opcja wygenerowania projektu dzięki Spring Initializra. Nie potrzebujemy zaawansowanych dependencji. Jedyne, co jest najważniejsze to aby ustawić go jako projekt “Gradle’owy”, nie “Mavenowy” (trochę inne narzędzie z podobnymi zastosowaniami, bardzo prawdopodobne iż o nim słyszałeś)

Struktura projektu

Jak wspomniałem, będę wdrażać SonarQube do mojego projektu. Nie ma to jednak większego znaczenia gdzie Ty będziesz to robić. Tak naprawdę w samym projekcie będziemy edytować jeden plik, jeden utworzymy oraz nazwa package’u w którym jest nasza klasa startowa będzie potrzebna w celach wyłącznie konfiguracyjnych. Nie będę tu bawić się w dzielenie plików gradle’owych na jeszcze mniejsze. Zakładam też, iż posiadasz wrappera, więc struktura projektu powinna być mniej więcej taka:

• gradle – folder z wrapperem i jego konfiguracją, bezpośrednio nie będziemy tam nic zmieniać
• src – folder z głównym kodem aplikacji. Tam również nie przewidujemy wprowadzania zmian. Jedyne, co będzie nam potrzebne do nazwa package’a, gdzie znajduje się “punkt startowy” aplikacji
• build.gradle – główny plik, to tutaj będziemy wprowadzać główne zmiany
• gradlew/gradlew.bat – skrypty odpowiednio na systemu z rodziny Linux i Windows. Będziemy za jego pomocą uruchamiać to, co zaraz stworzymy

Omówię jeszcze krótko strukturę pliku build.gradle na przykładzie wygenerowanego projektu dzięki Spring Initializr. Zdaję sobię sprawę z tego, iż część osób może nie wiedzieć co tam się dzieje:

Dobrze, mamy wszystko, do dzieła!

Nareszcie! Wdrażamy SonarQube

Aby dodać projekt do SonarQube, musimy ustalić parę rzeczy, aby przyjemniej Ci się drogi użytkowniku tego Sonara konfigurowało. Będę w dalszej części posta używał następujących pojęć:

• PROJECT_NAME – nazwa projektu, u mnie My Coach
• PROJECT_KEY – klucz projektu, u mnie my-coach
• PROJECT_PACKAGE – package, w którym znajduje się punkt startowy aplikacji, u mnie pl.arturczopek.mycoach
• SONAR_USER – użytkownik, dzięki którego będziemy logować się do Sonara, zostanę dla celów poradnika przy “admin”
• SONAR_PASS – hasło użytkownika opisanego powyżej, dla celów poradnika “sonar”
• SONAR_URL – adres serwera, na którym działa SonarQube oraz odpowiedni port (domyślnie 9000), u mnie http://raspberrypi:9000.

Będziemy te wszystkie zmienne definiować w skrypcie gradle’owym. Dane bardziej poufne będziemy trzymać w osobnym pliku, tak jak zaleca twórca SonarQube. o ile nie chcesz takich danych udostępniać to po prostu nie wrzucaj tego jednego pliku do publicznego repozytorium. W głównym folderze z projektem utwórz plik gradle.properties. To tutaj zdefiniujemy adres serwera oraz dane do logowania dla użytkownika. Możesz w tym miejscu definiować też inne adekwatności oraz używać ich w innych skryptach gradle’owych. Zmiany powinny być wprowadzone w ten sposób:

Przechodząc do kodu. W pierwszej kolejności do naszego gradle’owego pliku – build.gradle – dodamy odpowiedni plugin. Będzie to proste. Wystarczy dodać do buildscriptu ścieżkę do odpowiedniego pluginu, a następnie go zaaplikować:

Świetnie, mamy plugin, mamy dane do połączenia, jesteśmy już blisko. W następnej kolejności musimy skonfigurować tylko dla taska SonarQube odpowiednie propertiesy (właściwości) czyli nazwę projektu oraz klucz dla niego i package z “punktem startowym”. Dosłownie kilka linii kodu. W moim przypadku wygląda to tak:

Ok, konfigurację mamy za sobą. o ile wszystkie dane i ścieżki zgadzają się, odpal terminal, przejdź do folderu z projektem i wpisz:

Jeżeli wszystko jest dobrze skonfigurowane powinniśmy zobaczyć w konsoli:

Uruchom teraz przeglądarkę i przejdź do strony, gdzie działa Twój SonarQube. Co widzisz?

Wow, udało Ci się dokonać analizy Twojego pierwszego projektu! Brawo!

Odczytywanie wiadomości z SonarQube

Projekt przeanalizowany pod względem jakości kodu to bardzo dobra rzecz. Możliwe, iż jeszcze nie wiesz jak te informacje odczytać, jak dowiedzieć się co mogłoby być lepiej zrobione. Spokojnie, z tym też Ci pomogę

Jeżeli klikniesz w tą piękną jedynkę, która pokazuje ilość projektów przeanalizowanych (hej, jakoś trzeba zacząć) powinieneś ujrzeć dashboard z przeanalizowanymi projektami. Dla jednego projektu nie będzie on zbyt okazały, ale podstawowe informacje na pewno będziesz w stanie odczytać.

Jak widzisz, większość miejsca zajmują rowki (tutaj rowek) z projektami. Mamy tam opisaną wiarygodność, poziom bezpieczeństwa, utrzymania, pokrycie testami, ilość procentową zduplikowanego kodu oraz ilość linii kodu w danym języku, wielkość projektu, a także czy jakość kodu finalnie jest dobra. Trochę wstydem jest “-” przy pokryciu testami, ale obiecuję się poprawić Po lewej mamy filtry. Możemy wyświetlać tylko projekty które spełniają dane wymogi. adekwatności, po których możemy filtrować to właśnie te wcześniej wymienione. Wraz z większą ilością projektów dashboard będzie na pewno bardziej okazały.

Na pewno chciałbyś dowiedzieć się czegoś więcej o projekcie. Jest to także bardzo intuicyjne. Wystarczy kliknąć w tytuł projektu. Każdy rowek z projektem go posiada. o ile jednak go nie widzisz to dla pewności zaznaczyłem obszar w którym powinien on się znaleźć na wyżej zamieszczonym screenshocie. Po przejściu do projektu zobaczymy też odpowiedni dla niego dashboard. Jest on trochę bardziej szczegółowy od poprzedniego.

Myślę, iż nazwy są dość wymowne. Bardzo interesująca jest druga rubryka, z długiem technologicznymi i “zapachami kodu”. Warto nie zawsze kierować się długiem technologicznym dokładnie. Czasami poprawa pewnych rzeczy (szczególnie w starszych projektach) może trwać dłużej. Zdarzają się też sytuację w drugą stronę. Poprawa jednej rzeczy, która zajmuje 5 sekund może okazać się dla Sonara zadaniem na…5 minut. Warto poeksperymentować i przekonać się na własnej skórze. o ile chcemy dowiedzieć się czegoś o danej rubryce, wystarczy kliknąć w wartość liczbową dla niej, pod nią kryje się link. Zobaczmy sobie na przykład skąd tu ten dług się bierze. SonarQube ocenia go na bardzo niski, o czym świadczy literka “A” z zieloną obwódką. Z drugiej strony, jak widziałeś wcześniej, projekt na 1500 linii nie jest zbyt duży. W każdym razie, kliknij w ten dług.

U mnie jest to tylko jeden problem, więc główna rubryka z prawej strony nie jest zbyt zapchana. Tutaj właśnie są opisane wszystkie nasze problemy, mniejsze lub większe. Jest opisane ładnie gdzie one się znajdują, ile szacunkowo będzie trwała poprawa kodu, oraz jak istotny problem to jest. Dokładniejszy opis i rozwiązanie jest opisane w przejściu dzięki linka nad problemem. Nie będę tutaj tego demonstrować. Na końcu pokażę plugin do IntelliJ, który jeszcze bardziej ułatwia integrację. Z lewej strony natomiast są odpowiednie filtry, działają analogicznie do tych na głównej stronie.

Ciekawą rzeczą, na którą warto spojrzeć, bo być może będziesz kiedyś zmieniać, są reguły. Możemy je dość łatwo zmieniać. Przejdź więc do zakładki “Rules” w głównej nawigacji.

Tutaj możemy zobaczyć wszystkie zasady. Są odpowiednio kwalifikowane, jako bugi, zapachy kodu… Są też zdefiniowane odpowiednio dla niektórych języków programowania. Sonar cały czas się rozrasta na tym polu. Oczywiście, filtrowanie i sprawdzanie jest łatwo możliwe z lewego panelu, tak jak na innych zakładkach.

To tyle o ile chodzi o podstawowe funkcjonalności SonarQube. Na koniec przejdźmy do deseru.

SonarLint – łatwiejsza integracja Sonara z Intellij

Jeżeli tu dotarłeś to znaczy, iż spędziłeś dużo czasu, więc nie będę specjalnie owijał. SonarLint pozwala nam w łatwy sposób synchronizować projekt z serwerem Sonara oraz sprawdzać dla klasy w której w tej chwili się znajdujemy naruszone reguły oraz mamy pod ręką metody, w jaki możemy to poprawić. Fantastyczna sprawa. Jak instalować pluginy pewnie wiesz, ale dzięki jednego obrazka pokażę jak go znaleźć. Przejdź do zakładki “Settings…” w IntelliJ. Następnie:

Po zainstalowaniu plugina i zrestartowaniu IDE podpinamy serwer. UWAGA! Nie jest to krok konieczny, SonarQube pokaże nam problemy z kodem, ale według swoich, jakiś domyślnych reguł. Może się to różnić w zależności od wersji Sonara oraz Twoich reguł. Warto go podpiąć, ale jak wspomniałem, nie jest to warunek konieczny. Robimy to w ten znowu w settingsach:

Myślę, iż jest to dość intuicyjne. Przechodzimy do odpowiedniej zakładki (1, 2), następnie dodajemy nowy serwer (3), podajemy tam nazwę połączenia, adres oraz dane do użytkownika(4). Następnie, sprawdzamy połączenie (5). o ile wszystko jest dobrze skonfigurowane powinniśmy ujrzeć informacje o sukcesie. Możemy ją zamknąć (6) oraz dodać serwer (7). Teraz serwer należy dołączyć do projektu.

Wystarczy przejść do zakładki poniżej oraz z niej wybrać serwer. Jako, iż posiadasz prawdopodobnie jeden to wybór nie będzie zbyt duży. Po skonfigurowaniu plugina i połączeniu serwera z projektem możemy zobaczyć problemy w danych klasach. Ja miałem jedyny w klasie MyCoachInitializer. Przejdźmy więc do niej

Po wybraniu z zakładek zamieszczonych poniżej “SonarLint” widzimy te problemy. Faktycznie, pokrywają się one z tym, co zobaczyliśmy w Sonarze. Po prawej widać też opis problemu, dlaczego to jest złe oraz rozwiązanie. Z lewej strony jeszcze mamy panel z konfiguracją oraz z uruchomieniem skanowania (gdyby coś nie działało, domyślnie kod jest sprawdzany przy zmianach). Świetna sprawa, wszystko mamy pod ręką!

Na zakończenie

Uff, dużo pracy kosztowały oba te wpisy. Mam nadzieję, iż wszystkie niezbędne podstawy oraz etap wdrażania opisałem dość dobrze i iż coś z tego wyniosłeś. W weekend temat mniej związany z samym kodem, ale także myślę, iż pomogę Ci usprawnić pracę. Do przeczytania!