В чем разница Jenkins и GitLab CI

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

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

Как отвечать

Главное различие в модели:

• Jenkins: отдельный self-hosted сервер на Java, контроллер и агенты. С репозиторием связан через плагины и вебхуки, работает с любым Git-хостингом. Пайплайн описывается в Jenkinsfile на Groovy, декларативным или скриптовым синтаксисом. Почти всё, от отчётов до агентов в Kubernetes, добавляется плагинами, и их обновление это отдельная работа;
• GitLab CI: часть GitLab. Конфигурация лежит в .gitlab-ci.yml в корне репозитория, задачи выполняют раннеры с исполнителями docker, shell, kubernetes. Код, merge request, пайплайн и отчёты в одном интерфейсе.

Для QA важны конкретные механизмы:

• запуск: в GitLab CI через rules на merge request, по расписанию или вручную, в Jenkins через триггеры и параметризованные сборки с выбором стенда и браузера;
• параллельность: parallel:matrix и needs в GitLab, блок parallel в стадиях Jenkinsfile;
• отчёты: в GitLab artifacts:reports:junit показывает упавшие тесты прямо в merge request, Allure публикуют артефактом или через Pages. В Jenkins шаг junit и плагин Allure;
• окружение: services в GitLab CI для базы или браузера, в Jenkins Docker-агенты или Selenium Grid.

Итог: GitLab CI удобнее, когда код уже в GitLab и нужен быстрый старт, Jenkins выигрывает гибкостью в разнородной инфраструктуре и сложной оркестрации. Добавьте, с чем работали сами и какой пайплайн настраивали.

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

Говорят, что GitLab CI «почти не настраивается». На нём строят сложные пайплайны с матрицами, дочерними пайплайнами и зависимостями между проектами.

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

Лечат нестабильные тесты через retry: 2 и считают задачу закрытой. Ретрай прячет проблему: флаки нужно помечать, собирать по ним статистику и чинить.