O que é Flyway?

Flyway é uma ferramenta de migração de banco de dados de código aberto que permite aos desenvolvedores aplicar práticas de controle de versão em seus bancos de dados. As alterações feitas no banco de dados pelo Flyway são conhecidas como Migrações. No Flyway, as migrações têm dois tipos; eles podem ser versionados ou repetíveis, sendo versionado o mais comum.

Por que o versionamento do esquema é necessário?

Os aplicativos, se quiserem ter algum valor, mudarão e evoluirão com o tempo. Quando os aplicativos evoluem, os bancos de dados mudam, tornando necessária a migração de dados.

Essa migração de dados é necessária ao atualizar o esquema do banco de dados em ambientes de produção e para atualizar servidores de teste, servidores de teste e até mesmo ambientes de desenvolvimento local de desenvolvedores.

Na iBCScorp™ temos aplicações multi-tenant, então imagine ter centenas ou milhares de bancos de dados que precisam ser atualizados. As migrações nos permitem aplicar as mesmas migrações de forma consistente para todos os bancos de dados e aplicativos.

Características do Flyway

O Flyway favorece fortemente a simplicidade e a convenção em vez da configuração.

Alguns de seus recursos incluem:

- Migração tranquila do banco de dados
- Controle de versão
- Mecanismo de reversão
- Retornos de chamada (retorno de chamada Java e retorno de chamada SQL)

O Flyway é baseado em apenas 7 comandos básicos: migrar, limpar, informações, validar, desfazer, linha de base e reparar.

Migração Flyway

O Migrate modifica o esquema de uma versão para outra. Especificamente, ele executa SQL em um banco de dados e observa que a migração foi executada registrando o número da versão na tabela flyway. O processo de migração é simples.

Como regra, o código que depende da migração é sempre liberado com a migração para que a migração do aplicativo seja tranquila e sem problemas. Mais sobre Migrate podem ser encontrados aqui.

Validar

Validate garante que as migrações de esquema sejam precisas e conforme o esperado no banco de dados de destino. Validar acontece por padrão no tempo de construção de nossos aplicativos e se houver uma alteração em um arquivo flyway , a compilação não nos indicará que há um problema que precisa ser resolvido. Isso simplifica a garantia de que as migrações de banco de dados funcionarão corretamente e que de fato foram aplicadas corretamente na produção.

Estes não usamos:

Limpar

Clean permite a limpeza do banco de dados. Mais informações podem ser encontradas aqui: Limpar. Como as migrações são tão fáceis de repetir, achamos fácil simplesmente descartar um banco de dados e recomeçar.

Informações

O comando info fornece informações sobre o estado da migração. Mais detalhes aqui: Informações. Como lidamos muito com aplicativos SAAS e PAAS multilocatários, onde muitos bancos de dados são usados, achamos conveniente apenas verificar a tabela flyway diretamente.

Desfazer

Como o nome sugere, isso nos permite reverter alterações. Desfazer, entretanto, nunca foi usado por nós. Isso ocorre porque testamos primeiro e bem e avançamos. Isto não significa que não cometemos erros, mas com a estratégia de avanço, se precisarmos de alterar alguma coisa, teremos outra estratégia de migração para fazer essa mudança.

Linha de base

A linha de base permite redefinir o ponto inicial da migração para que a sobrecarga nos scripts possa ser reduzida. Na prática, limpamos nossos scripts de migração e atualizamos nosso histórico de esquema para uma versão mais limpa, em vez de usar Linha de base, embora possa haver situações em que a linha de base seja uma opção melhor.

Reparar

Isso reparará sua tabela flyway para corresponder ao esquema real que você está usando. Reparar é o rei de um processo automatizado, normalmente não usamos isso e fazemos ajustes manuais.

Introdução ao Flyway e ao Spring Boot

É um caminho natural e fácil de usar como ferramenta de versionamento de software com boot de mola ou estrutura de mola. Muitos desenvolvedores de software usam esta ou outras ferramentas de migração para gerenciar o processo de migração de dados.

Configuração Flyway para migração perfeita de banco de dados

Práticas recomendadas para migração de banco de dados usando Flyway

Flyway é uma ótima ferramenta para gerenciar migrações de banco de dados.

O Flyway pronto para uso ajuda os desenvolvedores a recriar um banco de dados do zero, o que é valioso ao criar um novo ambiente, economizando muito trabalho. As ferramentas de migração fornecem garantia de que um aplicativo será executado com o estado atual do banco de dados. Isso pode evitar que um desenvolvedor encontre um erro de coluna não encontrada, por exemplo.

Mas como usar essa ferramenta de migração flyway?

Para fazer isso, primeiro precisamos começar adicionando a dependência do Gradle e seguir as etapas restantes.

Dependência de instalação do Gradle

Adicione a dependência Flyway ao pom.xml para o projeto Maven ou construa o Gradle se você estiver usando o Gradle.

Pom.xml


                

                org.flywaydb 
                flyway-core 
                6.4.3 



                build.gradle

                implementation ‘org.flywaydb:flyway-core:6.4.3’

                Se quiser usar Flyway com linha de comando, então para Maven

                mvn flyway:info
                  e para Gradle

                  ./gradlew flywayInfo e adicione também o seguinte plug-in.

Maven

           org.flywaydb
                flyway-maven-plugin
                6.4.3

Gradle

           plug-ins {

                    id “org.flywaydb.flyway” versão “6.4.3”
                

                }

Alguns dos comandos comuns que podemos usar

Maven	Gradle	Descrição
migrar	flywayMigrates	Migrar o banco de dados
limpar	flywayClean	Descarta todos os objetos no esquema configurado
informações	flywayInfo	Imprime os detalhes e informações de status de todas as migrações.

Configuração

Esta seção explica as configurações iniciais necessárias para Flyway.

Configuração de flyway de um novo projeto

Atualize src/main/resources/application.propertiespara definir seu


                spring.application.name=demoFlyway



                spring.datasource.url=jdbc:postgresql://localhost:5432/demoflywaydb?createDatabaseIfNotExist=true
                

                spring.jpa.hibernate.ddl-auto=update
                

                spring.datasource.username=postgres
                

                spring.datasource.password=test123
                

                spring.datasource.platform=postgresql
                

                spring.jpa.hibernate.ddl-auto=update
                





                # Flyway


                spring.flyway.schemas=migrations
                


                spring.flyway.locations=classpath:db/migration
                


                # DataSource
                spring.datasource.hikari.schema=migrations

Criar um arquivo SQL de migração

Flyway lê os arquivos de script de migração por padrão do diretório src/main/resources/db/migration. Na etapa anterior, definimos o local do arquivo de migração que está em

src/main/resources/db/migration.

O arquivo de migração tem sua própria convenção de nomenclatura e deve ser seguida rigorosamente.

O formato do arquivo de migração =<prefix> <version>__<description>.sql</description> </version> </prefix>

Crie um novo arquivo com a seguinte convenção de nomenclatura

Prefixo: o padrão é V.
Versões: pontos ou sublinhados separados em quantas partes desejar
Separador: o padrão é _ _ (dois sublinhados) e separa a versão da descrição.
Descrição: um texto com palavras separadas por sublinhados ou espaços.
Sufixo: o padrão é .sql.

Para nosso tutorial no GitHub, criamos V1_ _ Initial.sql.



                CREATE SEQUENCE users_seq

                INCREMENT BY 50

                MINVALUE 1

                MAXVALUE 9223372036854775807

                START 10000

                CACHE 1

                NO CYCLE;


                CREATE TABLE USERS (

                testUser_id int8 NOT NULL DEFAULT nextval('users_seq'::regclass),

                testUser_name VARCHAR(45));



                INSERT INTO USERS (testUser_name) VALUES (test1);

Os arquivos dentro de src/main/resources/db/migration serão, após a adição de outros arquivos de migração, mostrados como:

Depois de executar o aplicativo e a execução bem-sucedida, podemos ver os USUÁRIOS & tabelas flyway_schema_history criadas em seu banco de dados.

E em flyway_schema_history, serão inseridas as entradas de todas as migrações conforme mostrado na imagem abaixo.

Executando Flyway

O Flyway oferece suporte a diversas opções diferentes para executar migrações de banco de dados:

Linha de comando
API Java
Por meio de plug-ins Maven e Gradle, e
por meio de plug-ins comunitários e integrações como Spring Boot

Configuração automática do SpringBoot

Se uma implementação de DataSource como uma dependência for definida no caminho de classe, será fácil para o Spring Boot instanciar esse DataSource e disponibilizá-lo para execução de consultas de banco de dados. Em seguida, o DataSource é repassado automaticamente para configurar automaticamente o Flyway. Para que isso aconteça, a seguinte dependência precisa ser adicionada ao nosso arquivo de construção (notação Gradle): implementação 'org.flywaydb:flyway-core'

Por padrão, o Spring Boot executa migrações de banco de dados Flyway automaticamente na inicialização do aplicativo. E a configuração automática do Spring Boot é a abordagem mais simples que requer esforço mínimo para oferecer suporte imediato às migrações de banco de dados.

API Java

Novamente, precisamos adicionar flyway como uma dependência (notação Gradle): implementação 'org.flywaydb:flyway-core'

Agora só precisamos configurar e executar a classe principal Flyway como parte da inicialização do aplicativo:


                import org.flywaydb.core.Flyway;

                public class MyApplication {

                public static void main(String[] args) {

                DataSource dataSource = ... 

                Flyway flyway = Flyway.configure().dataSource(dataSource).load();

                flyway.migrate();

                // Inicie o resto da aplicação
                }

                }

Chamar flyway.migrate() agora executará todas as migrações de banco de dados que não foram executadas antes.

Dividindo o esquema

Normalmente dividimos nosso esquema com arquivos de migração flyway separados para cada esquema. Nunca usamos o esquema público, mas usamos um esquema específico para cada agrupamento natural de nossos objetos de banco de dados. Isso nos permite ter vários caminhos de migração para vários módulos ou agrupamentos de microsserviços.

Portanto, o esquema flyway pode ter diversas tabelas com caminhos de migração separados como este

E cada um deles em cada banco de dados de clientes.

Convenções de esquema

Como geralmente trabalhamos em aplicativos corporativos que possuem vários módulos, separamos os módulos e também separamos o gerenciamento de esquema em módulos específicos. Portanto, se houver um módulo de produtividade, o esquema usado pelo módulo será gerenciado nessa base de código. Cada um desses módulos obtém sua própria tabela de histórico do esquema flyway, facilitando o gerenciamento de cada módulo ou grupo de microsserviços independentemente dos outros.

Convenções de versionamento

As versões sempre precisam subir e são aplicadas em ordem de número. O tempo também avança, então usamos uma data como parte de nosso esquema de controle de versão. Por exemplo, V2023.12.10.01__ads_user_table.sql pode ser um arquivo SQL flyway para adicionar um usuário que foi a primeira migração em 10 de dezembro de 2023. Organizamos ainda mais os arquivos de migração por ano e mês para que não tenhamos apenas um diretório com centenas de migrações.

Dados de teste

Às vezes, um módulo específico pode exigir esquemas que não existem naquele módulo para testes de integração. Usamos migrações flyway especiais para adicionar esquema de teste e dados de teste ao nosso aplicativo.

Essas dependências de teste adicionam dados de teste necessários para testes de migração.

Limpar

Com o tempo, nossos arquivos de migração podem se tornar um grande número. Isso torna lento a execução de testes ou a configuração de um ambiente de desenvolvimento. Periodicamente limpamos os arquivos, podemos ter 5 ou 10 arquivos que ao longo de um ou dois anos estão aplicando atualizações e modificações em uma tabela. Podemos substituir esses 10 campos posteriormente por apenas um arquivo que constrói a tabela final como está agora. Isso nos permite reduzir o número de migrações e ter apenas a versão final

Conclusão

Neste artigo, aprendemos como funciona o Flyway e como podemos usar essa ferramenta para remodelar nosso banco de dados de aplicativos.