Запуск тестов через Slack бота для множества микросервисов

Предисловие

Привет, Хабр, я QA инженер в команде интеграции. Моя команда интегрирует локальных платежных провайдеров, чтобы наши клиенты могли заводить и выводить деньги. Из-за большого количество провайдеров у нас возникла проблема с деплоем сервисов на нужную ветку для тестирования. В этой статье, я представлю наше решение этой проблемы в виде Slack бота и не только. Надеюсь кому-то это тоже поможет решить подобную проблему.

Описание контекста и проблем

Как я и сказал, мы интегрируем платежных провайдеров. Каждый провайдер - это отдельный сервис, в котором заключена реализация взаимодействия с провайдером. Кодовая база всех сервисов располагается в одном репозитории, где есть общая логика и отдельные реализации конкретных провайдеров, которых мы называем драйверами. Автотесты и мок, который содержит необходимые примеры ответов от реальных провайдеров и тестовые кейсы, располагаются в отдельных репозиториях. Сервисы располагаются в Kubernetes, а управление настройками и версионностью сервисов идет через Helm charts. На данном этапе у нас 2 окружения: Prod и Dev и 60+ сервисов. 

В команде 8 разработчиков и 3 тестировщика. Все мы работаем в одном тестовом окружении, в котором можно запустить только одну версию каждого сервиса, поэтому мы прописываем нужный tag/branch сервису в репозиторий gitops. По сути, это монорепа с отдельной версионностью для каждого сервиса. После работы над сервисом, мы конечно же забываем вернуть его на основную ветку. Каждую ночь у нас запускается smoke прогон, а в выходные большой regress, и как результат, многие тесты красные, так как сервисы задеплоены на dev ветки, которые еще не смержены. Как итог, приходится тратить много времени на разбор падений, которые в итоге не релевантны, так как тестировалась неактуальная ветка. 

Следующая проблема которая была обнаружена - это фиксы базовой логики. Данные изменения затрагивают либо все сервисы, либо большое их количество. Чаще всего разработчику лень деплоить такое количество сервисов и он тестирует свои изменения на нескольких, что, конечно, недос��аточно, ведь не раз после этого, мы ловили баги на проде от тех сервисов, которые не были протестированы перед релизом.

Еще одна минорная проблема - это сложность запуска тестов через CI. Во-первых, чтобы запустить тесты на основной ветке в репозитории с автотестами в Gitlab CI, нужно иметь права на мерж, и не хочется всем их выдавать. Также не всегда очевидно какие и как правильно запустить тесты для тех или иных сервисов, для этого каждый раз приходится спрашивать тестировщика и отвлекать его от текущей задачи. Вместе с нужной веткой тестов, необходимо так же задеплоить мок сервис.

Все это создает трудности перед командой, что увеличивает шансы не запустить тесты и зарелизить сервис с багами.

 После обсуждения этих проблем и пары серьезных багов с прода, мы сформулировали наши пожелания и требования к решению.

Что мы хотим:

• Повысить стабильность и актуальность тестов Smoke (ночные) и Regress ( еженедельные) прогонов

• Облегчить деплой нужной версии драйвера и мока, и запуск только тех тестов, чьи сервисы были затронуты

• Сделать удобный интерфейс, чтобы не нужно было заходить в CI по стандартным случаям

Требования к решению:

• Обновление или деплой сервиса и мока на основную ветку перед Smoke и Regression тестированием

• Откат сервисов на текущую ветку после тестирования

• Деплой одного или списка сервисов и мока на нужную ветку и запуск тестов для этих сервисов

• Сделать интерфейс, что бы не заходить в Gitlab CI

Реализация

 В итоге получилось решение состоящее из 3-х частей:

1. Python скрипты для деплоя и определения скоупа для тестирования

2. Gitlab pipeline, который управляет деплоем сервисов, запуском тестов и откатом

3. Slack bot в виде сервиса, который реализует необходимый интерфейс

Скрипт по управлению версионностью сервисов - это первая часть решения. Как было упомянуто раньше, конфигурация сервисов хранится в git, конфиг flux. Чтобы задеплоить сервис с нужной версией, необходимо отредактировать файл соответствующего сервиса в этом репозитории, закоммитить и запушить.

Скрипт использует особенность flux конфига, а именно kustomization patchesStrategicMerge. Эта стратегия подразумевает, что нижняя структура переопределяет настройки верхней. Для этого был создан файл “ci.yaml” в директории, где располагаются настройки сервисов для конкретного неймспейса. Чтобы это файл считался самым нижним и имел финальный приоритет настроек, необходимо прописать его в “kustomization.yaml”.

apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
namespace: psp
resources:
 - ../../base/cards/psp-driver1
 - ../../base/psp/psp-driver2


patchesStrategicMerge:
 - psp-driver1.yaml
 - psp-driver2.yaml
 

 # Autotest automation, must be the last one in patches list
 - ci.yaml

После мы определили формат шаблона настроек, который будет записываться в файл “ci.yaml”.

KUSTOMIZATION_TEMPLATE = """
apiVersion: helm.toolkit.fluxcd.io/v2beta1
kind: HelmRelease
metadata:
  name: {name}
spec:
  values:
    image:
      tag: {tag}
    env:
      X_UPDATE: {serial}
"""

Элементы, которые вставляются в этот шаблон при записи:

• Name - это имя сервиса, к которому будет применяться данные настройки 

• Tag - это тэг или имя ветки, на которую нужно будет задеплоить сервис 

• X_UPDATE: {serial} - это переменная окружения, в которую записывается случайный набор цифр. Она не влияет на работу сервиса, но помогает в его деплое. 

Еще одна особенность работы flux, в том, что если он видит, что новые настройки не отличаются от предыдущих, то сервис не будет обновлен. В итоге, X_UPDATE, со случайным набор цифр, делает принудительную разницу в настройках и “заставляет” kubernetes задеплоить сервис на нужную ветку. Это дает нам возможность подгрузить свежую версию текущей ветки, если сервис давно не редеплоился.

В итоге, скрипт на вход получает список сервисов и тэг(ветку). Заполняет и записывает шаблон для каждого сервиса в файл “ci.yaml”. 

Но мало просто запушить настройки, нужно еще понять когда они применились. Поэтому в скрипте была реализована работа с API kubernetes, которая получает список сервисов и ожидает когда они перезагрузятся и будут готовы.

Откат изменений тоже происходит через этот скрипт. Тут все гораздо проще. Скрипт очищает файл “ci.yaml” и ждет когда список сервисов перезагрузится и будут готовы к работе. Когда “ci.yaml” очищается , то применяются те настройки, которые прописаны в верхних файлах, тем самым, после тестового прогона, можно спокойно продолжить работу, без необходимости возвращать сервис, например, c основной на свою dev-ветку руками.

Полный скрипт деплоя

Вторая часть решения - это Gitlab pipeline. Он был реализован в репозитории с тестами.

Полный шаблон деплой джобыTest pipeline

Полный шаблон деплой джобы

.gitops_tests_deploy:
  timeout: 40m
  image: $CONTAINER_RELEASE_IMAGE
  variables:
    # required variables (aka arguments)
    _NAMESPACE: ''
    _DRIVERS: ''
    _TAG: ''
    _DEPLOY_JOB_NAME: ''
  before_script:
    # use before_script to add behavior
  script:
    - !reference [.enable_debug, script]

    # check arguments
    - if [[ -z $_NAMESPACE ]]; then exit 1; fi
    - if [[ -z $_TAG ]]; then exit 1; fi
    - if [[ -z $_DRIVERS ]]; then exit 1; fi
    - if [[ -z $_DEPLOY_JOB_NAME ]]; then exit 1; fi

    - !reference [.setup_update_drivers_variables, script]
    - !reference [.setup_git, script]
    - !reference [.fix_driver_names, script]

    - git clone -b $GITOPS_BRANCH $GITOPS_REPO_URL gitops
    - cd gitops

    - 'echo "Updating drivers: $_DRIVERS"'

    - $SCRIPTS_DIR/update-drivers.py update "$_NAMESPACE"
            --tag "$_TAG"
            --drivers "$_DRIVERS"
            --env "$UPDATE_DRIVERS_ARG_ENV"
    - git add apps && git commit -m "[AUTOTEST] [$_NAMESPACE] Update $_DRIVERS to $_TAG"
    - git pull origin $GITOPS_BRANCH --rebase
    - |
      for try in $(seq 1 5); do
        if git push origin $GITOPS_BRANCH; then
          break
        else
          git pull origin $GITOPS_BRANCH --rebase
        fi
      done
    - $SCRIPTS_DIR/update-drivers.py wait "$_NAMESPACE"
        --tag "$_TAG"
        --drivers "$_DRIVERS"
        --env "$UPDATE_DRIVERS_ARG_ENV"
    - echo "$_DEPLOY_JOB_NAME=1" >> $CI_PROJECT_DIR/build.env
  artifacts:
    expire_in: 1 days
    reports:
      dotenv: build.env

- git clone -b $GITOPS_BRANCH $GITOPS_REPO_URL gitops
    - cd gitops

    - 'echo "Updating drivers: $_DRIVERS"'

    - $SCRIPTS_DIR/update-drivers.py update "$_NAMESPACE"
            --tag "$_TAG"
            --drivers "$_DRIVERS"
            --env "$UPDATE_DRIVERS_ARG_ENV"
    - git add apps && git commit -m "[AUTOTEST] [$_NAMESPACE] Update $_DRIVERS to $_TAG"
    - git pull origin $GITOPS_BRANCH --rebase
    - |
      for try in $(seq 1 5); do
        if git push origin $GITOPS_BRANCH; then
          break
        else
          git pull origin $GITOPS_BRANCH --rebase
        fi

В шаблоне идет скачивание GitOps репозитория, вызов скрипта по деплою. В шаблон на вход подаем:

• NAMESPACE - содержит имя директории в структуре Gitops репозитория. Так как мок и сервисы лежат в разных “директориях”, тем самым мы указываем в какой именно “ci.yaml” нужно внести изменения

• TAG - тэг или имя ветки, на которую нужно задеплоить сервис

• DRIVERS - это список драйверов\сервисов. DRIVERS может в себе содержать как имя одного сервиса, так и список, также может содержать значение “all”, тогда скрипт считывает из Gitops репозитория имена всех сервисов и подает их на вход функции деплоя

Скрипту подается команда "update", по которой он обновляет “ci.yaml” файл. Далее, джоба пытается пушнуть изменения в репозиторий. Потом скрипту подается команда “wait” с аналогичным набором аргументов, и он ждем когда все сервисы задеплояться и будут готовы к тестированию.

Этот шаблон применяется для джоб по деплою сервисов и мока. Отличие только в списке имени сервиса(ов), имени ветки и NAMESPACE, так как мок лежит отдельно от основных сервисов.

Пример ввыода джобы деплоя

...
Skipping Git submodules setup
Executing "step_script" stage of the job script
02:08
$ if ! docker info &> /dev/null ;then echo non_docker_environment ; else mkdir -p /root/.docker/; echo $DOCKER_AUTH_CONFIG > /root/.docker/config.json; docker login ; fi
non_docker_environment
$ if [[ -n "$ARG_TEST_SCOPE" ]]; then # collapsed multi-line command
$ if [[ "$ENABLE_DEBUG" == 1 ]]; then set -x; env; fi
$ if [[ -z $_NAMESPACE ]]; then exit 1; fi
$ if [[ -z $_TAG ]]; then exit 1; fi
$ if [[ -z $_DRIVERS ]]; then exit 1; fi
$ if [[ -z $_DEPLOY_JOB_NAME ]]; then exit 1; fi
$ [[ "$CLUSTER" == "gt-stage" ]] && export UPDATE_DRIVERS_ARG_ENV="gt-stage-rke"
$ git config --global user.email "<>"
$ git config --global user.name $GITOPS_GIT_NAME
$ _DRIVERS=$($SCRIPTS_DIR/translate_drivers_names.py "$FIX_DRIVER_NAME" "$_DRIVERS")
$ git clone -b $GITOPS_BRANCH $GITOPS_REPO_URL gitops
Cloning into 'gitops'...
$ cd gitops
$ echo "Updating drivers: $_DRIVERS"
Updating drivers: driver1
$ $SCRIPTS_DIR/update-drivers.py update "$_NAMESPACE" --tag "$_TAG" --drivers "$_DRIVERS" --env "$UPDATE_DRIVERS_ARG_ENV"
$ git add apps && git commit -m "[AUTOTEST] [$_NAMESPACE] Update $_DRIVERS to $_TAG"
[develop fbea0174a] [AUTOTEST] [psp] Update friver1 to master
 1 file changed, 11 insertions(+)
$ git pull origin $GITOPS_BRANCH --rebase
From https://git.ops.gt.env/devops/platform/gitops
 * branch                develop    -> FETCH_HEAD
Current branch develop is up to date.
$ for try in $(seq 1 5); do # collapsed multi-line command
remote: 
remote: To create a merge request for develop, visit:        
remote:   https://git.ops.gt.env/devops/platform/gitops/-/merge_requests/new?merge_request%5Bsource_branch%5D=develop        
remote: 
To https://git.ops.gt.env/devops/platform/gitops.git
   c16e890fb..fbea0174a  develop -> develop
$ $SCRIPTS_DIR/update-drivers.py wait "$_NAMESPACE" --tag "$_TAG" --drivers "$_DRIVERS" --env "$UPDATE_DRIVERS_ARG_ENV"
INFO:update-drivers:waiting for kustomization to apply using k8s API
INFO:update-drivers:waiting for 1 driver(s):
psp-driver1
INFO:update-drivers:[1/1] psp/psp-driver1 has been updated to master
INFO:update-drivers:All drivers have been updated successfully
$ echo "$_DEPLOY_JOB_NAME=1" >> $CI_PROJECT_DIR/build.env
Uploading artifacts for successful job
00:01
Uploading artifacts...
build.env: found 1 matching files and directories  
Uploading artifacts as "dotenv" to coordinator... ok  id=10567162 responseStatus=201 Created token=64_WEHMH
Cleaning up project directory and file based variables
00:01
Job succeeded

Далее идет вызов джобы тестов.

 - |
      if [[ -n "$ARG_TEST_SCOPE" ]]; then
        export PYTEST_TEST_ARGS="-m $ARG_TEST_SCOPE"
        if [[ "$IS_CUSTOM_MARKER" == 1 ]]; then
          export PYTEST_TEST_ARGS=$PSP_MARKER
        fi
      else
        ARG_DRIVERS=$($SCRIPTS_DIR/translate_drivers_names.py "$FIX_DRIVER_NAME" "$ARG_DRIVERS")
        export PYTEST_TEST_ARGS=$($SCRIPTS_DIR/translate_drivers_names.py "$DRIVER_NAME_TO_TEST_PATH" "$ARG_DRIVERS")
        if [ -z "$PYTEST_TEST_ARGS" ]; then
          export PYTEST_TEST_ARGS=$PSP_MARKER
        fi
      fi

    - cd "$PSP_TEST_PATH"
    - 'echo "pytest arguments: $PSP_TEST_ARGS $PYTEST_TEST_ARGS"'

    - echo "Selenium URL $SELENIUM_EXECUTABLE_PATH"
    - >
      if [[ -n "${SLACK_WEBHOOK}" ]];
      then
        $SCRIPTS_DIR/slack.sh
      else
        echo "WARN: SLACK_WEBHOOK variables is not set";
        echo "WARN: Slack notifications are disabled";
      fi

      if [[ "$ENABLE_ALLURE" == 1 ]]; then
        echo 'Running tests with upload an allure report to Allure TestOps'
        /allurectl watch -- $(which pytest) \
          --slack_hook=${SLACK_WEBHOOK} \
          --slack_username="Testing results" \
          --slack_report_link=${CI_JOB_URL} \
          --alluredir=$ALLURE_RESULTS \
        $PSP_TEST_ARGS $PYTEST_TEST_ARGS
        
      else
        echo 'Running tests with pytest save N allure repost to artifacts'
        pytest $PSP_TEST_ARGS $PYTEST_TEST_ARGS --alluredir=$ALLURE_RESULTS
      fi

В начале идет работа по определению маркера, с которым будут запускаться тесты. В зависимости от scope будет выбран соответствующий маркер для smoke или regress тестов. Далее, вызывается скрипт по определению директорий тестов, который сопоставляет имена драйверов с папками с тестами. В итоге, нужный маркер и список директорий подаются на вход pytest и начинается прогон тестов.

 Шаблон revert джоб

- git clone -b $GITOPS_BRANCH $GITOPS_REPO_URL gitops
    - cd gitops

    - $SCRIPTS_DIR/update-drivers.py revert "$_NAMESPACE"
            --env "$UPDATE_DRIVERS_ARG_ENV"
    - git add apps && git commit -m "[AUTOTEST] [$_NAMESPACE] Revert $_DRIVERS"
    - git pull origin $GITOPS_BRANCH --rebase
    - |
      for try in $(seq 1 5); do
        if git push origin $GITOPS_BRANCH; then
          break
        else
          git pull origin $GITOPS_BRANCH --rebase
        fi
      done
    - $SCRIPTS_DIR/update-drivers.py wait "$_NAMESPACE"
        --tag "$TAG_ANY_VERSION"
        --drivers "$_DRIVERS"
        --env "$UPDATE_DRIVERS_ARG_ENV"

Этот шаблон, очень похож на шаблон деплоя. Так же идет скачивание GitOps репозитория. На втором шаге происходит вызов скрипта с командой  “revert” и переменными, которые имеют те же значения что и в шаблоне деплоя. Скрипт очищает “ci.yaml” в соответствующем NAMESPACE. Далее, идет пуш изменений в репозиторий и ожидание, когда список сервисов обновится. На этом этапе вместо ветки, передается значение “any”, которая говорит скрипту, что нужно дождаться только деплоя сервиса и не проверять его ветку. Так же, как и шаблон деплоя, шаблон отката используется для основных сервисов и мока и отличается только входными переменными.

В итоге получился pipeline, который деплоит нужную ветку на тестируемые сервисы и нужную версию мока, прогоняет тесты только нужных сервисов, и откатывает тестируемую ветку. Вызов этого pipeline был добавлен в Schedules, тем самым прогон smoke и regress тестов идет через него.

Последняя часть решения - Slack bot. Это сервис, который располагается в нашем же окружении. Он реализует интерфейс и принимает на вход все необходимые переменные: список сервисов и их ветки, мок и его ветка и ветка тестов.

Меню с выбором ветки драйвера и скоупом запуска

В бота были добавлены функции-помощники, которые помогают не держать в голове правильные имена сервисов и веток. Бот с периодичностью выкачивает необходимые репозитории, чтобы обновить список сервисов и доступных веток.

Пример подсказки имен драйверов

Все опции интерфейса Slack бота

Пример выбора скоупа тестового прогона

Другие опции по выбору ветки тестов и мок сервиса

Итоги

В результате реализации решения, мы смогли повысить стабильность ежедневных и еженедельных прогонов. Так как перед запуском тестов, все сервисы деплоятся на основную ветку, берется основная ветка мока и тестов. Тем самым мы получаем меньше ложных падений из-за того, что сервис был на dev ветке. Плюс, мы не прерываем разработку, так как разработчику не нужно возвращаться на свою ветку обратно после ночного прогона, он может спокойно продолжить разработку и тестирование.

Еще один плюс который был получен, это легкий способ запуска тестов. Разработчику теперь не нужно идти в репозиторий тестов и gitops, все настраивать и запускать CI через GitLab. Теперь достаточно просто в боте указать нужные сервисы, ветки и получить результат тестов. Это повысило количество запускаемых тестов, качество выпускаемых сервисов, скорость тестирования, а самое главное разработчики смело делают рефакторинги, большие изменения в нескольких сервисах или в базовой логике, так как знают что смогут легко прогнать автотесты и отловить ошибки.

И неожиданный бонус, который был обнаружен. Нам пришлось актуализировать некоторые тесты. Дело в том, что у нас есть “старые” сервисы, которые  давно не обновлялись в дев окружении. Это связанно с тем, что  в код этих сервисах давно не вносились изменения, так как все баги и проблемы были исправлены уже давно. Но после запуска скрипта, была подтянута свежая версия основной ветки и наши тесты посыпались. Как оказалось, базовая логика под этими сервисами давно была изменена, а наши тесты нет. Как результат, после принудительного обновления сервисов, тесты и сервисы разъехались. Получается, что еженедельное обновление всех сервисов, теперь помогает нам держать тесты в актуальном состоянии.

Но в нашем решении есть пару недостатков: 

Во-первых, данное решение не подойдет для сложных сервисов, в которых есть взаимная зависимость или зависимость от миграций БД и т.д. Всем этим сложно управлять в рамках такого небольшого и простого скрипта. Такие сервисы мы деплоим и откатываем по старому.

Второй минус, это невозможность параллельной работы. Тут есть несколько блокеров. Первый - это реверт скрипт, который очищает полностью файл “ci.yaml”, что ломает соседний прогон. Второй момент, вероятность пересечения сервисов, не до конца понятно как и в какой момент это разруливать. Но думаю, что это решаемые проблемы и когда это будет нас замедлять в выпуске сервисов, то мы займемся ими.

Реализовал все это решение Александр Скурихин. Спасибо за ревью статьи Александр Скурихину и Владиславу Александрову