Naszym doświadczeniem we wdrażaniu platformy SonarQube do ciągłej analizy i pomiaru jakości kodu chcemy podzielić się z istniejącymi procesami rozwoju systemu DPO (dodatek do systemu księgowości depozytowo-rozliczeniowej Alameda) Krajowego Depozytu Rozliczeniowego.
Krajowy Depozyt Rozliczeniowy (grupa spółek Moscow Exchange) jest jedną z kluczowych firm w infrastrukturze finansowej, przechowującą i rozliczającą papiery wartościowe emitentów rosyjskich i zagranicznych o wartości ponad 50 bilionów rubli. Rosnący wolumen operacji realizowanych przez system, a także ciągłe poszerzanie funkcjonalności, wymagają utrzymania wysokiej jakości kodu źródłowego systemów. Jednym z narzędzi umożliwiających osiągnięcie tego celu jest analizator statyczny SonarQube. W tym artykule opiszemy udane doświadczenia związane z bezproblemowym wdrożeniem analizatora statycznego SonarQube do istniejących procesów rozwojowych naszego działu.
Krótko o wydziale
Nasze kompetencje obejmują następujące moduły: płatności dla klientów NSD, elektroniczne zarządzanie dokumentami (EDF), przetwarzanie komunikatów z repozytorium transakcji (rejestracja transakcji pozagiełdowych), kanały elektronicznej interakcji pomiędzy klientami a NSD i wiele innych. Ogólnie rzecz biorąc, jest wiele do zrobienia w zakresie technicznej strony działań operacyjnych. Działamy w oparciu o zgłoszenia. Zgłoszenia od oficerów operacyjnych są przetwarzane przez analityków: zbierają wymagania klienta i przedstawiają nam swoją wizję tego, jak powinno to wpasować się w program. Dalej schemat standardowy: opracowanie kodu – testowanie – działanie próbne – dostarczenie kodu na obwód produkcyjny do bezpośredniego klienta.
Dlaczego SonarQube?
To pierwsze doświadczenie naszego działu we wdrażaniu platformy do kontroli jakości kodu - wcześniej robiliśmy to ręcznie, przeprowadzając jedynie recenzje kodu. Jednak rosnący wolumen pracy wymaga automatyzacji tego procesu. Dodatkowo w skład zespołu wchodzą także niedoświadczeni pracownicy, którzy nie do końca znają wewnętrzne regulacje rozwojowe i popełniają więcej błędów. Aby kontrolować jakość kodu zdecydowano się na wdrożenie analizatora statycznego. Ponieważ SonarQube był już używany w niektórych systemach NSD, wybór nie trwał długo. Wcześniej koledzy z innych działów analizowali w nim kod mikroserwisów w systemie Alameda (własny system księgowości depozytowo-rozliczeniowej NSD), w CFT (informatyczny system do prowadzenia księgowości, bilansów, sporządzania raportowania obowiązkowego i wewnętrznego), w niektórych inne systemy. Do eksperymentów postanowiliśmy zacząć od darmowej wersji SonarQube. Przejdźmy zatem do naszej sprawy.
Proces wdrażania
Mamy:
- automatyczny montaż systemu w TeamCity;
- skonfigurowano proces przesyłania kodu poprzez MergeRequest z gałęzi funkcjonalności do gałęzi master w GitLabie (proces rozwoju według GitHub Flow);
- SonarQube, skonfigurowany do analizy kodu dla systemu DPO zgodnie z harmonogramem.
Nasz cel: wdrożenie automatycznej analizy kodu w procesach CI/CD DPO.
Trzeba skonfigurować: proces automatycznego sprawdzania kodu przez analizator statyczny przy każdym żądaniu MergeRequest do głównej gałęzi.
Te. Docelowy obraz jest następujący: gdy tylko programista prześle zmiany do gałęzi funkcji, uruchamiane jest automatyczne sprawdzanie nowych błędów w kodzie. Jeśli nie ma błędów, zmiany można zaakceptować, w przeciwnym razie błędy będą musiały zostać poprawione. Już na początkowym etapie udało nam się zidentyfikować pewną ilość błędów w kodzie. System posiada bardzo elastyczne ustawienia: można go skonfigurować tak, aby sprawdzał się pod konkretne zadania programistów, dla każdego systemu i stylu programowania.
Konfigurowanie QualityGate w SonarQube
Analiza QualityGate to coś, o czym czytamy w głębinach Internetu. Początkowo stosowaliśmy inne podejście, bardziej złożone i pod pewnymi względami nie do końca poprawne. Najpierw dwukrotnie przeprowadziliśmy skanowanie przez SonarQube: przeskanowaliśmy gałąź funkcji i gałąź, w której zamierzaliśmy połączyć gałąź funkcji, a następnie porównaliśmy liczbę błędów. Metoda ta nie była stabilna i nie zawsze dawała prawidłowy wynik. I wtedy dowiedzieliśmy się, że zamiast dwukrotnie uruchamiać SonarQube, możemy ustawić limit liczby popełnianych błędów (QualityGate) i analizować tylko tę gałąź, którą wgrasz i porównasz.
Na razie nadal używamy raczej prymitywnego przeglądu kodu. Należy zaznaczyć, że SonarQube nie jest kompatybilny z niektórymi językami programowania, w tym z Delphi. Na chwilę obecną analizujemy dla naszego systemu wyłącznie kod PLSql.
Działa to tak:
- Na potrzeby naszego projektu analizujemy wyłącznie kod PL/SQL.
- SonarQube ma skonfigurowaną QualityGate tak, że liczba błędów nie zwiększa się wraz z zatwierdzeniem.
- Liczba błędów przy pierwszym uruchomieniu wyniosła 229. Jeśli podczas zatwierdzenia wystąpi więcej błędów, scalanie nie jest dozwolone.
- Ponadto, jeśli błędy zostaną poprawione, możliwa będzie ponowna konfiguracja QualityGate.
- Możesz także dodać nowe punkty do analizy, np. pokrycie kodu testami itp.
Schemat pracy:
W komentarzach do skryptu widać, że liczba błędów w gałęzi funkcji nie wzrosła. Więc wszystko jest w porządku.
Przycisk Scal stanie się dostępny.
W komentarzach do skryptu widać, że liczba błędów w gałęzi funkcji przekroczyła dozwoloną. Więc wszystko jest ZŁE.
Przycisk Scal jest czerwony. W tej chwili nie ma zakazu przesyłania zmian w oparciu o błędny kod, ale odbywa się to według uznania odpowiedzialnego programisty. W przyszłości możesz zapobiec dodawaniu takich zatwierdzeń 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 swoich rygorystycznych standardów. To, co uważa za błąd, może w rzeczywistości nim nie być w naszym kodzie. Należy zatem sprawdzić i zanotować, czy rzeczywiście jest to pomyłka, czy też nie ma potrzeby edytowania w naszych warunkach. W ten sposób zmniejszamy liczbę błędów. Z biegiem czasu system nauczy się rozumieć te niuanse.
Do czego doszliśmy
Naszym celem było zrozumienie, czy w naszym przypadku wskazane jest przeniesienie weryfikacji kodu do automatyzacji. A wynik spełnił oczekiwania. SonarQube pozwala nam pracować z potrzebnymi nam językami, wykonuje dość kompetentne analizy i ma potencjał, aby uczyć się na wskazówkach programistów. Generalnie jesteśmy zadowoleni z naszych pierwszych doświadczeń z SonarQube i planujemy dalszy rozwój w tym kierunku. Oczekujemy, że w przyszłości będziemy mogli zaoszczędzić więcej czasu i wysiłku na przeglądaniu kodu i ulepszyć go, eliminując czynnik ludzki. Być może w trakcie odkryjemy wady platformy, a wręcz przeciwnie, po raz kolejny upewnimy się, że jest to fajna rzecz z ogromnym potencjałem.
W tym artykule przeglądowym omówiliśmy naszą znajomość z analizatorem statycznym SonarQube. Jeśli masz pytania, napisz w komentarzach. Jeśli interesuje Cię ten temat, w nowej publikacji opiszemy bardziej szczegółowo, jak wszystko poprawnie skonfigurować i napisać kod, który wykona takie sprawdzenie.
Autor tekstu:
Źródło: www.habr.com