Pomimo tego, że wszyscy doskonale wiedzą, że testowanie oprogramowania jest ważne i konieczne, a wielu robi to automatycznie od dawna, w ogromie Habr nie było ani jednego przepisu na zestawienie kombinacji tak popularnych produktów w tej niszy jako (nasz ulubiony) GitLab i JUnit. Wypełnijmy tę lukę!
wprowadzający
Najpierw podam kontekst:
Ponieważ wszystkie nasze aplikacje działają na Kubernetesie, rozważymy przeprowadzenie testów na odpowiedniej infrastrukturze.
Do montażu i wdrożenia używamy werf (jeśli chodzi o elementy infrastruktury, oznacza to automatycznie również udział Helma).
Nie będę wdawał się w szczegóły faktycznego tworzenia testów: w naszym przypadku klient sam pisze testy, a my jedynie zapewniamy ich uruchomienie (i obecność odpowiedniego raportu w żądaniu scalania).
Jak będzie wyglądać ogólna sekwencja działań?
Budowa aplikacji – opis tego etapu pominiemy.
Wdróż aplikację w osobnej przestrzeni nazw klastra Kubernetes i rozpocznij testowanie.
Wyszukiwanie artefaktów i analizowanie raportów JUnit za pomocą GitLab.
Usuwanie wcześniej utworzonej przestrzeni nazw.
Teraz - do realizacji!
regulacja
GitLab CI
Zacznijmy od fragmentu .gitlab-ci.yaml, który opisuje wdrożenie aplikacji i uruchomienie testów. Zestawienie okazało się dość obszerne, dlatego zostało szczegółowo uzupełnione komentarzami:
variables:
# объявляем версию werf, которую собираемся использовать
WERF_VERSION: "1.0 beta"
.base_deploy: &base_deploy
script:
# создаем namespace в K8s, если его нет
- kubectl --context="${WERF_KUBE_CONTEXT}" get ns ${CI_ENVIRONMENT_SLUG} || kubectl create ns ${CI_ENVIRONMENT_SLUG}
# загружаем werf и деплоим — подробнее об этом см. в документации
# (https://werf.io/how_to/gitlab_ci_cd_integration.html#deploy-stage)
- type multiwerf && source <(multiwerf use ${WERF_VERSION})
- werf version
- type werf && source <(werf ci-env gitlab --tagging-strategy tag-or-branch --verbose)
- werf deploy --stages-storage :local
--namespace ${CI_ENVIRONMENT_SLUG}
--set "global.commit_ref_slug=${CI_COMMIT_REF_SLUG:-''}"
# передаем переменную `run_tests`
# она будет использоваться в рендере Helm-релиза
--set "global.run_tests=${RUN_TESTS:-no}"
--set "global.env=${CI_ENVIRONMENT_SLUG}"
# изменяем timeout (бывают долгие тесты) и передаем его в релиз
--set "global.ci_timeout=${CI_TIMEOUT:-900}"
--timeout ${CI_TIMEOUT:-900}
dependencies:
- Build
.test-base: &test-base
extends: .base_deploy
before_script:
# создаем директорию для будущего отчета, исходя из $CI_COMMIT_REF_SLUG
- mkdir /mnt/tests/${CI_COMMIT_REF_SLUG} || true
# вынужденный костыль, т.к. GitLab хочет получить артефакты в своем build-dir’е
- mkdir ./tests || true
- ln -s /mnt/tests/${CI_COMMIT_REF_SLUG} ./tests/${CI_COMMIT_REF_SLUG}
after_script:
# после окончания тестов удаляем релиз вместе с Job’ом
# (и, возможно, его инфраструктурой)
- type multiwerf && source <(multiwerf use ${WERF_VERSION})
- werf version
- type werf && source <(werf ci-env gitlab --tagging-strategy tag-or-branch --verbose)
- werf dismiss --namespace ${CI_ENVIRONMENT_SLUG} --with-namespace
# мы разрешаем падения, но вы можете сделать иначе
allow_failure: true
variables:
RUN_TESTS: 'yes'
# задаем контекст в werf
# (https://werf.io/how_to/gitlab_ci_cd_integration.html#infrastructure)
WERF_KUBE_CONTEXT: 'admin@stage-cluster'
tags:
# используем раннер с тегом `werf-runner`
- werf-runner
artifacts:
# требуется собрать артефакт для того, чтобы его можно было увидеть
# в пайплайне и скачать — например, для более вдумчивого изучения
paths:
- ./tests/${CI_COMMIT_REF_SLUG}/*
# артефакты старше недели будут удалены
expire_in: 7 day
# важно: эти строки отвечают за парсинг отчета GitLab’ом
reports:
junit: ./tests/${CI_COMMIT_REF_SLUG}/report.xml
# для упрощения здесь показаны всего две стадии
# в реальности же у вас их будет больше — как минимум из-за деплоя
stages:
- build
- tests
build:
stage: build
script:
# сборка — снова по документации по werf
# (https://werf.io/how_to/gitlab_ci_cd_integration.html#build-stage)
- type multiwerf && source <(multiwerf use ${WERF_VERSION})
- werf version
- type werf && source <(werf ci-env gitlab --tagging-strategy tag-or-branch --verbose)
- werf build-and-publish --stages-storage :local
tags:
- werf-runner
except:
- schedules
run tests:
<<: *test-base
environment:
# "сама соль" именования namespace’а
# (https://docs.gitlab.com/ce/ci/variables/predefined_variables.html)
name: tests-${CI_COMMIT_REF_SLUG}
stage: tests
except:
- schedules
Kubernetes
Teraz w katalogu .helm/templates stwórzmy YAML z Jobem - tests-job.yaml — do uruchamiania testów i potrzebnych zasobów Kubernetes. Zobacz wyjaśnienia po wystawieniu aukcji:
Jakie zasoby opisane w tej konfiguracji? Podczas wdrażania tworzymy unikalną przestrzeń nazw dla projektu (jest to wskazane w .gitlab-ci.yaml - tests-${CI_COMMIT_REF_SLUG}) i rozwiń go:
Mapa konfiguracji ze skryptem testowym;
Praca z opisem kapsuły i określoną dyrektywą command, który właśnie uruchamia testy;
PV i PCV, które umożliwiają przechowywanie danych testowych.
Zwróć uwagę na warunek wprowadzający z if na początku manifestu - odpowiednio należy opakować pozostałe pliki YAML wykresu Helma z aplikacją odwracać zaprojektować tak, aby nie zostały wdrożone podczas testowania. To jest:
{{- if ne .Values.global.run_tests "yes" }}
---
я другой ямлик
{{- end }}
Jeśli jednak testy wymagają pewnej infrastruktury (na przykład Redis, RabbitMQ, Mongo, PostgreSQL...) - ich YAML mogą być nie wyłączyć coś. Wdróż je również w środowisku testowym... oczywiście dostosowując je według własnego uznania.
Ostatni dotyk
Ponieważ montaż i wdrożenie przy użyciu werf działa na razie tylko na serwerze kompilacji (z gitlab-runner), a kapsuła z testami zostanie uruchomiona na serwerze głównym, będziesz musiał utworzyć katalog /mnt/tests na mistrza i daj biegaczowi, na przykład przez NFS. Szczegółowy przykład z objaśnieniami można znaleźć w Dokumentacja K8.
Nikt nie zabrania tworzenia udziału NFS bezpośrednio na gitlab-runner, a następnie montowania go w podach.
Operacja
Być może zastanawiasz się, po co wszystko komplikować, tworząc zadanie, skoro możesz po prostu uruchomić skrypt z testami bezpośrednio w programie Shell? Odpowiedź jest dość banalna...
Niektóre testy wymagają dostępu do infrastruktury (MongoDB, RabbitMQ, PostgreSQL itp.), aby sprawdzić, czy działają poprawnie. Ujednolicamy testowanie – dzięki takiemu podejściu łatwo jest uwzględnić takie dodatkowe podmioty. Oprócz tego otrzymujemy standard podejście do wdrażania (nawet przy użyciu NFS, dodatkowe montowanie katalogów).
Doświadcz mocnych i skutecznych rezultatów
Co zobaczymy, gdy zastosujemy przygotowaną konfigurację?
Żądanie połączenia wyświetli statystyki podsumowujące testy przeprowadzone w najnowszym potoku:
Aby uzyskać szczegółowe informacje, kliknij tutaj każdy błąd:
NB: Uważny czytelnik zauważy, że testujemy aplikację NodeJS, a na zrzutach ekranu - .NET... Nie zdziw się: tyle, że podczas przygotowywania artykułu nie znaleziono żadnych błędów w testowaniu pierwszej aplikacji, ale one znaleziono w innym.
wniosek
Jak widać, nic skomplikowanego!
W zasadzie jeśli masz już kolektor powłoki i działa, ale nie potrzebujesz Kubernetesa, dołączenie do niego testów będzie jeszcze prostszym zadaniem, niż opisano tutaj. I w Dokumentacja GitLab CI znajdziesz przykłady dla Ruby, Go, Gradle, Maven i kilku innych.