Пайплайн gitlab для Spring REST приложения. Часть 3

Для выполнения этой стадии необходимо подготовиться.

1. Устанавливаем sonarqube на сервер. Как вы это сделаете — на ваше усмотрение, я предпочитаю везде по возможности использовать docker, поэтому просто выполняю команду docker run -d -p 9000:9000 sonarqube

2. Авторизуемся в админке sonarqube и настраиваем токены, для этого прямо в админке есть подробная инструкция.

3. Добавьте необходимые строки для работы проекта с sonarqube в файл build.gradle, после чего в gradle у нас появляются новые таски для sonarqube:

После подготовки добавляем новую стадию в наш пайплайн.

variables:   SONAR_USER_HOME: "${CI_PROJECT_DIR}/.sonar"   GIT_DEPTH: "0" stages:   - feature   - feature-artefact   - feature-clean-stand   - feature-install-stand   - test feature development:   tags:     - feature   stage: feature   image: gradle:7.5.0-jdk11   script:     - cd rest-service     - ./gradlew assemble  feature docker image:   tags:     - feature   stage: feature-artefact   script:     - cd rest-service     - ./gradlew jibDockerBuild        feature clean stand:   tags:     - feature   stage: feature-clean-stand   allow_failure: true   script:     - cd rest-service/.chart     - helm uninstall docker-compose-feature --namespace=yamangulov-feature    feature install stand:   tags:     - feature   stage: feature-install-stand   script:     - cd rest-service/.chart/     - helm install docker-compose-feature docker-compose --namespace=yamangulov-feature --values=docker-compose/values-yamangulov-feature.yaml  testing:   stage: test   image: gradle:7.5.0-jdk11   cache:     key: "${CI_JOB_NAME}"     paths:       - .sonar/cache   script:     - cd rest-service     - gradle sonarqube -Dsonar.qualitygate.wait=true   rules:     - if: '$CI_BUILD_REF_NAME != "main" && $CI_PIPELINE_SOURCE == "push" || $CI_PIPELINE_SOURCE == "merge_request_event"' 

Стадия тестирования разворачивает приложение в docker- контейнере и затем выполняет в gradle таску для проведения unit-тестов (конечно, нужно их написать в приложении) и прочие проверки. После выполнения стадии необходимо зайти в админку и просмотреть результаты проверок (sonarqube очень подробно распишет вам, где что не так), если нужно — доработать код для устранения недостатков и запустить пайплайн снова.

Стадии для smoke и регрессионного тестирования

Сами по себе настройки этих стадий в файле gitlab-ci.yml довольно просты, мы просто поднимаем приложение в контейнере и запускаем нужные таски gradle, которые сами и выполнят нужные тесты:

variables:   SONAR_USER_HOME: "${CI_PROJECT_DIR}/.sonar"   GIT_DEPTH: "0" stages:   - feature   - feature-artefact   - feature-clean-stand   - feature-install-stand   - test   - smoke   - regress feature development:   tags:     - feature   stage: feature   image: gradle:7.5.0-jdk11   script:     - cd rest-service     - ./gradlew assemble  feature docker image:   tags:     - feature   stage: feature-artefact   script:     - cd rest-service     - ./gradlew jibDockerBuild        feature clean stand:   tags:     - feature   stage: feature-clean-stand   allow_failure: true   script:     - cd rest-service/.chart     - helm uninstall docker-compose-feature --namespace=yamangulov-feature    feature install stand:   tags:     - feature   stage: feature-install-stand   script:     - cd rest-service/.chart/     - helm install docker-compose-feature docker-compose --namespace=yamangulov-feature --values=docker-compose/values-yamangulov-feature.yaml  testing:   stage: test   image: gradle:7.5.0-jdk11   cache:     key: "${CI_JOB_NAME}"     paths:       - .sonar/cache   script:     - cd rest-service     - gradle sonarqube -Dsonar.qualitygate.wait=true   rules:     - if: '$CI_BUILD_REF_NAME != "main" && $CI_PIPELINE_SOURCE == "push" || $CI_PIPELINE_SOURCE == "merge_request_event"'  smoke testing:   stage: smoke   image: gradle:7.5.0-jdk11   script:     - cd rest-service     - gradle clean integrationTest --tests "*smokeTest*"   rules:     - if: '$CI_BUILD_REF_NAME != "main" && $CI_PIPELINE_SOURCE == "push" || $CI_PIPELINE_SOURCE == "merge_request_event"'  regression testing:   stage: regress   image: gradle:7.5.0-jdk11   script:     - cd rest-service     - gradle clean integrationTest --tests "*regressionTest*"   rules:     - if: '$CI_BUILD_REF_NAME != "main" && $CI_PIPELINE_SOURCE == "push" || $CI_PIPELINE_SOURCE == "merge_request_event"' 

Интерес здесь представляют только строки, которые запускают выборочно одну отдельно взятую таску gradle по ее названию и выполняют в ней только один выбранный по шаблону тест.. Сложность этих стадий не в их настройке, а в выполнении самих тестов. И здесь приходят на помощь testcontainers — очень полезная библиотека, которая позволяет поднимать специальные контейнеры для интеграционных тестов. Настройки для подключения библиотеки вы можете увидеть в образце файла build.gradle из предыдущей части этой статьи. Написание самих интеграционных тестов может иногда представлять некоторую сложность и зависит от функционала вашего приложения. Как вариант, приведу в качестве образчика, два класса, описывающие, как это делал я для моего приложения:

PostgresContainerWrapper и TestContainer

В основном можно считать, что для большинства приложений выполненных стадий для пайплайна gitlab ci/cd вполне достаточно, если приложения не предполагают достаточно высокой нагрузки. Если речь идет о высоконагруженном приложении, то без нагрузочных тестов уже не обойтись. Тогда необходимо добавить еще одну стадию для них. Поэтому я планирую через некоторое время дополнить статью четвертой завершающей частью, где и будет описываться мой опыт по выполнению нагрузочного тестирования и включения его в пайплайн.

В заключение приглашаю всех на бесплатный урок от моих коллег из OTUS, где в процессе занятия пройдёмся по метрикам и конечным точкам для работы с приложением. Ощутим мощь актуатора и даже напишем свой «индикатор здоровья». Регистрация на урок доступна по ссылке ниже.

• Зарегистрироваться на бесплатный урок