Dit het nooit gebeur nie, en hier is dit weer!
Met die volgende projek het ons besluit om Liquibase van die begin af te gebruik om probleme in die toekoms te vermy. Soos dit geblyk het, weet nie alle jongspanlede hoe om dit reg te gebruik nie. Ek het 'n interne werkswinkel gedoen, wat ek toe besluit het om in 'n artikel te omskep.
Hierdie artikel bevat nuttige wenke en beskrywings van drie van die mees voor die hand liggende slaggate waarin u kan val wanneer u met relasionele databasismigrasie-nutsgoed werk, veral Liquibase. Ontwerp vir Java-ontwikkelaars van Junior en Middelvlak, vir meer ervare ontwikkelaars kan dit interessant wees om te struktureer en te herhaal wat heel waarskynlik reeds bekend is.
Liquibase en Flyway is die belangrikste mededingende tegnologieë vir die oplossing van die probleme van weergawebeheer van relasionele strukture in die Java-wêreld. Die eerste is heeltemal gratis, in die praktyk word dit meer dikwels vir gebruik gekies, en daarom is Liquibase as die held van die publikasie gekies. Sommige van die praktyke wat beskryf word, kan egter generies wees, afhangend van die argitektuur van jou aansoek.
Relasionele migrasies is 'n gedwonge manier om die swak buigsaamheid van relasionele datawinkels te hanteer. In die era van mode vir OOP het die styl van werk met die databasis beteken dat ons die skema een keer sou beskryf en nie weer daaraan sou raak nie. Maar die realiteit is altyd dat dinge verander, en veranderinge aan die struktuur van tabelle word gereeld vereis. Natuurlik is die proses self pynlik en onaangenaam.
Ek sal nie delf in die beskrywing van die tegnologie en instruksies om die biblioteek by jou projek te voeg nie, genoeg artikels is oor hierdie onderwerp geskryf:
Daarbenewens was daar reeds 'n wonderlike artikel oor die onderwerp van nuttige wenke:
Советы
Ek wil my raad en kommentaar deel, wat gebore is deur die sweet, bloed en pyn om probleme met migrasie op te los.
1. Voordat jy begin, moet jy die beste praktyke-afdeling oor Liquibase
eenvoudige maar baie belangrike dinge word beskryf, waarsonder die gebruik van die biblioteek jou lewe kan bemoeilik. Byvoorbeeld, 'n nie-strukturele benadering tot veranderingstelbestuur sal vroeër of later tot verwarring en gebroke migrasies lei. As jy nie op dieselfde tyd wedersyds afhanklike veranderinge in die struktuur van die databasis en die logika van dienste uitrol nie, is daar 'n groot waarskynlikheid dat dit tot rooi toetse of 'n stukkende omgewing sal lei. Daarbenewens bevat die aanbevelings vir die gebruik van Liquibase op die amptelike webwerf 'n paragraaf oor die ontwikkeling en verifikasie van terugrolskrifte saam met die hoofmigrasieskrifte. Wel, in die artikel daar is voorbeelde van kode wat verband hou met migrasies en die terugrolmeganisme.
2. As jy migrasienutsmiddels begin gebruik het, moenie handmatige regstellings in die databasisstruktuur toelaat nie
Soos die spreekwoord sê: "Eens Persil, altyd Persil." As die basis van u toepassing deur Liquibase-nutsgoed begin bestuur word, lei enige handmatige veranderinge onmiddellik tot 'n inkonsekwente toestand, en die vlak van vertroue in veranderingsstelle word nul. Potensiële risiko's - 'n paar uur spandeer aan die herstel van die databasis, in die ergste geval - 'n dooie bediener. As jou span 'n "ou skool" DBA-argitek het, verduidelik geduldig en bedagsaam aan hom hoe sleg dinge sal wees as hy net die databasis op sy eie manier redigeer vanaf die voorwaardelike SQL-ontwikkelaar.
3. As die veranderingstel reeds na die bewaarplek gestoot is, vermy redigering
As 'n ander ontwikkelaar 'n veranderingstel getrek en toegepas het wat later geredigeer sal word, sal hy jou beslis met 'n vriendelike woord onthou wanneer hy 'n fout ontvang wanneer die toepassing begin. As die wysiging van die veranderingstel op een of ander manier in ontwikkeling uitlek, sal jy die glibberige helling van hotfixes moet afgaan. Die kern van die probleem berus op die validering van veranderinge deur hash-som - die hoofmeganisme van Liquibase. Wanneer die veranderingsetkode gewysig word, verander die hash-som. Die wysiging van veranderingsstelle is slegs moontlik wanneer dit moontlik is om die hele databasis van nuuts af te ontplooi sonder om data te verloor. In hierdie geval kan herfaktorering van SQL- of XML-kode, inteendeel, die lewe makliker maak, migrasies meer leesbaar maak. 'n Voorbeeld sou 'n situasie wees wanneer, aan die begin van die toepassing, die skema van die brondatabasis binne die span gekoördineer is.
4. Het geverifieerde databasis-rugsteun indien moontlik
Hier, dink ek, is alles duidelik. As die migrasie skielik onsuksesvol was, kan alles teruggestuur word. Liquibase het 'n terugrol-instrument, maar die terugrol-skripte word ook deur die ontwikkelaar self geskryf, en hulle kan probleme hê met dieselfde waarskynlikheid as in die hoofveranderingsetskrifte. Dit beteken dat dit in elk geval nuttig is om dit veilig te speel met rugsteun.
5. Gebruik geverifieerde databasisrugsteun in ontwikkeling indien moontlik
As dit nie kontrakte en privaatheid weerspreek nie, is daar geen persoonlike data in die databasis nie, en dit weeg nie soos twee sonne nie - voordat jy dit op regstreekse migrasiebedieners toepas, kan jy kyk hoe dit op die ontwikkelaar se masjien werk en byna 100% bereken van potensiële probleme tydens migrasie.
6. Gesels met ander ontwikkelaars in die span
In 'n goed georganiseerde ontwikkelingsproses weet almal in die span wie wat doen. In werklikheid is dit dikwels nie die geval nie, daarom, as jy veranderinge in die databasisstruktuur as deel van jou taak voorberei, is dit raadsaam om die hele span addisioneel hieroor in kennis te stel. As iemand parallel veranderinge aanbring, moet jy versigtig organiseer. Dit is die moeite werd om met kollegas te kommunikeer, selfs aan die einde van die werk, nie net aan die begin nie. Baie potensiële probleme met veranderingsstelle kan opgelos word tydens die kodehersieningstadium.
7. Dink wat jy doen!
Oënskynlik vanselfsprekende advies van toepassing op enige situasie. Baie probleme kon egter vermy gewees het as die ontwikkelaar weereens ontleed het wat hy doen en wat dit kan raak. Om met migrasies te werk, verg altyd ekstra aandag en akkuraatheid.
strikke
Kom ons kyk nou na die tipiese strikke waarin jy kan trap as jy nie die raad hierbo volg nie, en wat moet eintlik gedoen word?
Situasie 1. Twee ontwikkelaars probeer om nuwe veranderings op dieselfde tyd by te voeg
Vasya en Petya wil 'n weergawe 4-veranderingstel skep sonder om van mekaar te weet. Hulle het veranderinge aan die databasisstruktuur aangebring en 'n trekversoek uitgerol met verskillende veranderingsetlêers. Die volgende meganisme word hieronder voorgestel:
Hoe om op te los
- Op een of ander manier moet kollegas saamstem oor die volgorde waarin hul veranderings moet plaasvind, kom ons sê Petin moet eers toegepas word.
- Een persoon moet die ander een in gooi en Vasya se veranderingset met weergawe 5 merk. Dit kan gedoen word via Cherry Pick of 'n netjiese samesmelting.
- Na die veranderinge, maak seker dat u die geldigheid van die aksies wat geneem is, nagaan.
Trouens, die Liquibase-meganismes sal jou toelaat om twee weergawe 4-veranderingsstelle in die bewaarplek te hê, sodat jy alles kan laat soos dit is. Dit wil sê, jy sal eenvoudig twee hersienings van weergawe 4 met verskillende name hê. Met hierdie benadering word databasisweergawes later baie moeilik om te navigeer.
Daarbenewens hou Liquibase, soos die huise van hobbits, baie geheime. Een daarvan is die validCheckSum-sleutel, wat sedert weergawe 1.7 verskyn het en jou toelaat om 'n geldige hash-waarde vir 'n spesifieke veranderingstel te spesifiseer, ongeag wat in die databasis gestoor word. Dokumentasie sê die volgende:
Voeg 'n kontrolesom by wat as geldig vir hierdie veranderingSet beskou word, ongeag wat in die databasis gestoor word. Word hoofsaaklik gebruik wanneer jy 'n changeSet moet verander en nie wil hê dat foute op databasisse gegooi word waarop dit reeds geloop het nie (nie 'n aanbevole prosedure nie)
Ja, dit word nie aanbeveel nie. Maar soms bemeester 'n sterk ligte towenaar ook donker tegnieke.
Geval 2: Data-gedrewe migrasie
Kom ons sê jy kan nie databasisrugsteun vanaf lewendige bedieners gebruik nie. Petya het 'n veranderingstel geskep, dit plaaslik getoets en met volle vertroue dat hy reg was, 'n trekversoek aan die ontwikkelaar gerig. Net vir ingeval, die projekleier het duidelik gemaak of Petya dit nagegaan het, en dit toe ingegooi. Maar die ontplooiing op die ontwikkelingsbediener het gedaal.
Trouens, dit is moontlik, en niemand is immuun hierteen nie. Dit gebeur as wysigings aan die tabelstruktuur op een of ander manier gekoppel is aan spesifieke data van die databasis. Dit is duidelik dat, as Petya se databasis slegs met toetsdata gevul is, dit moontlik nie alle probleemgevalle dek nie. Byvoorbeeld, wanneer 'n tabel uitgevee word, blyk dit dat daar rekords in ander tabelle deur Foreign Key geassosieer word met rekords in die een wat uitgevee word. Of wanneer die kolomtipe verander word, blyk dit dat nie 100% van die data na die nuwe tipe omgeskakel kan word nie.
Hoe om op te los
- Skryf spesiale skrifte wat een keer saam met die migrasie toegepas sal word en bring die data in die regte vorm. Dit is 'n algemene manier om die probleem op te los om data na nuwe strukture oor te dra nadat migrasies toegepas is, maar iets soortgelyks kan voorheen toegepas word, in spesiale gevalle. Hierdie pad is natuurlik nie altyd beskikbaar nie, want die redigering van data op lewendige bedieners kan gevaarlik en selfs dodelik wees.
- Nog 'n moeilike manier is om 'n bestaande veranderingstel te wysig. Die moeilikheid is dat al die databasisse waar dit reeds in sy bestaande vorm toegepas is, herstel sal moet word. Dit is heel moontlik dat die hele backend-span gedwing sal word om die databasis van nuuts af plaaslik op te rol.
- En die mees universele manier is om die dataprobleem na die ontwikkelaar se omgewing oor te dra, dieselfde situasie te herskep en 'n nuwe veranderingstel by 'n stukkende een by te voeg wat die probleem sal omseil.
Oor die algemeen, hoe meer die databasis in samestelling soortgelyk is aan die produksiebedienerdatabasis, hoe minder waarskynlik sal probleme met migrasies ver strek. En, natuurlik, voordat jy die veranderingset na die bewaarplek stuur, moet jy verskeie kere dink of dit iets sal breek.
Situasie 3. Liquibase begin gebruik word nadat dit in produksie is
Gestel die spanleier het Petya gevra om Liquibase by die projek in te sluit, maar die projek is reeds in produksie en daar is 'n reeds bestaande databasisstruktuur.
Gevolglik is die probleem dat op enige nuwe bedieners of ontwikkelaarmasjiene die tabeldata van nuuts af herskep moet word, en die reeds bestaande omgewing moet in 'n konsekwente toestand bly, gereed wees om nuwe veranderinge te aanvaar.
Hoe om op te los
Daar is ook verskeie maniere:
- Die eerste en mees voor die hand liggende is om 'n aparte skrif te hê wat met die hand toegepas moet word wanneer 'n nuwe omgewing geïnisieer word.
- Die tweede, minder voor die hand liggend, is om 'n Liquibase-migrasie te hê wat in 'n ander Liquibase-konteks is en dit toe te pas. Jy kan meer lees oor Liquibase Context hier: . Oor die algemeen is dit 'n interessante meganisme wat suksesvol aangewend kan word, byvoorbeeld vir toetsing.
- Die derde pad bestaan uit verskeie stappe. Eerstens moet 'n migrasie vir bestaande tabelle geskep word. Dan moet dit op een of ander omgewing toegepas word en sodoende sal die hash-som daarvan verkry word. Die volgende stap is om leë Liquibase-tabelle op ons nie-leë bediener te inisialiseer, en jy kan 'n rekord van 'n "asof toegepas" veranderingstel met die veranderinge wat reeds in die databasis is, met die hand in die tabel plaas met die geskiedenis van toepassing van veranderings. Dus, op 'n reeds bestaande bediener, sal die geskiedenis vanaf weergawe 2 begin, en alle nuwe omgewings sal identies optree.
Scenario 4: Migrasies word groot en kan nie byhou nie
Aan die begin van diensontwikkeling word Liquibase as 'n reël as 'n eksterne afhanklikheid gebruik, en alle migrasies word verwerk wanneer die toepassing begin. Met verloop van tyd kan jy egter op die volgende gevalle struikel:
- Migrasies word groot en neem 'n lang tyd om te voltooi.
- Daar is 'n behoefte om te migreer in verspreide omgewings, byvoorbeeld op verskeie gevalle van databasisbedieners op dieselfde tyd.
In hierdie geval sal die toepassing van migrasies vir te lank lei tot 'n uitteltyd wanneer die toepassing begin. Die toepassing van migrasies op 'n toepassingsinstansie-basis kan ook daartoe lei dat verskillende bedieners in 'n buite gesinkroniseerde toestand is.
Hoe om op te los
In sulke gevalle is u projek reeds groot, miskien selfs 'n volwassene, en Liquibase begin as 'n aparte eksterne hulpmiddel optree. Die feit is dat Liquibase, as 'n biblioteek, in 'n jar-lêer saamgestel is, en kan as 'n afhanklikheid binne die projek werk, sowel as selfstandig.
Vanlyn kan jy die toepassing van migrasies na jou CI/CD-omgewing of aan die sterk skouers van jou sysadmins/ontplooiers oorlaat. Om dit te doen, benodig jy die Liquibase-opdragreël . In hierdie modus word dit moontlik om die toepassing te begin nadat al die nodige migrasies voltooi is.
Output
Trouens, daar is baie meer slaggate wanneer u met databasismigrasies werk, en baie van hulle vereis 'n kreatiewe benadering. Dit is belangrik om te verstaan dat as jy die gereedskap korrek gebruik, die meeste van hierdie lokvalle vermy kan word. Spesifiek, ek moes al die probleme wat in verskillende vorme genoem word, in die gesig staar, en sommige van hulle was die gevolg van my jambs. Basies gebeur dit natuurlik as gevolg van onoplettendheid, maar soms - as gevolg van die kriminele onvermoë om die instrument te gebruik.
Bron: will.com