Narzędzie do automatyzacji migracji bazy danych

Tytuł	Narzędzie do automatyzacji migracji bazy danych
Standard	[In progress] Ewolucja schematu bazy danych (Flyway)
Status
Data zgłoszenia	21.09.2022
Autorzy	Łukasz Szymańczuk
Właściciele	Łukasz Szymańczuk
Epik	<style type="text/css"> #refresh-module-1299135598 .icon { background-position: left center; background-repeat: no-repeat; display: inline-block; font-size: 0; max-height: 16px; text-align: left; text-indent: -9999em; vertical-align: text-bottom; } </style>
Kontekst	Narzędzie DO zarządzania Schematem bazy danych 1. Dlaczego? Włączenie narzędzi automatyzujących zarządzanie zmianami w schemacie baz danych do procesu wytwarzania oprogramowania jest szeroko stosowaną praktyką mającą na celu skrócenie czasu potrzebnego do zaimplementowania i wdrożenia kolejnych zmian oraz zmniejszenie ryzyka popełnienia błędu. 2. Narzędzia A. Liquibase Narzędzie open source umożliwiające tworzenie skryptów migracji w SQL, YAML, JSON lub XML. Migracje są zarządzane za pomocą changelogu w którym definiujemy jakie migracje i w jakiej kolejności mają zostać wykonane. Aktualny stan bazy danych przechowywany jest domyślnie w tabeli databasechangelog B. Flyway Również jest narzędziem typu open source. Nie stosuje changelogu, a konwencję nazewniczą plików. Każdy plik rozpoczyna się jednym z 3 prefixów: V dla nowej migracji, U dla wycofania migracji, R dla migracji powtarzającej się. Po prefixie następuje ciąg definiujący wersję, separator oraz nazwa migracji, wersją może być zarówno liczba, data jak i dowolny ciąg alfanumeryczny np. V1__Init.sql. Aktualny stan również w tym przypadku przechowywany jest w specjalnej tabeli, domyślnie jest to flyway_schema_history. 3. Przykłady użycia Poniższe przykłady zakładają użycie Flyway i Spring Boot, w przypadku użycia Liquidbase i/lub innych frameworków zasada działania pozostaje taka sama. A. Jeden serwis - jedna baza – jedno repozytorium W tym najprostszym przypadku: · załączamy zależność do Flyway do konfiguracji gradle/maven · tworzymy migracje w katalogu src/main/resources/db/migration · migracja jest automatycznie wykonywana na starcie serwisu B. Wiele serwisów – jedna baza – jedno repozytorium Podobnie jak w przypadku wyżej, ale: · Tworzymy dedykowany moduł z plikami migracji i zależnością do Flyway · Moduł załączamy do innych serwisów w repozytorium · Migracja jest automatycznie wykonywana podczas starty dowolnego serwisu C. Wiele serwisów – jedna baza – wiele repozytoriów W odróżnieniu od sytuacji wyżej: · Moduł z migracją i zależnością Flyway umieszczamy w dedykowanym repozytorium · Moduł w procesie CI publikuje bibliotekę do repozytorium artefaktów, którą załączają zainteresowane serwisy · Dodatkowo jest budowany obraz Docker zawierający skrypty migracyjne oraz Flyway wykonujący te skrypty na starcie kontenera · Serwisy wykonują migrację na środowiskach lokalnych, developerskich, testowych ale jest ona wyłączona dla środowisk staging, production itp · Obraz Docker jest używany manualnie lub półautomatycznie do wykonania migracji na środowiskach staging, production itp., np. za pomocą Gitlab CI/CD lub Kubernetes Job D. Środowisko z predefiniowanymi użytkownikami Jest to przypadek w którym baza posiada predefiniowanych użytkowników na środowiskach przygotowanych przez zespół DBA w odróżnieniu od środowisk lokalnych czy testów integracyjnych: · Skrypty wspólne dla obu środowisk umieszczamy w katalogu db/migration/common, a skrypty specyficzne dla poszczególnych środowisk w osobnych katalogach np. db/migration/prod · A konfiguracji serwisu tworzymy konfigurację dla danego środowiska np. application-local.yaml i application-prod.yaml · W application-prod.yaml wskazuje na migracje z katalogów db/migration/common i db/migration/prod i analogiczne dla środowiska local jeśli potrzebujemy, jeśli nie wskazujemy tylko katalog db/migration/common np: spring: flyway: locations: classpath:db/migration/common,classpath:db/migration/${spring.profiles.active} · W katalogu dla danego środowiska możemy teraz zdefiniować skrypty i lub callbacki specyficznym dla tej sytuacji np. w pliku db/migration/prod/afterMigration.sql możemy zdefiniować nadanie uprawnień dla użytkowników istniejących tylko na tym środowisku 4. Źródła A. https://www.red-gate.com/blog/database-development/why-and-how-you-should-automate-database-migrations B. https://github.blog/2020-02-14-automating-mysql-schema-migrations-with-github-actions-and-more/ C. https://www.baeldung.com/liquibase-vs-flyway D. https://flywaydb.org/documentation/concepts/callbacks
Decyzje	Wartość wynika z automatyzacji procesu, spójności środowisk, ułatwienia rozwoju i testów projektów, a nie z wybrania jednego konkretnego rozwiązania Flyway i Liquidbase oferują niemal identyczny model pracy, jest to “szczegół” implementacji który nie wycieka poza dany projekt Dopuszczamy użycie obu rozwiązań: Flyway i Liquidbase Flyway jest preferowanym rozwiązaniem dla nowych projektów ze względu na nieco większą popularność - zarówno w firmie jak i poza nią
Konsekwencje	Nowe projekty (JVM) MUSZĄ używać Flyway lub ewentualnie Liquidbase Rozwijane projekty POWINNY wdrożyć Flyway lub Liquidbase W pozostałych projektach (legacy) MOŻNA rozważyć użycie Flyway/Liquidbase, chociażby w formie obrazu dockerowego który wykonuje skrypty w sposób półautomatyczny np w manualnie wyzwalanym etapie pipeline’a CI/CD TRZEBA stworzyć przykłady użycia Flyway i Liquidbase oraz udostępnić je jako repozytorium dostępne do odczytu dla wszystkich chętnych

Notatki

[ITD-89] Narzędzie do automatyzacji migracji bazy danych - Jira (atlassian.net)

Last modified: 30 May 2024