Še nikoli prej, pa smo spet!
Pri našem naslednjem projektu smo se že od samega začetka odločili uporabiti Liquibase, da bi se izognili težavam v prihodnosti. Izkazalo se je, da ga vsi mladi člani ekipe ne znajo pravilno uporabljati. Izvedla sem interno delavnico, ki sem se jo nato odločila spremeniti v članek.
Članek vključuje koristne nasvete in opis treh najbolj očitnih pasti, v katere se lahko ujamete pri delu z orodji za selitev relacijskih baz podatkov, zlasti Liquibase. Zasnovan za razvijalce Java na nižji in srednji ravni; za bolj izkušene razvijalce je lahko zanimiv za strukturiranje in ponavljanje tega, kar je najverjetneje že znano.
Liquibase in Flyway sta glavni konkurenčni tehnologiji za reševanje problemov nadzora različic relacijskih struktur v svetu Jave. Prvi je popolnoma brezplačen, v praksi je za uporabo najpogosteje izbran, zato je bil Liquibase izbran za junaka objave. Vendar pa so nekatere od opisanih praks morda univerzalne, odvisno od arhitekture vaše aplikacije.
Migracije relacijskih struktur so prisiljen način za spopadanje s šibko prožnostjo relacijskih podatkovnih shramb. V dobi mode OOP je stil dela z bazami podatkov pomenil, da shemo enkrat opišemo in se je ne dotikamo več. Toda v resnici se stvari vedno spreminjajo in spremembe strukture tabele so potrebne precej pogosto. Seveda je sam proces lahko boleč in neprijeten.
Ne bom se poglabljal v opis tehnologije in navodila za dodajanje knjižnice v vaš projekt, na to temo je bilo napisanih kar nekaj člankov:
Poleg tega je bil že odličen članek na temo uporabnih nasvetov:
Советы
Deliti želim svoje nasvete in komentarje, ki so nastali v znoju, krvi in bolečini reševanja problemov z migracijami.
1. Preden začnete z delom, se seznanite z razdelkom o najboljših praksah Liquibase
opisane so preproste, a zelo pomembne stvari, brez katerih si uporaba knjižnice lahko zaplete življenje. Na primer, nestrukturiran pristop k upravljanju naborov sprememb bo prej ali slej povzročil zmedo in neuspešne migracije. Če hkrati ne uvedete medsebojno odvisnih sprememb strukture baze podatkov in storitvene logike, obstaja velika verjetnost, da bo to vodilo do rdečih testov ali pokvarjenega okolja. Poleg tega priporočila za uporabo Liquibase na uradnem spletnem mestu vsebujejo klavzulo o razvoju in testiranju skriptov za povrnitev nazaj skupaj z glavnimi skripti za selitev. No, v članku Obstajajo primeri kode v zvezi s selitvami in mehanizmom za povrnitev.
2. Če začnete uporabljati orodja za selitev, ne dovolite ročnih popravkov v strukturi baze podatkov
Kot pravi pregovor: "Enkrat Persil, vedno Persil." Če osnovo vaše aplikacije začne upravljati Liquibase, vse ročne spremembe takoj vodijo v nedosledno stanje in stopnja zaupanja v nabore sprememb postane nič. Potencialna tveganja vključujejo več ur, porabljenih za obnavljanje baze podatkov; v najslabšem primeru mrtev strežnik. Če imate v svoji ekipi arhitekta DBA »stare šole«, mu potrpežljivo in premišljeno razložite, kako slabe bodo stvari, če preprosto uredi bazo podatkov v skladu s svojim razumevanjem pogojnega razvijalca SQL.
3. Če je bil nabor sprememb že potisnjen v repozitorij, se izogibajte urejanju
Če je drug razvijalec naredil poteg in uporabil nabor sprememb, ki bo kasneje urejen, se vas bo zagotovo spomnil s prijazno besedo, ko bo prejel napako pri zagonu aplikacije. Če urejanje nabora sprememb nekako uide v razvoj, boste morali slediti spolzkemu pobočju hitrih popravkov. Bistvo problema je v validaciji sprememb z zgoščeno vsoto - glavnim mehanizmom Liquibase. Pri urejanju kode nabora sprememb se spremeni količina zgoščene vrednosti. Urejanje naborov sprememb je možno le, če je mogoče celotno bazo podatkov namestiti iz nič brez izgube podatkov. V tem primeru lahko preoblikovanje kode SQL ali XML, nasprotno, olajša življenje in naredi migracije bolj berljive. Primer bi bila situacija, ko je bila na začetku aplikacije znotraj ekipe dogovorjena shema izvorne baze podatkov.
4. Po možnosti imejte preverjene varnostne kopije baze podatkov
Tukaj, mislim, je vse jasno. Če je bila selitev nenadoma neuspešna, je mogoče vse vrniti nazaj. Liquibase ima orodje za povrnitev sprememb, vendar tudi skripte za povrnitev napiše razvijalec sam in imajo lahko težave z enako verjetnostjo kot skripti glavnega nabora sprememb. To pomeni, da je v vsakem primeru koristno igrati varno z varnostnimi kopijami.
5. Pri razvoju uporabljajte preizkušene varnostne kopije baze podatkov, če je mogoče
Če to ni v nasprotju s pogodbami in zasebnostjo, v bazi ni osebnih podatkov in ne tehta toliko kot dve sonci - pred uporabo na strežnikih za migracijo v živo lahko preverite, kako se bo obnesel na stroju razvijalca in izračunajte skoraj 100 % morebitnih težav med selitvijo.
6. Komunicirajte z drugimi razvijalci v skupini
V dobro organiziranem razvojnem procesu vsi v ekipi vedo, kdo kaj dela. V resnici pogosto ni tako, zato je priporočljivo, če v okviru svoje naloge pripravljate spremembe strukture baze podatkov, o tem dodatno obvestiti celotno ekipo. Če nekdo vzporedno izvaja spremembe, se morate skrbno organizirati. S sodelavci je vredno komunicirati po končanem delu, ne le na začetku. Številne morebitne težave z nizi sprememb je mogoče rešiti v fazi pregleda kode.
7. Premislite, kaj počnete!
Zdi se kot samoumeven nasvet, ki velja za vsako situacijo. Vendar bi se številnim težavam lahko izognili, če bi razvijalec še enkrat analiziral, kaj počne in na kaj lahko vpliva. Delo z migracijami vedno zahteva dodatno pozornost in natančnost.
Pasti
Oglejmo si zdaj tipične pasti, v katere se lahko ujamete, če ne upoštevate zgornjih nasvetov, in kaj točno bi morali storiti?
Situacija 1: Dva razvijalca poskušata dodati nove nabore sprememb hkrati
Vasya in Petya želita ustvariti nabor sprememb različice 4, ne da bi vedela drug za drugega. Spremenili so strukturo baze podatkov in izdali zahtevo za vlečenje z različnimi datotekami nabora sprememb. Predlaga se naslednji mehanizem delovanja:
Kako se odločiti
- Nekako se morajo kolegi dogovoriti o vrstnem redu, v katerem naj gredo njihovi nabori sprememb, na primer, najprej je treba uporabiti Petin.
- Nekdo bi moral dodati drugega k sebi in označiti Vasyin nabor sprememb z različico 5. To je mogoče storiti s Cherry Pick ali čednim spajanjem.
- Po spremembah vsekakor preverite veljavnost izvedenih dejanj.
Pravzaprav vam bodo mehanizmi Liquibase omogočili, da imate v skladišču dva nabora sprememb različice 4, tako da lahko vse pustite tako, kot je. To pomeni, da boste preprosto imeli dve spremembi različice 4 z različnimi imeni. S tem pristopom je kasneje zelo težko krmariti po različicah baze podatkov.
Poleg tega Liquibase, kot dom hobitov, hrani veliko skrivnosti. Eden od njih je ključ validCheckSum, ki se je pojavil v različici 1.7 in vam omogoča, da določite veljavno zgoščeno vrednost za določen nabor sprememb, ne glede na to, kaj je shranjeno v bazi podatkov. Dokumentacija govori naslednje:
Dodajte kontrolno vsoto, ki se šteje za veljavno za ta changeSet, ne glede na to, kaj je shranjeno v bazi podatkov. Uporablja se predvsem, ko morate spremeniti changeSet in ne želite, da se v bazah podatkov, v katerih se je že izvajal, pojavijo napake (ni priporočen postopek)
Da, da, ta postopek ni priporočljiv. Včasih pa močan svetlobni mag obvlada tudi temne tehnike
2. situacija: selitev, ki je odvisna od podatkov
Predpostavimo, da nimate možnosti uporabe varnostnih kopij podatkovnih baz iz strežnikov v živo. Petya je ustvaril nabor sprememb, ga testiral lokalno in s popolnim prepričanjem, da je imel prav, podal zahtevo za vleko razvijalcu. Za vsak slučaj je vodja projekta pojasnil, ali je Petya to preveril, in nato dodal. Toda uvedba na razvojnem strežniku je padla.
Pravzaprav je to mogoče in nihče ni imun na to. To se zgodi, če so spremembe strukture tabele nekako povezane z določenimi podatki iz baze podatkov. Očitno je, da če je Petyina zbirka podatkov napolnjena samo s testnimi podatki, morda ne bo zajemala vseh težavnih primerov. Na primer, pri brisanju tabele se izkaže, da obstajajo zapisi v drugih tabelah po zunanjem ključu, ki so povezani z zapisi v tisti, ki se briše. Ali pa se pri spreminjanju vrste stolpca izkaže, da ni mogoče 100 % podatkov pretvoriti v novo vrsto.
Kako se odločiti
- Napišite posebne skripte, ki bodo uporabljene enkrat ob selitvi in spravite podatke v ustrezno obliko. To je splošen način reševanja problema prenosa podatkov v nove strukture po uporabi migracij, vendar je nekaj podobnega mogoče uporabiti že prej, v posebnih primerih. Ta pot seveda ni vedno na voljo, saj je urejanje podatkov na živih strežnikih lahko nevarno in celo uničujoče.
- Drug težaven način je urejanje obstoječega nabora sprememb. Težava je v tem, da bo treba obnoviti vse zbirke podatkov, kjer je bil že uporabljen v obstoječi obliki. Povsem mogoče je, da bo celotna zaledna ekipa prisiljena lokalno uvesti bazo podatkov iz nič.
- In najbolj univerzalen način je prenos težave s podatki v okolje razvijalca, ponovno ustvarjanje iste situacije in dodajanje novega nabora sprememb pokvarjenemu, ki bo zaobšel težavo.
Na splošno velja, da bolj kot je baza podatkov po sestavi podobna bazi podatkov proizvodnega strežnika, manjša je možnost, da bodo težave s selitvami segle daleč. In seveda, preden pošljete nabor sprememb v repozitorij, morate večkrat premisliti, ali bo kaj pokvaril.
Situacija 3. Liquibase se začne uporabljati po začetku proizvodnje
Recimo, da je vodja skupine Petyo prosil, naj v projekt vključi Liquibase, vendar je projekt že v proizvodnji in obstaja obstoječa struktura baze podatkov.
V skladu s tem je težava v tem, da je treba na vseh novih strežnikih ali strojih za razvijalce te tabele ponovno ustvariti iz nič, obstoječe okolje pa mora ostati v konsistentnem stanju, pripravljeno za sprejemanje novih naborov sprememb.
Kako se odločiti
Obstaja tudi več načinov:
- Prvi in najbolj očiten je imeti ločen skript, ki ga je treba uporabiti ročno pri inicializaciji novega okolja.
- Drugi je manj očiten, pripravite selitev Liquibase, ki je v drugem kontekstu Liquibase, in jo uporabite. Več o Liquibase Context lahko preberete tukaj: . Na splošno je to zanimiv mehanizem, ki ga je mogoče uspešno uporabiti na primer za testiranje.
- Tretja pot je sestavljena iz več korakov. Najprej je treba ustvariti selitev za obstoječe tabele. Nato ga je treba uporabiti v nekem okolju in tako bo pridobljena njegova zgoščena vsota. Naslednji korak je inicializacija praznih tabel Liquibase na našem nepraznem strežniku, v tabelo z zgodovino uporabe naborov sprememb pa lahko ročno vnesete zapis o naboru sprememb »kot uporabljen« s spremembami, ki že obstajajo v bazi podatkov . Tako se bo na obstoječem strežniku odštevanje zgodovine začelo od različice 2 in vsa nova okolja se bodo obnašala enako.
Situacija 4. Migracije postanejo ogromne in nimajo časa za dokončanje
Na začetku razvoja storitve se Liquibase praviloma uporablja kot zunanja odvisnost, vse migracije pa se obdelajo ob zagonu aplikacije. Vendar pa lahko sčasoma naletite na naslednje primere:
- Migracije postanejo ogromne in trajajo dolgo časa.
- Obstaja potreba po selitvi v porazdeljenih okoljih, na primer na več primerkih strežnika baze podatkov hkrati.
V tem primeru bo predolga uporaba selitev povzročila časovno omejitev ob zagonu aplikacije. Poleg tega lahko uporaba selitev za vsak primerek aplikacije posebej povzroči, da različni strežniki niso sinhronizirani.
Kako se odločiti
V takih primerih je vaš projekt že velik, morda celo odrasel, Liquibase pa začne delovati kot ločeno zunanje orodje. Dejstvo je, da je Liquibase kot knjižnica prevedena v datoteko jar in lahko deluje kot odvisnost znotraj projekta ali samostojno.
V samostojnem načinu lahko izvajanje selitev prepustite svojemu okolju CI/CD ali močnim ramenom vaših sistemskih skrbnikov in strokovnjakov za uvajanje. Za to boste potrebovali ukazno vrstico Liquibase . V tem načinu je mogoče zagnati aplikacijo, potem ko so bile izvedene vse potrebne selitve.
Izhod
Pravzaprav je lahko veliko več pasti pri delu s selitvami baz podatkov in mnoge od njih zahtevajo kreativen pristop. Pomembno je razumeti, da se je večini teh pasti mogoče izogniti, če orodje uporabljate pravilno. Natančneje, z vsemi naštetimi težavami sem se moral soočiti v različnih oblikah, nekatere pa so bile posledica mojih napak. Večinoma se to zgodi seveda zaradi nepazljivosti, včasih pa zaradi kriminalne nezmožnosti uporabe orodja.
Vir: www.habr.com