Schema Migration — суть, типи та інструменти міграції схем БД

Що таке Schema Migration

Schema Migration — це практика управління змінами структури бази даних через версіоновані файли, які послідовно застосовуються до різних середовищ. Кожен файл містить набір SQL-команд: створення таблиці, додавання колонки, зміна індексу або оновлення обмежень. Інструмент міграції відстежує застосовані версії та гарантує, що кожна зміна виконується рівно один раз.

На відміну від Data Migration, яка переносить вміст таблиць, Schema Migration управляє тільки структурою — DDL-операціями. Це фундаментальна відмінність: Schema Migration працює до Data Migration, створюючи цільову схему, в яку потім завантажуються дані. За даними Redgate (2024), 62% інцидентів у продакшен-базах пов'язані з ручними змінами схеми без міграційних скриптів.

Версіонування міграцій

Кожна Schema Migration отримує унікальний ідентифікатор — зазвичай версію (V1, V2) або timestamp. Інструмент зберігає в спеціальній таблиці (flyway_schema_history, alembic_version) список застосованих міграцій. При запуску він порівнює список з файлами в classpath і застосовує тільки нові. Ідемпотентність — ключова властивість: повторний запуск не викликає побічних ефектів.

Типи змін схеми

Типові операції Schema Migration: створення таблиць (CREATE TABLE), додавання колонок (ALTER TABLE ADD COLUMN), зміна типів, створення індексів, додавання зовнішніх ключів та оновлення послідовностей. Більш складні міграції включають перейменування колонок зі збереженням даних, розбиття таблиці на декілька та реплікацію схеми на шарди.

Навіщо потрібна міграція схеми БД

Без Schema Migration розробники змінюють БД вручну — правлять DDL в консолі, додають колонки в dev-середовищі та копіюють їх у staging по пам'яті. Результат: розходження схем між середовищами, втрата змін при деплої та зламані міграції на production. Schema Migration вирішує три ключові проблеми: консистентність, відтворюваність та аудит.

Консистентність між середовищами

Коли структура БД описана в коді, вона ідентична на dev, staging та production. Розробник не може забути застосувати зміну — інструмент виконає всі пропущені міграції послідовно. Якщо на production колонка відсутня, а код вимагає її — додаток впаде з помилкою. Автоматична перевірка виключає цей сценарій.

Відтворюваність для нових розробників

Новий учасник команди запускає flyway migrate та отримує актуальну схему за декілька секунд — без дампу з продакшену та ручних DDL-запитів. Це особливо важливо при мікросервісній архітектурі, де кожен сервіс має власну БД і схема збирається з десятків міграцій. Повна відтворюваність скорочує онбординг з днів до хвилин.

Аудит змін

Кожна Schema Migration зберігається в системі контролю версій разом з кодом додатка. Можна відкрити Pull Request, побачити точні SQL-команди зміни схеми та провести code review. При інциденті легко визначити, яка міграція була застосована останньою та хто її автор. Git-історія дає повний трейл змін бази даних за весь час проекту.

Інструменти міграції схем

На ринку існують десятки інструментів Schema Migration для різних мов та платформ. Вибір залежить від стеку технологій, формату опису міграцій та вимог до відкату. Розглянемо основні категорії та популярні інструменти.

Як вибрати інструмент

Для Java/Kotlin стеків — Flyway як найлегший та передбачуваний. Для проектів з частими відкатами — Liquibase, у якого rollback вбудований архітектурно. Для Python/Django — Alembic як стандартний інструмент SQLAlchemy. Для стартапів без DevOps-інженера — вибирайте інструмент з найменшою конфігурацією: Flyway потребує тільки файл зі скриптом та команду migrate.

Комерційні рішення

Крім open-source інструментів існують комерційні: Redgate SQL Change Automation, Datical DB та DBmaestro. Вони надають візуальне порівняння схем, автоматичне вирішення конфліктів та інтеграцію з CI/CD пайплайнами. Однак для більшості проектів Flyway або Alembic покривають 100% потреб без додаткових ліцензій.

Міграція з Flyway

Розглянемо практичний приклад Schema Migration на Kotlin з Flyway. Створимо міграцію, що додає таблицю orders до бази даних PostgreSQL. Flyway автоматично створює таблицю flyway_schema_history та відстежує застосовані версії.

-- V1__Create_Orders_Table.sql
CREATE TABLE orders (
    id              UUID PRIMARY KEY DEFAULT gen_random_uuid(),
    user_id         UUID NOT NULL,
    total_amount    DECIMAL(10,2) NOT NULL,
    currency        VARCHAR(3) NOT NULL DEFAULT 'USD',
    status          VARCHAR(20) NOT NULL DEFAULT 'pending',
    created_at     TIMESTAMPTZ NOT NULL DEFAULT NOW(),
    CONSTRAINT fk_user FOREIGN KEY (user_id) REFERENCES users(id)
);

Підключення Flyway в Kotlin-проекті через конфігурацію dataSource. Після налаштування команда flyway:migrate застосує всі нові міграції з classpath.

// FlywayConfig.kt — конфігурація Flyway в Spring Boot
import org.springframework.context.annotation.Bean
import org.springframework.context.annotation.Configuration
import org.flywaydb.core.Flyway

@Configuration
class FlywayConfig {
    @Bean
    fun flyway(dataSource: DataSource): Flyway {
        return Flyway.configure()
            .dataSource(dataSource)
            .locations("classpath:db/migration")
            .baselineOnMigrate(true)
            .load()
    }
}

Alembic для Python проектів

Alembic — інструмент Schema Migration для Python, побудований поверх SQLAlchemy. Його ключова особливість — авто-генерація скриптів на основі порівняння моделі SQLAlchemy з поточною схемою БД. Alembic підходить для проектів на Django, FastAPI та Flask.

Ініціалізація та створення міграції

Після ініціалізації (alembic init alembic) та налаштування connection string, команда alembic revision --autogenerate сканує моделі SQLAlchemy та генерує скрипт міграції. Розробнику залишається перевірити згенерований код та застосувати його через alembic upgrade head. Autogenerate економить години ручного написання DDL.

# models.py — модель SQLAlchemy для авто-генерації
from sqlalchemy import Column, Integer, String, DateTime, Enum
from sqlalchemy.orm import DeclarativeBase
import enum

class OrderStatus(enum.Enum):
    pending = "pending"
    paid = "paid"
    shipped = "shipped"

class Base(DeclarativeBase):
    pass

class Order(Base):
    __tablename__ = "orders"
    id = Column(Integer, primary_key=True)
    status = Column(Enum(OrderStatus), nullable=False)
    created_at = Column(DateTime, nullable=False)

Найкращі практики міграції схем

Досвідчені команди виробили набір правил Schema Migration, які знижують ризик збоїв та спрощують налагодження. Дотримання цих практик — ознака зрілої інженерної культури. П'ять ключових правил охоплюють проектування, тестування та деплой міграцій.

Одна міграція — одна зміна

Кожна Schema Migration повинна робити рівно одну логічну зміну: створити таблицю, додати колонку або змінити індекс. Змішування декількох операцій в одній міграції ускладнює відкат — якщо друга операція впала, перша вже застосувалася і її потрібно відкочувати окремо. Малі кроки — основа надійних міграцій.

Ніколи не редагувати опубліковані міграції

Після того як міграція застосована до production, її не можна змінювати — тільки створити нову, яка виправляє проблему. Редагування опублікованої міграції ламає трекер: розробники з іншою базою побачать хеш-невідповідність. Immutable міграції гарантують передбачувану поведінку на всіх середовищах.

Тестування на копії production

Перед застосуванням Schema Migration на production виконайте її на копії продакшен-даних. Мета — перевірити швидкість виконання, наявність блокувань таблиць та коректність змін. Для великих таблиць ALTER TABLE може блокувати запис на години — тест виявить це заздалегідь. Staging з продакшен-дампом — обов'язковий крок.

Уникати NOT NULL для нових колонок

Нова колонка без значення за замовчуванням з NOT NULL — часта причина збою міграції. В існуючих записах значення буде NULL, і NOT NULL викличе помилку. Best practice: створити колонку з дефолтом та nullable, потім окремою міграцією додати NOT NULL після заповнення даних.