In questo articolo voglio spiegarti come far sì di utilizzare Flyway per la migrazione degli script del database con una web app che utilizza Spring Boot. Normalmente per fare queste prove utilizzo Heroku così da poter rilasciare l’applicazione. Se vuoi partire dalla base ed utilizzare Heroku ti consiglio di iscriverti al piano gratuito e dunque seguire questo tutorial. Se vuoi ho scritto anche un articolo con video per guidarti: [VIDEO] Come Registrarsi e Come Iniziare con Heroku.

Una volta che hai la tua applicazione Java sei pronto per partire.

Cos’è Flyway?

Flyway è un tool per la migrazione del database. Funziona con Oracle, PostgreSQL, SQLServer, MySQL, MariaDB, SQLite, Derby e tanti altri database. E’ molto affidabile, infatti non mi ha mai dato un problema nemmeno con applicazioni cross-schema, né con script di grandi dimensioni (non mi viene in mente un caso in cui non abbia funzionato). Ti permette di tenere traccia delle modifiche che vengono fatte al database aiutandoti a mantenere un database identico in ogni ambiente.

Per esempio in passato utilizzavo diversi ambienti per ciascuna applicazione: locale, sviluppo, test e produzione. Ognuno di questi ha il suo database. In locale ho tutto ciò che sto sviluppando, incluse tabelle nuove ed i miei script arrivano alla versione 000625. In sviluppo ancora mancano gli ultimi 2 script e siamo alla versione 000623. Non appena farò push (o solo commit per chi usa SVN) l’ambiente di sviluppo subirà cambiamenti nel database con la migrazione che eseguirà gli script 000624 e 000625. In test il mio ambiente invece è più o meno stabile, serve al cliente per poter accedere e testare i nuovi sviluppi e trova solo feature concluse. La migrazione del database in test è ferma alla versione 000610. In produzione gli utenti non ricevono rilasci da 2 settimane, quindi ho ancora la versione 000605.

Mentre sviluppo, se trovo un errore in una struttura del database, una function, trigger o procedure non devo far altro che fare un nuovo script per risolvere il problema ed il problema verrà risolto in tutti gli ambienti durante i rilasci. La cosa positiva è che avendo eseguito con estrema certezza sempre gli stessi script flyway e sempre nello stesso ordine, se l’errore è presente in un ambiente è sicuramente presente in tutti gli altri ambienti (o almeno in tutti quelli che hanno effettuato già quella migrazione).

Non ti dimenticare anche dei team con più sviluppatori. Non c’è modo più sicuro di questo per far sì che tutti abbiano la stessa identica situazione in locale.

Il Main

Una volta fatto il setup iniziale della spring boot app seguendo il tutorial di cui sopra ti ritroverai con una classe Main.

Questa classe utilizza già le annotazioni:

• @Controller
• @SpringBootApplication

Inoltre è caratterizzata da diversi endpoint e dal @Bean del DataSource. All’interno del Bean del DataSource puoi iniziare ad utilizzare Flyway da codice. Nel mio caso ho cercato di fare una configurazione iniziale e rapida:

Quando farai partire l’applicazione e verrà eseguito il bean avrai il datasource “popolato” e verrà eseguito il migrate di flyway.

Quali script vengono utilizzati?

Gli script SQL che vengono utilizzati vanno inseriti di default in src/main/resources/db/migration e vanno nominati in forma V{numero_versione}__{nome_script}{estensione}. Per esempio “V000000__init.sql” o anche “V000001__createTableDogs.sql”:

Il pom

Nel file pom.xml è necessario inserire la dipendenza a flyway-core, quindi:

• groupId > org.flywaydb
• artifactId > flyway-core

La version va specificata solo se non si sta usando Spring Boot o un’altra dipendenza che già si porta con sé flyway-core.

Dopo di che, per chi utilizza Spring Boot e riceve l’errore di ClassNotFoundException sulla classe org.springframework.jdbc.support.MetaDataAccessException deve inserire nel pom.xml anche il richiamo alla dipendenza:

• groupId > org.springframework
• artifactId > spring-jdbc

Esecuzione

Collegati al database con il tuo strumento preferito e fai partire la tua applicazione. Nel caso di Heroku ricorda di eseguire in ordine:

• mvn package
• heroku local

A questo punto vedrai comparire le tabelle nel tuo schema. Per questa applicazione ho un database locale ed un database di produzione. Quando fai il push della tua applicazione ed esegui il deploy (nel caso di Heroku è automatico con il push) anche il tuo database di produzione subirà la migrazione degli script.

Conclusione

In questo articolo hai imparato perché è importante utilizzare Flyway e come utilizzarlo con Heroku in particolare. Perchè con Heroku in particolare? Perché nonostante preferisco utilizzare Flyway con il plugin Maven su Heroku non è possibile fare un’operazione di questo tipo. Per approfondire questo argomento puoi provare a seguire anche questa guida.

A breve mi pongo come obiettivo quello di creare un corso su Udemy per insegnare ad un pubblico più vasto come creare un vero e proprio gestionale ReactJS + Java + PostgreSQL.

Se ti è piaciuto l’articolo seguimi su Facebook e Twitter oppure rimani sempre aggiornato con la newsletter (da 1 a 4 mail al mese!)