В какой момент pipeline происходят тесты в GitLab CI

Жизненный цикл тестирования в GitLab CI/CD Pipeline

В GitLab CI/CD нет единственного "момента" для тестов — тестирование является распределённым процессом, который интегрирован на различных стадиях pipeline в соответствии с принципами непрерывной интеграции (CI) и непрерывного развёртывания/доставки (CD). Конкретное размещение тестов определяется структурой файла .gitlab-ci.yml и выбранной стратегией разработки.

Ключевые стадии (Stages) и место тестов в них

Стандартный pipeline организован в последовательные стадии, которые выполняются по порядку. Типичный набор стадий включает:

stages:
  - build
  - test
  - deploy

Тесты традиционно сосредоточены в стадии test, но современные практики DevOps предполагают их выполнение и на других этапах:

1. Раннее тестирование (в стадии build или даже до неё):

   • Статический анализ кода (SAST) — линтеры, анализаторы безопасности (например, ESLint, Bandit, SonarQube)
   • Проверка зависимостей — сканирование уязвимостей в пакетах (например, npm audit, snyk test)

   lint_code:
     stage: build
     script:
       - npm run lint
       - python -m pylint app/
   

2. Основной комплекс тестов (стадия test):

   • Модульные тесты (Unit tests) — быстрые тесты отдельных компонентов
   • Интеграционные тесты — проверка взаимодействия модулей
   • Функциональные/системные тесты — тестирование API или ключевых сценариев

   unit_tests:
     stage: test
     script:
       - npm test
       - pytest tests/unit/ --cov=app
   
   api_tests:
     stage: test
     script:
       - newman run api_tests.json
   

3. Поздние тесты (после стадии deploy или в параллельных окружениях):

   • Приёмочные тесты (Acceptance tests) — в staging-окружении
   • Нагрузочное тестирование (Load testing)
   • Тесты безопасности (DAST) — сканирование развёрнутого приложения
   • Регрессионное тестирование

   e2e_tests:
     stage: deploy
     environment: staging
     script:
       - cypress run
     only:
       - main
   

Стратегии распределения тестов в современном CI/CD

• Параллельное выполнение: Для ускорения pipeline тесты разбиваются на группы и запускаются параллельно с использованием parallel или parallel:matrix

  parallel_tests:
    stage: test
    parallel: 5
    script:
      - ./run_tests_segment.sh $CI_NODE_INDEX $CI_NODE_TOTAL
  

• Многоуровневая воронка тестирования (Testing Pyramid):

  • Быстрые тесты выполняются первыми (линтеры, юнит-тесты)
  • Медленные тесты (E2E, интеграционные) — позже или по условию
  • Критические тесты безопасности — на всех этапах

• Условное выполнение: Тесты могут запускаться по правилам (rules, only/except)

  security_scan:
    stage: test
    script: ["./scan.sh"]
    rules:
      - if: $CI_PIPELINE_SOURCE == "merge_request_event"
  

Особые сценарии GitLab

1. Merge Request Pipelines: Тесты запускаются при создании/обновлении MR для проверки кода перед слиянием
2. Декомпозиция pipeline:
   • Parent-Child Pipelines: Тесты могут быть выделены в отдельный дочерний pipeline
   • Directed Acyclic Graphs (DAG): Позволяют определять сложные зависимости между job
3. Тесты в review-окружениях: Динамические окружения для каждого MR с развёрнутым приложением и полным циклом тестирования

Практические рекомендации по организации тестов

• Принцип раннего обнаружения ошибок: Самые быстрые и критичные проверки должны выполняться первыми
• Оптимизация времени выполнения: Кэширование зависимостей, артефактов между job
• Последовательность стадий: test → deploy:staging → e2e_tests → deploy:production
• Интеллектуальные триггеры: Запуск тяжёлых тестов только при изменениях в relevant-модулях

Итоговый ответ: Тесты в GitLab CI происходят на протяжении всего pipeline, но их основная концентрация приходится на стадию test. Современные практики предполагают распределённое тестирование — от статического анализа на ранних этапах до acceptance-тестов в staging-окружении. Ключевой принцип: быстрые тесты выполняются раньше медленных, а критичные проверки — перед менее важными, что минимизирует время обратной связи и снижает стоимость исправления дефектов. Конфигурация .gitlab-ci.yml позволяет гибко настраивать это распределение в соответствии с потребностями проекта и зрелостью процессов DevOps.