Perché e quando Liquibase?

98

Ho provato a cercare questa domanda su overflow dello stack ma non sono riuscito a trovare alcuna domanda per questo.
Sono nuovo Liquibasee voglio sapere

Perché Liquibase?
Quando esattamente si dovrebbe usare Liquibasenel progetto?

So che questo serve a mantenere tutte le modifiche al database in un unico posto, ma lo stesso può essere fatto creando un semplice SQLfile in qualche sistema di repository e continuando ad aggiornarlo nel tempo.

database liquibase

— Shakeel Shahzad
fonte

69

La chiave di differenziazione tra un file di creazione schema autogestito e Liquibase (o altri strumenti di migrazione dello schema ) è che quest'ultimo fornisce un log delle modifiche dello schema. Questa è una registrazione delle modifiche dello schema nel tempo. Consente al progettista del database di specificare le modifiche nello schema e consente l'aggiornamento o il downgrade programmatico dello schema su richiesta.

Ci sono altri vantaggi, come:

Indipendenza dal fornitore di database (questo è discutibile, ma ci provano)
documentazione automatizzata
differenze dello schema del database

Uno strumento alternativo è flyway .

Sceglieresti di utilizzare uno strumento di migrazione dello schema quando desideri o devi gestire automaticamente gli aggiornamenti dello schema senza perdere dati. Cioè, ci si aspetta che lo schema cambi dopo che il sistema è stato distribuito in un ambiente di lunga durata come un sito del cliente o un ambiente di test stabile.

— Synesso
fonte

1

Ma supponiamo di creare un file e di scrivere il nostro primo script al suo interno e di eseguirne il commit in git. Ora, con il tempo, lo schema verrà aggiornato e possiamo tornare a qualsiasi intervallo di tempo e cambiare anche lo schema, no?

— Shakeel Shahzad

1

Con questo approccio puoi ricreare lo schema, ma non puoi eseguire il downgrade / upgrade. La differenza è la perdita di dati.

— Synesso

1

Ma l'altra parte, quando manca l'uso?

— Shakeel Shahzad

1

Synesso non vedo ancora come sia possibile eseguire il downgrade automatico di un database di produzione dopo che è stato utilizzato per un po 'e sono state prese decisioni sui dati utilizzando, ad esempio, le colonne appena aggiunte. Non puoi semplicemente lasciarli cadere ora necessariamente. Inoltre, non vedo perché questo sia meglio di una serie di script SQL con versione mantenuti nel controllo del codice sorgente che includono un semplice inserimento in una tabella delle versioni all'inizio e un aggiornamento alla fine per tenere traccia di ciò che è stato applicato.

— Khorkrak,

Un'altra domanda che aggiunge ... come possiamo registrare l'errore tramite e-mail in java. quando le modifiche SQL vengono modificate tramite XML?

— UmaShankar

18

Ho visto liquibase creare disciplina tra gli sviluppatori quando si tratta di modificare lo schema. Non puoi semplicemente sovrascrivere il cambiamento di un altro sviluppatore ed eseguire. Invece, crei il tuo changeset e lo aggiungi alla fine della sequenza di modifiche da eseguire. Questo fa anche chiarezza su quale cambiamento è avvenuto, quando e chi lo ha portato.

Un approccio molto "versionato" alla manutenzione dello schema.

Per cominciare, dà l'impressione di "lavoro non necessario" però.

— iCrus
fonte

4

Quale sono io (Mi dà l'esatta impressione che hai menzionato: P) +1 per quella determinazione cruciale

— Ismail Sahin

hai ragione, possiamo tenere traccia di tutte le modifiche che hanno apportato le ultime modifiche e quando. se dovessimo tornare a un punto specifico, liquibase sarà utile

— Anoop PS

7

Quando hai più istanze di database in dev, qa, produzione e vuoi avere uno strumento per tracciare automaticamente la cronologia delle modifiche e applicare le modifiche in modo intelligente (applica il diff dello schema corrente e dello schema finale), strumenti come liquibase o flyway saranno molto utili .

— Ted Xu
fonte

3

Credo che Liquibase sia eccezionale quando la tua filosofia è che il database è un ripensamento. Questa filosofia ha causato la maggior parte dei database danneggiati in produzione e la maggior parte di essi sono danneggiati. Un database dovrebbe essere progettato con una visione completa dell'intero sistema aziendale, non messo a punto dagli sviluppatori di applicazioni che lavorano ciascuno nei propri silos. Quest'ultimo metodo si traduce in soluzioni alternative, dati denormalizzati, relazioni scadenti tra le tabelle, duplicazione di aree di business e un sistema complessivamente disordinato e con costi di manutenzione elevati che il cliente odierà subito dopo la distribuzione a causa dei problemi che causa. Se un database è progettato per riflettere ACCURATAMENTE le relazioni commerciali, la sua durata sarà 5 volte più lunga e servirà al suo scopo 5 volte meglio di uno progettato in modo frammentario come purtroppo la maggior parte è.

Liquibase non è un problema in sé, ma consente la pratica che gli sviluppatori di applicazioni progettano il database. Quello è il problema.

— Bob Barry
fonte

19

Le specifiche cambiano, vengono aggiunte nuove funzionalità, i bug vengono corretti. Anche supponendo che "un database sia progettato per riflettere ACCURATAMENTE le relazioni commerciali", è normale e previsto che sarà necessario apportare modifiche al DB nel tempo, poiché le attività e le relazioni commerciali cambiano nel tempo. Liquibase ti aiuta solo a gestire questi cambiamenti. Questo è tutto.

— Steven Byks

Nella mia esperienza, pochissimi amministratori di database e tutta una serie di sviluppatori utilizzano Liquibase - penso che @ bob-barry sia perfetto con la maggior parte dei risultati finali. Tuttavia, gli amministratori di database che utilizzano strumenti come Liquibase (o semplicemente il vecchio git per la cronologia delle modifiche) lo troveranno utile.

— PhillipHolmes

Le pratiche evolutive del DB, e in generale agili, incoraggiano e consentono le revisioni tra pari. Per un database con esigenze di prestazioni, i DBA continuano a collaborare con i team dell'app per le modifiche al database. Strumenti come Liquibase consentono un refactoring più semplice, andando contro il tuo argomento di denormalizzazione. 10 anni fa, ho lavorato per un prodotto installato su più di 20 client, ciascuno con le proprie patch e cicli di aggiornamento. Dopo 2 anni di incubo e cercando di scrivere a mano tale strumento, siamo passati a liquibase non appena ne abbiamo saputo. E avevamo tabelle con 200 M record, non enormi neanche per quel periodo, ma qualcosa che necessitava di DBA.

— user6317694

3

Spero di incontrarti lì in paradiso un giorno. Certo che suona bene.

— Bijan

3

Penso perché si possa rispondere a liquibase se si consulta l'articolo seguente http://shengwangi.blogspot.com/2016/04/liquibase-helloworld-example.html

Se lo leggi attentamente la possibilità di eseguire il downgrade a una versione inferiore da una versione superiore con l'aiuto di semplici comandi mvn o CLI è molto utile che non ottieni se segui l'approccio del commit del tuo file sql in GIT perché allora tu devi eseguire manualmente quegli script e inoltre non hai il set di modifiche come: - chi ha fatto l'autore delle modifiche, ecc.

— Shikhar Chaudhary
fonte

0

Essendo DevOps Person del mio team, preferirei avere tutti i miei file SQL in un unico posto, ovvero nel mio SCM (Source Code Management)

Anche durante la fase CI / CD, se lo schema DB viene creato insieme ad esso, si risparmia molto tempo e risorse. Non dovresti avere un'altra persona che gestisce il tuo database per quel cliente.

ORM come Flyway, Liquibase, EF ecc. Aiutano a raggiungere questo obiettivo.

— Sloka Roy
fonte