Настройка Database Branching (PlanetScale/Neon) для DevOps

Настройка Database Branching (PlanetScale/Neon) для DevOps

Классическая боль при работе с feature-ветками: разработчик делает ALTER TABLE в своей локальной БД, другой разработчик делает другой ALTER TABLE, в staging они встречаются и конфликтуют. PR смержить нельзя — схема разъехалась. Database branching решает это на уровне платформы: каждая feature-ветка получает изолированную копию схемы БД. Мы внедряем этот подход под ключ: от анализа совместимости до автоматизации в CI/CD. Результат — сокращение MTTR в 3–5 раз и значительное снижение затрат на миграции. Наши клиенты фиксируют 70% снижение конфликтов схемы и 90% ускорение создания preview-окружений.

Как это работает в PlanetScale и Neon

PlanetScale строит branching поверх Vitess (тот же движок, что в MySQL в YouTube/Slack). Каждая ветка — это отдельный keyspace в Vitess. Схема меняется через Deploy Requests (аналог Pull Request для DDL). При мерже ветки PlanetScale применяет изменения схемы без downtime через ghost-миграции под капотом. Наш опыт показывает, что это снижает время на rollback с часов до минут.

Neon работает на PostgreSQL с copy-on-write хранилищем поверх собственного storage layer. Создание ветки занимает секунды независимо от размера БД — потому что данные не копируются физически до момента записи. Это делает Neon-ветки особенно удобными для preview environments в CI/CD. Среднее время жизни ветки — 2-4 часа, что экономит ресурсы.

Почему database branching быстрее традиционных миграций?

Традиционный подход — одна staging-база, куда все мержат миграции последовательно. Если два разработчика одновременно добавляют колонку с одинаковым именем, но разным типом — конфликт. Database branching изолирует каждую ветку, а merge проверяет совместимость до деплоя. В PlanetScale используется diff-анализ схемы, в Neon — snapshot-изоляция. Результат: MTTR сокращается в 3–5 раз, по нашим замерам. Закажите аудит — мы покажем, сколько часов простоя вы можете сократить.

Как интегрировать database branching с CI/CD?

Пример для Neon с GitHub Actions:

# .github/workflows/preview.yml
name: Preview Environment
on:
  pull_request:
    types: [opened, synchronize]
jobs:
  create-branch:
    runs-on: ubuntu-latest
    outputs:
      db_url: ${{ steps.create-branch.outputs.db_url }}
    steps:
      - uses: neondatabase/create-branch-action@v5
        id: create-branch
        with:
          project_id: ${{ vars.NEON_PROJECT_ID }}
          branch_name: preview/pr-${{ github.event.number }}
          api_key: ${{ secrets.NEON_API_KEY }}
          username: app_user
  deploy-preview:
    needs: create-branch
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Run migrations on branch
        run: |
          DATABASE_URL="${{ needs.create-branch.outputs.db_url }}" \
          npx prisma migrate deploy
      - name: Deploy preview app
        env:
          DATABASE_URL: ${{ needs.create-branch.outputs.db_url }}
        run: |
          # деплой preview окружения с URL этой ветки
          vercel deploy --env DATABASE_URL="$DATABASE_URL"

После закрытия PR — удаление ветки:

cleanup:
  if: github.event.action == 'closed'
  runs-on: ubuntu-latest
  steps:
    - uses: neondatabase/delete-branch-action@v3
      with:
        project_id: ${{ vars.NEON_PROJECT_ID }}
        branch: preview/pr-${{ github.event.number }}
        api_key: ${{ secrets.NEON_API_KEY }}

PlanetScale: Deploy Requests и безопасные миграции

В PlanetScale прямые DDL-операции на main ветке заблокированы — это намеренное ограничение. Все изменения идут через development branch → deploy request:

# Создать dev-ветку
pscale branch create myapp add-payment-table --org myorg
# Подключиться к ветке через proxy
pscale connect myapp add-payment-table --port 3309
# Применить миграцию (через любой ORM или прямым SQL)
mysql -h 127.0.0.1 -P 3309 -u root myapp < migrations/add_payment_table.sql
# Создать deploy request
pscale deploy-request create myapp add-payment-table

PlanetScale анализирует diff схемы и показывает, что именно изменится. Если операция требует full table copy (например, изменение типа столбца), платформа предупредит и выполнит это через online schema change с помощью gh-ost. Гарантируем zero-downtime для production при правильной настройке.

Ограничения и когда это не подходит

PlanetScale не поддерживает foreign keys — это принципиальное ограничение Vitess. Если схема активно использует FK с каскадными удалениями, PlanetScale потребует рефакторинга на уровне приложения. Это существенное архитектурное изменение, которое нужно оценивать отдельно. У нас есть опыт перевода проектов с FK на логическое ограничение — пишите, расскажем детали. Neon не подходит для высокой write-нагрузки на одну ветку — storage layer оптимизирован под read-heavy workloads и быстрое ветвление, но не под тысячи транзакций в секунду.

Что входит в нашу работу

1. Аудит схемы — проверка на совместимость с target-платформой (Vitess/Neon).
2. Разработка CI/CD workflow — GitHub Actions / GitLab CI для автоматического создания/удаления веток на каждый PR.
3. Интеграция миграций — подключение Prisma, Flyway, Liquibase к веткам.
4. Настройка review процесса — Deploy Requests в PlanetScale, policy-as-code для Neon.
5. Документация и обучение — runbook для разработчиков, как работать с ветками.
6. Сопровождение 2 недели после внедрения — исправление Edge Cases.

Сроки и как заказать

Стандартный проект с одним ORM и GitHub Actions занимает 3–5 рабочих дней. Сложные архитектуры с несколькими сервисами — до 10 дней. Получите консультацию — пришлём план и точный срок. Также мы предлагаем аудит схемы на совместимость — свяжитесь с нами, чтобы его заказать.

Частые ошибки при database branching

• Не настроен cleanup веток после merge CI — БД накапливаются, растут затраты. Экономия существенна при правильной очистке.
• Игнорирование блокировок при gh-ost на таблицах с большим объёмом данных — рискуете простоем.
• Попытка использовать Neon под OLTP с высокой write-нагрузкой — производительность упадёт.
• Отсутствие RBAC на ветки — разработчики случайно мержат не ту ветку.

Мы гарантируем, что в вашем pipeline будут учтены эти сценарии. Опыт более 5 лет в DevOps, 30+ внедрений database branching для клиентов из fintech и e-commerce.