Implantando o Flyway em sistemas Java - Parte 2

 Neste segundo post falando sobre o Flyway, vamos meter a mão na massa e trazer um exemplo para implementar a ferramenta em um projeto Java EE. Basicamente, mexeremos no arquivo pom.xml, então conhecimentos de Maven serão necessários. Tentarei explicar os principais conceitos ao longo do post. Vamos lá!

(o post relativo a primeira parte pode ser lido aqui)

O primeiro passo é criar a pasta src/main/resources/db/migration, onde ficarão os scripts de banco de dados. Esses scripts deverão receber um padrão de nomeação especial: todos os scripts deverão conter o prefixo Vxx__, com xx indicando a versão. Repare no duplo caractere underline. Se o script se referir à uma view ou stored procedure, o prefixo deve ser R__. Alguns exemplos de nomes de scripts: 

• V01__criacao_tabelas.sql;
• V02__inclui_indice.sql;
• R__view_func_ativos.sql;
• R__sp_inclui_func.sql.

No segundo passo, vamos mexer no pom.xml. Adicionaremos, na seção plugins, o plugin do Flyway. Os plugins são uma forma que o Maven criou para ser estendido com novas funcionalidades. No momento da criação deste post, a versão mais atual era a 7.7.3 - descubra qual a versão mais atual no site mvnrepository.com, procurando por Flyway Maven Plugin. Toda a configuração do Flyway deve ser adicionada nesta seção a ser incluída: qual o driver JDBC, URL de acesso, usuário, senha, schema do banco a ser utilizado. Duas subseções serão configuradas: a subseção de dependências, contendo o driver JDBC, e a subseção de configuração, com as demais informações. Todo o trecho XML ficará parecido com o trecho abaixo:

<plugins>
   ...
   <plugin>
      <groupId>org.flywaydb</groupId>
      <artifactId>flyway-maven-plugin</artifactId>
      <version>7.7.3</version>
      <dependencies>
         <dependency>
            <groupId>mysql</groupId>
            <artifactId>mysql-connector-java</artifactId>
            <version>8.0.16</version>
         </dependency>
      </dependencies>
      <configuration>
         <driver>com.mysql.cj.jdbc.Driver</driver>
         <url>jdbc:mysql://localhost:3306/musicas?serverTimezone=UTC</url>
         <user>usrmusica</user>
         <password>usrmusica</password>

         <!--
         <schemas>
            <schema>musicas</schema>
         </schemas>

         -->
      </configuration>
   </plugin>

   ...

<plugins>

As três primeiras linhas identificam o plugin do Flyway e sua versão; a seguir, temos a subseção de dependências, com a configuração do driver JDBC - neste nosso exemplo, o driver do MySQL; por último, a subseção de configuração e a descrição da classe correspondente ao driver JDBC, URL, usuário e senha de acesso ao banco de dados, e o schema do banco - reparem que deixei comentado pois a URL já indica o banco de dados MySQL sendo acessado - não há um schema especifico. Essa parte da configuração será necessária se você estiver utilizando outro banco de dados, como o Oracle ou o SQL Server.

Com tudo configurado, podemos executar o goal migrate do Flyway para realizar a migração inicial. Nessa migração inicial, a tabela de controle do Flyway será criada, e os primeiros scripts que estiverem presentes na pasta serão executados. O comando a ser executado é mvn flyway:migrate. Eis os resultados:

No meu exemplo, eu adicionei apenas um script à pasta, chamado V01__criaTabelas.sql. Os próximos prints mostram a tabela de controle e as demais tabelas criadas no MySQL:

Tabelas criadas no MySQL, incluindo a tabela de controle do Flyway, flyway_schema_history

Descrição da tabela de controle do Flyway, flyway_schema_history

Adicionamos mais um script à pasta, agora chamado V02__InsertInicial_Tabelas.sql, que popula as tabelas com valores iniciais. Uma nova execução do migrate do Flyway traz os seguintes resultados:

Reparar a mensagem que informa que a versão atual é a V02, ou seja, nossos dois scripts foram executados com sucesso e aplicados ao banco de dados. Como podemos verificar a versão atual e os scripts que foram executados pelo Flyway? Com o comando mvn flyway:info. Veja os resultados:

Reparem que temos alguns problemas com essa abordagem inicial:

• Temos a senha de acesso ao nosso banco de dados chapada no arquivo pom.xml. Toda e qualquer pessoa que tenha acesso ao código-fonte também terá acesso a essa senha, que possui permissões DDL no nosso banco de dados;
• Se tivermos ambientes diferentes para o nosso projeto (desenvolvimento, testes, homologação, produção, etc.), como iremos diferenciar os diferentes conjuntos de bancos de dados e credenciais de acesso?
• Quando observarmos o arquivo jar / war gerado, perceberemos que os scripts são incluídos. Não queremos que nosso jar / war contenha esse tipo de arquivo, totalmente desnecessário para a execução do projeto.

No próximo post (parte 3 da nossa série sobre o Flyway), mostraremos soluções para os problemas citados acima, utilizando recursos interessantes do Maven. Até o próximo post!!