Настройка CI/CD для frontend: pipeline, preview, quality gates

Введение. CI/CD для Next.js — это не только deploy, а контроль качества на каждом PR с preview для дизайна и SEO. Материал для product- и engineering-лидеров, которые принимают решения на горизонте 12–24 месяцев, а не гонятся за хайпом в презентации.

Что получите на выходе

Большинство срывов в теме «CI/CD для frontend» начинается не с кода, а с размытого scope: маркетинг обещает одно, продажи фиксируют другое, а ИТ закрывает техдолг третьим приоритетом. В итоге бюджет уходит в интеграции «на скотч» и ручные сверки в Excel. Мы видим это в проектах, где не описаны границы MVP, нет владельца метрик и не зафиксированы SLA на данные между системами.

Команды без нормализованного pipeline тратят, по нашим наблюдениям, 20–30% времени на ручные шаги вокруг релиза: собрать билд локально, вручную прогнать регрессию, договориться в чате, кто мержит и когда. Это время не создаёт фичи — оно просто компенсирует отсутствие автоматизации, которую можно один раз настроить и забыть.

Подготовка окружения

Опорный принцип: сначала поток ценности, потом стек. Нарисуйте journey от первого касания до оплаты и поддержки, отметьте ручные шаги и точки отказа. Только после этого выбирайте CI/CD и модель данных. Для CI/CD для frontend мы обычно рекомендуем PR → lint/test/build → preview URL → main → production + smoke: она даёт предсказуемый TCO и не блокирует масштабирование команды.

Зафиксируйте ADR по ключевым решениям: хранилище, очереди, авторизация, наблюдаемость. Включите в Definition of Done контрактные тесты API, схему событий и политику миграций. frontend имеет смысл заказывать только когда есть согласованный backlog с приоритетами P0/P1 и измеримые KPI на квартал.

Наблюдаемость pipeline — это не только зелёная галочка в GitHub Actions, а история: сколько времени занимает каждый шаг, какие тесты флакуют чаще других, где узкое место — install, build или e2e. Без этих данных оптимизация pipeline превращается в интуицию: кто-то «чувствует», что стало медленнее, а цифр для приоритизации нет.

Шаги внедрения

Кейс A (продуктовая команда). Клиент пришёл с болью: ручные регрессии перед релизом. Мы разбили релиз на три волны: стабилизация данных, автоматизация рутины, персонализация. Через 14 недель e2e на критичных путях сократило инциденты на 45%. Критично было не «переписать всё», а остановить утечку лидов на стыке каналов.

Кейс B (агентство). Другая ситуация: много проектов. Здесь сработала обратная стратегия — сначала интеграция с CRM и нормализация справочников, затем редизайн витрины. Итог: шаблон pipeline с matrix снизил время onboarding devops.

Как проверить результат

1. Собирать весь monorepo на каждый PR вместо affected-only builds — pipeline занимает 20 минут ради правки одной страницы.
2. Хранить секреты в переменных репозитория вместо vault — они попадают в форки и логи.
3. Не кэшировать зависимости и build artifacts — каждый запуск начинается с нуля.
4. Пропускать preview-окружения для дизайн-ревью — баги находят уже в проде, а не в PR.
5. Не иметь задокументированного отката за 5 минут — hotfix превращается в ночной созвон с гаданием, что откатывать.

Типичные сбои

• [ ] Падающие тесты воспроизводятся локально, а не только в CI
• [ ] Flaky-тесты помечены и не блокируют merge молча из спринта в спринт
• [ ] Кэш зависимостей инвалидируется при смене lock-файла, а не хранит устаревшие пакеты
• [ ] Секреты в CI не попадают в логи при упавшем шаге
• [ ] Есть алерт в Slack при падении pipeline на main, а не только красная иконка в GitHub
• [ ] Rollback-процедура протестирована хотя бы раз, а не только описана в README

Следующий шаг

Свяжите с design system и visual regression. Если нужна внешняя экспертиза — начните с брифа или оценки: так быстрее получить реалистичный план, чем спорить о стеке в вакууме.

Зафиксируйте в README командный порядок hotfix: кто approves, какой tag, как уведомляется поддержка. Для monorepo добавьте affected-only builds — pipeline не должен собирать весь мир на правку typo в README.

• Кэш зависимостей в CI
• Секреты через vault, не в репо
• Protected branches

Pipeline frontend

CI/CD для frontend: lint → typecheck → unit → build → e2e smoke → deploy preview → production с manual approval или canary. Кэшируйте node_modules и build artifacts. Preview на каждый PR ускоряет review дизайна. Secrets — только в CI vault, не в репозитории. Для Next.js на Vercel часть шагов встроена; self-hosted — GitHub Actions + Docker + nginx.

Включите Lighthouse CI или аналог на критичных URL — регресс perf ловят до merge. Версионируйте env: staging максимально близок к prod. Документируйте, как откатить релиз за 5 минут. Услуга CI/CD имеет смысл, когда команда тратит >4 ч/нед на ручные деплои.

Branch protection: required checks, no direct push main. Dependabot + policy на critical CVE. Artifact signing для production deploy. Уведомления в Slack при failed deploy on main. Раз в квартал — game day: симуляция падения CI и восстановление из backup config. Если команда <5 человек, не усложняйте — один pipeline с preview часто достаточен.

Храните production env в encrypted secrets; diff env staging/prod должен быть осознанным, не «случайно забыли ключ».