SpringBoot + Flyway - "Projeto Java de A a Z"

Um artigo de uma série sobre a criação de um projeto Java (links para outros materiais estão no final). Seu objetivo é analisar tecnologias-chave, o resultado é escrever um bot de telegrama. Nesta parte, tentamos lançar SpringBoot e Flyway. A quantidade mínima de teoria, como você quiser))) Omitimos a comparação final do Flyway/Liquibase por um período de tempo indefinido e vamos direto ao ponto. E mesmo assim já se arrastou. Para não descrever o Flyway duas vezes, decidi adicioná-lo imediatamente ao nosso futuro projeto JRTB.

O que precisamos fazer como parte disso?

1. Inicie um aplicativo SpringBoot baseado em Maven.
2. Adicione Flyway lá: felizmente, eles são facilmente integrados.
3. Adicione um esquema para as tabelas que temos no banco de dados de exemplo.

Assim aprenderemos como trabalhar com Flyway. Por que um projeto separado e não imediatamente em nosso JRTB? Porque depois quem quiser entender como fazer isso terá um projeto com um exemplo e um artigo que descreve como trabalhar com ele. Bem, vamos!

O que é flyway

Para usar algo, primeiro você precisa descobrir o que é e por quê. Flyway é uma ferramenta de controle de versão de banco de dados. As palavras são conhecidas, mas de alguma forma o entendimento não foi acrescentado, certo? Vamos tentar descrever o problema que o flyway resolve. Digamos que temos um projeto. Como tudo no nosso mundo, não é perfeito, por isso não foi possível planear e elaborar a versão final do projeto. Cada vez que aparecem certas nuances não explicadas. O projeto utiliza um banco de dados em seu trabalho. É claro que se o projeto mudar, a estrutura do banco de dados também poderá mudar. Digamos que adicionamos um novo campo para uma das entidades do nosso projeto. Como fazer isso?

1. Adicione este campo à nossa entidade, atualize tudo para que a lógica de negócio funcione.
2. Atualize o banco de dados. A única maneira possível é fazê-lo manualmente. Para fazer isso, você precisa entrar e registrar o script sql necessário.

O segundo ponto levanta muitas questões:

1. Mas se tivermos mais de um local onde implantamos nosso projeto, então isso precisa ser feito em cada um deles?
2. e se quisermos voltar, como saberemos exatamente em que estado está a estrutura do banco de dados agora?
3. Como teremos certeza de que a alteração do banco de dados foi bem-sucedida?
4. Como posso ter a oportunidade de acompanhar todas as alterações do banco de dados que ocorreram no projeto?

Se você fizer isso manualmente, as respostas não serão as melhores... Para evitar todas essas dificuldades, você pode utilizar uma ferramenta de migração de banco de dados. Um deles é o Flyway. Qual é o trabalho dele? Como parte do projeto, armazenamos arquivos SQL separados (as chamadas migrações), que armazenam tudo o que fazemos com o banco de dados de uma só vez. Todas as migrações ocorrem estritamente em uma determinada ordem, o que permite rastrear alterações na estrutura e nos dados do banco de dados (muitas vezes, por meio da migração, os dados de teste são adicionados ao projeto para que, quando for implantado em algum servidor, ele já tenha algum valores com os quais você pode testar o projeto). Após a aprovação dos testes, as migrações são lançadas quando o projeto é compilado. Eles se conectam ao banco de dados e realizam migrações. Se as migrações já foram realizadas neste banco de dados, o flyway simplesmente irá ignorá-las (ele armazena dados sobre migrações e seu status em uma tabela separada no banco de dados, o que ajuda a gerenciá-las), e se alguma migração não tiver êxito, então o projeto build e sua montagem (implantação) no servidor serão interrompidas. Tentei descrevê-lo com o máximo de detalhes possível. Se tudo ainda não estiver totalmente claro, não importa: com a prática, a compreensão virá.

Inicie SpringBoot + Flyway

O que é inicialização de primavera

O que estamos lançando?... Para entender o que e por que estamos fazendo, você precisa decidir o que é SpringBoot. Primeiro, vamos falar rapidamente (bem, muito rapidamente) sobre Spring . No momento, é o padrão de fato da indústria no desenvolvimento de aplicativos de servidor em Java. Padrão de quê? Como posso explicar isso para você? Spring é o esqueleto do aplicativo, no qual jogamos a “carne” – nossa lógica de negócios. Com a ajuda do Spring (doravante usarei este papel vegetal para não perder tempo trocando de idioma :D)) o Spring nos dá um ponto de partida a partir do qual começamos a fazer tudo. É multifacetado, multimodular:

1. Você quer trabalhar com um banco de dados? Você quer relacional? Você quer não relacional? Aqui estamos com Spring Data.
2. Você quer trabalhar com solicitações http? Aqui está, Spring web (Spring MVC).
3. Você precisa de um contêiner para todos os seus objetos em um só lugar? Aqui está o Spring Core.
4. Você precisa configurar a segurança em um projeto para que haja diferentes funções e cadeias de comando? Segurança da Primavera.
5. Justamente quando você pensou que seria bom ter tal coisa, descobriu-se que o Spring já tem o que você precisa e se integra de forma rápida e fácil.

Portanto, podemos dizer que não se trata apenas de um framework (uma biblioteca tão grande), mas de todo um ecossistema que se desenvolve em ritmo alucinante. Para entender o que é Spring Core, ou seja, a base à qual os módulos estão conectados, aconselho você a assistir a uma demonstração ao vivo sobre como criar seu próprio framework. É hospedado por Evgeny Borisov, um cara muito legal na área de Java e Spring. Faça tudo o que ele fez e o trabalho da primavera ficará mais claro para você. SpringBoot, por sua vez, é o auge de tudo o que eles possuem. A magia da água pura. Configurações mínimas para fazer o primeiro lançamento do aplicativo. É claro que isso não lhe dará uma compreensão de como usá-lo e do que fazer. Mas antes de mergulhar nas profundezas do desenvolvimento, você precisa olhar tudo do ponto de vista de um pássaro.

Iniciando SpringBoot

Como já entendemos o que é Maven, vamos criar um novo projeto para as nossas necessidades. Para isso, basta acessar um site criado especialmente para esse assunto. Chama-se Spring Initializr . Aqui você precisa preencher e selecionar o que precisa:

1. A ferramenta de construção do projeto é gradle ou maven. Como você pode ver, Ant nem é mais mencionado. Esta é uma boa dica sobre quais ferramentas de construção valem seu tempo.
2. A linguagem em que você pode escrever é java, kotlin, groovy. Tudo é simples aqui: todos eles são semelhantes a JVM e executam facilmente código Java. Aliás, vale a pena dar uma olhada no Kotlin. Groovy francamente se tornou desinteressante (houve um tempo em que eles mudaram para grooves, mas isso passou rapidamente).
3. Versão Spring... Aqui você precisa entender que as versões da parte principal do Spring e seus módulos são consistentes.
4. Dados do projeto. Já descrevi essas coisas.
5. Nós escolhemos qual arquivo será coletado - Jar ou War.
6. Bem, a versão Java do nosso favorito. E recentemente surgiram muitas dessas versões... Eles esperaram anos, e agora são duas por ano.

No nosso caso, publicaremos este projeto na organização da comunidade JavaRush , portanto as informações sobre o projeto serão adequadas:

1. Maven - não foi à toa que falamos com você sobre isso antes.
2. Java é nosso queridinho :D
3. Vamos pegar a versão 2.2.11. Por que não o mais novo? Porque quanto mais novo for, maior será a chance de haver alguns bugs ali. Para nós não importa qual versão, mas a mais antiga será mais confiável. Portanto, escolhemos 2.2.11.
4. Grupo: com.github.javarushcommunity
5. Artefato: springboot-flyway-demo
6. Nome: Demonstração SpringBoot + Flyway
7. Descrição: Projeto demonstra integração entre SpringBoot e Flyway . (Sim, a capacidade de escrever documentação é uma parte importante do desenvolvimento :))
8. Nome do pacote: com.github.javarushcommunity.springbootflywaydemo . Aqui eles criarão imediatamente um pacote básico para nós com uma classe que iniciará nosso aplicativo.
9. Embalagem: Frasco
10. Java: 8. Não vamos adiantar a locomotiva e pegar o bom e velho oito. Por que não 11? Pelo que? Para o nosso exemplo, não vejo sentido.

Agora vamos adicionar os módulos. Precisamos encontrar integração com Flyway. Você também pode adicionar algo relacionado ao MySQL e Spring Data. Vamos adicionar outro lombok (isso é uma coisa muito necessária, confie em mim por enquanto :D)) Para fazer isso, clique em ADICIONAR DEPENDÊNCIAS ... e selecione tudo que você precisa: É assim que adicionamos Flyway. Lombok... E assim por diante. Como resultado, obtemos: Huh... preenchemos tudo)) Agora clique em GERAR... e pronto - o arquivo com o projeto gerado está pronto :) Também existe uma coisa tão legal como COMPARTILHAR... , que fornece um link para a página que você acabou de preencher. Ou seja, aqui está o que eu gerei . E mesmo que algo dê errado, você sempre pode verificar usando o link. Em seguida, precisamos vincular o projeto criado ao repositório Git, então clonamos o projeto springboot-flyway-demo criado e baixamos-o via IDEA. Para fazer isso, você precisa abrir a ideia e selecionar Arquivo -> Novo -> Projeto de fontes existentes... : Agora adicione a URL e clique em Clonar . O próximo passo é transferir o interior do projeto gerado para dentro daquele que clonamos. Confuso? Eu vou te mostrar agora. Descompactei e recebi o seguinte conjunto de arquivos: Eles precisam ser transferidos para o projeto clonado. Como no artigo anterior, vamos adicionar pom.xml como um projeto maven: Agora estamos interessados ​​em ver o que foi gerado para nós. Se você abrir todas as pastas em src e além, verá a hierarquia usual em projetos Maven, que discutimos no artigo anterior . Para quem ainda não leu, leia! Pode-se observar que temos uma classe Application e nosso aplicativo SpringBoot será iniciado a partir dela. Graças ao plugin Maven para SpringBoot, agora temos a tarefa necessária para o Maven, ou seja, spring-boot:run. Onde podemos encontrar essas informações? À direita, abrindo a placa Maven e nosso projeto: Haverá um erro, e não conseguiremos lê-lo, veremos algo assim: Para obter mais informações, para maior velocidade podemos executar o método principal de a classe Application: E aí veremos o real motivo: Aqui já tem mais informações e você pode fazer algo com elas. O que está errado? Temos dependências associadas ao banco de dados e, portanto, precisamos fornecer configurações para conexão com ele. Para fazer isso, pesquisamos no Google e descobrimos que precisamos adicionar as seguintes configurações ao application.properties:

spring.datasource.url=jdbc:mysql://localhost:3306/flyway_demo_db
spring.datasource.username=root
spring.datasource.password=root
spring.datasource.driver-class-name=com.mysql.cj.jdbc.Driver

Executamos o método principal novamente e obtemos: Agora precisamos adicionar pelo menos uma migração. Para compor corretamente uma migração, você precisa usar o seguinte modelo: V<VERSION>__<NAME>.sql Usando este modelo, criaremos um arquivo de migração chamado V00001__Create_country_table.sql na pasta apropriada: /src/main/resources/ db.migration/ . Vamos criar uma tabela de países nela. Vamos pegar o script do segundo artigo sobre banco de dados . Antes de começar, vamos criar um banco de dados para trabalho: flyway_demo_db. Vamos fazer isso através do MysqlWorkbench: Agora podemos executar novamente o método main: Deu tudo certo, mas como ainda não temos nada no projeto, ele terminou de funcionar. No entanto, fica claro nos logs ( leia o que são logs ) que:

1. Conectado com sucesso ao banco de dados.
2. A migração foi validada e está tudo bem.
3. Flyway criou uma tabela para gerenciar migrações.
4. E o que a migração 00001 começou - a criação do país foi um sucesso.

Para verificar isso, você pode ver o que está sendo feito no banco de dados. Então vamos ao nosso servidor MySQL e ver o que está acontecendo com as tabelas do banco de dados flyway_demo_db: $ USE flyway_demo_db; $MOSTRAR TABELAS; Como eu esperava, ocorreu uma migração, durante a qual foi criada a tabela country e apareceu a tabela flyway_schema_history, que armazena informações sobre migrações. Vamos mais longe e ver quais registros existem (e se existem). $SELECT * FROM flyway_schema_history; Aqui está a gravação, a única. Ele contém muitos dados interessantes. Versão, descrição da migração, que tipo de SQL (e talvez também XML), o nome do próprio script, soma de verificação ( isso é algo como um código hash, que é usado para verificar se a migração mudou ou não. Isso é feito caso fizemos uma migração no banco de dados e depois foi corrigido: isso não pode ser feito, todas as alterações são feitas apenas através de uma nova migração e para evitar que isso aconteça, o valor do cheque monitora isso), nome sql do usuário, processamento de migração data, tempo de execução e resultado (bem sucedido ou mal sucedido). Uma migração escrita uma vez não deve ser alterada no futuro. Mesmo que haja um defeito nele. Todas as alterações ocorrem apenas através de uma nova migração. É muito importante. Para mostrar o que vai acontecer, vamos mudar um pouco nosso script e tentar executá-lo novamente. Vamos adicionar uma entrada à tabela country em nossa migração: e executar o método main e é isso que obtemos: Como eu esperava, o flyway reconheceu que o script havia sido alterado e não realizou a migração. Em alguns casos, pode ser necessário executar uma migração atualizada e, para que o flyway ignore isso, é necessário excluir a entrada na tabela flyway_schema_history e, em seguida, executar a migração atualizada. Este não é um comportamento normal e não deveria ser assim, mas você também precisa conhecer esse método de solução do problema. Lidamos com a primeira migração. Agora gostaria de adicionar outra migração, com dados sobre países, como estava no artigo sobre o banco de dados: arquivo V00002__Add_test_data_to_country.sql E vamos executar o método principal novamente: Pelos logs fica claro que antes de iniciar a migração, o banco de dados era na versão 00001, portanto todas as migrações após esta versão. Em seguida, a versão 00002 foi lançada e obteve sucesso. Vamos verificar, ou você já acredita que três registros no país já estarão no banco de dados?)) Eu verificaria, então comprovação: Algo assim. Se você executar o projeto novamente, o flyway simplesmente ignorará a implementação das migrações, uma vez que o banco de dados está em total conformidade com a versão exigida.

Conclusão

Desta vez aprendemos como entender e usar uma ferramenta de migração de banco de dados em conjunto com SpringBoot. Essas informações são necessárias para entender o que é uma ferramenta de controle de versão de banco de dados, usando o Flyway como exemplo. Amigos, o código fonte do projeto que mostrei está publicado em nossa organização no Github . Se você gostou do exemplo, dê uma estrela e entenderei que meu trabalho é útil e realmente vale a pena continuar. Tradicionalmente, sugiro assinar minha conta no Github . Através dele conduzo todo o meu trabalho em código aberto e todos aqueles projetos de demonstração que invariavelmente acompanham meus artigos. Obrigado a todos pela leitura. Da próxima vez escreveremos nossa aplicação. Haverá alguma teoria necessária sobre o Docker no futuro, mas iremos diluí-la fortemente com a prática.

Links Úteis

Hoje não existem muitos links úteis. Preste atenção no vídeo do Evgeniy, vale muito a pena!

1. Site para criação de projetos no Spring
2. Evgeniy Borisov – construtor de primavera
3. Documentação no Spring para Flyway

Uma lista de todos os materiais da série está no início deste artigo.