В какой момент происходит автоматический запуск Pipeline в CI/CD?

«В какой момент происходит автоматический запуск Pipeline в CI/CD?» — вопрос из категории CI/CD и DevOps, который задают на 24% собеседований AQA / Automation. Ниже — развёрнутый ответ с разбором ключевых моментов.

Ответ

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