Какой опыт работы в системах непрерывной интеграции

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

Настраивали ли вы конвейер сами или только смотрели на красные прогоны. Ответ показывает, насколько вы автономны: сможете ли добавить стадию, разобрать падение и не сломать чужой пайплайн. Следом спрашивают про нестабильные тесты и про то, сколько идёт полный прогон.

Как отвечать

Говорите про конкретную систему и свой конвейер:

• инструмент: GitHub Actions, GitLab CI, Jenkins, TeamCity. Называйте тот, где реально писали конфиг, и скажите какой: .github/workflows/*.yml, .gitlab-ci.yml, Jenkinsfile;
• триггеры и стадии: пул-реквест и пуш в основную ветку, ночной регресс по расписанию. Стадии линтер, юнит-тесты, сборка, интеграционные, сквозные, выкатка на стенд;
• окружение: образ с зависимостями, Testcontainers для базы и очереди, сиды тестовых данных, отдельная схема на прогон, чтобы параллельные джобы не мешали друг другу;
• скорость: кэш зависимостей, матричная стратегия, разбиение прогона на части (--shard в Playwright, pytest-xdist), дымовой набор на пул-реквест и полный регресс ночью;
• результаты: отчёты в формате JUnit XML и Allure, скриншоты, видео и трассировки для упавших, обязательные проверки, блокирующие мерж, уведомления в мессенджер;
• нестабильные тесты: карантин, точечный повтор только для помеченных, регулярный разбор верхушки падений, а не молчаливое отключение.

Приводите цифры: сколько тестов, сколько минут идёт прогон, какая доля падений оказалась ложной, что вы с этим сделали. Про Travis CI как текущий выбор лучше не говорить, в командах его почти не осталось.

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

Описывают опыт как «запускал сборку кнопкой и смотрел отчёт». Это опыт пользователя CI, а спрашивают про инженерный.

Ставят глобальный повтор на все тесты. Красные прогоны исчезают, реальные дефекты уезжают на прод, доверие к автотестам падает.

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