Как происходит деплой на нынешней работе?

Как происходит деплой на нынешней работе

В моем текущем проекте используется Dokku как PaaS (Platform as a Service) решение для развертывания, что это интересный и не очень типичный выбор для frontend разработчика. Расскажу подробно о процессе.

Архитектура деплоя

У нас это монорепозиторий с фронтенд и бэкенд частями, развертываемые на одном сервере через Dokku:

[Git репозиторий]
      ↓
[GitHub (git push dokku main)]
      ↓
[Dokku Server на DigitalOcean]
      ├─ Frontend (Next.js standalone)
      └─ Backend (FastAPI)

Процесс деплоя фронтенда

Шаг 1: Подготовка кода

Перед деплоем нужно убедиться, что код готов:

# Проверить, что все работает локально
npm run build  # Сборка Next.js
npm run lint   # Линтинг
npm test       # Тесты

Все тесты должны пройти, иначе выполнить исправления.

Шаг 2: Commit и Push

После того как код готов, создается коммит:

# Локально (я не коммичу и не пушу - это делает только пользователь/лид)
git add .
git commit -m "feat: добавил новую фичу"

Пользователь делает:

# Push в основной Git репозиторий
git push origin main

# Push в Dokku (это инициирует деплой)
git push dokku main

Шаг 3: Dokku получает push

Когда коммит пришел на Dokku сервер:

1. Dokku получает git push
2. Обнаруживает, что это Node.js приложение (по package.json)
3. Запускает buildpack (build процесс)

Build процесс на Dokku

Докку использует buildpacks для сборки приложения:

# На Dokku сервере (автоматически)

# 1. Установить зависимости
npm ci  # или npm install

# 2. Собрать приложение
npm run build

# 3. Результат: standalone Next.js приложение в .next/standalone/

# 4. Создать Docker образ
# (Dokku использует Procfile или detectуется автоматически)

Для Next.js нужен Procfile в корне проекта:

web: node -e "require('next/dist/bin/next').nextStart({ dir: 'frontend', minimalMode: true })"

Или для standalone выпуска:

web: cd frontend && node .next/standalone/server.js

Конфигурация

next.config.js настройки

// Для Dokku важны эти параметры:
module.exports = {
  output: 'standalone',  // Важно! Создает standalone приложение
  distDir: '.next',
  compress: true,
  // ...
}

Environment переменные на Dokku

# Устанавливаются через Dokku CLI
dokku config:set myapp NODE_ENV=production
dokku config:set myapp NEXT_PUBLIC_API_URL=https://api.prepbro.ru

Шаг 4: Запуск контейнера

После сборки Dokku:

# 1. Создает Docker образ
# 2. Запускает контейнер
# 3. Проксирует трафик через Nginx

# На выходе:
# https://prepbro.ru -> Nginx -> Docker контейнер (Next.js)

Мониторинг деплоя

# Посмотреть логи деплоя
dokku logs myapp

# Посмотреть текущие процессы
dokku ps:inspect myapp

# Проверить конфигурацию
dokku config:show myapp

Типичные проблемы и решения

Проблема 1: Build fail

# Ошибка при npm install или build
# Решение:
- Проверить package-lock.json
- Убедиться, что все зависимости указаны
- Смотреть логи: dokku logs myapp

Проблема 2: Память

# Next.js требует памяти при build
# Решение:
dokku config:set myapp NODE_OPTIONS="--max-old-space-size=2048"

Проблема 3: Порт

# Next.js слушает PORT 3000, но Dokku может ждать другого
# Решение: в Procfile указать правильный порт
web: node .next/standalone/server.js

Откат деплоя

Если что-то пошло не так, можно откатить на предыдущую версию:

# Voir доступные версии
dokku releases:list myapp

# Откатить на предыдущую
dokku releases:rollback myapp

CI/CD отсутствует

Интересный момент: в нашем проекте нет внешнего CI/CD (GitHub Actions, GitLab CI). Все происходит на Dokku сервере. Это означает:

Преимущества:
- Простота: git push = деплой
- Меньше конфигурации

Недостатки:
- Нет тестирования перед деплоем
- Нет автоматических проверок (lint, test)
- Больше ответственности на разработчике

Поэтому важно запускать npm run lint и npm test локально перед пушем.

Типичный workflow

# 1. Работаю над фичей
git checkout -b feature/my-feature

# 2. Делаю коммиты
git add .
git commit -m "feat: мояфич"

# 3. Перед пушем — локальная проверка
npm run build
npm run lint
npm test

# 4. Push в GitHub
git push origin feature/my-feature

# 5. Pull request (или в main if no PR required)

# 6. Как только одобрено, лид делает
git merge
git push origin main
git push dokku main  # <-- Автоматический деплой!

# 7. Проверяю на продакшене
# https://prepbro.ru

Масштабирование

Докку позволяет масштабировать приложение:

# Увеличить количество процессов
dokku scale myapp web=3

# Установить лимиты памяти
dokku resource:limit myapp --memory 512m

Сравнение с другими подходами

Итоги

Наш деплой:

1. Simple: git push dokku main = деплой
2. Controlled: Dokku управляет контейнерами и масштабированием
3. Integrated: Фронт и бэк в одном месте
4. Responsible: Разработчик отвечает за качество перед пушем

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