Что такое CI/CD pipeline

CI/CD pipeline нужен, чтобы команда не собирала и не выкатывала приложение вручную каждый раз. Он делает процесс повторяемым: один и тот же набор команд запускается в одинаковой среде и дает понятный результат.

Для frontend это не абстрактный DevOps-вопрос. Pipeline ловит ошибки, которые часто не видны в локальной разработке: production build падает из-за переменной окружения, TypeScript не проходит в чистой среде, e2e ломается на критичном пути, bundle внезапно становится тяжелее.

На интервью держите простую структуру: что автоматизируется, где проходит CI, где начинается CD, какой риск это снижает.

Типовой pipeline для веб-приложения может выглядеть так:

# Упрощенный пример GitHub Actions
name: frontend-ci

on:
  pull_request:
  push:
    branches: [main]

jobs:
  checks:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: 22
          cache: npm
      - run: npm ci
      - run: npm run lint
      - run: npm run typecheck
      - run: npm test
      - run: npm run build

Это не универсальный идеал, а понятный минимум. npm ci ставит зависимости по lock-файлу. Линтер ловит часть ошибок качества. Type-check ловит ошибки типов. Тесты проверяют логику. Production build показывает, что приложение реально можно собрать. Для продукта с высокой ценой ошибки сюда добавляют e2e на логин, оплату или оформление заявки, smoke-проверку доступности и budget на размер бандла.

Плохой вариант: запускать только npm run build на сервере после merge и считать это CI/CD. Так вы узнаете о проблеме поздно. Если деплой уже начался, пользователи могут увидеть белый экран, форму без рабочего submit или тяжелый bundle на мобильной сети. Безопаснее проверять pull request до merge, деплоить один собранный артефакт и иметь быстрый rollback.

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

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

CD может означать два похожих, но не одинаковых подхода.

Continuous Delivery значит, что после успешных проверок у вас есть готовый к релизу артефакт. Деплой в production может требовать ручного подтверждения. Это удобно, если бизнес хочет контролировать момент релиза.

Continuous Deployment значит, что успешное прохождение pipeline автоматически выкатывает изменения. Это быстрее, но требует доверия к тестам, мониторинга, алертов и быстрого отката. Иначе автоматизация просто быстрее доставит баг пользователям.

В frontend pipeline стоит думать не только о том, прошли ли тесты. Пользователь получает статические файлы, bundle, HTML, CSS, sourcemaps и конфигурацию окружения. Ошибка в любом из этих мест может выглядеть как белый экран, сломанная авторизация, неверный API endpoint, потерянный фокус после ошибки формы или сильное замедление загрузки.

Хорошая формулировка:

Я бы сказал, что CI/CD для фронтенда должен проверять код до merge, собирать production-артефакт в чистой среде и доставлять его через контролируемый процесс. Важны не только тесты, но и env, секреты, размер бандла, базовая доступность, мониторинг ошибок и возможность откатиться.

Замените детали под свой опыт. Если вы не настраивали деплой сами, можно честно сказать: "Я не был владельцем pipeline, но пользовался им и понимаю, какие проверки для фронтенда важны".

На интервью не нужно перечислять все инструменты подряд. Лучше назвать 2-3 знакомых варианта, например GitHub Actions, GitLab CI, Jenkins, CircleCI, и объяснить принцип. Инструмент меняется, а логика остается: триггер, jobs, проверки, артефакт, деплой, контроль результата.

Хороший ответ показывает, что вы понимаете цель pipeline. Он дает быстрый feedback разработчику, снижает ручные ошибки, делает релиз воспроизводимым и помогает безопаснее доставлять изменения. Но он не заменяет инженерное мышление: плохие тесты, утекшие секреты и отсутствие rollback все равно оставят продукт в зоне риска.