Þrátt fyrir að allir viti vel að það er mikilvægt og nauðsynlegt að prófa hugbúnaðinn þinn, og margir hafa gert það sjálfkrafa í langan tíma, þá var ekki ein einasta uppskrift að því að setja upp samsetningu af svo vinsælum vörum í víðerni Habr. þetta sess sem (uppáhaldið okkar) GitLab og JUnit. Við skulum fylla þetta skarð!
Inngangur
Leyfðu mér fyrst að gefa samhengi:
Þar sem öll forritin okkar keyra á Kubernetes munum við íhuga að keyra próf á viðeigandi innviðum.
Fyrir samsetningu og dreifingu notum við werf (hvað varðar innviðaíhluti þýðir þetta líka sjálfkrafa að Helm á hlut að máli).
Ég mun ekki fara í smáatriðin um raunverulega stofnun prófa: í okkar tilviki skrifar viðskiptavinurinn prófin sjálfur og við tryggjum aðeins að þær verði settar af stað (og tilvist samsvarandi skýrslu í sameiningarbeiðninni).
Hvernig mun almenn röð aðgerða líta út?
Að byggja upp forritið - við munum sleppa lýsingu á þessu stigi.
Dreifðu forritinu í sérstakt nafnrými Kubernetes þyrpingarinnar og byrjaðu að prófa.
Leita að gripum og þátta JUnit skýrslur með GitLab.
Eyðir áður búið til nafnrými.
Nú - að framkvæmd!
aðlögun
GitLab CI
Byrjum á broti .gitlab-ci.yaml, sem lýsir uppsetningu forritsins og keyrslu prófana. Skráningin reyndist nokkuð fyrirferðarmikil og því var bætt við hana rækilega með athugasemdum:
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
Nú í möppunni .helm/templates búum til YAML með Job - tests-job.yaml - til að keyra próf og Kubernetes auðlindir sem það þarf. Sjá skýringar eftir skráningu:
Hvers konar auðlindir lýst í þessari uppsetningu? Við uppsetningu búum við til einstakt nafnrými fyrir verkefnið (þetta er gefið til kynna í .gitlab-ci.yaml - tests-${CI_COMMIT_REF_SLUG}) og rúllaðu því út:
ConfigMap með prófunarhandriti;
Starf með lýsingu á belgnum og tilgreindri tilskipun command, sem keyrir bara prófin;
PV og PVC, sem gerir þér kleift að geyma prófunargögn.
Gefðu gaum að inngangsskilyrðum með if í upphafi upplýsingaskrárinnar - í samræmi við það verður að pakka öðrum YAML skrám af Helm töflunni með forritinu inn í öfugt hanna þannig að þeir verði ekki notaðir við prófun. Það er:
{{- if ne .Values.global.run_tests "yes" }}
---
я другой ямлик
{{- end }}
Hins vegar, ef próf þarfnast einhverra innviða (til dæmis Redis, RabbitMQ, Mongo, PostgreSQL...) - YAML þeirra geta verið ekki Slökkva á. Settu þá líka inn í prófunarumhverfi... stilltu þá að sjálfsögðu eins og þér sýnist.
Final snerta
Vegna þess að samsetning og dreifing með werf er enn að vinna aðeins á byggingarþjóninum (með gitlab-runner), og belgurinn með prófunum er ræstur á masternum, þá þarftu að búa til möppu /mnt/tests á meistarann og gefðu hlauparanum það, til dæmis í gegnum NFS. Ítarlegt dæmi með skýringum er að finna í K8s skjöl.
Enginn bannar að gera NFS-deilingu beint á gitlab-runner og setja það síðan í belg.
Athugið
Þú gætir verið að spyrja hvers vegna flækja allt með því að búa til Job ef þú getur einfaldlega keyrt skriftu með prófum beint á skeljahlauparann? Svarið er frekar léttvægt...
Sum próf krefjast aðgangs að innviðunum (MongoDB, RabbitMQ, PostgreSQL o.s.frv.) til að sannreyna að þau virki rétt. Við gerum prófun sameinaða - með þessari nálgun verður auðvelt að hafa slíka viðbótareiningar með. Þessu til viðbótar fáum við staðlað dreifingaraðferð (jafnvel þótt NFS sé notað, viðbótaruppsetning á möppum).
Niðurstaðan
Hvað munum við sjá þegar við beitum tilbúnu uppsetningunni?
Samrunabeiðnin mun sýna yfirlitstölfræði fyrir prófanir sem keyrðar eru í nýjustu leiðslunni:
Hægt er að smella á hverja villu hér til að fá nánari upplýsingar:
NB: Eftirtektarsamur lesandi mun taka eftir því að við erum að prófa NodeJS forrit, og á skjáskotunum - .NET... Ekki vera hissa: það er bara að við undirbúning greinarinnar fundust engar villur við prófun fyrsta forritsins, en þær fundust í öðru.
Ályktun
Eins og þú sérð, ekkert flókið!
Í grundvallaratriðum, ef þú ert nú þegar með skeljasafnara og hann virkar, en þú þarft ekki Kubernetes, mun það vera enn einfaldara verkefni að tengja prófun við það en lýst er hér. Og í GitLab CI skjöl þú finnur dæmi fyrir Ruby, Go, Gradle, Maven og nokkra aðra.