Это решает проблемы ручных обновлений, ошибок в сборке и задержек в релизах. В гайде разберем настройку 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 для новых ключей — они быстрее и безопаснее.

Создание базового 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 в фоне и авторестартит при сбоях. Это экономит часы на ручном деплое. Теперь разберем пример кода.

1. Триггер: on: push: branches: [main] — запускает на пуше в main.
2. Job: runs-on: ubuntu-latest, steps с actions/checkout@v4 и actions/setup-node@v4.
3. 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.

Выберите по нуждам: статика — 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 для скорости.