Aktywnie wykorzystujemy platformę w naszej pracy SoundQube aby utrzymać jakość kodu na wysokim poziomie. Podczas integracji jednego z projektów napisanych w VueJs+maszynopis, pojawiły się problemy. Dlatego chciałbym opowiedzieć bardziej szczegółowo, jak udało nam się je rozwiązać.

W tym artykule porozmawiamy, jak napisałem powyżej, o platformie SonarQube. Trochę teorii - ogólnie o co chodzi, dla tych, którzy słyszą o tym po raz pierwszy:

SoundQube (dawny Sonar) to platforma typu open source do ciągłej kontroli i pomiaru jakości kodu.
Obsługuje analizę kodu i wykrywanie błędów zgodnie z zasadami standardów programowania MISRA C, MISRA C++, MITRE/CWE i CERT Secure Coding Standards. Potrafi także rozpoznać błędy z list OWASP Top 10 i CWE/SANS Top 25 błędów programistycznych.
Pomimo tego, że platforma korzysta z różnych gotowych narzędzi, SonarQube redukuje wyniki do jednego dashboardu, zachowując historię uruchomień i tym samym pozwalając zobaczyć ogólny trend zmian jakości oprogramowania w trakcie rozwoju.

Więcej szczegółów można znaleźć na stronie Oficjalna strona

Obsługiwana jest duża liczba języków programowania. Sądząc po informacjach z powyższego linku, jest to ponad 25 języków. Aby obsługiwać konkretny język, należy zainstalować odpowiednią wtyczkę. Wersja społecznościowa zawiera wtyczkę do pracy Javascript (w tym typyсript), chociaż wiki mówi coś przeciwnego. Za Javascript odpowiedzi na wtyczki SonarJS, dla maszynopisu SonarTS odpowiednio.

Oficjalny klient służy do wysyłania informacji o zasięgu skaner sonarqube, który za pomocą ustawień z config-file, wysyła te dane do serwera SoundQube do dalszej konsolidacji i agregacji.

dla Javascript jest opakowanie npm. Zacznijmy więc wdrażanie krok po kroku SoundQube в Vue-projekt za pomocą Maszynopis.

Aby wdrożyć serwer SoundQube skorzystajmy dokować-komponować.

sonar.yaml:

version: '1'
    services:
        simplesample-sonar:
            image: sonarqube:lts
            ports:
                - 9001:9000
                - 9092:9092
            network_mode: bridge

Uruchomić:

docker-compose -f sonar.yml up

Odtąd SoundQube będzie dostępny pod adresem: http://localhost:9001 .

Nie ma w nim jeszcze żadnych projektów i to jest sprawiedliwe. Naprawimy tę sytuację. Wziąłem oficjalny przykładowy projekt VueJS+TS+Jest. Nachylmy to do siebie:

git clone https://github.com/vuejs/vue-test-utils-typescript-example.git

Najpierw musimy zainstalować klienta SoundQubektóry nazywa się sonar-skanerdla Npm jest opakowanie:

yarn add sonarqube-scanner

I natychmiast dodaj polecenie do skrypty pracować z tym.

pakiet.json:

{
 … 
   scripts: {
      ...
      "sonar": "sonar-scanner"
      ...
   },
 …
}

Następnie, aby skaner działał, musisz ustawić ustawienia projektu w specjalnym pliku. Zacznijmy od podstaw.

właściwości projektu sonarowego:

sonar.host.url=http://localhost:9001

sonar.projectKey=test-project-vuejs-ts
sonar.projectName=Test Application (VueJS+TS)

sonar.sources=src
# sonar.tests=
sonar.test.inclusions=src/**/*tests*/**
sonar.sourceEncoding=UTF-8

sonar.host.url - adres Sonar'A;
sonar.projectKey – unikalny identyfikator projektu na serwerze Sonar'A;
sonar.Nazwa projektu – jego nazwę, można ją w każdej chwili zmienić, ponieważ projekt jest identyfikowany przez klucz projektu;
sonar.źródła – folder ze źródłami, zazwyczaj ten src, ale może być wszystko. Folder ten jest ustawiony względem folderu głównego, czyli folderu, z którego uruchamiany jest skaner;
testy sonaru – parametr, który idzie w parze z poprzednim. Jest to folder, w którym znajdują się testy. W tym projekcie nie ma takiego folderu, a test znajduje się obok testowanego komponentu w folderze 'test', więc na razie go zignorujemy i użyjemy następnego parametru;
włączenia.testu.sonara – ścieżka do testów z wykorzystaniem maski, może być wymienionych kilka elementów oddzielonych przecinkami;
sonar.sourceKodowanie – kodowanie plików źródłowych.

Na pierwsze uruchomienie skanera wszystko jest gotowe, poza główną czynnością poprzedzającą: uruchomieniem samego silnika testowego, aby mógł wygenerować informację o zasięgu, którą skaner będzie później wykorzystywał.

Aby to jednak zrobić, należy skonfigurować silnik testowy do generowania tych informacji. W tym projekcie silnikiem testowym jest Żart. A jego ustawienia znajdują się w odpowiedniej sekcji pliku pakiet.json.

Dodajmy te ustawienia:

"collectCoverage": true,
"collectCoverageFrom": [
      "src/**/*",
      "!src/main.ts",
      "!src/App.vue",
      "!src/**/*.d.*",
      "!src/**/*__tests__*"
],

Oznacza to, że ustawiamy samą flagę na potrzebę obliczenia zasięgu i źródło (wraz z wyjątkami), na podstawie którego zostanie ono utworzone.

Teraz przeprowadźmy test:

yarn test

Zobaczymy co następuje:

Powodem jest to, że w samym komponencie nie ma kodu. Naprawmy to.

HelloWorld.vue:

...
methods: {
    calc(n) {
      return n + 1;
    }
  },
mounted() {
  this.msg1 = this.msg + this.calc(1);
},
...

To wystarczy do obliczenia zasięgu.

Po ponownym uruchomieniu testu upewnimy się, że:

Na ekranie powinniśmy zobaczyć informację o zasięgu, a w folderze projektu zostanie utworzony folder pokrycie z informacjami o zasięgu testów w uniwersalnym formacie LCOV (rozszerzenie LTP GCOV).

Gcov to swobodnie rozpowszechniane narzędzie do sprawdzania pokrycia kodu. Gcov generuje dokładną liczbę wykonań dla każdej instrukcji w programie i pozwala na dodanie adnotacji do kodu źródłowego. Gcov jest standardowym narzędziem wchodzącym w skład pakietu GCC.
Lkow - interfejs graficzny dla gcov. Składa pliki gcov dla wielu plików źródłowych i tworzy zestaw stron HTML z kodem i informacjami o zasięgu. Strony są również generowane, aby ułatwić nawigację. Lcov obsługuje pokrycie ciągów, funkcji i gałęzi.

Po zakończeniu testów informacje o zasięgu zostaną umieszczone w zasięg/lcov.info.
Musimy powiedzieć Sonar'Skąd mogę to dostać? Dlatego dodajmy następujące linie do jego pliku konfiguracyjnego. Ale jest jeden punkt: projekty mogą być wielojęzyczne, to znaczy w folderze src istnieją kody źródłowe dla kilku języków programowania i przynależność do jednego lub drugiego, a z kolei użycie tej lub drugiej wtyczki zależy od jej rozszerzenia. Informacje o zasięgu mogą być przechowywane w różnych miejscach dla różnych języków programowania, więc każdy język ma własną sekcję do konfiguracji. Nasz projekt wykorzystuje Maszynopis, więc potrzebujemy tylko sekcji ustawień:

właściwości projektu sonarowego:

sonar.typescript.coveragePlugin=lcov
sonar.typescript.lcov.reportPaths=coverage/lcov.info

Wszystko jest gotowe na pierwsze uruchomienie skanera. Pragnę zauważyć, że projekt jest Sonar'e jest tworzone automatycznie przy pierwszym uruchomieniu skanera dla danego projektu. W kolejnych momentach gromadzone będą informacje, aby zobaczyć dynamikę zmian parametrów projektu w czasie.

Użyjmy więc polecenia utworzonego wcześniej w pakiet.json:

yarn run sonar

Uwaga: możesz także użyć parametru -X w celu uzyskania bardziej szczegółowego logowania.

Jeśli skaner został uruchomiony po raz pierwszy, najpierw zostanie pobrany plik binarny samego skanera. Następnie uruchamia się i rozpoczyna skanowanie serwera Sonar'a dla zainstalowanych wtyczek, obliczając w ten sposób obsługiwany język. Ładowane są również różne inne parametry jego działania: profile jakości, aktywne reguły, repozytorium metryk, reguły serwera.

Uwaga: Nie będziemy się nad nimi szczegółowo rozwodzić w ramach tego artykułu, ale zawsze możesz skontaktować się z oficjalnymi źródłami.

Następnie rozpoczyna się analiza folderów src o dostępność plików źródłowych dla wszystkich (o ile konkretny nie jest wyraźnie określony) obsługiwanego języka, wraz z ich późniejszym indeksowaniem.

Następnie przychodzą różne inne analizy, na których nie skupiamy się w tym artykule (na przykład takie jak linting, wykrywanie duplikacji kodu itp.).

Na samym końcu pracy skanera wszystkie zebrane informacje są agregowane, archiwizowane i wysyłane na serwer.

Po tym możemy już zobaczyć, co wydarzyło się w interfejsie internetowym:

Jak widać coś zadziałało, a nawet pokazuje jakiś zasięg, ale nie dorównuje naszemu Żart-raport.

Rozwiążmy to. Przyjrzyjmy się projektowi bardziej szczegółowo, kliknij wartość pokrycia i „przejdźmy” do szczegółowego raportu w pliku:

Tutaj widzimy, oprócz głównego, zbadanego pliku HelloWorld.vue, jest też plik główne.ts, co psuje cały obraz zasięgu. Ale dlaczego wyłączyliśmy to z obliczeń zasięgu. Tak, wszystko się zgadza, ale było na poziomie Żart, ale skaner go zindeksował, więc znalazł się w jego obliczeniach.

Naprawmy to:

właściwości projektu sonarowego:

...
sonar.exclusions=src/main.ts
...

Chciałbym wyjaśnić: oprócz folderów określonych w tym parametrze dodawane są również wszystkie foldery wymienione w tym parametrze włączenia.testu.sonara.

Po uruchomieniu skanera widzimy poprawną informację:

Spójrzmy na następny punkt - Profile jakości. O wsparciu wspomniałem powyżej Sonarom kilka języków jednocześnie. To jest dokładnie to, co widzimy. Ale wiemy, że nasz projekt jest zapisany TS, więc po co obciążać skaner niepotrzebnymi manipulacjami i kontrolami. Język analizy ustalimy dodając jeszcze jeden parametr do pliku konfiguracyjnego Sonar'A:

właściwości projektu sonarowego:

...
sonar.language=ts
...

Uruchommy skaner ponownie i zobaczmy wynik:

Zasięg całkowicie zniknął.

Jeśli spojrzymy na dziennik skanera, zobaczymy następujący wiersz:

Oznacza to, że pliki naszych projektów po prostu nie zostały zindeksowane.

Sytuacja wygląda następująco: oficjalnie wspierana VueJs jest we wtyczce SonarJSkto jest za to odpowiedzialny Javascript.

Ale tej obsługi nie ma we wtyczce SonarTS dla TS, o którym otwarto oficjalny bilet w narzędziu do śledzenia błędów Sonar'A:

Oto kilka odpowiedzi jednego z przedstawicieli deweloperów SonarQube potwierdzających ten fakt.

Ale u nas wszystko zadziałało, sprzeciwiasz się. Tak, spróbujmy trochę "włamać się".
Jeśli jest wsparcie .vue-akta Sonar- Och, w takim razie spróbujmy mu powiedzieć, żeby uznał je za Maszynopis.

Dodajmy parametr:

właściwości projektu sonarowego:

...
sonar.typescript.file.suffixes=.ts,.tsx,.vue
...

Uruchommy skaner:

I voila, wszystko wróciło do normy i to tylko z jednym profilem Maszynopis. Oznacza to, że udało nam się rozwiązać problem w ramach wsparcia VueJs+TS dla SoundQube.

Spróbujmy pójść dalej i nieco poprawić informacje o zasięgu.

Co zrobiliśmy do tej pory:

dodany do projektu Sonar-scanner;
organizować coś Żart do generowania informacji o zasięgu;
skonfigurowany Sonar-scanner;
rozwiązał problem wsparcia .vue-pliki + Maszynopis.

Oprócz pokrycia testowego istnieją inne interesujące, przydatne kryteria jakości kodu, na przykład duplikacja kodu i liczba linii (biorących udział w obliczaniu współczynników związanych ze złożonością kodu) projektu.

W obecnej implementacji wtyczki do pracy z TS (SonarTS) nie będzie działać CPD (detektor kopiowania i wklejania) i liczenie linii kodu .vue-akta.

Aby stworzyć syntetyczną sytuację duplikacji kodu, po prostu zduplikuj plik składowy pod inną nazwą i również dodaj go do kodu główne.ts funkcję fikcyjną i zduplikuj ją pod inną nazwą. Aby sprawdzić duplikację, jak w .vuea w .ts -akta.

główne.ts:

...
function name(params:string): void {
  console.log(params);
}
...

Aby to zrobić, musisz tymczasowo skomentować linię konfiguracyjną:

właściwości projektu sonarowego:

...
sonar.exclusions=src/main.ts
...

Zrestartujmy skaner wraz z testowaniem:

yarn test && yarn run sonar

Oczywiście nasz zasięg będzie spadał, ale teraz nie jesteśmy tym zainteresowani.

Jeśli chodzi o powielanie linii kodu, zobaczymy:

Aby sprawdzić, użyjemy CPD-pożytek - jscpd:

npx jscpd src

Dla linii kodu:

Być może zostanie to rozwiązane w przyszłych wersjach wtyczek SonarJS(TS). Chciałbym zauważyć, że stopniowo zaczynają łączyć te dwie wtyczki w jedną SonarJS, co moim zdaniem jest słuszne.

Teraz chciałem rozważyć opcję poprawy informacji o zasięgu.

Na razie widać procentowe pokrycie testów dla całego projektu, a w szczególności dla plików. Istnieje jednak możliwość rozszerzenia tego wskaźnika o informację o ilości jednostka-testy pod projekt, jak i w kontekście plików.

Jest taka biblioteka, która to potrafi Żart-konwersja raportu do formatu Sonar'A:
ogólne dane testowe - https://docs.sonarqube.org/display/SONAR/Generic+Test+Data.

Zainstalujmy tę bibliotekę w naszym projekcie:

yarn add jest-sonar-reporter

I dodaj to do konfiguracji Żart:

pakiet.json:

…
"testResultsProcessor": "jest-sonar-reporter"
…

Teraz przeprowadźmy test:

yarn test

Następnie w katalogu głównym projektu zostanie utworzony plik raport-testowy.xml.

Użyjmy go w konfiguracji Sonar'A:

właściwości projektu sonarowego:

…
sonar.testExecutionReportPaths=test-report.xml
…

I uruchom ponownie skaner:

yarn run sonar

Zobaczmy, co zmieniło się w interfejsie Sonar'A:

I nic się nie zmieniło. Faktem jest, że Sonar nie uważa plików opisanych w raporcie Jest za pliki jednostka-testy. Aby skorygować tę sytuację, używamy parametru konfiguracyjnego Sonar testy sonaru, w którym wyraźnie wskażemy foldery z testami (na razie mamy tylko jeden):

właściwości projektu sonarowego:

…
sonar.tests=src/components/__tests__
…

Uruchommy ponownie skaner:

yarn run sonar

Zobaczmy, co zmieniło się w interfejsie:

Teraz zobaczyliśmy liczbę naszych jednostka-tests i po nieudanym kliknięciu możemy zobaczyć rozkład tej liczby pomiędzy plikami projektu:

wniosek

Przyjrzeliśmy się więc narzędziu do ciągłej analizy SoundQube. Udało nam się zintegrować z nim napisany w nim projekt VueJs+TS. Naprawiono niektóre problemy ze zgodnością. Zwiększyliśmy zawartość informacyjną wskaźnika pokrycia testami. W tym artykule zbadaliśmy tylko jedno z kryteriów jakości kodu (być może jedno z głównych), ale SoundQube wspiera inne kryteria jakości, w tym badania bezpieczeństwa. Jednak nie wszystkie z tych funkcji są w pełni dostępne w społeczność-wersje. Jedną z ciekawych i przydatnych funkcji jest integracja SoundQube z różnymi systemami zarządzania repozytorium kodu, takimi jak GitLab i BitBucket. Aby zapobiec łączenie żądania ściągania (scalania).„a do głównej gałęzi repozytorium w przypadku pogorszenia zasięgu. Ale to już historia na zupełnie inny artykuł.

PS: Wszystko opisane w artykule w formie kodu jest dostępne w mój widelec.

W ankiecie mogą brać udział tylko zarejestrowani użytkownicy. Zaloguj się, Proszę.

Czy korzystasz z platformy SonarQube:

26,3%Tak5
15,8%Nie3
15,8%Słyszałem o tej platformie i chcę z niej skorzystać3
10,5%Słyszałem o tej platformie i nie chcę używać2
0,0%Używam innej platformy0
31,6%Pierwszy raz o niej słyszę6

Głosowało 19 użytkowników. 3 użytkowników wstrzymało się od głosu.

Źródło: www.habr.com

Integracja projektu VueJS+TS z SonarQube

wniosek

Czy korzystasz z platformy SonarQube:

Dodaj komentarz Anuluj odpowiedź