Ùn hè mai accadutu, è quì hè di novu!
In u prossimu prughjettu, avemu decisu di utilizà Liquibase da u principiu per evità prublemi in u futuru. Cum'è s'hè risultatu, micca tutti i ghjovani membri di a squadra sanu cumu aduprà bè. Aghju fattu un attellu internu, chì dopu decisu di trasfurmà in un articulu.
Questu articulu include cunsiglii utili è descrizzioni di trè di e trappule più evidenti chì pudete cascà in quandu travagliate cù strumenti di migrazione di basa di dati relazionale, in particulare Liquibase. Cuncepitu per i sviluppatori Java di livellu Junior è Mediu, per i sviluppatori più sperimentati pò esse interessante per a strutturazione è a ripetizione di ciò chì hè prubabilmente digià cunnisciutu.
Liquibase è Flyway sò i principali tecnulugii cuncurrenti per risolve i prublemi di cuntrollu di versione di strutture relazionali in u mondu Java. U primu hè cumplettamente liberu, in a pratica hè più spessu sceltu per l'usu, per quessa chì Liquibase hè statu sceltu cum'è l'eroi di a publicazione. Tuttavia, alcune di e pratiche descritte ponu esse generiche, secondu l'architettura di a vostra applicazione.
E migrazioni relazionali sò un modu furzatu per trattà cù a debule flessibilità di i magazzini di dati relazionali. In l'era di a moda per l'OOP, u stilu di travaglià cù a basa di dati significava chì avemu da descriverà u schema una volta è micca toccu di novu. Ma a realità hè sempre chì e cose cambianu, è i cambiamenti à a struttura di e tavule sò dumandati abbastanza spessu. Naturalmente, u prucessu stessu hè doloroso è dispiacevule.
Ùn aghju micca sfondate in a descrizzione di a tecnulugia è l'istruzzioni per aghjunghje a biblioteca à u vostru prughjettu, abbastanza articuli sò stati scritti nantu à questu tema:
Inoltre, ci era digià un grande articulu nantu à u tema di cunsiglii utili:
Советы
Vogliu sparte i mo cunsiglii è i cumenti, chì sò nati per u sudore, u sangue è u dulore di risolve i prublemi cù a migrazione.
1. Prima di principiatu, vi duvite leghje a rùbbrica megliu pratichi nantu Liquibase
cose simplici, ma assai impurtanti sò descritte, senza chì l'usu di a biblioteca pò cumplicà a vostra vita. Per esempiu, un approcciu non strutturale à a gestione di i cambiamenti, prima o dopu, porta à cunfusione è migrazioni rotte. Se ùn fate micca mudificà mutualmente dipendente in a struttura di a basa di dati è a logica di i servizii à u stessu tempu, allora ci hè una alta probabilità chì questu porta à testi rossi o un ambiente rottu. Inoltre, i cunsiglii per l'usu di Liquibase nantu à u situ web ufficiale cuntenenu un paràgrafu nantu à u sviluppu è a verificazione di script di rollback inseme cù i script di migrazione principali. Ebbè, in l'articulu ci sò esempi di codice in relazione à migrazioni è u mecanismu di rollback.
2. Sè avete principiatu cù l'uttene di migrazione, ùn permettenu micca correzioni manuali in a struttura di basa di dati
Cume si dice: "Una volta Persil, sempre Persil". Se a basa di a vostra applicazione hà cuminciatu à esse gestita da l'arnesi Liquibase, ogni cambiamentu manuale porta istantaneamente à un statu inconsistente, è u livellu di fiducia in i cambiamenti diventa zero. Rischi potenziali - parechje ore passate à restaurà a basa di dati, in u peghju scenariu - un servitore mortu. Se u vostru squadra hà un Architettu DBA di "vecchia scola", spiegà cun pacienza è penseru quantu seranu e cose male s'ellu solu edita a basa di dati in u so modu da u Sviluppatore SQL cundizionale.
3. Se u changeset hè digià statu imbuttatu à u repository, evite l'edità
Se un altru sviluppatore hà tiratu è appiicatu un set di cambiamenti chì serà editatu più tardi, ellu vi ricurdarà di sicuru cun una parolla gentile quandu riceve un errore quandu l'applicazione principia. Se l'edità di u cambiamentu di qualchì manera si filtra in u sviluppu, duverete falà a pendenza slippery di hotfixes. L'essenza di u prublema si basa nantu à a validazione di i cambiamenti per hash sum - u mecanismu principale di Liquibase. Quandu editate u codice di cambiamentu, a somma hash cambia. L'edità di i cambiamenti hè pussibule solu quandu hè pussibule implementà a basa di dati sana da zero senza perde dati. In questu casu, refactoring codice SQL o XML pò, à u cuntrariu, rende a vita più faciule, rende migrazioni più leghjite. Un esempiu seria una situazione quandu, à l'iniziu di l'applicazione, u schema di a basa di dati fonte era coordinatu in u squadra.
4. Avè verificatu backups di basa di dati, se pussibule
Quì, pensu, tuttu hè chjaru. Se di colpu a migrazione ùn hè micca successu, tuttu pò esse tornatu. Liquibase hà un strumentu di rollback, ma i scripts rollback sò ancu scritti da u sviluppatore stessu, è ponu avè prublemi cù a listessa probabilità cum'è in i scripts changeset principali. Questu significa chì ghjucà in modu sicuru cù backups hè utile in ogni casu.
5. Aduprate backups di basa di dati verificate in u sviluppu s'ellu hè pussibule
Se questu ùn hè micca cuntrariu à i cuntratti è a privacy, ùn ci hè micca dati persunali in a basa di dati, è ùn pesa micca cum'è dui soli - prima di applicà nantu à i servitori di migrazione in diretta, pudete verificà cumu si travaglia nantu à a macchina di u sviluppatore è calculate quasi 100% di prublemi potenziali durante a migrazione.
6. Chat cù altri sviluppatori in a squadra
In un prucessu di sviluppu ben organizatu, tutti in a squadra sanu quale hè chì face. In a realtà, questu ùn hè micca spessu u casu, per quessa, se preparanu cambiamenti in a struttura di a basa di dati cum'è parte di u vostru compitu, hè cunsigliatu di avvisà ancu a squadra sana nantu à questu. Se qualchissia face cambiamenti in parallelu, duvete urganizà cun cura. Vale a pena di cumunicà cù i culleghi ancu à a fine di u travagliu, micca solu à u principiu. Parechji prublemi potenziali cù i cambiamenti ponu esse risolti in u stadiu di rivisione di codice.
7. Pensate ciò chì fate !
Consigli apparentemente evidenti applicabili à ogni situazione. In ogni casu, parechji prublemi puderianu esse evitati se u sviluppatore avia analizatu di novu ciò chì facia è ciò chì puderia affettà. U travagliu cù migrazioni sempre richiede una attenzione extra è precisione.
Trappi
Fighjemu avà e trappule tipiche chì pudete cascà si ùn seguite micca i cunsiglii sopra, è chì, in fattu, deve esse fattu?
Situazione 1. Dui sviluppatori cercanu di aghjunghje novi cambiamenti à u stessu tempu
Vasya è Petya volenu creà una versione 4 di cambiamenti senza sapè l'un l'altru. Anu fattu cambiamenti à a struttura di a basa di dati, è anu rializatu una dumanda di pull, cù diversi schedarii di cambiamenti. U meccanismo d'azzione seguente hè prupostu quì sottu:
Cumu risolve
- In ogni modu, i culleghi anu da accunsentà nantu à l'ordine in quale i so cambiamenti sò duverebbe andà, dicemu chì Petin deve esse applicatu prima.
- Una persona deve versà l'altru è marcate u cambiamentu di Vasya cù a versione 5. Questu pò esse fattu via Cherry Pick o una fusione pulita.
- Dopu à i cambiamenti, assicuratevi di verificà a validità di l'azzioni pigliate.
In fatti, i meccanismi di Liquibase vi permettenu di avè duie versioni 4 di cambiamenti in u repository, cusì pudete lascià tuttu ciò chì hè. Questu hè, avete solu duie rivisioni di a versione 4 cù nomi diffirenti. Cù questu approcciu, e versioni di basa di dati diventanu assai difficiuli di navigà dopu.
Inoltre, Liquibase, cum'è e case di l'hobbits, guarda assai sicreti. Unu di elli hè a chjave validCheckSum, chì hè apparsu da a versione 1.7 è permette di specificà un valore di hash validu per un cambiamentu specificu, indipendentemente da ciò chì hè almacenatu in a basa di dati. Documentazione dice u seguente:
Aghjunghjite un checksum chì hè cunsideratu validu per questu changeSet, indipendentemente da ciò chì hè almacenatu in a basa di dati. Adupratu principarmenti quandu avete bisognu di cambià un ChangeSet è ùn vulete micca errori lanciati nantu à basa di dati nantu à quale hè digià eseguitu (micca una prucedura cunsigliata)
Iè, questu ùn hè micca cunsigliatu. Ma qualchì volta un magu di luce forte pussede ancu tecniche scure.
Casu 2: Migrazione guidata da dati
Diciamu chì ùn pudete micca aduprà backups di basa di dati da i servitori live. Petya hà criatu un set di cambiamenti, l'hà pruvatu in u locu, è cun piena cunfidenza chì era ghjustu, hà fattu una dumanda di pull à u sviluppatore. In casu, u capu di u prugettu hà chiaritu se Petya hà verificatu, è poi l'hà versatu. Ma l'implementazione nantu à u servitore di sviluppu hè cascata.
In fatti, questu hè pussibule, è nimu hè immune da questu. Questu succede se e mudificazioni à a struttura di a tavula sò in qualchì modu ligati à dati specifichi da a basa di dati. Ovviamente, se a basa di dati di Petya hè piena di solu dati di prova, allora ùn pò micca copre tutti i casi di prublemi. Per esempiu, quandu si sguassate una tavula, si trova chì ci sò registri in altre tavule per Chjave Straniera assuciata cù registri in quellu chì hè sguassatu. O quandu cambia u tipu di colonna, si trova chì micca 100% di i dati ponu esse cunvertiti in u novu tipu.
Cumu risolve
- Scrivite scripts spiciali chì saranu appiicati una volta cù a migrazione è portanu i dati in a forma propria. Questu hè un modu generale per risolve u prublema di trasferimentu di dati à novi strutture dopu l'applicazione di migrazioni, ma qualcosa simili pò esse appiicata prima, in casi spiciali. Questa strada, di sicuru, ùn hè micca sempre dispunibule, perchè l'edità di dati nantu à i servitori in diretta pò esse periculosa è ancu fatale.
- Un altru modu complicatu hè di edità un set di cambiamenti esistenti. A difficultà hè chì tutte e basa di dati induve hè digià stata appiicata in a so forma esistente duverà esse restaurata. Hè abbastanza pussibule chì tutta a squadra di backend serà furzata à rinfurzà localmente a basa di dati da zero.
- È u modu più universale hè di trasfiriri u prublema di dati à l'ambiente di u sviluppatore, ricreate a stessa situazione è aghjunghje un novu cambiamentu, à un rottu, chì sguassate u prublema.
In generale, più a basa di dati hè simile in cumpusizioni à a basa di dati di u servitore di produzzione, u menu prubabile chì i prublemi cù migrazioni andaranu luntanu. E, sicuru, prima di mandà u changeset à u repository, duvete pensà parechje volte s'ellu rompe qualcosa.
Situazione 3. Liquibase principia à esse utilizatu dopu à a produzzione
Suppone chì u capu di a squadra hà dumandatu à Petya per include Liquibase in u prugettu, ma u prugettu hè digià in produzzione è ci hè una struttura di basa di dati chì esiste.
In cunsiquenza, u prublema hè chì nantu à qualsiasi servitori novi o macchine di sviluppatore, i dati di a tavula deve esse ricreati da zero, è l'ambienti digià esistenti deve esse in un statu coherente, essendu prontu à accettà novi cambiamenti.
Cumu risolve
Ci hè ancu parechje manere:
- U primu è più ovvi hè di avè un script separatu chì deve esse appiicatu manualmente quandu inizializza un novu ambiente.
- U sicondu, menu ovvi, hè di avè una migrazione Liquibase chì hè in un Cuntestu Liquibase differente è appricà. Pudete leghje più nantu à Liquibase Context quì: . In generale, questu hè un mecanismu interessante chì pò esse applicatu cù successu, per esempiu, per pruvà.
- A terza strada hè custituita da parechji passi. Prima, una migrazione deve esse creata per e tavule esistenti. Allora deve esse appiicatu nantu à qualchì ambiente è cusì u so hash sum serà ottenutu. U prossimu passu hè di inizializà e tavule Liquibase vacanti nantu à u nostru servitore micca viotu, è pudete mette manualmente un registru di un cambiamentu "cum'è applicatu" cù i cambiamenti digià in a basa di dati in a tavula cù a storia di l'applicazioni di cambiamenti. Cusì, in un servitore digià esistente, a storia principiarà da a versione 2, è tutti i novi ambienti si cumportanu in modu identicu.
Scenariu 4: E migrazioni diventanu enormi è ùn ponu micca seguità
À u principiu di u sviluppu di serviziu, in regula, Liquibase hè utilizatu cum'è una dependenza esterna, è tutte e migrazioni sò processate quandu l'applicazione principia. Tuttavia, cù u tempu, pudete sbattà in i seguenti casi:
- E migrazioni diventanu enormi è piglianu assai tempu per compie.
- Ci hè bisognu di migrà in ambienti distribuiti, per esempiu, in parechji casi di servitori di basa di dati à u stessu tempu.
In questu casu, l'applicazione di migrazioni per troppu longu hà da risultatu in un timeout quandu l'applicazione principia. Inoltre, l'applicazione di migrazioni nantu à una basa di l'istanza di l'applicazione pò esse risultatu in diversi servitori in un statu di sincronia.
Cumu risolve
In tali casi, u vostru prughjettu hè digià grande, forsi ancu un adultu, è Liquibase principia à agisce cum'è un strumentu esternu separatu. U fattu hè chì Liquibase, cum'è una biblioteca, hè assemblatu in un schedariu jar, è pò travaglià cum'è una dependenza in u prugettu, è ancu standalone.
Offline, pudete lascià l'applicazione di migrazioni à u vostru ambiente CI / CD o à e spalle forti di i vostri sysadmins / deployers. Per fà questu, avete bisognu di a linea di cummanda Liquibase . In questu modu, diventa pussibule di lancià l'applicazione dopu chì tutte e migrazioni necessarie sò state compiute.
cunchiusioni
In fatti, ci sò assai più trappule quandu travaglianu cù migrazioni di basa di dati, è assai di elli necessitanu un approcciu creativo. Hè impurtante di capiscenu chì, se aduprate l'uttellu currettamente, a maiò parte di sti trappule pò esse evitata. In particulare, aghju avutu affruntà tutti i prublemi elencati in diverse forme, è alcuni di elli eranu u risultatu di i mo jambs. In fondu, questu succede, sicuru, per inattenzione, ma qualchì volta - per via di l'incapacità criminali di utilizà l'uttellu.
Source: www.habr.com