Eu tentei pesquisar esta pergunta sobre estouro de pilha, mas não consegui encontrar nenhuma pergunta para isso.
Eu sou novo Liquibasee quero saber
Liquibase?Liquibaseno projeto?Eu sei que isso é para manter todas as alterações do banco de dados em um só lugar, mas o semelhante pode ser feito criando SQLarquivos simples em algum sistema de repositório e atualizando-o com o tempo.
Respostas:
O principal diferenciador entre um arquivo de criação de esquema autogerenciado e Liquibase (ou outras ferramentas de migração de esquema ) é que o último fornece um log de alterações do esquema. Este é um registro das mudanças de esquema ao longo do tempo. Ele permite que o designer do banco de dados especifique as mudanças no esquema e permite a atualização ou downgrade programática do esquema sob demanda.
Existem outros benefícios, como:
Uma ferramenta alternativa é o flyway .
Você escolheria usar uma ferramenta de migração de esquema quando quiser ou precisar gerenciar automaticamente as atualizações de esquema sem perder dados. Ou seja, você espera que o esquema mude depois que seu sistema for implantado em um ambiente de longa duração, como um site do cliente ou ambiente de teste estável.
Eu vi o liquibase criar disciplina entre os desenvolvedores quando se trata de modificar o esquema. Você simplesmente não pode ir e sobrescrever a mudança de outro desenvolvedor e executar. Em vez disso, você cria seu próprio changeset e o adiciona ao final da sequência de mudanças a serem executadas. Isso também traz clareza sobre que mudança ocorreu, quando e quem a trouxe.
Uma abordagem muito "versionada" para a manutenção do esquema.
Para começar, dá uma impressão de "trabalho desnecessário".
Quando você tem várias instâncias de banco de dados em dev, qa, production e deseja ter uma ferramenta para rastrear automaticamente o histórico de alterações e aplicar as alterações de forma inteligente (aplique o diff do esquema atual e do esquema final), ferramentas como liquibase ou flyway serão muito úteis .
Eu acredito que a Liquibase é ótima quando sua filosofia é que o banco de dados é uma reflexão tardia. Essa filosofia causou a maioria dos bancos de dados ruins em produção - e muitos deles são ruins. Um banco de dados deve ser projetado com uma visão completa de todo o sistema de negócios, não em partes por desenvolvedores de aplicativos, cada um trabalhando em seus próprios silos. O último método resulta em soluções alternativas, dados desnormalizados, relacionamentos ruins entre tabelas, duplicação de áreas de negócios e um sistema geral confuso e de alto custo de manutenção que o cliente odiará logo após a implantação devido aos problemas que causa. Se um banco de dados for projetado para refletir COM PRECISÃO as relações comerciais, sua vida útil será 5 vezes mais longa e atenderá a sua finalidade 5 vezes melhor do que um banco de dados projetado de forma fragmentada, como infelizmente a maioria é.
Liquibase não é um problema em si, mas permite que os desenvolvedores de aplicativos projetem o banco de dados. Esse é o problema.
Acho que por que liquibase pode ser respondido se você ler o artigo abaixo http://shengwangi.blogspot.com/2016/04/liquibase-helloworld-example.html
Se você ler atentamente, a capacidade de fazer o downgrade para uma versão inferior de uma versão superior com a ajuda de comandos simples mvn ou CLI é muito útil, o que você não obterá se passar pela abordagem de submeter seu arquivo sql no GIT porque então você tem que executar manualmente esses scripts e também não tem o conjunto de alterações como: - quem fez o autor das alterações, etc.
Sendo DevOps Pessoa de minha equipe, eu preferiria ter todos os meus arquivos SQL em um só lugar, ou seja, em meu SCM (Gerenciamento de Código Fonte)
Também durante a fase de CI / CD, se o esquema de banco de dados for criado junto com ele, isso economiza muito tempo e recursos. Você não teria que ter outra pessoa gerenciando seu banco de dados para esse cliente.
ORM como Flyway, Liquibase, EF etc. ajudam a conseguir isso.