Привет, меня зовут Андрей, я руководитель бэкенд разработки компании Бимейстер.
Хочу поделиться опытом быстрого подсвечивания возможных проблемных зон объёмного и малознакомого кода.

Для кого эта статья?
Показанное здесь решение позволяет сэкономить до 8 часов времени на чтение документации и на путь проб и ошибок руководителю разработки любого уровня, лиду команды и просто разработчику, которому нужно быстро подсветить потенциальные проблемы в объёмной незнакомой кодовой базе.

Когда кода много, а времени мало, можно устроить анонимный опрос и узнать источники боли у коллег, для которых исследуемый код ближе.
-
Плюсы:
-
он, несомненно, проще (привет, KISS);
-
можно узнать не только о проблемах, но и их отношении к этому.
-
-
Минусы:
-
ответы будут субъективны;
-
они будут касаться лишь тех областей кода, с которыми конкретный человек недавно работал;
-
есть риск вскрыть нарыв, тем самым обрекая себя на исповедь (а по ситуации и отповедь), что может быть затратно по времени;
-
повторная операция потребует столько же времени.
-
А можно взять принятое в сообществе бесплатное решение, натравить его на код и посмотреть на результаты анализа.
-
Плюсы
-
будет получен более-менее объективный анализ;
-
мы никого не будем отвлекать;
-
такой прогон можно повторить по результатам сделанных исправлений почти бесплатно (привет DRY).
-
-
Минусы
-
порог вхождения выше — надо с чем-то разбираться;
-
понимание результата весьма смутное в самом начале пути — нет понимания, окупится ли вложенное время;
-
если не особо вкладываться в настройку правил анализа, будет подсвечено много нерелевантного.
-
Я прошёл вариант с опросом, но параллельно решил и прогнать что-то стороннее для большей объективности своих будущих запросов на исправление.
(спасибо всем, кто дочитал до этого места)

Итак, в этой статье я постараюсь исправить два первых минуса, а именно:
-
предоставить читателю готовую пошаговую инструкцию настройки SonarQube в контейнерах Docker Desktop;
-
сформировать у заинтересованных ожидания от конечного результата.
Поставленная Цель. Быстро и без последствий для локального ноутбука иметь возможность прогнать дефолтные правила одного из популярных сканеров кодовой базы.
Дисклеймер. В этой статье не будет ничего про настройки интеграции сканера в пайплайны CI/CD.

Собственно, как я спойлернул выше, решение было выбрано следующее: локально развёрнутый на Windows-ноутбуке Docker Desktop с wsl + SonarQube.
Наскоро пробежав глазами документацию c Docker Hub-а, находим требования к хосту.
Открываем консоль PowerShell, выполняем подключение к терминалу docker-desktop:
wsl -d docker-desktop
Вводим рекомендованные в настроечные команды (если коротко, мы делаем это потому, что elasticsearch под капотом требует ресурсов больше, чем выделено по умолчанию):
sysctl -w vm.max_map_count=524288 sysctl -w fs.file-max=131072 ulimit -n 131072 ulimit -u 8192
(последняя команда вызвала у меня ошибку ‘unknown argument u’, однако, на финальный результат это не повлияло)
После настройки хоста готовим файлик sonar.yaml, очень похожий на рекомендуемый на странице вендора:
version: "3.8" services: sonarqube: image: sonarqube:community ports: - "9000:9000" - "9092:9092" depends_on: - db environment: SONAR_JDBC_URL: jdbc:postgresql://db:5432/sonar SONAR_JDBC_USERNAME: sonar SONAR_JDBC_PASSWORD: sonar volumes: - sonarqube_conf:/opt/sonarqube/conf - sonarqube_data:/opt/sonarqube/data - sonarqube_logs:/opt/sonarqube/logs - sonarqube_extensions:/opt/sonarqube/extensions - sonarqube_bundled-plugins:/opt/sonarqube/lib/bundled-plugins networks: sonar_network: db: image: postgres:12 ports: - "5432:5432" command: postgres -c 'max_connections=300' volumes: - postgresql:/var/lib/postgresql - postgresql_data:/var/lib/postgresql/data environment: POSTGRES_DB: sonar POSTGRES_USER: sonar POSTGRES_PASSWORD: sonar networks: sonar_network: restart: unless-stopped volumes: sonarqube_conf: sonarqube_data: sonarqube_logs: sonarqube_extensions: sonarqube_bundled-plugins: postgresql: postgresql_data: networks: sonar_network:
Запускаем контейнеры командой:
docker-compose -f sonar.yml -p sonar up -d
Если всё сделали правильно, у нас стартуют оба контейнера и мы получаем доступ к панели администратора SonarQube по адресу http://localhost:9000/.

Первым делом нас просят сменить пароль на что-то более безопасное.
Затем мы попадаем на страницу создания нового проекта. Нам предлагается выбор источников исходного кода, я выбрал «From GitLab» (ещё один дисклеймер: я шёл по шагам «мастера» добавления нового проекта, и поскольку у меня есть доступ к GitLab, я решил воспользоваться именно этим пунктом. Однако, забегая вперёд и учитывая, что весь код в итоге скачивался, собирался и анализировался локально, я не уверен, что нужно было идти именно таким путём).

Итак, я выбрал From GitLab.
Для автоматического подтягивания списка репозиториев потребуется токен доступа к GitLab. Идём в GitLab > User Settings > Access Tokens и создаём новый токен со скоупом api. Не забыв скопировать токен в буфер обмена, возвращаемся в админку SonarQube и вводим её в соответствующее поле. Получаем список репозиториев, выбираем:

Определившись с репозиторием, выбираем — как мы будем проводить анализ?
Нам представлено несколько вариантов интеграции, однако мы идём по локальному пути — жмём Locally, расположенный внизу особняком:

Далее требуется ввести существующий или выбрать генерацию нового токена на сканирование выбранного репозитория:

Важно! Сканирование любого Git-репозитория с этим токеном будет автоматически привязано к данному репозиторию в SonarQube, поэтому переиспользовать эти токены сканирования желательно только в рамках одной репы.
Генерируем, получаем что-то вроде sqp_d42feed11ed20248464f8ceb22897aec19533212.
Жмём Continue.
Далее выбираем — на что больше всего похож наш билд? В моём случае это .net core приложение, так что жмём .NET и .NET Core:

Получаем список из четырёх команд для последовательного запуска в папке с репозиторием (в моём случае, solution-файл лежал на один уровень глубже, так что открываем PowerShell и проваливаемся до папки с solution-файлом, не забыв перед сканированием обновить локальный репозиторий посредством git pull).
Копируем со странички в окно PowerShell-консоли и выполняем одну за другой 4 команды:
dotnet tool install --global dotnet-sonarscanner dotnet sonarscanner begin /k:"common_identity_ABzn02OgsqQ2PsdJYMkV" /d:sonar.host.url="http://localhost:9000" /d:sonar.login="sqp_d42feed11ed20248464f8ceb22897aec19533212" dotnet build dotnet sonarscanner end /d:sonar.login="sqp_d42feed11ed20248464f8ceb22897aec19533212"
Последняя команда может работать минуты на большом количестве кода. После завершения обновляем окно проекта в SonarQube и видим красивый интерактивный отчёт.

Сразу становится понятен общий уровень кода и на что нужно обратить внимание в ближайшем спринте.

Получаем, кстати, не только подсвеченные области, вызывающие вопросы, как, например, вот это использование всеми любимого класса Random():

Бонусом идут готовые варианты решения (нужно перейти на вкладку «How can you fix it?»:

Можно идти фиксить самому или превращать в прекрасно описанные задачи.

Спасибо за внимание!
ссылка на оригинал статьи https://habr.com/ru/company/bimeister/blog/671900/
Добавить комментарий