Как правильно построить схему деплоя?

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

Правильная схема деплоя — это набор автоматизированных процессов, которые переводят код из репозитория на production с минимальными рисками. Вот ключевые элементы:

1. Версионирование и теги

Используй семантическое версионирование (SemVer): MAJOR.MINOR.PATCH

• MAJOR: несовместимые API изменения
• MINOR: новый функционал, обратно совместимый
• PATCH: исправления ошибок

# pyproject.toml или setup.py
version = "2.3.1"

Теги в Git должны совпадать с версией:

git tag -a v2.3.1 -m "Release version 2.3.1"
git push origin v2.3.1

2. CI/CD pipeline

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

# .github/workflows/deploy.yml
name: Deploy
on:
  push:
    tags:
      - "v*"

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      - name: Run tests
        run: pytest --cov=app tests/
      - name: Lint
        run: ruff check .
  
  deploy:
    needs: test
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      - name: Deploy to production
        env:
          DEPLOY_KEY: ${{ secrets.DEPLOY_KEY }}
        run: |
          echo "$DEPLOY_KEY" > key.pem
          chmod 600 key.pem
          ssh -i key.pem user@server "cd /app && git pull && systemctl restart app"

3. Окружения

Раздели окружения явно:

• Development — локальная машина, быстрая итерация
• Staging — копия production, тестирование перед release
• Production — боевой сервер, real users

Каждое окружение должно иметь:

• Отдельную БД
• Отдельные secrets и API ключи
• Отдельный домен (dev.example.com, staging.example.com)

# config.py
import os

env = os.getenv('ENVIRONMENT', 'development')

if env == 'production':
    DEBUG = False
    DATABASE_URL = os.getenv('DATABASE_URL')
    WORKERS = 8
elif env == 'staging':
    DEBUG = False
    DATABASE_URL = os.getenv('STAGING_DATABASE_URL')
    WORKERS = 4
else:
    DEBUG = True
    DATABASE_URL = 'sqlite:///dev.db'
    WORKERS = 1

4. Миграции и rollback

Перед деплоем new version:

# 1. Примени миграции
alembic upgrade head

# 2. Перезагрузи приложение
sudo systemctl restart myapp

# 3. Мониторь логи
tail -f /var/log/myapp.log

Если что-то сломалось, откатись:

# Откати последнюю миграцию
alembic downgrade -1

# Верни предыдущую версию кода
git checkout v2.3.0
git push --force

5. Мониторинг и алерты

После деплоя нужно активно следить:

# Отправляй метрики
from prometheus_client import Counter, Histogram

error_counter = Counter('app_errors_total', 'Total errors')
response_time = Histogram('http_request_duration_seconds', 'Request duration')

try:
    response = process_request()
except Exception as e:
    error_counter.inc()
    logger.error(f"Error: {e}")
    raise

Настрой алерты:

• Ошибки (HTTP 500) > 1% за 5 минут
• Время ответа > 1 сек
• CPU/Memory > 80%
• Database connection errors

6. Blue-Green deployment

Для zero-downtime обновлений:

# 1. Запусти новую версию на отдельном сервере (green)
ssh user@green-server
cd /app && git pull && python -m gunicorn app:app

# 2. Протестируй health check
curl http://green-server/health

# 3. Переключи traffic (load balancer)
nginx_switch_upstream(blue_to_green)

# 4. Если ошибки — быстрый откат
nginx_switch_upstream(green_to_blue)

7. Database migrations strategy

Важно: миграции должны быть backward compatible:

# Плохо — может сломать старую версию
class Migration:
    def upgrade(self):
        # Удаляю колонку
        alter_table('users', drop_column='old_field')

# Хорошо — оба версии работают
class Migration:
    def upgrade(self):
        # 1. Добавляю новую колонку
        alter_table('users', add_column='new_field')
    
    def downgrade(self):
        alter_table('users', drop_column='new_field')

8. Секреты и конфиги

НЕ коммить secrets в Git:

# Хорошо
.env                    # .gitignore
env/secrets/prod.yml    # .gitignore

# Хранить в:
# - AWS Secrets Manager
# - HashiCorp Vault
# - GitHub Secrets
# - .env файлы в .gitignore

from dotenv import load_dotenv
import os

load_dotenv()
db_password = os.getenv('DB_PASSWORD')

9. Полный пример Dokku деплоя

# На сервере
dokku apps:create myapp
dokku config:set myapp ENVIRONMENT=production
dokku postgres:create mydb
dokku postgres:link mydb myapp

# На локальной машине
git remote add dokku dokku@server:myapp
git push dokku main:main

# Логи
dokku logs myapp --tail 100

Заключение

Правильная схема деплоя — это:

1. Автоматизация (GitHub Actions, GitLab CI)
2. Тестирование (unit, integration, e2e перед деплоем)
3. Staging окружение (перед боем)
4. Мониторинг (логи, метрики, алерты)
5. Rollback возможность (быстрый откат при проблемах)
6. Documentation (как деплоить, как откатываться)

Это дает confidence что production работает надежно и any issues решаются быстро.