Как деплоишь проект?

Что такое деплой

Деплой (от deploy — развёртывание) — это процесс доставки кода из окружения разработки на продакшн (боевой) сервер, где его будут использовать реальные пользователи. Это критичный этап в жизненном цикле приложения, требующий планирования, тестирования и стратегии минимизации рисков.

Основные этапы деплоя

1. Подготовка кода

# Проверка качества кода
make lint      # Запуск linter
make test      # Запуск тестов
make build     # Компиляция/сборка

# Проверка покрытия тестами
pytest --cov=src tests/

Что проверяется:

• Код соответствует стандартам (PEP 8, mypy)
• Все тесты проходят (unit, integration, E2E)
• Нет ошибок типизации (TypeScript, Python typing)
• Покрытие тестами >= 90%

2. Версионирование

# Семантическое версионирование (SemVer: MAJOR.MINOR.PATCH)
git tag v1.2.3

# Например:
# v1.0.0 — первый релиз
# v1.1.0 — добавлены новые фичи (minor)
# v1.1.1 — багфиксы (patch)
# v2.0.0 — ломающие изменения (major)

3. Сборка артефактов

# Docker образ
docker build -t myapp:v1.2.3 .
docker push registry.example.com/myapp:v1.2.3

# Или бинарник для production
pyinstaller --onefile app.py

4. Развёртывание на продакшн

Распространённые способы деплоя

Способ 1: Git Push (простой, подходит для малых проектов)

# На локальной машине
git add .
git commit -m "Release v1.2.3"
git tag v1.2.3
git push origin main
git push origin v1.2.3

# На сервере (автоматически или вручную)
git pull origin main
pip install -r requirements.txt
restartapp  # Перезагрузка сервиса

Плюсы: простота, быстро Минусы: ненадёжно, может сломать продакшн

Способ 2: Docker + Docker Compose (надёжно)

# Локально
docker build -t app:v1.2.3 .
docker push registry.example.com/app:v1.2.3

# docker-compose.yml на сервере
version: '3.8'
services:
  web:
    image: registry.example.com/app:v1.2.3
    ports:
      - "80:8000"
    environment:
      - DEBUG=false
      - DATABASE_URL=postgresql://...
    volumes:
      - ./logs:/app/logs

# Деплой
docker-compose pull
docker-compose up -d

Плюсы: стабильность, легко откатиться, изолированность Минусы: нужен Docker, требует больше ресурсов

Способ 3: CI/CD Пайплайн (enterprise стандарт)

# .github/workflows/deploy.yml
name: Deploy
on:
  push:
    branches: [main]
    tags: ['v*']

jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      
      - name: Run tests
        run: make test
      
      - name: Build Docker image
        run: |
          docker build -t app:${{ github.sha }} .
          docker push registry.example.com/app:${{ github.sha }}
      
      - name: Deploy to production
        run: |
          ssh user@prod.example.com 'docker pull registry.example.com/app:${{ github.sha }} && docker-compose up -d'

Плюсы: автоматизация, безопасность, отслеживание Минусы: сложнее настроить

Способ 4: Kubernetes (масштабируемость)

# deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: myapp
spec:
  replicas: 3
  selector:
    matchLabels:
      app: myapp
  template:
    metadata:
      labels:
        app: myapp
    spec:
      containers:
      - name: myapp
        image: registry.example.com/app:v1.2.3
        ports:
        - containerPort: 8000
        env:
        - name: DATABASE_URL
          valueFrom:
            secretKeyRef:
              name: db-secret
              key: url

kubectl apply -f deployment.yaml
kubectl rollout status deployment/myapp

Плюсы: масштабируемость, отказоустойчивость, автоматизированное управление Минусы: сложно для малых проектов

Способ 5: PaaS (Platform as a Service)

# Heroku
git push heroku main  # Автоматический деплой

# Vercel (для фронта)
vercel deploy --prod

# Railway, Render, Fly.io — похожие подходы

Плюсы: очень просто, не нужно управлять сервером Минусы: дорого, меньше контроля

Стратегии развёртывания

Blue-Green Деплой (нулевой downtime)

Производство:
  Blue  [v1.0.0] ← трафик идёт сюда
  Green [v1.1.0] ← загружаем новую версию

После проверки:
  Blue  [v1.0.0]
  Green [v1.1.0] ← переключаем трафик сюда

Преимущества:

• Нет простоя сервиса
• Легко откатиться (switch back)
• Полное тестирование перед переключением

Canary Деплой (постепенное внедрение)

Производство:
  v1.0.0 [90% трафика] ← старая версия
  v1.1.0 [10% трафика] ← новая версия
  
  Если всё хорошо → увеличиваем процент
  Если ошибки → откатываемся

Преимущества:

• Минимизация рисков
• Мониторинг в реальном времени
• Быстрый откат при проблемах

Rolling Deployment (последовательное обновление)

Сервер 1: v1.0.0 → v1.1.0 (выводим из балансировщика)
Сервер 2: v1.0.0 → v1.1.0
Сервер 3: v1.0.0 → v1.1.0

Преимущества:

• Нет полного downtime
• Естественное распределение нагрузки

Практический пример: FastAPI на продакшн

# 1. Локально: тесты, сборка
make lint
make test

# 2. Версионирование и тег
git tag v2.1.0
git push origin v2.1.0

# 3. Build Docker
docker build -t myapi:v2.1.0 .
docker push registry.example.com/myapi:v2.1.0

# 4. Деплой на сервер (через SSH или CI/CD)
ssh deploy@prod.example.com << 'DEPLOY'
  cd /app
  docker pull registry.example.com/myapi:v2.1.0
  docker stop myapi || true
  docker rm myapi || true
  docker run -d --name myapi \
    -p 8000:8000 \
    -e DATABASE_URL=postgresql://... \
    -e SECRET_KEY=... \
    registry.example.com/myapi:v2.1.0
  
  # Проверка здоровья
  sleep 5
  curl http://localhost:8000/health
DEPLOY

Проверки перед деплоем (Pre-deployment Checklist)

• ✅ Все тесты проходят (make test)
• ✅ Код прошёл lint проверку (make lint)
• ✅ Покрытие тестами >= 90%
• ✅ Переменные окружения установлены
• ✅ База данных в нужном состоянии (миграции накачаны)
• ✅ Резервная копия БД создана
• ✅ Коллеги провели Code Review
• ✅ Build успешный
• ✅ На staging всё работает

Откат (Rollback)

# Если что-то пошло не так
kubectl rollout undo deployment/myapp
# или
docker stop myapp && docker run ... image:v2.0.0
# или
git revert HEAD

Деплой — это искусство баланса между скоростью и надёжностью. Выбирайте подход в зависимости от размера проекта и требований к отказоустойчивости!