GitHub Actions CI/CD для Next.js: гайды по автоматизации деплоя

kirilljsx

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

Это решает проблемы ручных обновлений, ошибок в сборке и задержек в релизах. В гайде разберем настройку workflow, секретов и примеры для разных серверов. Вы получите готовые шаги для запуска CI/CD без лишних инструментов.

Настройка секретов и SSH-доступа для безопасного деплоя

Секреты в GitHub — это основа безопасной автоматизации. Они хранят чувствительные данные вроде ключей SSH и IP сервера, не раскрывая их в коде. Без них деплой рискует утечкой информации или просто не сработает.

Представьте: вы пушите код, а Actions подключается к серверу по SSH, устанавливает зависимости и перезапускает app. Это работает для VPS вроде AWS EC2 или Hostinger. Главное — правильно сгенерировать ключи и добавить публичный ключ на сервер командой cat github_action.pub >> authorized_keys. Логично перейти к шагам настройки, чтобы все заработало.

HOST: укажите IP вашего сервера, например, для EC2.
USERNAME: имя пользователя на сервере, обычно ubuntu или root.
SSH_PRIVATE_KEY: приватный ключ в формате PEM, сгенерируйте через ssh-keygen.

После добавления секретов в репозитории (Settings > Secrets and variables > Actions) проверьте доступ. Важно: используйте ed25519 для новых ключей — они быстрее и безопаснее.

Секрет	Описание	Пример значения
HOST	IP сервера	192.0.2.1
USERNAME	Пользователь	ubuntu
SSH_PRIVATE_KEY	Приватный ключ	-----BEGIN OPENSSH PRIVATE KEY-----…

Создание базового workflow для сборки и деплоя на VPS

Workflow — это YAML-файл в .github/workflows/deploy.yml, который определяет шаги CI/CD. Он триггерится на push в main или другую ветку, checkout’ит код, устанавливает Node.js и деплойит.

Для Next.js типичный пайплайн: checkout, setup Node, install deps с npm ci, build с npm run build, затем SSH на сервер для pull и restart. Используйте PM2 для управления процессом — он держит app в фоне и авторестартит при сбоях. Это экономит часы на ручном деплое. Теперь разберем пример кода.

Триггер: on: push: branches: [main] — запускает на пуше в main.
Job: runs-on: ubuntu-latest, steps с actions/checkout@v4 и actions/setup-node@v4.
Deploy шаг: SSH-скрипт с ssh -o StrictHostKeyChecking=no $USERNAME@$HOST.

Нюанс: добавьте concurrency group, чтобы избежать параллельных деплоев — concurrency: group: deploy cancel-in-progress: false.

Пример фрагмента:

name: Deploy Next.js
on:
  push:
    branches: [main]
jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: '20'
      - run: npm ci
      - run: npm run build
      - name: Deploy to server
        uses: appleboy/ssh-action@v1.0.0
        with:
          host: ${{ secrets.HOST }}
          username: ${{ secrets.USERNAME }}
          key: ${{ secrets.SSH_PRIVATE_KEY }}
          script: |
            cd /path/to/app
            git pull
            npm install --production
            pm2 restart ecosystem.config.js

Деплой на GitHub Pages или serverless: статические сайты Next.js

Для статических Next.js (с output: export в next.config.js) подойдет GitHub Pages — бесплатно и просто. Actions собирают out-директорию и пушат в gh-pages ветку.

Serverless-вариант через Vercel или AWS Lambda тоже автоматизируется: тег v1.0 триггерит prod-деплой, push в main — staging. Это масштабируется без сервера. Сравним варианты, чтобы выбрать под проект.

GitHub Pages: для статических сайтов, использует actions/deploy-pages@v4.
Vercel: нативная интеграция, но с лимитами на бесплатном плане.
Serverless Next.js: для динамики, с отдельными staging/prod workflows.

Платформа	Преимущества	Минусы	Триггер
GitHub Pages	Бесплатно, просто	Только статика	Push в main
Vercel	SSR/SSG, preview	Лимиты трафика	Git интеграция
VPS + PM2	Полный контроль	Нужно настраивать	Push/tag

Выберите по нуждам: статика — Pages, динамика — VPS или serverless.

Тестирование и отладка пайплайна: ловим ошибки заранее

CI/CD не только деплой, но и тесты: lint, unit-тесты с Jest, e2e с Playwright. Добавьте шаги перед build — если тесты падают, деплой не запустится.

В логах Actions видно каждую ошибку: failed npm install или SSH timeout. Используйте artifacts для сохранения build-логов. Это ускоряет итерации. Переходим к списку проверок.

Lint: npm run lint — ловит код-стайл ошибки.
Tests: npm test — запускает юнит-тесты.
Build smoke-test: npm run build && npm start в фоне.

Совет: для больших проектов добавьте caching deps — actions/cache на node_modules.

Масштабирование CI/CD: от staging до продакшена

Автоматизация staging/prod разделяет риски: main — staging, теги v* — prod. ArgoCD или Kubernetes добавляют GitOps для сложных сетапов, но начните с Actions.

Это подводит к продвинутым фичам вроде blue-green деплоя или rollback. Подумайте о мониторинге: интегрируйте Sentry или Datadog в workflow. Осталось пространство для кастомизации под ваш стек.

В гайде мы прошли базовый и продвинутый деплой, но темы вроде multi-env или Docker-интеграции требуют отдельного разбора. Стоит поэкспериментировать с caching и parallel jobs для скорости.