Какой опыт с DevOps?

Что проверяют

Понимаете ли вы, как ваши тесты живут в конвейере поставки, и можете ли сами поправить пайплайн, а не ждать DevOps-инженера. Следом спрашивают, что происходит, когда тесты в CI падают, и как вы боретесь с нестабильными тестами.

Как отвечать

Говорите о своей зоне: тестирование внутри CI/CD. Каркас с опорой на опыт:

• пайплайн: где запускаются ваши тесты (GitLab CI, GitHub Actions, Jenkins), на каком событии (merge request, ночной прогон, деплой на стенд), что блокирует слияние;
• окружения: тестовый стенд в Docker, зависимости через docker compose или Testcontainers, стенд на ветку, если он был;
• скорость: параллельный запуск, шардирование UI-тестов, деление на быстрый smoke и полный регресс;
• отчёты и сигналы: Allure или JUnit XML в артефактах, уведомление в чат, карантин для нестабильных тестов с задачей на починку;
• эксплуатация: умение посмотреть логи сервиса (kubectl logs, Grafana, Kibana), чтобы понять, баг это или упавший стенд.

Назовите цифры своего проекта: сколько длился прогон до и после, сколько тестов в smoke. Если опыт скромный, например вы запускали тесты в готовом пайплайне и правили пару строк в .gitlab-ci.yml, так и скажите, и добавьте, в чём разобрались сами: как собирается образ, откуда тесты берут переменные окружения.

Где спотыкаются

Сводят DevOps к Jenkins. Это культура и набор практик: автоматизация, быстрая обратная связь, общая ответственность за прод, а инструмент вторичен.

Путают CI и CD. Непрерывная интеграция это сборка и тесты на каждое изменение, доставка и развёртывание это автоматическая выкладка, и у тестов в них разные роли.

Лечат нестабильные тесты автоматическим перезапуском. Флак остаётся, пайплайн удлиняется, а настоящие баги гонки проходят под видом «опять моргнуло».