Как происходила раскатка с использованием Jenkins или GitLab CI?

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

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

Как отвечать

Опишите реальный пайплайн своего проекта по стадиям. Для Java-сервиса типичный каркас такой:

• сборка и тесты: mvn verify или ./gradlew build, модульные и интеграционные тесты (часто на Testcontainers), статический анализ в SonarQube;
• артефакт: Docker-образ через Dockerfile или Jib, тег по SHA коммита, публикация в registry. Образ собирается один раз и продвигается по окружениям без пересборки;
• деплой: dev автоматически, stage и prod через ручное подтверждение. В GitLab CI это when: manual и блок environment, в Jenkins шаг input в декларативном Jenkinsfile. Сама выкладка через Helm, ArgoCD или Ansible на виртуальные машины;
• стратегия: rolling update в Kubernetes с readiness-пробой на /actuator/health/readiness, чтобы трафик шёл только на поднявшиеся поды, а для рискованных релизов canary или blue-green;
• миграции: Flyway или Liquibase, изменения схемы обратно совместимы с предыдущей версией кода;
• секреты: маскированные переменные CI или Vault, но не репозиторий;
• откат: повторный деплой предыдущего тега или helm rollback.

Если пайплайн настраивали не вы, так и скажите и расскажите, какие стадии знаете и что меняли сами: добавляли тесты, чинили упавшую сборку, писали миграцию. Это честнее выдуманной роли автора.

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

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

Не могут объяснить откат. «Откатим» без понимания, что делать с уже применённой миграцией, звучит как отсутствие плана.

Путают Jenkins и GitLab CI в деталях: Jenkinsfile против .gitlab-ci.yml, агенты против раннеров. Если работали с одним, скажите это прямо, а про второй дайте общую картину.