Paradigmas caem dia apos dia na tecnologia da informacao. Tal dinamica e conhecida por desenvolvedores atentos as mudancas de metodologia de desenvolvimento de software, linguagens e ao proprio modelo e ciclo de implantacao de suas aplicacoes. Essa dinamica gerada pela demanda de inovacao em razao do empreendedorismo de diferenciacao, com a necessidade de entregar mais e melhor em menor tempo a menor custo revolucionou camadas de frontend, backend, integracoes e interacoes com objetos que tornaram-se cache e responsabilidade de CDNs (Content Delivery Network). Mas pouco falava-se na camada de dados.Um exemplo pratico do metodo utilizado em grandes organizacoes para o gerenciamento da estrutura de dados geralmente segue o seguinte modelo: O desenvolvedor cria seus SQLs necessarios para atender uma demanda de negocio(ou correcao de erro) com scripts de install e rollback e em algumas circunstancias perfumados com um gerenciador de publicacao de estrutura de dados: O qual recebe o script, ordena, valida sintaxe ou algo neste sentido. Em conjunto com processos delineados de gestao de mudancas, entra em cena o nosso amado DBA(administrador de banco de dados), o qual tem o papel de avaliar o conteudo e seu impacto na performance, tambem a integridade da base de dados, e quando passar nestes quesitos aplicar tais scripts, ocasionalmente em horario comercial quando temos um nivel de amadurecimento alto, ou em funcao da criticidade e risco nas madrugadas frias de sabado para domingo. Enquanto isto, do lado do codigo da aplicacao o desenvolvedor com sua veia inovadora utiliza-se de novas solucoes e metodologias para que a atualizacao de sua aplicacao seja feita da maneira mais agil possivel, resguardado por seus testes de performance, funcionalidade, cobertura de codigo e outros que lhe permitem a realizacao cada vez mais eficaz de entrega e integracao. Pois bem, mas chegada a hora do desenvolvedor atualizar informacoes na base e toda inovacao fica fadada a execucao de um processo lento e dependente, passivel de erros e falhas humanas durante um rollback ou install. Finalizada a apresentacao de fluxos e cenarios que ainda existem, e sao comuns em organizacoes, vamos ao que o FlywayDB, uma das solucoes disponiveis de versionamento de estrutura de dados, pode fazer e como ele pode fazer. O FlywayDB (https://flywaydb.org) em comparacao com o Liquibase (http://www.liquibase.org/) parece-me mais flexivel e simples em sua implantacao cujo cenario descrito acima nesta publicacao seja o vigente. Dai a opcao de uso desta solucao, mas vale fazer uma comparacao das duas. Em que versionar as alteracoes de estruturas de dados e dados pode beneficiar? Primeiramente em mapear alteracoes, ou seja, saber o que e quando causou impacto, tambem acompanhar o ciclo de evolucao da base de dados. Veja um exemplo da tabela de migrations do FlywayDB: Com essa informacao e possivel saber do que se trata a migration, qual versao a base esta e quais foram bem sucedidas das migrations e quando. Abordaremos entao os metodos de integracao com o seu projeto Maven e repositorio de versionamento GIT. No exemplo utilizado para integrar a um projeto Maven os scripts SQL precisarao estar situados no diretorio, ou alterar no pom.xml o