Настройка CI/CD для Next.js: пошаговая инструкция от коммита до продакшена

Next.js, фреймворк для React, предоставляет мощные возможности для рендеринга на стороне сервера (SSR), статической генерации сайтов (SSG) и создания гибридных приложений. Однако его особенности требуют продуманного подхода к настройке конвейера непрерывной интеграции и доставки (CI/CD). В этой статье мы разберем пошаговую инструкцию по построению надежного пайплайна для Next.js-приложения, используя популярные инструменты.

Шаг 1: Подготовка репозитория и определение стратегии.
Все начинается с кода. Организуйте ваш репозиторий (GitHub, GitLab, Bitbucket) с четкой структурой веток. Стандартный подход: `main`/`master` — стабильная ветка для продакшена, `develop` — для интеграции, feature-ветки для новой функциональности. Определитесь со стратегией деплоя: будете ли вы использовать статический экспорт (`next export`) или развертывать полноценное Node.js-приложение для SSR. Это ключевое решение, влияющее на все последующие шаги.

Шаг 2: Настройка скриптов package.json.
Убедитесь, что в вашем `package.json` есть стандартные скрипты для сборки, тестирования и линтинга.
`"scripts": {
 "dev": "next dev",
 "build": "next build",
 "start": "next start",
 "lint": "next lint",
 "test": "jest" // или ваш тестовый раннер
}`
Скрипт `build` для SSR-приложения создаст оптимизированную сборку в папке `.next`. Для статического сайта (`next export`) команда будет выглядеть как `next build && next export`.

Шаг 3: Выбор платформы CI/CD и создание конфигурационного файла.
Мы рассмотрим пример на GitHub Actions как одном из самых популярных решений. В корне репозитория создайте папку `.github/workflows` и файл `ci-cd.yml`.

Шаг 4: Написание стадии Continuous Integration (CI).
Эта стадия запускается при каждом пулл-реквесте в `main` или `develop`. Ее задачи:

• Проверка кода (checkout).
• Установка Node.js и кэширования зависимостей (для ускорения).
• Установка зависимостей (`npm ci` — предпочтительнее `npm install` для CI, так как обеспечивает детерминированность).
• Запуск линтера (`npm run lint`).
• Запуск юнит- и интеграционных тестов (`npm run test`).
• Сборка приложения (`npm run build`). Это критически важно для Next.js, так как команда `build` также выполняет проверку типов TypeScript (если используется) и выявляет ошибки, которые могут не проявиться на стадии линтинга.

Пример фрагмента конфигурации GitHub Actions для стадии CI:
```
jobs:
 ci:
 runs-on: ubuntu-latest
 steps:
 - uses: actions/checkout@v3
 - uses: actions/setup-node@v3
 with:
 node-version: '18'
 cache: 'npm'
 - run: npm ci
 - run: npm run lint
 - run: npm run test
 - run: npm run build
```

Шаг 5: Написание стадии Continuous Deployment (CD).
Эта стадия срабатывает после успешного мерджа в основную ветку (например, `main`). Ее логика зависит от цели деплоя.
Вариант А: Деплой статического сайта (SSG). После сборки и экспорта (`next export`) вы получаете папку `out`. Ее можно задеплоить на любую хостинговую платформу для статики: Vercel (нативный для Next.js), Netlify, AWS S3 + CloudFront, GitHub Pages. В пайплайн добавляются шаги для установки CLI нужной платформы и загрузки файлов.
Вариант Б: Деплой Node.js-приложения (SSR/API Routes). Здесь нужна инфраструктура, способная запускать Node.js: собственный сервер, VPS (например, на DigitalOcean), платформы как сервис (PaaS) вроде Heroku, Railway или AWS App Runner. Пайплайн должен будет собрать приложение, возможно, создать Docker-образ, отправить его в реестр (Docker Hub, AWS ECR) и развернуть на целевой платформе, используя ее API или CLI.

Шаг 6: Внедрение тестирования в пайплайн.
Помимо юнит-тестов, для Next.js крайне полезно добавить:

• Тестирование E2E с помощью Playwright или Cypress. Эти тесты можно запускать на стадии CI или после деплоя на staging-окружении.
• Проверку производительности сборки. Можно использовать Lighthouse CI, чтобы автоматически проверять метрики производительности (Performance, SEO, Accessibility) и не допускать регрессии.

Шаг 7: Настройка переменных окружения.
Next.js поддерживает переменные окружения. Никогда не храните секреты (API-ключи, пароли БД) в коде репозитория. Используйте механизмы секретов вашей CI/CD-платформы (GitHub Secrets, GitLab CI Variables) и передавайте их в процесс сборки или рантайма. Для сборки используйте префикс `NEXT_PUBLIC_` для переменных, доступных в браузере.

Шаг 8: Создание staging-окружения.
Перед продакшеном обязательно настройте промежуточное (staging) окружение, максимально приближенное к боевому. Пайплайн может быть настроен на автоматический деплой в staging при мердже в `develop`, а в продакшен — только при релизе с `main`. Это позволяет безопасно тестировать новые функции и интеграции.

Шаг 9: Мониторинг и откат.
После деплоя ваша работа не заканчивается. Интегрируйте мониторинг ошибок (Sentry, LogRocket) и отслеживание производительности. Продумайте стратегию быстрого отката (rollback) на предыдущую стабильную версию на случай критических инцидентов. Это может быть реализовано как дополнительный шаг в пайплайне или через возможности вашей платформы развертывания.

Следуя этим шагам, вы построите надежный, автоматизированный конвейер, который обеспечит высокое качество кода, быструю обратную связь для разработчиков и безопасный процесс доставки вашего Next.js-приложения пользователям.