Nikad se nije dogodilo, a evo ga opet!
Na sljedećem projektu odlučili smo koristiti Liquibase od samog početka kako bismo izbjegli probleme u budućnosti. Kako se pokazalo, ne znaju ga svi mladi članovi tima pravilno koristiti. Napravio sam internu radionicu koju sam potom odlučio pretvoriti u članak.
Ovaj članak uključuje korisne savjete i opise triju najočitijih zamki u koje možete upasti kada radite s alatima za migraciju relacijskih baza podataka, posebice s Liquibaseom. Dizajniran za Java programere junior i srednje razine, za iskusnije programere može biti zanimljiv za strukturiranje i ponavljanje onoga što je najvjerojatnije već poznato.
Liquibase i Flyway su glavne konkurentske tehnologije za rješavanje problema kontrole verzija relacijskih struktura u svijetu Jave. Prvi je potpuno besplatan, u praksi se češće odabire za korištenje, zbog čega je Liquibase odabran kao junak publikacije. Međutim, neke od opisanih praksi mogu biti generičke, ovisno o arhitekturi vaše aplikacije.
Relacijske migracije su prisilni način rješavanja slabe fleksibilnosti relacijskih pohrana podataka. U eri mode za OOP, stil rada s bazom podataka značio je da ćemo shemu jednom opisati i više je nećemo dirati. Ali stvarnost je takva da se stvari uvijek mijenjaju, a promjene u strukturi tablica potrebne su vrlo često. Naravno, sam proces je bolan i neugodan.
Neću ulaziti u opis tehnologije i upute za dodavanje knjižnice u vaš projekt, dovoljno je članaka napisano na ovu temu:
Osim toga, već je postojao sjajan članak na temu korisnih savjeta:
Советы
Želim podijeliti svoje savjete i komentare, koji su rođeni kroz znoj, krv i bol rješavanja problema s migracijama.
1. Prije početka trebali biste pročitati odjeljak s najboljim primjerima iz prakse Liquibase
opisane su jednostavne, ali vrlo važne stvari bez kojih vam korištenje knjižnice može zakomplicirati život. Na primjer, nestrukturalni pristup upravljanju skupom promjena prije ili kasnije će dovesti do zabune i prekinutih migracija. Ako ne uvedete međusobno ovisne promjene u strukturi baze podataka i logici usluga u isto vrijeme, postoji velika vjerojatnost da će to dovesti do crvenih testova ili pokvarenog okruženja. Osim toga, preporuke za korištenje Liquibase na službenoj web stranici sadrže odlomak o razvoju i provjeri skripti za vraćanje uz glavne skripte za migraciju. Pa u članku postoje primjeri koda koji se odnose na migracije i mehanizam povrata.
2. Ako ste počeli koristiti alate za migraciju, nemojte dopustiti ručne ispravke u strukturi baze podataka
Kao što izreka kaže: "Jednom Persil, uvijek Persil." Ako su bazom vaše aplikacije počeli upravljati Liquibase alati, sve ručne promjene odmah dovode do nekonzistentnog stanja, a razina povjerenja u skupove promjena postaje nula. Potencijalni rizici - nekoliko sati potrošeno na vraćanje baze podataka, u najgorem slučaju - mrtav poslužitelj. Ako vaš tim ima DBA arhitekta "stare škole", strpljivo i promišljeno mu objasnite kako će stvari biti loše ako samo uredi bazu podataka na svoj način iz uvjetnog SQL Developera.
3. Ako je skup promjena već gurnut u repozitorij, izbjegavajte uređivanje
Ako je drugi programer izvukao i primijenio skup promjena koji će se kasnije uređivati, sigurno će vas se sjetiti lijepom riječju kada primi grešku kada se aplikacija pokrene. Ako uređivanje skupa promjena na neki način procuri u razvoj, morat ćete ići niz sklizak niz hitnih popravka. Bit problema počiva na validaciji promjena hash sumom - glavnim mehanizmom Liquibase. Prilikom uređivanja koda skupa promjena, hash zbroj se mijenja. Uređivanje skupova promjena moguće je samo kada je moguće implementirati cijelu bazu podataka od nule bez gubitka podataka. U ovom slučaju, refaktoriranje SQL ili XML koda može, naprotiv, olakšati život, učiniti migracije čitljivijima. Primjer bi bila situacija kada je na početku aplikacije unutar tima bila usklađena shema izvorne baze podataka.
4. Imajte provjerene sigurnosne kopije baze podataka ako je moguće
Ovdje je, mislim, sve jasno. Ako je migracija odjednom bila neuspješna, sve se može vratiti natrag. Liquibase ima alat za vraćanje, ali skripte za vraćanje također piše sam programer i one mogu imati problema s istom vjerojatnošću kao i kod glavnih skripti skupa promjena. To znači da je igranje na sigurno sa sigurnosnim kopijama korisno u svakom slučaju.
5. Koristite provjerene sigurnosne kopije baze podataka u razvoju ako je moguće
Ako to nije u suprotnosti s ugovorima i privatnošću, nema osobnih podataka u bazi podataka, a ne teži kao dva sunca - prije nego što ga primijenite na poslužiteljima za migraciju uživo, možete provjeriti kako funkcionira na stroju programera i izračunati gotovo 100% potencijalnih problema tijekom migracije.
6. Razgovarajte s drugim programerima u timu
U dobro organiziranom razvojnom procesu svi u timu znaju tko što radi. U stvarnosti to često nije slučaj, stoga, ako u sklopu svog zadatka pripremate promjene u strukturi baze podataka, poželjno je o tome dodatno obavijestiti cijeli tim. Ako netko paralelno radi promjene, trebali biste se pažljivo organizirati. Vrijedno je komunicirati s kolegama i na kraju posla, ne samo na početku. Mnogi potencijalni problemi sa skupovima promjena mogu se riješiti u fazi pregleda koda.
7. Mislite što radite!
Naizgled samorazumljivi savjeti primjenjivi u svakoj situaciji. Međutim, mnogi problemi mogli su se izbjeći da je programer još jednom analizirao što radi i na što bi to moglo utjecati. Rad s migracijama uvijek zahtijeva dodatnu pažnju i točnost.
zamke
Pogledajmo sada tipične zamke u koje možete upasti ako ne slijedite gore navedene savjete i što, zapravo, treba učiniti?
Situacija 1. Dva programera pokušavaju dodati nove skupove promjena u isto vrijeme
Vasya i Petya žele stvoriti set promjena verzije 4, a da ne znaju jedno za drugo. Napravili su promjene u strukturi baze podataka i pokrenuli zahtjev za povlačenjem s različitim datotekama skupa promjena. U nastavku se predlaže sljedeći mehanizam:
Kako riješiti
- Nekako se kolege moraju dogovoriti kojim redoslijedom trebaju ići njihovi setovi promjena, recimo da se prvo treba primijeniti Petin.
- Jedna osoba treba uliti drugu i označiti Vasyin skup promjena s verzijom 5. To se može učiniti putem Cherry Picka ili urednog spajanja.
- Nakon izmjena svakako provjerite valjanost poduzetih radnji.
Zapravo, Liquibase mehanizmi će vam omogućiti da imate dva skupa promjena verzije 4 u repozitoriju, tako da možete ostaviti sve kako jest. To jest, jednostavno ćete imati dvije revizije verzije 4 s različitim imenima. Uz ovaj pristup, verzije baze podataka kasnije postaju vrlo teške za navigaciju.
Osim toga, Liquibase, poput domova hobita, čuva puno tajni. Jedan od njih je validCheckSum ključ, koji se pojavio od verzije 1.7 i omogućuje vam da navedete valjanu hash vrijednost za određeni skup promjena, bez obzira na to što je pohranjeno u bazi podataka. Dokumentacija kaže sljedeće:
Dodajte kontrolni zbroj koji se smatra valjanim za ovaj skup promjena, bez obzira na to što je pohranjeno u bazi podataka. Koristi se primarno kada trebate promijeniti changeSet i ne želite da se greške pojavljuju u bazama podataka na kojima je već pokrenut (nije preporučeni postupak)
Da, to se ne preporučuje. Ali ponekad jaki svjetlosni mag također vlada mračnim tehnikama.
Slučaj 2: Migracija vođena podacima
Recimo da ne možete koristiti sigurnosne kopije baze podataka s živih poslužitelja. Petya je napravio skup promjena, testirao ga lokalno i s punim uvjerenjem da je u pravu, uputio zahtjev za povlačenjem programeru. Za svaki slučaj, voditelj projekta pojasnio je je li ga Petya provjerio, a zatim ga ulio. Ali implementacija na razvojnom poslužitelju je pala.
Zapravo, to je moguće i nitko nije imun na to. To se događa ako su izmjene strukture tablice na neki način povezane s određenim podacima iz baze podataka. Očito, ako je Petyina baza podataka ispunjena samo testnim podacima, možda neće pokriti sve problematične slučajeve. Na primjer, kada brišete tablicu, ispada da postoje zapisi u drugim tablicama prema stranom ključu povezani sa zapisima u onoj koja se briše. Ili se prilikom promjene vrste stupca ispostavi da se ne može 100% podataka pretvoriti u novu vrstu.
Kako riješiti
- Napišite posebne skripte koje će se primijeniti jednom zajedno s migracijom i dovesti podatke u ispravan oblik. Ovo je opći način rješavanja problema prijenosa podataka u nove strukture nakon primjene migracija, no nešto slično može se primijeniti i prije, u posebnim slučajevima. Ovaj put, naravno, nije uvijek dostupan, jer uređivanje podataka na živim poslužiteljima može biti opasno, pa čak i kobno.
- Još jedan lukav način je urediti postojeći skup promjena. Poteškoća je u tome što će se morati obnoviti sve baze podataka gdje je već primijenjen u postojećem obliku. Sasvim je moguće da će cijeli backend tim biti prisiljen lokalno smotati bazu podataka od nule.
- A najuniverzalniji način je prenijeti problem s podacima u okruženje programera, ponovno stvoriti istu situaciju i dodati novi skup promjena, na pokvareni, koji će zaobići problem.
Općenito, što je baza podataka po sastavu sličnija bazi podataka proizvodnog poslužitelja, manja je vjerojatnost da će problemi s migracijama ići daleko. I, naravno, prije nego što pošaljete skup promjena u repozitorij, trebali biste nekoliko puta razmisliti hoće li nešto pokvariti.
Situacija 3. Liquibase se počinje koristiti nakon što krene u proizvodnju
Pretpostavimo da je voditelj tima zamolio Petyu da uključi Liquibase u projekt, ali projekt je već u produkciji i već postoji struktura baze podataka.
Sukladno tome, problem je u tome što se na svim novim poslužiteljima ili strojevima za razvojne programere podaci tablice moraju ponovno kreirati od nule, a već postojeće okruženje mora ostati u dosljednom stanju, spremno prihvatiti nove skupove promjena.
Kako riješiti
Također postoji nekoliko načina:
- Prvi i najočitiji je imati zasebnu skriptu koja se mora primijeniti ručno prilikom pokretanja novog okruženja.
- Drugi, manje očit, je imati Liquibase migraciju koja je u drugom Liquibase kontekstu i primijeniti je. Više o Liquibase Context možete pročitati ovdje: . Općenito, ovo je zanimljiv mehanizam koji se može uspješno primijeniti, na primjer, za testiranje.
- Treći put se sastoji od nekoliko koraka. Prvo se mora napraviti migracija za postojeće tablice. Zatim se mora primijeniti na neko okruženje i tako će se dobiti njegov hash zbroj. Sljedeći korak je inicijaliziranje praznih Liquibase tablica na našem nepraznom poslužitelju, a možete ručno staviti zapis skupa promjena "kao da je primijenjen" s promjenama koje su već u bazi podataka u tablicu s poviješću primjene skupova promjena. Tako će na već postojećem poslužitelju povijest krenuti od verzije 2, a sva nova okruženja će se ponašati identično.
Scenarij 4: Migracije postaju ogromne i ne mogu ih pratiti
Na početku razvoja usluge Liquibase se u pravilu koristi kao vanjska ovisnost, a sve migracije obrađuju se prilikom pokretanja aplikacije. Međutim, s vremenom možete naići na sljedeće slučajeve:
- Migracije postaju ogromne i potrebno im je mnogo vremena da se završe.
- Postoji potreba za migracijom u distribuiranim okruženjima, na primjer, na nekoliko instanci poslužitelja baze podataka u isto vrijeme.
U tom slučaju preduga primjena migracija rezultirat će istekom vremena kada se aplikacija pokrene. Također, primjena migracija po instanci aplikacije može dovesti do toga da različiti poslužitelji budu u stanju izvan sinkronizacije.
Kako riješiti
U takvim slučajevima vaš je projekt već velik, možda čak i odrastao, a Liquibase počinje djelovati kao zaseban vanjski alat. Činjenica je da je Liquibase, kao biblioteka, sastavljena u jar datoteku, te može raditi kao ovisnost unutar projekta, ali i samostalno.
Izvanmrežno, možete prepustiti primjenu migracija vašem CI/CD okruženju ili jakim ramenima vaših sistemskih administratora/deployera. Da biste to učinili, potreban vam je naredbeni redak Liquibase . U ovom načinu rada postaje moguće pokrenuti aplikaciju nakon što su dovršene sve potrebne migracije.
Izlaz
Zapravo, postoji mnogo više zamki pri radu s migracijama baza podataka, a mnoge od njih zahtijevaju kreativan pristup. Važno je razumjeti da se većina ovih zamki može izbjeći ako se alat pravilno koristi. Naime, morao sam se suočiti sa svim navedenim problemima u različitim oblicima, a neki od njih su rezultat mojih zastoja. Uglavnom, to se događa, naravno, zbog nepažnje, ali ponekad - zbog kriminalne nemogućnosti korištenja alata.
Izvor: www.habr.com