Praktyczna Java. SonarQube

By 19 czerwca 2016Praktyczna Java

Po ostatnim wpisie o Checkstyle, nie sposób nie wspomnieć o innym narzędziu – SonarQube. Zapraszamy na kolejną porcję informacji o statycznej analizie kodu oraz o tym, jak może Ci pomóc w codziennej pracy.

SonarQube vs Checkstyle

Choć oba narzędzia bazują na tym samym podejściu – statycznej analizie kodu (tj. analizie kodu źródłowego bez kompilowania go i uruchamiania) – są między nimi znaczące różnice. Przede wszystkim Checkstyle jest biblioteką – możliwą do uruchomienia ‚w locie’ w trakcie budowania projektu, ale nie przechowującą żadnych informacji w czasie. SonarQube jest bardziej systemem – wymaga instalacji zanim będziemy mogli go używać, ale zapewnia jednocześnie komplet informacji (nie tylko o problemach, ale także o zmianach – przykładowo: jakie problemy się pojawiły / jakie zostały rozwiązane od ostatniej zmiany). Informacje te przechowuje w lokalnej bazie danych, z podziałem na projekty. SonarQube pozwala także na analizę projektu jako całości, na co nie pozwala sam Checkstyle – może np. znaleźć martwy kod, który nigdy nie jest wywoływany lub inne problemy, które występują na przestrzeni kilku klas/pakietów.

W tym miejscu warto wspomnieć, że SonarQube może korzystać z reguł Checkstyle (w rzeczywistości Checkstyle jest uruchamiany jako narzędzie przez SonarQube). To bardzo wygodne rozwiązanie jeśli chodzi o ciągłą integrację – np. w połaczeniu z Jenkinsem czy innym podobnym systemem.

Podsumowując – żadne z narzędzi nie zastępuje drugiego, ale świetnie się uzupełniają :)

Instalacja SonarQube

SonarQube jest stworzony w Javie i jako taki można go uruchomić na dowolnym serwerze aplikacji (także na serwerze Tomcat). Do działania wymagana jest także baza danych, gdzie przechowywane są wszystkie informacje. Szczegółowy poradnik krok po kroku znajdziesz w dokumentacji.

Instalacji możesz także dokonać na lokalnym komputerze, musisz tylko pamiętać, aby uruchomić serwer za każdym razem, kiedy planujesz go użyć.

Tutaj dodatkowa uwaga – ponieważ komunikacja z serwerem odbywa się za pośrednictwem sieci, warto wcześniej pomyśleć jak planujesz korzystać z SonarQube – jeśli tylko do developmentu, lokalny komputer będzie lepszym rozwiązaniem niż serwer w chmurze; jeśli jednak będzie głównie wykorzystywany przez narzędzie CI (np. Jenkinsa), lepszym rozwiązaniem będzie instalacja na tym samym serwerze.

Korzystanie z SonarQube

Korzystanie z SonarQube jest możliwe na kilka sposobów – aby gromadzić statystyki i trendy możemy uruchamiać analizę z poziomu konsoli lub naszego środowiska CI. Możemy także skorzystać z wtyczki do Mavena jako formy weryfikacji lub zintegrować go z Eclipse – zarówno lokalnie jak i korzystając z ‚centralnych’ reguł dla projektu.

Uruchamianie z konsoli

Najbardziej podstawową opcją jest uruchamianie analizy z poziomu konsoli – wymogiem jest, że na danym serwerze musi znajdować się kod źródłowy projektu, który chcemy analizować (nie musi to być jednak serwer, na którym działa ‚serwerowa’ część SonarQube – możemy połączyć się z nią zdalnie).

Aby ten sposób analizy zadziałał, konieczne jest utworzenie pliku sonar-project.properties, w którym określamy id projektu (musi być unikalny dla danego serwera), nazwę wyświetlaną projektu (może być dowolna) oraz dodatkowe parametry takie jak lokalizację plików z kodem, kodowanie źródeł itp. Przykładowy minimalistyczny plik może wyglądać następująco:

sonar.projectKey=my:project
sonar.projectName=Mój projekt
sonar.projectVersion=1.0
sonar.sources=./src/main/java

Następnie wystarczy w katalogu głównym wywołać komendę sonar-scanner (uprzednio oczywiście instalując SonarQube), dzięki czemu kod zostanie przeanalizowany, a wyniki analizy będą dostępne na serwerze oraz za pomocą API.

Pełna dokumentacja uruchamiania z poziomu konsoli

Integracja z Mavenem

Drugą opcją jest integracja za pośrednictwem Mavena – z praktycznego punktu widzenia działa ona podobnie do wywołania z konsoli – różnicą jest jednak to, że możemy powiązać analizę z procesem budowania, dzięki czemu nie musimy pamiętać o dodatkowych komendach. Co więcej – możemy też skonfigurować go ‚globalnie’ dla całego naszego komputera, dzięki czemu zawsze wywołanie mvn sonar:sonar spowoduje analizę bieżącego projektu. Oczywiście także w tym wypadku wymagany jest opisany wyżej plik .properties. Podstawowa konfiguracja sprowadza się do dodania następującego fragmentu do pliku settings.xml (znajdziesz go w katalogu MAVEN_HOME, zwykle jest to katalog o nazwie .m2 umieszczony w katalogu domowym użytkownika):

<settings>
    <pluginGroups>
        <pluginGroup>org.sonarsource.scanner.maven</pluginGroup>
    </pluginGroups>
    <profiles>
        <profile>
            <id>sonar</id>
            <activation>
                <activeByDefault>true</activeByDefault>
            </activation>
            <properties>
                <sonar.host.url>http://myserver:9000</sonar.host.url>
            </properties>
        </profile>
    </profiles>
</settings>

Powyższa konfiguracja nie jest stricte wymagana – plugin sonar zadziała także bez niej, o ile wszystkie parametry są domyślne (tzn. serwer działa lokalnie i nie są wymagane login lub hasło do jego użycia).

Dokumentacja na temat integracji z Mavenem

Integracja z Jenkinsem

Jednym z najwygodniejszych sposobów integracji jest powiązanie z Jenkinsem (lub innym środowiskiem CI). W ten sposób za każdym razem, kiedy będziemy budowali kolejne zmiany w projekcie, zostanie wykonana analiza – jej wyniki będą dostępne w panelu SonarQube (oraz za pośrednictwem API).

Integracja sprowadza się do konfiguracji stosownego pluginu w Jenkinsie – szczegółowy opis wraz ze screenami znajdziesz w konfiguracji.

Dokumentacja dotycząca integracji z Jenkinsem
Wpis na blogu programisty opisujący sposób integracji

Integracja z Eclipsem (lub innym IDE)

Czwartym sposobem na integracje jest użycie pluginu do naszego IDE – np. Eclipse. Ten sposób integracji jest wyjątkowy, ponieważ nie wymaga instalacji serwera. Jeśli potrzebujesz feedbacku w trakcie pisania kodu, ale nie zależy Ci na statystykach w czasie czy trendach, to może być bardzo przydatna cecha ;) Plugin ten posiada dwie opcje – domyślnie korzysta z ‚lokalnych’ ustawień i nie wymaga komunikacji z serwerem. Możemy także skonfigurować połączenie, dzięki czemu reguły analizy pobierane są z serwera dla tego konkretnego projektu – jest to świetne rozwiązanie w większych projektach.

Integracja sprowadza się podobnie jak w przypadku Jenkinsa do instalacji pluginu – jest szybka i bezproblemowa, dokładny opis wraz ze screenami i wyjaśnieniem poszczególnych opcji znajdziesz w dokumentacji:

Strona pluginu do Eclipse z opisem konfiguracji

Inne IDE

Oczywiście poza Eclipse możliwa jest także integracja z innymi IDE – np. IntelliJ IDEA. Więcej informacji, także o konfiguracji, znajdziesz na stronie Sonar Lint.

Podsumowanie

SonarQube, mimo że wymaga nieco więcej konfiguracji niż np. Checkstyle, zdecydowanie jest bardzo wartościowym narzędziem – szczególnie w kontekście obserwowania trendów w projekcie i stosownego reagowania (jeśli np. ilość długu technicznego rośnie wraz z aktywnym rozwojem projektu, być może warto poświęcić jeden sprint na jego eliminację?).

Podobnie jak w przypadku Checkstyle, największą wartość uzyskasz stosując go w projekcie, w którym pracuje więcej osób, ale także dla Twoich prywatnych projektów może on przynieść wiele korzyści. Warto spróbować – całość jest Open Source na licencji GPL3 (istnieje możliwość wykupienia płatnego supportu, dodatkowych modułów do innych języków itp)

  •  
  •  
  •  
  •  
  •