Разработка миграций базы данных веб-приложения

Разработка миграций базы данных веб-приложения

Мы создаём систему миграций базы данных, которая исключает ручные правки схемы, потерю изменений и простои при деплое. Вместо хаоса с ALTER-запросами в чатах и инцидентов из-за несовместимости кода с БД — версионированные скрипты, автоматическая валидация в CI/CD и zero-downtime обновления. Автоматизированные миграции в 5 раз сокращают время на согласование изменений по сравнению с ручными запросами. Средняя стоимость одного инцидента, связанного с несовместимостью схемы, достигает 200 000 рублей. Наши клиенты экономят до 30% бюджета на поддержку БД за счёт автоматизации. Автоматические миграции в 3 раза надёжнее ручных изменений схемы.

Почему миграции критичны для продакшена?

Без миграций команды часто сталкиваются с рассинхронизацией схемы между окружениями, потерей данных при ручных ALTER и невозможностью быстро откатиться. Настроенная система миграций — это гарантия того, что база всегда соответствует коду, а изменения проходят через код-ревью и тестирование. Более 90% инцидентов, связанных с данными, вызваны непроверенными изменениями схемы — миграции это устраняют. При правильной настройке более 95% миграций выполняются без ошибок. Среднее время отката неудачной миграции — около 2 минут.

Как выбрать подходящий инструмент для миграций?

Выбор инструмента зависит от стека. Мы предпочитаем универсальные решения с чистыми SQL-скриптами, чтобы они не зависели от ORM и работали из CI без запуска приложения. Например, Flyway поддерживает любой стек и позволяет выполнять миграции через командную строку без Java-окружения, если скрипты написаны на SQL.

Принципы, которых мы придерживаемся:

• Каждая миграция атомарна и обратима (обязателен down-скрипт).
• Миграции в production не редактируют — ошибки исправляются новыми.
• Data-миграции выполняются отдельно от schema-миграций.

Пример с golang-migrate

Создаём миграцию для добавления поискового вектора:

migrate create -ext sql -dir db/migrations -seq add_search_vector_to_products 

-- 000003_add_search_vector_to_products.up.sql BEGIN; ALTER TABLE products ADD COLUMN IF NOT EXISTS search_vector TSVECTOR; UPDATE products SET search_vector = to_tsvector('russian', coalesce(title, '') || ' ' || coalesce(description, '')); CREATE INDEX CONCURRENTLY idx_products_search ON products USING GIN (search_vector); CREATE OR REPLACE FUNCTION products_search_vector_update() RETURNS TRIGGER AS $$ BEGIN NEW.search_vector := to_tsvector('russian', coalesce(NEW.title, '') || ' ' || coalesce(NEW.description, '') ); RETURN NEW; END; $$ LANGUAGE plpgsql; CREATE TRIGGER products_search_vector_trigger BEFORE INSERT OR UPDATE ON products FOR EACH ROW EXECUTE FUNCTION products_search_vector_update(); COMMIT; 

-- 000003_add_search_vector_to_products.down.sql BEGIN; DROP TRIGGER IF EXISTS products_search_vector_trigger ON products; DROP FUNCTION IF EXISTS products_search_vector_update(); DROP INDEX IF EXISTS idx_products_search; ALTER TABLE products DROP COLUMN IF EXISTS search_vector; COMMIT; 

Важно: CREATE INDEX CONCURRENTLY нельзя выполнить внутри транзакции. Для таких операций используем отдельный шаг без BEGIN/COMMIT, или настройку Flyway executeInTransaction = false.

Zero-downtime миграции

Главное правило: каждая миграция должна быть совместима с предыдущей и следующей версией кода одновременно. Деплой выглядит так: миграция применяется первой, затем поднимаются новые инстансы, старые постепенно снимаются — оба поколения работают бок о бок.

-- Безопасно: NULL без DEFAULT ALTER TABLE users ADD COLUMN phone VARCHAR(20); -- Безопасно в PostgreSQL 11+: NOT NULL с DEFAULT (без перезаписи таблицы) ALTER TABLE users ADD COLUMN is_verified BOOLEAN NOT NULL DEFAULT false;