Database Migrations
Flyway, Liquibase, Alembic — wersjonowanie schematu bazy, zero-downtime migrations, expand-contract pattern i rollback w mikrousługach.
6 narzędzi do migracji baz danych
Każde narzędzie jest dopasowane do innego ekosystemu i poziomu zaawansowania wymagań dotyczących rollback i automatyzacji.
| Narzędzie | Język/Format | Rollback | Autogenerowanie | Bazy | Kiedy |
|---|---|---|---|---|---|
| Flyway | Java / SQL | Tylko Teams (płatny) | Nie | PostgreSQL, MySQL, Oracle, SQL Server, inne | Simple SQL-first, Java ecosystem |
| Liquibase | XML/YAML/SQL/JSON | Wbudowany | Nie | Wszystkie (50+ baz) | Enterprise, multi-DB, rollback wymagany |
| Alembic | Python | downgrade() | Tak (z SQLAlchemy) | PostgreSQL, MySQL, SQLite, MS SQL | Python/FastAPI/Django projekty |
| Django Migrations | Python | migrate do poprzedniej wersji | Tak (automatyczne) | PostgreSQL, MySQL, SQLite, Oracle | Django aplikacje |
| Prisma Migrate | TypeScript | Manual SQL | Tak (z Prisma schema) | PostgreSQL, MySQL, SQLite, MongoDB | Node.js/TypeScript projekty |
| Goose | Go / SQL | down() function | Nie | PostgreSQL, MySQL, SQLite, MS SQL | Go microservices |
Często zadawane pytania
Co to są database migrations i jakie narzędzia wybrać?
Database migrations: skrypty zmieniające schemat bazy danych w kontrolowany, wersjonowany sposób. Bez migracji: każdy developer ma inną wersję schematu. Środowisko staging różni się od produkcji. Nie ma historii zmian. Problem rollback. Z migracjami: każda zmiana schematu = osobny plik migracji. Numerowane lub timestampowane (20240413_001_add_user_table.sql). Narzędzie wykonuje pending migracje w kolejności. Śledzi które zostały wykonane (tabela schema_migrations lub flyway_schema_history). Narzędzia migracji: Flyway (Java/JVM, ale działa dla każdej DB): wersjonowane SQL lub Java migracje. V1__init.sql, V2__add_index.sql. Repeatable migracje (R__) dla views/functions. Baseline dla istniejących baz. Liquibase: XML/YAML/JSON/SQL changesets. Changeset tracking per author i id. Rollback support (wbudowany). Alembic (Python, SQLAlchemy): autogenerate migracji z modeli. Revision system. Goose (Go): SQL lub Go migracje. Wbudowany w wiele Go frameworków. Flyway vs Liquibase: Flyway — prostszy, SQL-first. Liquibase — bardziej zaawansowany, rollback, wieloplatformowy. Rails ActiveRecord Migrations: Ruby DSL. up/down methods. Zero-downtime migrations gems.
Zero-downtime database migrations — jak nie blokować produkcji?
Wyzwanie: ALTER TABLE na dużej tabeli (miliony wierszy) blokuje tabelę na minuty lub godziny. Użytkownicy nie mogą czytać ani pisać. Problem: dodanie NOT NULL kolumny, zmiana typu, dodanie constraint. Strategie zero-downtime: 1. Dodaj kolumnę jako nullable: ALTER TABLE orders ADD COLUMN new_field VARCHAR(255). Nie blokuje, bo domyślnie nullable. 2. Backfill danych: UPDATE orders SET new_field = compute(old_field) WHERE new_field IS NULL LIMIT 1000. Batch update (nie blokuj cały UPDATE). 3. Dodaj NOT NULL constraint z DEFAULT: ALTER TABLE orders ALTER COLUMN new_field SET NOT NULL. 4. Usuń starą kolumnę (po migracji kodu). Expand-Contract pattern: Expand — dodaj nowe pole/tabelę. Contract — usuń stare po migracji kodu. Rolling rename: kolumna renamed -> dodaj nową, kopiuj dane, stara pozostaje jako alias, usuń starą. pg_repack / online DDL: pg_repack — przebudowuje tabelę bez blokowania. CREATE TABLE AS SELECT, swap. Percona pt-online-schema-change dla MySQL. MySQL 8+ / PostgreSQL 12+ mają wbudowane online DDL. gh-ost (GitHub): ghost table approach. Online schema migration dla MySQL. Używany przez GitHub. Liquibase Pro: wbudowane runAlways migrations. Flyway Dry Runs: weryfikacja przed produkcją.
Flyway — jak skonfigurować i używać w CI/CD?
Flyway konfiguracja: flyway.url = jdbc:postgresql://localhost:5432/mydb. flyway.user = dbuser. flyway.password = secret. flyway.locations = classpath:db/migration. Konwencja nazw: V{version}__{description}.sql. V1__Create_users_table.sql. V2__Add_email_index.sql. V2.1__Add_role_column.sql. Repeatable: R__{description}.sql — wykonywane gdy checksum zmieni się. Dobre dla views, functions, stored procedures. Baseline: flyway baseline — oznacz istniejącą DB jako wyjściowy punkt. Flyway Maven/Gradle plugin: mvn flyway:migrate — wykonaj pending migracje. mvn flyway:info — pokaż status migracji. mvn flyway:validate — sprawdź checksum. mvn flyway:repair — napraw failed migracje. CI/CD integration: Spring Boot auto-migrate przy starcie (spring.flyway.enabled=true). Kubernetes init container: wywołaj flyway:migrate przed startem aplikacji. GitHub Actions: krok 'Run DB migrations' przed 'Deploy application'. Multiple environments: osobna konfiguracja flyway per environment. flyway.out-of-order=false — nie pozwól na migracje poza kolejnością. Checksum validation: Flyway oblicza checksum dla każdego pliku. Zmodyfikowanie wykonanej migracji = błąd. Nigdy nie modyfikuj wykonanych migracji — twórz nowe. Flyway Teams: undo support (V1__create.sql -> U1__undo_create.sql). Dry run. Cherry-pick.
Rollback database migrations — jak cofnąć zmiany?
Rollback schematu bazy: trudniejszy niż rollback kodu (nie możesz po prostu wrócić do poprzedniej wersji). Podejścia: Up/Down migrations: każda migracja ma up() i down(). up() = wykonaj zmianę. down() = cofnij zmianę. Problem: przy dużej ilości danych down() może nie odtworzyć usuniętych danych. Liquibase rollback: OOTB support. rollback przez tag lub date. Odwraca changesets w odwrotnej kolejności. Flyway Undo (Teams): U{version}__{description}.sql. flyway:undo — cofnij ostatnią migrację. Expand-Contract rollback: Contract krok (usunięcie starego) = osobny deploy. Rollback = nie wykonaj Contract kroku. Stare i nowe istnieją razem. Feature Flags: aplikacja ma feature flag per migration. Rollback = wyłącz flag (nie cofaj schematu). Backup przed migracją: snapshot DB przed dużą migracją. Rollback = restore snapshot (downtime ale bezpieczne). Incremental backup (WAL-G dla PostgreSQL). Blue-Green Deployment: dwa środowiska (Blue = stare, Green = nowe). Migration na Green. Switch traffic na Green. Rollback = switch z powrotem na Blue. Wymaga synchronizacji danych między Blue i Green. Migration testing: sprawdź migrację na staging przed produkcją. Test down() przed produkcją. Automated rollback tests w CI.
Database schema evolution w mikrousługach — jak zarządzać?
Wyzwanie mikrousług: każda mikrousługa ma własną bazę danych. Każda może być deployowana niezależnie. Musimy zapewnić backward compatibility podczas rolling deployment. Zasady schema evolution: Additive changes only (dodaj, nie modyfikuj/usuwaj): dodanie nowej kolumny (nullable). dodanie nowej tabeli. dodanie nowego indeksu (CONCURRENTLY). Never remove columns that code uses: deprecate -> aplikacja przestaje używać -> usuń kolumnę. Two-phase deployment: faza 1 — deploy nowego kodu który obsługuje zarówno stary jak i nowy schemat. Wykonaj migrację. faza 2 — deploy kodu który wymaga nowego schematu (usuwa obsługę starego). Shared Database Anti-Pattern: wiele mikrousług na jednej bazie. Trudne migracje bo wiele serwisów zależy od jednego schematu. Rozwiązanie: oddzielna baza per mikrousługa. Consumer-Driven Contract Testing: definiuje kontrakt między serwisem a jego bazą. Schemaspy: automatyczna dokumentacja schematu. Diagram ER z istniejącej bazy. Liquibase Checks: automated compliance checks. Blokuj kolumny bez default przy NOT NULL. Enforced naming conventions. Database Schema Registry: centralne repozytorium schematów. Event Schema Registry (Confluent) dla event-driven. Avro/Protobuf schema evolution (backward/forward compatible). Migration in large teams: każdy developer tworzy własną gałąź migracji. Sequentialna numeracja przez CI (timestamp). Merge konflikty na numerach = CI blokuje.
Powiązane artykuły
Skontaktuj się z nami
Porozmawiajmy o Twoim projekcie. Bezpłatna wycena w ciągu 24 godzin.
Wyślij zapytanie
Telefon
+48 790 814 814
Pon-Pt: 9:00 - 18:00
adam@fotz.pl
Odpowiadamy w ciągu 24h
Adres
Plac Wolności 16
61-739 Poznań
Godziny pracy
Wolisz porozmawiać?
Zadzwoń teraz i porozmawiaj z naszym specjalistą o Twoim projekcie.
Zadzwoń teraz