Почему стандартные расписания в CI — это боль
Личный опыт: Признаюсь честно: я не фанат расписаний в CI. История запусков по таймеру часто превращается в:
- Ночные падения тестов - “Кто сломал билд в 3:00?”
- Проблемы окружения - “Это баг или тестовая среда упала?”
- Ресурсные ограничения - “Почему всё падает при параллельном запуске?”
Решение: Два уровня мониторинга Playwright
1. Часовой health-check (термометр системы)
# .gitlab-ci.yml
hourly_healthcheck:
script:
- echo "Запуск @health тестов Playwright"
- npx playwright test --grep "@health"
only:
variables:
- $TEST_MODE == "HEARTBEAT"
2. Полночный аудит (генеральная уборка)
# .gitlab-ci.yml
midnight_audit:
script:
- echo "Полный аудит через Playwright"
- npx playwright test --grep "@audit"
only:
variables:
- $TEST_MODE == "FULL_SCAN"
3. Настройка расписания в GitLab CI
Создаем новый schedule. Перейдите: CI/CD → Schedules. Нажмите New schedule.
Для hourly-тестов:
Cron: 0 * * * *
Переменные: TEST_MODE=HEARTBEAT
Для nightly-тестов:
Cron: 0 0 * * *
Переменные: TEST_MODE=FULL_SCAN
Для настройки cron-выражений (см. официальную документацию GitLab).
Для настройки cron-тегов (см. официальную документацию Playwright).
Почему это работает?
- Гибкость: - Разделение тестов по критичности и времени выполнения
- Контроль: - Четкое разграничение через переменные окружения
- Экономия ресурсов: - Тяжелые тесты только ночью
Важные предупреждения
- Логируйте ВСЁ (иначе ночные падения останутся загадкой)
- Настройте алерты (например, в Telegram, если упало)
- Помните: хрупкие тесты + расписание = ложные срабатывания
Тестирование — это диалог, а не монолог
Ваше тестовое окружение не нестабильно — оно просто живёт своей жизнью. Настройте мониторинг по этому руководству, и вы получите:
✅ Раннее обнаружение багов — ловите ошибки до попадания в прод ✅ Спокойные ночи — больше не просыпайтесь от алертов в 3:00 ✅ Экспертный уровень — автоматизация на Playwright станет вашей визитной карточкой