Деплой FastAPI и Django без простоя: CI/CD на GitHub Actions в 2026

Ручной релиз — это неявная очередь. Только один-два человека знают, как правильно выкатывать, поэтому остальные ждут. Релизы копятся, пакеты изменений растут, и каждый следующий деплой становится рискованнее предыдущего.

Большой релиз сложно отлаживать. Если в него вошло 40 коммитов, найти виновника сбоя непросто, а откат затрагивает и рабочие изменения. Небольшие частые релизы, наоборот, дают понятную причину проблемы и быстрое исправление.

Вот что чаще всего ломается при ручном процессе:

• Дрейф окружений: на сервере стоит другая версия библиотеки, чем в разработке.
• Забытые шаги: не собрана статика, не выполнена миграция, не перезапущен воркер Celery.
• Отсутствие аудита: непонятно, кто и когда выкатил конкретную версию.
• Простой при выкатке: перезапуск процесса обрывает активные запросы.

Для бизнеса это выражается в деньгах. Даже 5 минут простоя интернет-магазина в час пик — это потерянные заказы и удар по доверию. А если релиз откладывают из страха, фичи доходят до пользователей медленнее конкурентов.

Автоматизация решает проблему системно: один и тот же сценарий выполняется одинаково каждый раз. Человек перестаёт быть «исполнителем команд» и занимается тем, что действительно требует мышления.

Надёжный пайплайн — это последовательность этапов, где каждый следующий запускается только после успеха предыдущего. Принцип простой: чем раньше обнаружена ошибка, тем дешевле её исправить. Поэтому быстрые проверки идут первыми.

Типовая схема CI/CD для Python выглядит так:

1. Линтинг и типы: ruff, mypy. Занимает до минуты и отсекает очевидные ошибки.
2. Тесты: pytest с покрытием, база и Redis поднимаются как сервисные контейнеры.
3. Сборка образа: multi-stage Dockerfile, тег по SHA коммита, push в registry.
4. Миграции: выполняются отдельным шагом до переключения трафика.
5. Выкатка: обновление контейнеров выбранной стратегией.
6. Проверка: smoke-тест эндпоинта /health и автоматический откат при сбое.

Отдельно остановимся на миграциях — это самое тонкое место zero-downtime. Пока идёт выкатка, старая и новая версии кода работают одновременно с одной базой. Значит, схема должна быть совместима с обеими.

Применяйте паттерн expand/contract: сначала добавляйте столбец (nullable или с default), выкатывайте код, который его использует, и только в следующем релизе удаляйте старое. Переименование и удаление столбцов одним шагом — прямой путь к ошибкам 500.

Образ собирается один раз и в неизменном виде проходит через staging и production. Это гарантирует, что в проде работает ровно то, что было протестировано. Если вы строите архитектуру из нескольких сервисов, подробнее о подходах читайте на странице про разработку микросервисов.

GitHub Actions FastAPI и Django настраиваются практически одинаково: отличаются команды запуска и миграций. Ниже — компактный workflow, который тестирует код, собирает образ в GitHub Container Registry и выкатывает его по SSH. Положите его в .github/workflows/deploy.yml.

name: ci-cd
on:
  push:
    branches: [main]

jobs:
  test:
    runs-on: ubuntu-latest
    services:
      postgres:
        image: postgres:16
        env:
          POSTGRES_PASSWORD: test
        ports: ['5432:5432']
        options: --health-cmd pg_isready --health-interval 5s
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-python@v5
        with:
          python-version: '3.12'
          cache: pip
      - run: pip install -r requirements.txt
      - run: ruff check .
      - run: pytest -q
        env:
          DATABASE_URL: postgresql://postgres:test@localhost:5432/postgres

  build:
    needs: test
    runs-on: ubuntu-latest
    permissions:
      packages: write
    steps:
      - uses: actions/checkout@v4
      - uses: docker/login-action@v3
        with:
          registry: ghcr.io
          username: ${{ github.actor }}
          password: ${{ secrets.GITHUB_TOKEN }}
      - uses: docker/build-push-action@v6
        with:
          push: true
          tags: ghcr.io/${{ github.repository }}:${{ github.sha }}
          cache-from: type=gha
          cache-to: type=gha,mode=max

  deploy:
    needs: build
    runs-on: ubuntu-latest
    environment: production
    steps:
      - uses: appleboy/ssh-action@v1
        with:
          host: ${{ secrets.HOST }}
          username: ${{ secrets.USER }}
          key: ${{ secrets.SSH_KEY }}
          script: |
            export TAG=${{ github.sha }}
            cd /srv/app && ./deploy.sh

Скрипт deploy.sh на сервере забирает образ, выполняет миграцию и обновляет сервис. Для FastAPI с Alembic это docker compose run --rm app alembic upgrade head, для Django — python manage.py migrate --noinput. После этого запускается docker compose up -d или обновление сервиса в Swarm/Kubernetes.

Для Django добавьте шаг collectstatic на этапе сборки образа, а для FastAPI запускайте приложение через uvicorn с несколькими воркерами или под gunicorn с uvicorn-worker. Если нужна помощь с архитектурой самих приложений, посмотрите наши услуги по разработке на FastAPI и созданию Django-приложений.

Zero-downtime деплой строится на простой идее: новая версия должна быть готова принимать трафик до того, как старая перестанет. Способов добиться этого три, и у каждого свой баланс цены, скорости и риска.

Rolling update заменяет реплики по одной. Балансировщик отправляет запросы только на здоровые экземпляры, поэтому пользователи ничего не замечают. Это стандарт Kubernetes и Docker Swarm, он не требует дополнительных ресурсов. Минус: две версии работают одновременно, а откат занимает время.

Blue-green держит два полноценных окружения. Вы выкатываете новую версию в «зелёное», прогоняете smoke-тесты и переключаете трафик одной операцией. Откат мгновенный — достаточно вернуть переключатель. Цена — вдвое больше ресурсов на время релиза.

Canary направляет на новую версию малую долю трафика, например 5%, и постепенно увеличивает её, сверяя метрики. Это лучший вариант для критичных сервисов: ошибка затронет лишь малую часть пользователей. Но потребуется умный балансировщик (Nginx, Traefik, Istio) и хорошая наблюдаемость.

• Rolling — выбор по умолчанию для большинства проектов.
• Blue-green — когда важен мгновенный откат и есть бюджет на ресурсы.
• Canary — когда цена ошибки высока, а трафик достаточен для статистики.

Независимо от стратегии нужны три технических условия. Во-первых, эндпоинт /health с проверкой базы. Во-вторых, graceful shutdown: uvicorn и gunicorn должны дожидаться завершения текущих запросов (параметр --timeout-graceful-shutdown или --graceful-timeout). В-третьих, обратная совместимость схемы БД, о которой мы говорили выше.

Выбор стратегии часто упирается в инфраструктуру. Если вы сомневаетесь, что подойдёт вашему проекту, это удобно обсудить на DevOps-консультации.

Автоматический деплой без плана отката — это просто быстрый способ сломать прод. Откат должен быть таким же простым и отработанным, как выкатка. Поскольку образы тегируются SHA коммита, вернуть предыдущую версию можно одной командой или повторным запуском workflow с прошлым тегом.

Автоматизируйте решение: после выкатки пайплайн проверяет /health несколько раз подряд, и при неудаче сам возвращает прежний образ. Для Kubernetes это kubectl rollout undo, для Compose — повторный запуск с предыдущим TAG.

Мониторинг после релиза закрывает то, что не поймали тесты. Следите за четырьмя сигналами в первые 15-30 минут:

1. Доля ответов 5xx и рост latency (p95, p99).
2. Ошибки в Sentry: новые типы исключений после релиза.
3. Состояние очередей и воркеров Celery.
4. Нагрузка на БД и количество медленных запросов.

Отмечайте релизы в Grafana аннотациями — так на графиках сразу видно, что изменилось после выкатки.

Типичные ошибки при автоматизации повторяются из проекта в проект:

• Сборка образа на сервере вместо registry — релизы нерепродуцируемы.
• Тег latest в продакшене: непонятно, что именно запущено.
• Откат кода без учёта необратимых миграций.
• Секреты в репозитории или логах пайплайна.
• Отсутствие staging: тестируют сразу на пользователях.