{"id":2904,"date":"2022-01-03T14:19:57","date_gmt":"2022-01-03T13:19:57","guid":{"rendered":"https:\/\/arasoftware.pl\/?p=2904"},"modified":"2022-01-03T14:20:00","modified_gmt":"2022-01-03T13:20:00","slug":"flyway-migrowanie-bazy-danych-w-aplikacji-spring-boot","status":"publish","type":"post","link":"https:\/\/arasoftware.pl\/en\/flyway-migrowanie-bazy-danych-w-aplikacji-spring-boot\/","title":{"rendered":"Flyway – migrowanie bazy danych w aplikacji Spring Boot"},"content":{"rendered":"Czas czytania: <\/span> 4<\/span> minut<\/span><\/span>

Czym jest Flyway?<\/h3>\n\n\n

Flyway jest narzędziem pozwalającym utrzymywać bazę danych w odpowiedniej wersji za pomocą migracji. Eliminuje to problemy z utrzymaniem spójności. Wprowadza również prosty, ale wystarczający, system kontroli wersji baz danych. <\/strong>Aplikacje wykorzystujące Flayway mogą same zarządzać wersją bazy danych na danym środowisku.<\/p>\n\n\n

Często spotykamy się z problemem „rozjazdów” na bazie danych pomiędzy poszczególnymi środowiskami, na których jest zainstalowana aplikacja. W przypadku kodu źródłowego utrzymywanie jednej spójnej wersji aplikacji jest stosunkowo proste. Wystarczy użyć jednego z dostępnych systemów kontroli wersji. A co ze strukturą bazy danych, z której korzysta aplikacja? Jak ją wersjonować i utrzymywać jej spójność?<\/p>\n\n\n

Flyway i Spring Boot – Instalacja zależności i konfiguracja<\/h3>\n\n\n

Jak każda zależność w Spring, tak i Flyway musi zostać zaimportowany do naszego projektu za pośrednictwem np. Maven’a. Dodatkowo musimy stworzyć nowy plugin w naszym pliku pom.xml, który będzie wykorzystywany przez maven’a podczas budowania projektu. <\/p>\n\n\n

Na początek dodajmy niezbędne zależności. W naszym pokazowym projekcie użyjemy Postgres’a jako bazę danych. Musimy pamiętać, że jeśli chcemy używać bazy danych w naszej aplikacji, to pomocne będzie dodanie też zależności „spring-boot-starter-data-jpa”<\/p>\n\n\n\n

    <dependencies>\r\n\t\t<dependency>\r\n\t\t\t<groupId>org.springframework.boot<\/groupId>\r\n\t\t\t<artifactId>spring-boot-starter-data-jpa<\/artifactId>\r\n\t\t<\/dependency>\r\n\t\t<dependency>\r\n\t\t\t<groupId>org.flywaydb<\/groupId>\r\n\t\t\t<artifactId>flyway-core<\/artifactId>\r\n\t\t\t<version>${flyway.version}<\/version>\r\n\t\t<\/dependency>\r\n\t\t<dependency>\r\n\t\t\t<groupId>org.postgresql<\/groupId>\r\n\t\t\t<artifactId>postgresql<\/artifactId>\r\n\t\t\t<version>42.2.8<\/version>\r\n\t\t\t<scope>runtime<\/scope>\r\n\t\t<\/dependency>\r\n\t\t<dependency>\r\n\t\t\t<groupId>org.springframework.boot<\/groupId>\r\n\t\t\t<artifactId>spring-boot-starter-test<\/artifactId>\r\n\t\t\t<scope>test<\/scope>\r\n\t\t<\/dependency>\r\n\t\t<dependency>\r\n\t\t\t<groupId>org.springframework.boot<\/groupId>\r\n\t\t\t<artifactId>spring-boot-starter-web<\/artifactId>\r\n\t\t<\/dependency>\r\n\t<\/dependencies><\/code><\/pre>\n\n\n
Twoje sprawne oko programisty pewnie zobaczyło, że wersja Flyway’a jest ukryta pod placecholderem „${flyway.version}”. Nie musisz definiować tej właściwości samodzielnie w pliku pm.xml. Standardowa konfiguracja zależności Spring Boot’a na Twoim środowisku deweloperskim powinna zawierać definicję wersji Flyway – tak jak na obrazie poniżej.<\/p>\n\n\n\n
\"Spring
Wersje zale\u017cno\u015bci Spring Boot<\/figcaption><\/figure>\n\n\n
Wspomniałem wcześniej o implementacji pluginu w pom.xml. Oto on \ud83d\ude42<\/p>\n\n\n\n
            <plugin>\r\n\t\t\t\t<groupid>org.flywaydb<\/groupid>\r\n\t\t\t\t<artifactid>flyway-maven-plugin<\/artifactid>\r\n\t\t\t\t<version>${flyway.version}<\/version>\r\n\t\t\t\t<configuration>\r\n\t\t\t\t\t<driver>org.postgresql.Driver<\/driver>\r\n\t\t\t\t\t<url>jdbc:postgresql:\/\/localhost:5432\/postgres<\/url>\r\n\t\t\t\t\t<user>postgres<\/user>\r\n\t\t\t\t\t<password>my_password<\/password>\r\n\t\t\t\t\t<table>flyway_schema_history<\/table>\r\n\t\t\t\t\t<locations>\r\n\t\t\t\t\t\t<location>classpath:db\/migration\/<\/location>\r\n\t\t\t\t\t<\/locations>\r\n\t\t\t\t<\/configuration>\r\n\t\t\t<\/plugin><\/code><\/pre>\n\n\n
Plugin zawiera kilka istotnych informacji. Pierwszą z nich jest definicja połączenia do bazy danych, która będzie wykorzystywana do naszej aplikacji. Standardowo jak dla każdej aplikacji w Spring Boot podajemy tutaj dane o driverze, URL za pomocą którego możemy się połączyć z naszą bazą, nazwa użytkownika oraz hasło.<\/p>\n\n\n
Flayway do trzymania informacji o wersjach bazy danych wykorzystuj\u0119…. w\u0142a\u015bnie baz\u0119 danych \ud83d\ude42 Oczywi\u015bcie jest mu potrzebna dedykowana tabela w naszej bazie, która b\u0119dzie przechowywa\u0142a informacje o wykonanych migracjach. Jej nazw\u0119 mo\u017cna skonfigurowa\u0107 za pomoc\u0105 opcji „<table>” w pluginie. W projekcie pokazowym jest ona ustawiona na „flyway_schema_history”.<\/p>\n\n\n
Ostatnim niezbędnym elementem konfiguracji pluginu jest podanie katalogu, w którym będą przetrzymywane skrypty SQL. Możemy podać tu wiele różnych lokalizacji. Dla uproszczenia użyjemy tutaj standardowej lokalizacji „classpath:db\/migration\/”. Musimy pamiętać, aby utworzyć w naszym projekcie taką strukturę katalogów.<\/p>\n\n\n
Flyway i Spring Boot – Tworzenie migracji<\/h3>\n\n\n
Kolejnym krokiem, jaki musisz wykonać, jest utworzenie pierwszego pliku migracji. Nazwijmy go V1_0__init_db.sql. Dziwna nazwa? Jest ona podyktowana pewną konwencją nazewniczą. Zawiera ona wersję oraz opis migracji. W naszym przypadku po zbudowaniu aplikacji powinniśmy posiadać bazę danych w wersji 1.0, a nazwa migracji powinna być ustawiona na „init db”. Separatorem tych informacji jest podwujny znak „_”. To, co jest zdefiniowane przed tym separatorem, jest uznawane przez Flyway’a za wersję migracji. Natomiast wszystko za separatorem jest opisem naszej migracji.<\/p>\n\n\n\n
\"Flyway
Flyway – przyk\u0142adowa migracja<\/figcaption><\/figure>\n\n\n
Czas napisać Prosty skrypt SQL, który stworzy testową tabelę, która będzie przechowywała podstawowe informacje o użytkownikach aplikacji.<\/p>\n\n\n\n
CREATE TABLE USERS (\r\n  ID INT NOT NULL,\r\n  FIRST_NAME VARCHAR(50) NOT NULL,\r\n  LAST_NAME VARCHAR(50) NOT NULL,\r\n  EMAIL VARCHAR(50) NOT NULL\r\n);<\/code><\/pre>\n\n\n
Zarządzanie migracjami<\/h3>\n\n\n
Do odpalenia naszej migracji wystarczy, że uruchomisz swoją aplikację. Po poprawnym uruchomieniu aplikacji w logach powinniśmy zobaczyć, że Flyway zmigrował bazę danych do wersji 1.0.<\/p>\n\n\n\n
\"Flyway
Flyway – logi z migracji<\/figcaption><\/figure>\n\n\n
W bazie danych widać, że Flyway utworzył dwie tabele:<\/p>\n\n\n