Вопросы на собеседовании: CI/CD

Из каких jobs и зависимостей ты соберёшь базовый CI/CD pipeline для сервиса и почему не стоит превращать его в одну длинную команду?

как ответить Я разделю проверку формата и типов, сборку, тесты, упаковку и deploy на jobs с явными зависимостями. Независимые проверки запущу параллельно, а выпуск разрешу только после обязательных gates. Такое разбиение быстрее даёт обратную связь и показывает, на каком шаге и с какими входами произошёл сбой.

Чем artifact отличается от cache в CI? Что здесь должно пережить cache miss, а что обязано передаваться как результат сборки?

cache:
  key:
    files:
      - pnpm-lock.yaml
  paths:
    - .pnpm-store/

build:
  script:
    - pnpm install --frozen-lockfile
    - pnpm build
  artifacts:
    paths:
      - dist/

как ответить Cache ускоряет повторное получение зависимостей или промежуточных файлов, но job обязан корректно работать и при промахе cache. Artifact — результат конкретной job: бинарник, пакет, отчёт или каталог сборки, который скачивает следующая job либо пользователь. В примере .pnpm-store/ — cache, а dist/ — artifact этого build.

Один и тот же commit собрали дважды и получили разные container images. Что проверишь, чтобы сборка стала воспроизводимой?

как ответить Сначала фиксирую все входы: commit, lock-файлы, toolchain, base image по digest, build arguments и архитектуру runner. Сборка должна идти в чистом окружении без неявного сетевого или локального состояния. Затем ищу источники недетерминизма — время, случайный порядок файлов, плавающие версии и генерируемые метаданные.

Какие проверки должны блокировать merge и deploy, а какие можно запускать позже? Как не превратить test gate в формальность?

как ответить Merge блокируют быстрые и надёжные проверки, без которых commit заведомо нельзя считать пригодным: сборка, типы, lint и критичные тесты. Перед deploy добавляют проверки, зависящие от готового artifact и environment, например integration, security policy и smoke tests. Нестабильный тест нельзя просто пометить необязательным: его чинят или временно изолируют с владельцем и сроком возврата.

Как передавать секреты в CI/CD и почему маскирование значения в логах не считается границей безопасности?

как ответить Секрет храню в secret store CI или внешнем менеджере и выдаю только job, которой он нужен, с минимальными правами и областью environment. Маскирование защищает от случайного вывода известной строки, но привилегированный или скомпрометированный шаг может преобразовать и отправить секрет наружу. Поэтому недоверенный код не запускают на runner с production credentials.

Релиз сломал прод. Что должен заранее подготовить pipeline для быстрого rollback и почему нельзя просто пересобрать старый commit?

как ответить Pipeline должен хранить неизменяемый artifact каждого релиза, его digest, конфигурацию и историю deployment. Rollback повторно продвигает уже проверенный предыдущий artifact, а не пересобирает commit с потенциально новыми зависимостями и base images. Перед откатом проверяю совместимость со схемой данных, конфигурацией и внешними контрактами.

Как выпустить несовместимое изменение схемы базы без простоя, если во время rollout одновременно работают старая и новая версии приложения?

как ответить Использую expand-and-contract: сначала добавляю совместимую схему, затем выпускаю код, который умеет работать в переходном состоянии, переношу данные и только после этого удаляю старое поле отдельным релизом. Миграция запускается один раз из сериализованной job и наблюдается отдельно. Откат кода остаётся возможным, пока contract-шаг не убрал старый контракт.

Чем canary deployment отличается от blue-green и по каким сигналам ты будешь продвигать или останавливать новую версию?

как ответить Canary постепенно отдаёт новой версии ограниченную долю реального трафика и уменьшает blast radius, но требует корректного разделения трафика и сравнения метрик. Blue-green держит два полноценных окружения и переключает трафик между ними, поэтому cutover и возврат быстрые, но цена по ресурсам выше. Продвижение привязываю к заранее заданным SLO, техническим и бизнес-метрикам, а не только к тому, что процесс запустился.

Как устроить production gate так, чтобы одобрение действительно ограничивало риск, а не было кнопкой «пропустить дальше»?

как ответить Production оформляю как защищённый environment: разрешённые ветки и субъекты, обязательные проверки, при необходимости независимый reviewer и отдельные secrets. Одобряется конкретный commit и artifact после просмотра diff, test evidence и плана изменения. Инициатор не должен автоматически одобрять собственный опасный deploy, если процесс требует разделения обязанностей.

Два pipeline почти одновременно деплоят разные commit в один production environment. Какие гонки возможны и как их убрать?

как ответить Старый pipeline может закончить позже нового и затереть production более ранней версией; параллельные миграции и изменения конфигурации могут конфликтовать ещё опаснее. Для общего environment сериализую deployment через concurrency group или resource lock и запрещаю устаревшему commit продвигаться поверх нового. Сам deploy делаю идемпотентным и сверяю ожидаемую текущую версию.

Полный CI монорепозитория идёт полтора часа. Как безопасно запускать только affected-проекты и не пропустить поломку зависимого сервиса?

как ответить Changed files сопоставляю с проектами, затем по dependency graph добавляю все обратные зависимости, чьи build или tests могут измениться. Диапазон diff считаю от корректной базы до проверяемого head, а root lock-файл, общие конфиги и генераторы могут расширить набор вплоть до всего репозитория. Cache остаётся только оптимизацией, а merge queue и периодический full pipeline страхуют ошибки модели affected.

Почему OIDC для cloud deploy безопаснее постоянного ключа и какие границы доверия всё равно нужно настроить в CI?

permissions:
  contents: read
  id-token: write

как ответить OIDC позволяет job обменять подписанное утверждение о своей identity на короткоживущий cloud token, поэтому постоянный cloud key не хранится в CI. id-token: write только разрешает запрос OIDC-токена и само по себе не выдаёт доступ к облаку. Cloud trust policy обязана проверить issuer, audience и claims, ограничивающие repository, ref, workflow или защищённый environment.