Schema Migration — istota, typy i narzędzia migracji schematów BD

Co to jest Schema Migration

Schema Migration to praktyka zarządzania zmianami struktury bazy danych za pomocą wersjonowanych plików, które są kolejno stosowane w różnych środowiskach. Każdy plik zawiera zestaw poleceń SQL: utworzenie tabeli, dodanie kolumny, zmiana indeksu lub aktualizacja ograniczeń. Narzędzie migracji śledzi zastosowane wersje i gwarantuje, że każda zmiana jest wykonywana dokładnie raz.

W przeciwieństwie do Data Migration, która przenosi zawartość tabel, Schema Migration zarządza tylko strukturą — operacjami DDL. To fundamentalna różnica: Schema Migration działa przed Data Migration, tworząc docelowy schemat, do którego następnie ładowane są dane. Według Redgate (2024) 62% incydentów w produkcyjnych bazach danych wiąże się z ręcznymi zmianami schematu bez skryptów migracyjnych.

Wersjonowanie migracji

Każda Schema Migration otrzymuje unikalny identyfikator — zazwyczaj wersję (V1, V2) lub znacznik czasu. Narzędzie przechowuje w specjalnej tabeli (flyway_schema_history, alembic_version) listę zastosowanych migracji. Przy uruchomieniu porównuje listę z plikami w classpath i stosuje tylko nowe. Idempotentność to kluczowa właściwość: ponowne uruchomienie nie powoduje efektów ubocznych.

Rodzaje zmian schematu

Typowe operacje Schema Migration: tworzenie tabel (CREATE TABLE), dodawanie kolumn (ALTER TABLE ADD COLUMN), zmiana typów, tworzenie indeksów, dodawanie kluczy obcych i aktualizacja sekwencji. Bardziej złożone migracje obejmują zmianę nazwy kolumn z zachowaniem danych, podział tabeli na kilka i replikację schematu na shardy.

Po co potrzebna jest migracja schematu BD

Bez Schema Migration programiści ręcznie modyfikują BD — wykonują DDL w konsoli, dodają kolumny w środowisku deweloperskim i kopiują je do stagingu z pamięci. Rezultat: rozbieżność schematów między środowiskami, utrata zmian przy wdrożeniu i uszkodzone migracje na produkcji. Schema Migration rozwiązuje trzy kluczowe problemy: spójność, odtwarzalność i audyt.

Spójność między środowiskami

Gdy struktura BD jest opisana w kodzie, jest identyczna w dev, staging i production. Programista nie może zapomnieć zastosować zmiany — narzędzie wykona wszystkie pominięte migracje po kolei. Jeśli na produkcji brakuje kolumny, a kod jej wymaga — aplikacja zgłosi błąd. Automatyczna weryfikacja eliminuje ten scenariusz.

Odtwarzalność dla nowych programistów

Nowy członek zespołu uruchamia flyway migrate i otrzymuje aktualny schemat w kilka sekund — bez zrzutu z produkcji i ręcznych zapytań DDL. Jest to szczególnie ważne w architekturze mikrousług, gdzie każda usługa ma własną BD, a schemat składa się z dziesiątek migracji. Pełna odtwarzalność skraca czas wdrożenia z dni do minut.

Audyt zmian

Każda Schema Migration jest przechowywana w systemie kontroli wersji razem z kodem aplikacji. Można otworzyć Pull Request, zobaczyć dokładne polecenia SQL zmieniające schemat i przeprowadzić code review. W razie incydentu łatwo określić, która migracja została zastosowana jako ostatnia i kto jest jej autorem. Historia Git zapewnia pełny ślad zmian bazy danych przez cały czas trwania projektu.

Narzędzia migracji schematów

Na rynku istnieją dziesiątki narzędzi Schema Migration dla różnych języków i platform. Wybór zależy od stosu technologicznego, formatu opisu migracji i wymagań dotyczących wycofywania zmian. Rozważmy główne kategorie i popularne narzędzia.

Jak wybrać narzędzie

Dla stosów Java/Kotlin — Flyway jako najlżejszy i najbardziej przewidywalny. Dla projektów z częstymi wycofywaniami — Liquibase, który ma rollback wbudowany architektonicznie. Dla Python/Django — Alembic jako standardowe narzędzie SQLAlchemy. Dla startupów bez inżyniera DevOps — wybierz narzędzie z najmniejszą konfiguracją: Flyway wymaga tylko pliku ze skryptem i polecenia migrate.

Rozwiązania komercyjne

Oprócz narzędzi open-source istnieją komercyjne: Redgate SQL Change Automation, Datical DB i DBmaestro. Oferują one wizualne porównywanie schematów, automatyczne rozwiązywanie konfliktów i integrację z pipeline'ami CI/CD. Jednak dla większości projektów Flyway lub Alembic pokrywają 100% potrzeb bez dodatkowych licencji.

Migracja z Flyway

Rozważmy praktyczny przykład Schema Migration w Kotlin z Flyway. Stwórzmy migrację dodającą tabelę orders do bazy danych PostgreSQL. Flyway automatycznie tworzy tabelę flyway_schema_history i śledzi zastosowane wersje.

-- 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)
);

Podłączenie Flyway w projekcie Kotlin przez konfigurację dataSource. Po konfiguracji polecenie flyway:migrate zastosuje wszystkie nowe migracje z classpath.

// FlywayConfig.kt — Konfiguracja Flyway w 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 dla projektów Python

Alembic to narzędzie Schema Migration dla języka Python, zbudowane na bazie SQLAlchemy. Jego kluczową cechą jest auto-generacja skryptów na podstawie porównania modelu SQLAlchemy z bieżącym schematem BD. Alembic nadaje się do projektów w Django, FastAPI i Flask.

Inicjalizacja i tworzenie migracji

Po inicjalizacji (alembic init alembic) i konfiguracji connection string, polecenie alembic revision --autogenerate skanuje modele SQLAlchemy i generuje skrypt migracji. Programiście pozostaje sprawdzenie wygenerowanego kodu i zastosowanie go przez alembic upgrade head. Autogenerate oszczędza godziny ręcznego pisania DDL.

# models.py — Model SQLAlchemy do auto-generacji
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)

Najlepsze praktyki migracji schematów

Doświadczone zespoły wypracowały zestaw reguł Schema Migration, które zmniejszają ryzyko awarii i ułatwiają debugowanie. Przestrzeganie tych praktyk jest oznaką dojrzałej kultury inżynieryjnej. Pięć kluczowych zasad obejmuje projektowanie, testowanie i wdrażanie migracji.

Jedna migracja — jedna zmiana

Każda Schema Migration powinna wprowadzać dokładnie jedną logiczną zmianę: utworzyć tabelę, dodać kolumnę lub zmienić indeks. Mieszanie kilku operacji w jednej migracji utrudnia wycofanie — jeśli druga operacja się nie powiedzie, pierwsza już została zastosowana i trzeba ją wycofać osobno. Małe kroki to podstawa niezawodnych migracji.

Nigdy nie edytować opublikowanych migracji

Po zastosowaniu migracji na produkcji nie można jej modyfikować — należy utworzyć nową, która naprawia problem. Edytowanie opublikowanej migracji psuje tracker: programiści z inną bazą danych zobaczą niezgodność skrótu. Niezmienne migracje gwarantują przewidywalne działanie we wszystkich środowiskach.

Testowanie na kopii produkcji

Przed zastosowaniem Schema Migration na produkcji wykonaj ją na kopii danych produkcyjnych. Celem jest sprawdzenie szybkości wykonania, występowania blokad tabel i poprawności zmian. W przypadku dużych tabel ALTER TABLE może blokować zapis na godziny — test ujawni to z wyprzedzeniem. Staging z kopią produkcji to obowiązkowy krok.

Unikać NOT NULL dla nowych kolumn

Nowa kolumna bez wartości domyślnej z NOT NULL to częsta przyczyna błędu migracji. W istniejących rekordach wartość będzie NULL i NOT NULL spowoduje błąd. Najlepsza praktyka: utwórz kolumnę z wartością domyślną i nullable, a następnie osobną migracją dodaj NOT NULL po wypełnieniu danych.