Annak ellenére, hogy mindenki tökéletesen tudja, hogy a szoftver tesztelése fontos és szükséges, és sokan ezt már régóta automatikusan végzik, Habr hatalmas területén nem volt egyetlen recept az ilyen népszerű termékek kombinációjának létrehozására. ez a rés (kedvencünk) GitLab és JUnit . Töltsük be ezt a hiányt!
bevezető
Először is hadd mondjak egy kis kontextust:
Mivel minden alkalmazásunk Kubernetesen fut, megfontoljuk a tesztek futtatását a megfelelő infrastruktúrán.
Összeszereléshez és telepítéshez használjuk werf (az infrastrukturális összetevők tekintetében ez automatikusan azt is jelenti, hogy Helm érintett).
A tesztek tényleges elkészítésének részleteibe nem megyek bele: esetünkben a kliens maga írja meg a teszteket, mi pedig csak azok elindítását (és az összevonási kérelemben a megfelelő jelentés meglétét) biztosítjuk.
Hogyan fog kinézni a műveletek általános sorrendje?
Az alkalmazás felépítése - ennek a szakasznak a leírását elhagyjuk.
Telepítse az alkalmazást a Kubernetes-fürt külön névterébe, és kezdje el a tesztelést.
Műtermékek keresése és JUnit jelentések elemzése a GitLab segítségével.
Egy korábban létrehozott névtér törlése.
Most - a megvalósításhoz!
beállítás
GitLab CI
Kezdjük egy töredékkel .gitlab-ci.yaml, amely leírja az alkalmazás telepítését és a tesztek futtatását. A felsorolás elég terjedelmesnek bizonyult, így alaposan ki lett egészítve megjegyzésekkel:
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
Most a könyvtárban .helm/templates hozzuk létre a YAML-t Jobbal - tests-job.yaml — tesztek és a szükséges Kubernetes-erőforrások futtatása. Lásd a magyarázatot a felsorolás után:
Milyen források ebben a konfigurációban van leírva? Üzembe helyezéskor egyedi névteret hozunk létre a projekt számára (ezt jelzik .gitlab-ci.yaml - tests-${CI_COMMIT_REF_SLUG}) és kinyújtjuk:
ConfigMap teszt szkripttel;
Munka a pod leírásával és a megadott direktívával command, amely csak a teszteket futtatja;
PV és PVC, amelyek lehetővé teszik a tesztadatok tárolását.
Ügyeljen a bevezető feltételre if a manifest elején - ennek megfelelően az alkalmazással együtt lévő Helm diagram többi YAML fájlját be kell csomagolni fordított úgy kell megtervezni, hogy a tesztelés során ne kerüljenek telepítésre. Azaz:
{{- if ne .Values.global.run_tests "yes" }}
---
я другой ямлик
{{- end }}
Ha azonban a tesztek némi infrastruktúrát igényel (például Redis, RabbitMQ, Mongo, PostgreSQL...) - YAML-jeik lehetnek nincs kikapcsolni. Telepítse őket tesztkörnyezetbe is... természetesen tetszés szerint állítsa be őket.
Végső érintés
Mert összeszerelés és üzembe helyezés a werf munkáival egyelőre csak a build szerveren (gitlab-runnerrel), és a teszteket tartalmazó pod elindul a masteren, létre kell hoznia egy könyvtárat /mnt/tests a mesterre, és add a futónak, például NFS-en keresztül. Részletes példa magyarázatokkal a következő helyen található: K8s dokumentáció.
Senki sem tiltja, hogy NFS-megosztást készítsenek közvetlenül a gitlab-runneren, majd podokban rögzítsék.
Megjegyzés
Felmerülhet a kérdés, hogy miért kell mindent bonyolítani egy Job létrehozásával, ha egyszerűen futtathat egy szkriptet tesztekkel közvetlenül a shell runneren? A válasz elég triviális...
Egyes tesztekhez hozzáférés szükséges az infrastruktúrához (MongoDB, RabbitMQ, PostgreSQL stb.) a megfelelő működés ellenőrzéséhez. Egységessé tesszük a tesztelést – ezzel a megközelítéssel egyszerűvé válik az ilyen további entitások bevonása. Ezen felül kapunk standard telepítési megközelítés (még akkor is, ha NFS-t használ, a könyvtárak további csatlakoztatása).
Eredmény
Mit fogunk látni, amikor alkalmazzuk az elkészített konfigurációt?
Az egyesítési kérelem összefoglaló statisztikát jelenít meg a legutóbbi folyamatban futó tesztekhez:
Az egyes hibák ide kattintva megtekinthetők a részletekért:
NB: A figyelmes olvasónak feltűnik, hogy egy NodeJS alkalmazást tesztelünk, a képernyőképeken pedig - .NET... Ne lepődj meg: csak a cikk készítése közben nem találtak hibát az első alkalmazás tesztelésekor, de másikban találtak.
Következtetés
Amint látja, semmi bonyolult!
Elvileg, ha már van shell gyűjtőd, és működik, de nincs szükséged Kubernetesre, a tesztelést hozzácsatolni az itt leírtaknál is egyszerűbb feladat lesz. És be GitLab CI dokumentáció példákat találhat a Ruby, Go, Gradle, Maven és néhány más számára.