Ответ
Автоматический запуск пайплайна в CI/CD инициируется определенными событиями в системе контроля версий (VCS). С точки зрения QA, это триггеры для запуска набора автоматических тестов. Основные события:
- Push в ветку (например,
main,develop,feature/*) – самый частый триггер для запуска smoke, регрессионных и интеграционных тестов. - Создание или обновление Pull Request (PR) / Merge Request (MR) – критично для запуска проверок перед слиянием кода. Обычно запускаются модульные, линтеры и быстрые интеграционные тесты.
- По расписанию (cron) – для запуска длительных тестов (нагрузочных, security, полного регресса), которые нецелесообразно запускать на каждый коммит.
- Ручной запуск через UI CI/CD – для специфичных сценариев, например, запуск тестов на определенном окружении.
- Webhook из внешней системы – например, запуск тестов после деплоя на staging-окружение.
Пример конфигурации .gitlab-ci.yml для запуска тестов на push и в MR:
stages:
- test
- deploy
# Запускается при push в main или при любом MR
run_api_tests:
stage: test
script:
- echo "Запуск API-тестов..."
- pytest tests/api/ --junitxml=report.xml
artifacts:
when: always
reports:
junit: report.xml
only:
- main
- merge_requests
# Запускается по расписанию (каждую ночь)
run_performance_tests:
stage: test
script:
- echo "Запуск нагрузочных тестов..."
- locust -f performance_tests/locustfile.py --headless -u 100 -r 10 --run-time 1h
only:
- schedules # Специальное ключевое слово для scheduled pipelinesДля QA важно правильно настраивать эти триггеры, чтобы балансировать между скоростью обратной связи и стабильностью основного кода.
Ответ 18+ 🔞
Слушай, история-то вообще простая, как три копейки. Представь, у тебя есть эта ваша CI/CD система — такая штука, которая сама всё делает, пока ты кофе пьёшь. Так вот, она не просто так просыпается и начинает тесты гонять. Её кто-то должен пнуть, событием таким. С точки зрения тестировщика, это как триггер: событие → бабах → поехали проверки.
Основные пинки, от которых она заводится:
- Пуш в ветку (ну, в
main,developили какую-то фичевую) — это самый частый повод охуеть от количества работы. На каждый такой пуш обычно запускаются дымовые тесты, регресс какой-то и интеграция. Чтобы не сломалось то, что уже работало. - Создание или обновление Pull/Merge Request — вот это, блядь, святое! Прежде чем чей-то код вольётся в основную ветку, его надо проверить. Тут запускают модульные тесты, линтеры (чтоб код красивый был) и быстрые интеграционные проверки. Без этого — ни шагу, иначе потом разгребать ебаторий.
- Запуск по расписанию (cron) — это для тяжёлой артиллерии. Не будешь же на каждый чих нагрузочные тесты гонять или полный регресс на овердохуища сценариев. Их ставят на ночь, например. Пусть машины потеют.
- Ручной запуск через интерфейс — когда нужно что-то специфичное проверить. Скажем, запустить тесты на конкретном стенде, который только сегодня подняли.
- Вебхук из внешней системы — типа нам извне сигнальчик: "эй, на стейджинг всё залилось, можно тесты начинать". Удобно, когда процессы сложные.
Вот смотри, как это в конфиге для GitLab выглядит, чтоб ты понимал масштаб:
stages:
- test
- deploy
# Сработает при пуше в main ИЛИ при любом Merge Request
run_api_tests:
stage: test
script:
- echo "Запуск API-тестов..."
- pytest tests/api/ --junitxml=report.xml
artifacts:
when: always
reports:
junit: report.xml
only:
- main
- merge_requests
# А эта штука будет работать только по расписанию (например, каждую ночь)
run_performance_tests:
stage: test
script:
- echo "Запуск нагрузочных тестов..."
- locust -f performance_tests/locustfile.py --headless -u 100 -r 10 --run-time 1h
only:
- schedules # Это спец. слово как раз для крон-заданийЗадача QA — правильно эти триггеры настроить, ёпта. Чтобы и обратная связь была быстрой, и основная ветка не превращалась в помойку из-за каждого второго коммита. Баланс, блядь, нужен. Иначе будет тебе хиросима, а не пайплайн.