Nu s-a mai întâmplat niciodată și iată-ne din nou!
La următorul nostru proiect, am decis să folosim Liquibase de la bun început pentru a evita problemele pe viitor. După cum se dovedește, nu toți membrii tinerilor echipei știu să-l folosească corect. Am susținut un workshop intern, pe care apoi am decis să îl transform într-un articol.
Articolul include sfaturi utile și o descriere a celor mai evidente trei capcane în care puteți cădea atunci când lucrați cu instrumente de migrare a bazelor de date relaționale, în special Liquibase. Conceput pentru dezvoltatorii Java la nivelurile Junior și Middle; pentru dezvoltatorii mai experimentați poate fi de interes pentru structurarea și repetarea a ceea ce este cel mai probabil deja cunoscut.
Liquibase și Flyway sunt principalele tehnologii concurente pentru rezolvarea problemelor de control al versiunilor structurilor relaționale din lumea Java. Primul este complet gratuit, în practică este cel mai adesea ales pentru utilizare, motiv pentru care Liquibase a fost ales ca erou al publicației. Cu toate acestea, unele dintre practicile descrise pot fi universale, în funcție de arhitectura aplicației dvs.
Migrațiile structurilor relaționale sunt o modalitate forțată de a face față flexibilității slabe a depozitelor de date relaționale. În epoca modei OOP, stilul de lucru cu bazele de date însemna că vom descrie schema o dată și nu o mai atingem. Dar realitatea este întotdeauna că lucrurile se schimbă, iar modificările structurii tabelului sunt necesare destul de des. Desigur, procesul în sine poate fi dureros și neplăcut.
Nu voi intra mai adânc în descrierea tehnologiei și a instrucțiunilor pentru adăugarea unei biblioteci la proiectul dvs.; au fost scrise destul de multe articole pe această temă:
În plus, a existat deja un articol excelent pe tema sfaturilor utile:
Советы
Vreau să vă împărtășesc sfaturile și comentariile mele, care s-au născut din transpirația, sângele și durerea rezolvării problemelor legate de migrație.
1. Înainte de a începe lucrul, ar trebui să vă familiarizați cu secțiunea de bune practici despre Liquibase
Sunt descrise lucruri simple, dar foarte importante, fără de care folosirea bibliotecii vă poate complica viața. De exemplu, o abordare nestructurată a gestionării seturilor de modificări va duce mai devreme sau mai târziu la confuzie și la migrații întrerupte. Dacă nu implementați modificări reciproc dependente ale structurii bazei de date și ale logicii serviciului în același timp, există o probabilitate mare ca acest lucru să ducă la teste roșii sau la un mediu deteriorat. În plus, recomandările pentru utilizarea Liquibase pe site-ul oficial conțin o clauză despre dezvoltarea și testarea scripturilor de rollback împreună cu principalele scripturi de migrare. Ei bine, în articol Există exemple de cod privind migrarea și mecanismul de rollback.
2. Dacă începeți să utilizați instrumente de migrare, nu permiteți corecții manuale în structura bazei de date
După cum se spune: „Odată Persil, întotdeauna Persil”. Dacă baza aplicației dumneavoastră începe să fie gestionată de Liquibase, orice modificare manuală duce imediat la o stare inconsecventă, iar nivelul de încredere în seturile de modificări devine zero. Riscurile potențiale includ câteva ore petrecute pentru restaurarea bazei de date; în cel mai rău caz, un server mort. Dacă aveți un arhitect DBA de „școală veche” în echipa dvs., explicați-i cu răbdare și grijuliu cât de rău vor fi lucrurile dacă pur și simplu editează baza de date conform propriei sale înțelegeri de la un dezvoltator SQL condiționat.
3. Dacă setul de modificări a fost deja introdus în depozit, evitați editarea
Dacă un alt dezvoltator a făcut un pull și a aplicat un set de modificări, care va fi editat ulterior, cu siguranță vă va aminti cu un cuvânt amabil când va primi o eroare la pornirea aplicației. Dacă editarea setului de modificări se scurge cumva în dezvoltare, va trebui să urmați panta alunecoasă a remedierilor rapide. Esența problemei se bazează pe validarea modificărilor prin sumă hash - mecanismul principal al Liquibase. La editarea codului setului de modificări, valoarea hash se modifică. Editarea seturilor de modificări este posibilă numai atunci când este posibilă implementarea întregii baze de date de la zero fără a pierde date. În acest caz, refactorizarea codului SQL sau XML poate, dimpotrivă, să ușureze viața și să facă migrațiile mai lizibile. Un exemplu ar fi o situație în care, la începutul aplicației, schema bazei de date sursă a fost convenită în cadrul echipei.
4. Verificați copiile de siguranță ale bazei de date, dacă este posibil
Aici, cred, totul este clar. Dacă dintr-o dată migrația a eșuat, totul poate fi returnat înapoi. Liquibase are un instrument pentru anularea modificărilor, dar scripturile de rollback sunt scrise și de dezvoltator însuși și pot avea probleme cu aceeași probabilitate ca și scripturile setului de modificări principal. Aceasta înseamnă că este util să joci în siguranță cu backup-uri în orice caz.
5. Folosiți copii de siguranță dovedite ale bazei de date în dezvoltare, dacă este posibil
Dacă acest lucru nu contrazice contractele și confidențialitatea, nu există date personale în baza de date și nu cântărește atât de mult decât doi sori - înainte de a-l folosi pe serverele de migrare live, puteți verifica cum va funcționa pe mașina dezvoltatorului și să calculați aproape 100% din potențialele probleme în timpul migrației.
6. Comunicați cu alți dezvoltatori din echipă
Într-un proces de dezvoltare bine organizat, toată lumea din echipă știe cine ce face. În realitate, adesea nu este cazul, prin urmare, dacă pregătiți modificări ale structurii bazei de date ca parte a sarcinii dvs., este recomandabil să notificați suplimentar întreaga echipă despre acest lucru. Dacă cineva face schimbări în paralel, ar trebui să vă organizați cu atenție. Merită să comunicați cu colegii după terminarea lucrului, nu doar la început. Multe probleme potențiale cu seturile de modificări pot fi rezolvate în etapa de revizuire a codului.
7. Gândește-te la ceea ce faci!
S-ar părea un sfat de la sine înțeles care se aplică în orice situație. Cu toate acestea, multe probleme ar fi putut fi evitate dacă dezvoltatorul ar fi analizat din nou ceea ce face și ce ar putea afecta. Lucrul cu migrații necesită întotdeauna atenție și acuratețe suplimentare.
capcane
Să ne uităm acum la capcanele tipice în care poți cădea dacă nu urmezi sfaturile de mai sus și ce, mai exact, ar trebui să faci?
Situația 1: Doi dezvoltatori încearcă să adauge noi seturi de modificări în același timp
Vasya și Petya vor să creeze un set de modificări versiunea 4, fără să știe unul despre celălalt. Ei au făcut modificări în structura bazei de date și au emis o cerere de extragere cu diferite fișiere seturi de modificări. Se propune următorul mecanism de acțiune:
Cum să decizi
- Într-un fel, colegii trebuie să cadă de acord asupra ordinii în care ar trebui să meargă seturile de modificări, de exemplu, Petin ar trebui aplicat mai întâi.
- Cineva ar trebui să-l adauge pe al doilea și să marcheze setul de modificări al lui Vasya cu versiunea 5. Acest lucru se poate face prin Cherry Pick sau printr-o îmbinare îngrijită.
- După modificări, cu siguranță ar trebui să verificați validitatea acțiunilor întreprinse.
De fapt, mecanismele Liquibase vă vor permite să aveți două seturi de modificări ale versiunii 4 în depozit, astfel încât să puteți lăsa totul așa cum este. Adică veți avea pur și simplu două modificări la versiunea 4 cu nume diferite. Cu această abordare, mai târziu devine foarte dificil să navigați în versiunile bazei de date.
În plus, Liquibase, ca și casa hobbiților, păstrează multe secrete. Una dintre ele este cheia validCheckSum, care a apărut în versiunea 1.7 și vă permite să specificați o valoare hash validă pentru un anumit set de modificări, indiferent de ceea ce este stocat în baza de date. Documentație spune urmatoarele:
Adăugați o sumă de control care este considerată validă pentru acest set de modificări, indiferent de ceea ce este stocat în baza de date. Folosit în primul rând atunci când trebuie să modificați un set de modificări și nu doriți să apară erori în bazele de date pe care a rulat deja (nu este o procedură recomandată)
Da, da, această procedură nu este recomandată. Dar uneori un magician puternic al luminii stăpânește și tehnicile întunecate
Situația 2: Migrație care depinde de date
Să presupunem că nu aveți capacitatea de a utiliza copii de siguranță ale bazei de date de pe servere live. Petya a creat un set de modificări, l-a testat la nivel local și, cu încredere deplină că are dreptate, a făcut o cerere de extragere dezvoltatorului. Pentru orice eventualitate, liderul de proiect a clarificat dacă Petya l-a verificat și apoi l-a adăugat. Dar implementarea pe serverul de dezvoltare a căzut.
De fapt, acest lucru este posibil și nimeni nu este imun de acest lucru. Acest lucru se întâmplă dacă modificările aduse structurii tabelului sunt cumva legate de date specifice din baza de date. Evident, dacă baza de date Petya este plină doar cu date de testare, atunci este posibil să nu acopere toate cazurile cu probleme. De exemplu, la ștergerea unui tabel, se dovedește că există înregistrări în alte tabele prin cheie externă care sunt legate de înregistrările din cel care este șters. Sau la schimbarea unui tip de coloană, se dovedește că nu 100% din date pot fi convertite în noul tip.
Cum să decizi
- Scrieți scripturi speciale care vor fi folosite o dată odată cu migrarea și aduceți datele în forma adecvată. Aceasta este o modalitate generală de a rezolva problema transferului de date către structuri noi după aplicarea migrărilor, dar ceva similar poate fi aplicat înainte, în cazuri speciale. Această cale, desigur, nu este întotdeauna disponibilă, deoarece editarea datelor pe serverele live poate fi periculoasă și chiar distructivă.
- O altă modalitate dificilă este editarea unui set de modificări existent. Dificultatea este că toate bazele de date în care a fost deja aplicată în forma sa existentă vor trebui restaurate. Este foarte posibil ca întreaga echipă de backend să fie forțată să lanseze local baza de date de la zero.
- Și cea mai universală modalitate este de a transfera problema cu datele în mediul dezvoltatorului, recreând aceeași situație și adăugând un nou set de modificări, la cel rupt, care va ocoli problema.
În general, cu cât baza de date este mai asemănătoare ca compoziție cu baza de date a serverului de producție, cu atât sunt mai puține șanse ca problemele cu migrarea să meargă departe. Și, desigur, înainte de a trimite un set de modificări la depozit, ar trebui să vă gândiți de mai multe ori dacă va rupe ceva.
Situația 3. Liquibase începe să fie utilizată după ce intră în producție
Să presupunem că liderul echipei i-a cerut lui Petya să includă Liquibase în proiect, dar proiectul este deja în producție și există o structură de bază de date existentă.
În consecință, problema este că pe orice servere noi sau mașini de dezvoltare, aceste tabele trebuie recreate de la zero, iar mediul existent trebuie să rămână într-o stare consecventă, gata să accepte noi seturi de modificări.
Cum să decizi
Există, de asemenea, mai multe moduri:
- Primul și cel mai evident este să aveți un script separat care trebuie aplicat manual la inițializarea unui mediu nou.
- Al doilea este mai puțin evident, aveți o migrare Liquibase care se află într-un alt context Liquibase și aplicați-o. Puteți citi mai multe despre Liquibase Context aici: . În general, acesta este un mecanism interesant care poate fi folosit cu succes, de exemplu, pentru testare.
- Al treilea drum constă din mai mulți pași. În primul rând, trebuie creată o migrare pentru tabelele existente. Apoi trebuie aplicat la un anumit mediu și astfel se va obține suma de hash. Următorul pas este inițializarea tabelelor Liquibase goale pe serverul nostru non-vid, iar în tabelul cu istoricul utilizării seturilor de modificări, puteți pune manual o înregistrare despre setul de modificări „ca aplicat” cu modificările deja existente în baza de date. . Astfel, pe un server existent, numărătoarea inversă a istoricului va începe de la versiunea 2, iar toate mediile noi se vor comporta identic.
Situația 4. Migrațiile devin uriașe și nu au timp să fie finalizate
La începutul dezvoltării serviciului, de regulă, Liquibase este utilizat ca dependență externă, iar toate migrările sunt procesate la pornirea aplicației. Cu toate acestea, în timp, puteți întâlni următoarele cazuri:
- Migrațiile devin uriașe și durează mult.
- Este nevoie de migrare în medii distribuite, de exemplu, pe mai multe instanțe de server de baze de date simultan.
În acest caz, aplicarea migrărilor pentru prea mult timp va duce la o expirare la pornirea aplicației. În plus, aplicarea migrărilor la fiecare instanță de aplicație separat poate duce la desincronizarea diferitelor servere.
Cum să decizi
În astfel de cazuri, proiectul tău este deja mare, poate chiar un adult, iar Liquibase începe să acționeze ca un instrument extern separat. Faptul este că Liquibase ca bibliotecă este compilată într-un fișier jar și poate funcționa ca o dependență în cadrul unui proiect sau independent.
În modul de sine stătător, puteți lăsa implementarea migrărilor în mediul dumneavoastră CI/CD sau pe umerii puternici ai administratorilor de sistem și specialiștilor în implementare. Pentru a face acest lucru, veți avea nevoie de linia de comandă Liquibase . În acest mod, devine posibilă lansarea aplicației după ce au fost efectuate toate migrările necesare.
Producție
De fapt, pot exista multe mai multe capcane atunci când lucrați cu migrarea bazelor de date și multe dintre ele necesită o abordare creativă. Este important să înțelegeți că, dacă utilizați corect instrumentul, majoritatea acestor capcane pot fi evitate. Mai exact, a trebuit să mă ocup de toate problemele enumerate în diferite forme, iar unele dintre ele au fost rezultatul greșelilor mele. În mare parte, acest lucru se întâmplă, desigur, din cauza neatenției, dar uneori din cauza incapacității criminale de a folosi instrumentul.
Sursa: www.habr.com