Ответ
Автоматический запуск пайплайна в 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 важно правильно настраивать эти триггеры, чтобы балансировать между скоростью обратной связи и стабильностью основного кода.