Chcemy podzielić się doświadczeniem wdrożenia platformy do ciągłej analizy i mierzenia jakości kodu SonarQube w istniejące procesy rozwoju systemu DPO (uzupełnienie systemu depozytowo-rozliczeniowego „Alameda”) Krajowego Depozytu Papierów Wartościowych.
Krajowy Depozyt Papierów Wartościowych (grupa firm „Giełda Moskiewska”) jest jedną z kluczowych firm infrastruktury finansowej, przechowując i rejestrując papiery wartościowe emisji krajowych i zagranicznych o łącznej wartości ponad 50 bilionów rubli. Rosnąca liczba operacji realizowanych przez system oraz ciągły rozwój funkcjonalności wymagają utrzymania wysokiej jakości kodu źródłowego systemów. Jednym z narzędzi do osiągnięcia tego celu jest statyczny analizator SonarQube. W tym artykule opiszemy udane doświadczenie bezproblemowego wdrożenia statycznego analizatora SonarQube w istniejące procesy rozwoju naszego działu.
Krótko o dziale
W naszej kompetencji znajdują się następujące moduły: wypłaty dla klientów KDPW, elektroniczny obrót dokumentami (EOD), przetwarzanie wiadomości repozytoriów handlowych (rejestracja transakcji OTC), kanały elektronicznej współpracy między klientami a KDPW i wiele więcej. Ogólnie rzecz biorąc, to duża część pracy nad techniczną stroną działalności operacyjnej. Pracujemy na podstawie zgłoszeń. Zgłoszenia operatorów są przetwarzane przez analityków: zbierają oni wymagania klienta i przedstawiają nam swoją wizję, jak powinno to zostać wprowadzone do programu. Następnie standardowy schemat: rozwój kodu – testowanie – eksploatacja próbna – dostarczenie kodu do produkcyjnego obszaru bezpośredniemu zleceniodawcy.
Dlaczego właśnie SonarQube?
To doświadczenie naszego działu w implementacji platformy do kontroli jakości kodu – wcześniej robiliśmy to ręcznie, przeprowadzając jedynie przegląd kodu. Jednak rosnąca ilość pracy wymaga automatyzacji tego procesu. Dodatkowo w zespole są mniej doświadczone osoby, które nie są w pełni zaznajomione z wewnętrznymi regulacjami dotyczącymi rozwoju i mają skłonność do popełniania większej liczby błędów. W celu kontroli jakości kodu postanowiono wprowadzić analizator statyczny. Ponieważ SonarQube był już stosowany w niektórych systemach NPD, nie trzeba było długo wybierać. Wcześniej koledzy z innych działów analizowali przy jego pomocy kod mikrousług w systemie „Alameda” (własny system depozytowo-rozliczeniowy NPD), w CFT (system informacyjny do prowadzenia księgowości, bilansu, przygotowywania obowiązkowych i wewnętrznych raportów), a także w niektórych innych systemach. Na potrzeby eksperymentów postanowiliśmy rozpocząć od bezpłatnej wersji SonarQube. Przejdźmy zatem do naszego przypadku.
Proces wdrożenia
Mamy:
- automatyczne budowanie systemu w TeamCity;
- ustawiony proces wgrywania kodu przez MergeRequest z gałęzi feature do gałęzi master w GitLab (proces rozwoju zgodnie z GitHub Flow);
- SonarQube, skonfigurowany do analizy kodu dla systemu DPO według harmonogramu.
Naszym celem: wprowadzić automatyczną analizę kodu do procesów CI/CD DPO.
Musimy ustawić: proces automatycznej weryfikacji kodu przez analizator statyczny przy każdym MergeRequest do głównej gałęzi.
Tj. docelowy obraz jest następujący: gdy tylko programista wprowadza zmiany w gałęzi feature, uruchamiana jest automatyczna weryfikacja pod kątem nowych błędów w kodzie. Jeśli błędów nie ma, zmiany mogą zostać zaakceptowane, w przeciwnym razie będą musiały zostać naprawione. Już na wczesnym etapie udało nam się wykryć pewną liczbę błędów w kodzie. System ma bardzo elastyczne ustawienia: można go konfigurować tak, aby działał pod konkretne zadania programistów, dla każdego systemu i stylu programowania.
Konfiguracja QualityGate w SonarQube
Analiza QualityGate to coś, co odkryliśmy w zakamarkach internetu. Początkowo używaliśmy innego, bardziej skomplikowanego podejścia, które w pewnym sensie nie było całkiem poprawne. Najpierw dwukrotnie uruchamialiśmy skanowanie przez SonarQube: skanowaliśmy gałąź funkcjonalną i gałąź, do której chcieliśmy zintegrować gałąź funkcjonalną, a następnie porównywaliśmy liczbę błędów. Ta metoda nie była stabilna i nie zawsze dawała poprawne wyniki. Potem dowiedzieliśmy się, że zamiast podwójnego uruchomienia SonarQube, można ustawić limit na dopuszczalną liczbę błędów (QualityGate) i analizować tylko tę gałąź, którą wdrażasz i porównujesz.
Na razie stosujemy dość prymitywną kontrolę kodu. Warto zauważyć, że SonarQube jest niekompatybilny z niektórymi językami programowania, w tym Delphi. Obecnie w naszym systemie analizowany jest tylko kod PLSql.
Działa to w ten sposób:
- Analizujemy dla naszego projektu tylko kod PL/SQL.
- W SonarQubeQualityGate jest ustawiony tak, aby liczba błędów nie wzrastała przy commicie.
- Podczas pierwszego uruchomienia liczba błędów wyniosła 229. Jeśli liczba błędów przy commicie wzrasta, to merge nie jest dozwolony.
- Następnie, pod warunkiem naprawienia błędów, można będzie ponownie skonfigurować QualityGate.
- Można również dodawać nowe punkty do analizy, na przykład pokrycie kodu testami itd.
Schemat działania:
W komentarzach dotyczących pracy skryptu widać, że liczba błędów w gałęzi funkcjonalnej nie wzrosła. Zatem wszystko jest w porządku.
Pojawia się przycisk Merge.
W komentarzach dotyczących pracy skryptu widać, że liczba błędów w gałęzi funkcjonalnej przekroczyła dopuszczalną wartość. Zatem jest źle.
Przycisk Merge jest czerwony. Na ten moment nie ma zakazu wprowadzania zmian w kodzie z błędami, ale to zależy od uznania odpowiedzialnego dewelopera. W przyszłości można zakazać wprowadzania takich commitów do głównej gałęzi.
Samodzielna praca nad błędami
Następnie należy sprawdzić wszystkie błędy wykryte przez system, ponieważ SonarQube analizuje według własnych surowych standardów. To, co uznaje za błąd, w naszym kodzie może nie być błędem. Dlatego trzeba sprawdzić i zaznaczyć, czy to rzeczywiście błąd, czy też nie ma potrzeby dokonania poprawek w naszych warunkach. W ten sposób redukujemy liczbę błędów. Z czasem system nauczy się rozumieć te niuanse.
Do czego doszliśmy
Naszym celem było zrozumieć, czy warto w naszym przypadku automatyzować kontrolę kodu. I wynik spełnił oczekiwania. SonarQube umożliwia nam pracę z potrzebnymi językami, przeprowadza dość szczegółową analizę i ma potencjał uczenia się na podstawie wskazówek programistów. Ogólnie rzecz biorąc, jesteśmy zadowoleni z naszego pierwszego doświadczenia z SonarQube i planujemy rozwijać się w tym kierunku dalej. Oczekujemy, że w przyszłości będziemy mogli zaoszczędzić więcej czasu i wysiłku na kontrolę kodu, a także uczynić ją bardziej jakościową, eliminując czynnik ludzki. Być może w trakcie odkryjemy wady platformy lub, przeciwnie, jeszcze raz przekonamy się, że to świetna rzecz z dużym potencjałem.
W tym przeglądowym artykule opowiedzieliśmy o naszym zapoznaniu się z analizatorem staticznym SonarQube. Jeśli masz pytania, pisz proszę w komentarzach. Jeśli interesuje Cię ten temat, w nowej publikacji dokładniej opisujemy, jak prawidłowo wszystko skonfigurować i napisać kod, aby przeprowadzić tego typu kontrolę.
Autor tekstu:
Źródło: habr.com
