Ez da inoiz gertatu, eta hemen dago berriro!
Hurrengo proiektuan, Liquibase hasiera-hasieratik erabiltzea erabaki genuen etorkizunean arazoak saihesteko. Ikusten denez, taldekide gazte guztiek ez dakite behar bezala erabiltzen. Barne tailer bat egin nuen, eta orduan artikulu bihurtzea erabaki nuen.
Artikulu honek datu-base erlazionalak migratzeko tresnekin lan egiten duzunean, Liquibase bereziki, jasa ditzakezun hiru hutsuneen inguruko aholku lagungarriak eta deskribapenak biltzen ditu. Junior eta Erdi mailako Java garatzaileentzat diseinatua, esperientziadun garatzaileentzat interesgarria izan daiteke ziurrenik ezagutzen dena egituratzeko eta errepikatzeko.
Liquibase eta Flyway dira Java munduan erlazio-egituren bertsio-kontrolaren arazoak konpontzeko lehian dauden teknologia nagusiak. Lehenengoa guztiz doakoa da, praktikan maizago aukeratzen da erabiltzeko, horregatik Liquibase aukeratu zen argitalpenaren heroi gisa. Hala ere, deskribatutako praktika batzuk generikoak izan daitezke, zure aplikazioaren arkitekturaren arabera.
Erlazio-migrazioak datu-biltegien malgutasun ahulari aurre egiteko modu behartua dira. OOP-aren modaren garaian, datu-basearekin lan egiteko estiloak eskema behin deskribatuko genuela eta berriro ez ukituko genuen. Baina errealitatea beti da gauzak aldatzen direla, eta taulen egituran aldaketak behar izaten dira sarritan. Jakina, prozesua bera mingarria eta desatsegina da.
Ez naiz zure proiektuan liburutegia gehitzeko teknologiaren deskribapenean eta argibideetan sakonduko, gai honi buruz nahikoa artikulu idatzi dira:
Horrez gain, dagoeneko artikulu bikaina zegoen aholku baliagarrien gaiari buruz:
Π‘ΠΎΠ²Π΅ΡΡ
Nire aholkuak eta iruzkinak partekatu nahi ditut, migrazio arazoak konpontzeko izerdi, odol eta minaren bidez jaio direnak.
1. Hasi aurretik, praktika onen atala irakurri beharko zenuke Liquibase
gauza sinple baina oso garrantzitsuak deskribatzen dira, eta horiek gabe liburutegiaren erabilerak bizitza zail dezake. Adibidez, aldaketa-multzoen kudeaketaren ikuspegi ez-egituralak lehenago edo beranduago nahasmena eta hautsitako migrazioak ekarriko ditu. Datu-basearen egituran eta zerbitzuen logikan aldi berean elkarren menpeko aldaketak egiten ez badituzu, orduan proba gorriak edo hautsitako ingurunea ekartzeko probabilitate handia dago. Horrez gain, webgune ofizialean Liquibase erabiltzeko gomendioek migrazio script nagusiekin batera itzultzeko scripten garapenari eta egiaztapenari buruzko paragrafo bat dute. Tira, artikuluan migrazioekin eta itzulerarako mekanismoarekin lotutako kodeen adibideak daude.
2. Migrazio tresnak erabiltzen hasi bazara, ez onartu eskuzko zuzenketak datu-basearen egituran
Esaerak dioen bezala: "Behin Persil, beti Persil". Zure aplikazioaren oinarria Liquibase tresnek kudeatzen hasi bada, eskuzko aldaketek berehala egoera ez-koherentea dakar, eta aldaketa-multzoen konfiantza maila zero bihurtzen da. Balizko arriskuak - datu-basea leheneratzen igarotako hainbat ordu, kasurik txarrenean - hildako zerbitzari bat. Zure taldeak "eskola zaharreko" DBA Arkitekto bat badu, pazientziaz eta pentsakor azaldu iezaiozu zein txarra izango diren SQL Developer baldintzapeko datu-basea bere erara editatzen badu.
3. Aldaketa multzoa biltegira bidali bada, saihestu editatzea
Beste garatzaile batek geroago editatuko den aldaketa-multzo bat atera eta aplikatuko balu, zalantzarik gabe, hitz atsegin batekin gogoratuko zaitu aplikazioa abiatzean errore bat jasotzen duenean. Aldaketa multzoa editatzeak garapenean filtratzen badu nolabait, konponketen malda labainkorra jaitsi beharko duzu. Arazoaren funtsa aldaketak hash batuketaren bidez balioztatzean oinarritzen da - Liquibaseren mekanismo nagusia. Aldaketa-kodea editatzean, hash batura aldatzen da. Aldaketa-multzoak editatzea posible da datu-base osoa hutsetik zabaltzea datuak galdu gabe. Kasu honetan, SQL edo XML kodea refactorizatzeak, aitzitik, bizitza erraztu dezake, migrazioak irakurgarriagoak egin. Adibide bat izango litzateke, aplikazioaren hasieran, iturburuko datu-basearen eskema taldean koordinatuta dagoen egoera.
4. Egiaztatu datu-basearen babeskopiak ahal izanez gero
Hemen, nire ustez, dena argi dago. Bat-batean migrazioak ez badu arrakastarik izan, dena itzul daiteke. Liquibasek atzera egiteko tresna bat du, baina atzera egiteko scriptak garatzaileak berak idazten ditu, eta aldaketa-multzo nagusien script-en probabilitate berdinarekin arazoak izan ditzakete. Horrek esan nahi du babeskopiekin seguru jokatzea erabilgarria dela edozein kasutan.
5. Erabili egiaztatutako datu-baseen babeskopiak garapenean, ahal bada
Horrek kontratuekin eta pribatutasunarekin kontraesanean jartzen ez badu, datu-basean ez dago datu pertsonalik, eta ez du bi eguzkitan bezala pisatzen - zuzeneko migrazio-zerbitzarietan aplikatu aurretik, garatzailearen makinan nola funtzionatzen duen egiaztatu dezakezu eta ia % 100 kalkula dezakezu. migrazioan egon daitezkeen arazoei buruz.
6. Txateatu taldeko beste garatzaile batzuekin
Ondo antolatutako garapen prozesu batean, taldeko guztiek dakite nork zer egiten duen. Egia esan, askotan ez da horrela gertatzen, beraz, datu-basearen egituran aldaketak prestatzen ari bazara zure zereginaren barruan, komeni da talde osoari horren berri ematea. Norbait aldaketak paraleloki egiten ari bada, arretaz antolatu beharko zenuke. Lanaren amaieran ere lankideekin komunikatzea merezi du, ez hasieran bakarrik. Aldaketa-multzoekin arazo potentzial asko kodea berrikusteko fasean konpon daitezke.
7. Pentsa zer egiten ari zaren!
Itxuraz argia den aholkua edozein egoerari aplikagarria. Dena den, arazo asko saihes zitezkeen garatzaileak berriro ere zer egiten ari zen eta zer eragin zezakeen aztertu izan balu. Migrazioekin lan egiteak arreta eta zehaztasun gehiago eskatzen du beti.
tranpak
Ikus ditzagun orain goiko aholkuak jarraitzen ez badituzu erori daitezkeen tranpa tipikoak, eta, hain zuzen ere, zer egin beharko litzateke?
1. egoera. Bi garatzaile aldi berean aldaketa-multzo berriak gehitzen saiatzen ari dira
Vasyak eta Petya-k 4. bertsioa sortu nahi dute elkarren berri izan gabe. Datu-basearen egituran aldaketak egin zituzten, eta pull request bat zabaldu zuten, aldaketa-fitxategi ezberdinekin. Jarraian, mekanismo hau proposatzen da:
Nola konpondu
- Nolabait, lankideek adostu behar dute beren aldaketa-multzoak zein ordenatan joan behar duten, demagun lehenik Petin aplikatu behar dela.
- Pertsona batek bestea sartu eta Vasyaren aldaketa multzoa 5. bertsioarekin markatu behar du. Hori Cherry Pick edo fusionazio txukun baten bidez egin daiteke.
- Aldaketen ondoren, ziurtatu egindako ekintzen baliozkotasuna egiaztatzea.
Izan ere, Liquibase mekanismoek biltegian 4. bertsioko bi aldaketa-multzo edukitzeko aukera emango dizute, dena dagoen bezala utz dezazuen. Hau da, 4. bertsioaren bi berrikuspen besterik ez dituzu izen ezberdinekin. Planteamendu honekin, datu-baseen bertsioak oso zailak bihurtzen dira geroago nabigatzea.
Gainera, Liquibasek, hobbiten etxeak bezala, sekretu asko gordetzen ditu. Horietako bat validCheckSum gakoa da, 1.7 bertsioaz geroztik agertu dena eta aldaketa-multzo jakin baterako hash balio baliodun bat zehazteko aukera ematen du, datu-basean gordetzen dena kontuan hartu gabe. Dokumentazioa honako hau dio:
Gehitu aldaketa-multzo honetarako baliozkotzat jotzen den checksum bat, datu-basean gordeta dagoena kontuan hartu gabe. Aldaketa-multzo bat aldatu behar duzunean eta dagoeneko exekutatu den datu-baseetan akatsak bota nahi ez dituzunean erabiltzen da (ez da gomendatutako prozedura bat)
Bai, hau ez da gomendagarria. Baina batzuetan argi mago indartsu batek teknika ilunak ere menperatzen ditu.
2. kasua: Datuetan oinarritutako migrazioa
Demagun ezin duzula datu-basearen babeskopiak erabili zuzeneko zerbitzarietatik. Petya-k aldaketa-multzo bat sortu zuen, lokalean probatu zuen eta arrazoia zuela ziurtasunez, tira-eskaera bat egin zion garatzaileari. Badaezpada, proiektuaren buruak argitu zuen Petya-k egiaztatu zuen ala ez, eta gero bota zuen. Baina garapen zerbitzariaren hedapena jaitsi egin da.
Izan ere, hori posible da, eta inor ez dago honetatik salbu. Hau gertatzen da taula-egituraren aldaketak datu-baseko datu zehatzekin nolabait lotzen badira. Jakina, Petya-ren datu-basea probako datuekin bakarrik betetzen bada, baliteke arazo-kasu guztiak ez estaliko. Esate baterako, taula bat ezabatzean, beste tauletan erregistroak daudela ematen du, ezabatzen ari den erregistroekin lotutako atzerriko gakoaren arabera. Edo zutabe mota aldatzean, datuen % 100 ezin da mota berrira bihurtu.
Nola konpondu
- Idatzi migrazioarekin batera behin aplikatuko diren script bereziak eta ekarri datuak forma egokian. Modu orokor bat da migrazioak aplikatu ondoren datuak egitura berrietara transferitzearen arazoa konpontzeko, baina aurretik antzeko zerbait aplika daiteke, kasu berezietan. Bide hau, noski, ez dago beti eskuragarri, zuzeneko zerbitzarietan datuak editatzea arriskutsua eta are hilgarria izan daitekeelako.
- Beste modu zail bat lehendik dagoen aldaketa multzo bat editatzea da. Zailtasuna da lehendik dagoen forman aplikatuta dauden datu-base guztiak berreskuratu beharko direla. Litekeena da backend talde osoa datu-basea hutsetik lokalean biltzera behartuta egotea.
- Eta modu unibertsalena datuen arazoa garatzailearen ingurunera transferitzea da, egoera bera birsortzea eta arazoa saihestuko duen aldaketa multzo berri bat gehitzea, hautsitako bati.
Oro har, zenbat eta datu-basea ekoizpen-zerbitzariaren datu-basearen osaeran antzekoagoa izan, orduan eta litekeena da migrazioekin arazoak urrutira jotzea. Eta, noski, aldaketa-multzoa biltegira bidali aurretik, hainbat aldiz pentsatu beharko zenuke zerbait hautsiko duen.
3. egoera. Liquibase ekoizten hasi ondoren erabiltzen hasten da
Demagun talde-buruak Petya-ri Liquibase proiektuan sartzeko eskatu diola, baina proiektua dagoeneko ekoizten ari da eta dagoeneko badago datu-base-egitura bat.
Horren arabera, arazoa zerbitzari edo garatzaile-makin berrietan, taulako datuak hutsetik birsortu behar dira, eta lehendik dagoen inguruneak egoera koherentean egon behar duela, aldaketa-multzo berriak onartzeko prest egonik.
Nola konpondu
Hainbat modu ere badaude:
- Lehenengoa eta nabarmenena ingurune berri bat hasieratzerakoan eskuz aplikatu beharreko script bereizia izatea da.
- Bigarrena, ez hain agerikoa, Liquibaseren migrazio bat Liquibase Testuinguru ezberdin batean dagoena izatea eta aplikatzea da. Liquibase Context-ari buruz gehiago irakur dezakezu hemen: . Oro har, arrakastaz aplika daitekeen mekanismo interesgarria da, adibidez, probak egiteko.
- Hirugarren bideak hainbat urrats ditu. Lehenik eta behin, migrazio bat sortu behar da dauden tauletarako. Ondoren, ingurune batzuetan aplikatu behar da eta horrela bere hash batura lortuko da. Hurrengo urratsa da hutsik dauden Liquibase taulak hasieratzea gure zerbitzari hutsean, eta eskuz jar dezakezu datu-basean dauden aldaketekin "aplikatuta bezala" aldaketa-multzo baten erregistroa taulan aldaketa-multzoak aplikatzearen historiarekin. Horrela, lehendik dagoen zerbitzari batean, historia 2. bertsiotik hasiko da, eta ingurune berri guztiek berdin-berdin jokatuko dute.
4. eszenatokia: migrazioak izugarriak izaten dira eta ezin dute jarraitu
Zerbitzuaren garapenaren hasieran, normalean, Liquibase kanpoko menpekotasun gisa erabiltzen da, eta migrazio guztiak prozesatzen dira aplikazioa hasten denean. Hala ere, denboraren poderioz, kasu hauekin aurki ditzakezu:
- Migrazioak izugarriak bihurtzen dira eta denbora luzea behar dute burutzeko.
- Banatutako inguruneetan migratu beharra dago, adibidez, datu-baseen zerbitzarien hainbat instantziatan aldi berean.
Kasu honetan, migrazioak denbora gehiegi aplikatuz gero, aplikazioa abiaraztean denbora-muga bat izango da. Gainera, migrazioak aplikazio-instantzia bakoitzeko aplikatzeak zerbitzari desberdinak sinkronizatu gabe egotea eragin dezake.
Nola konpondu
Horrelakoetan, zure proiektua dagoeneko handia da, agian heldua ere bai, eta Liquibase kanpoko tresna bereizi gisa jokatzen hasten da. Kontua da Liquibase, liburutegi gisa, jar fitxategi batean muntatuta dagoela, eta menpekotasun gisa funtziona dezakeela proiektuaren barruan, baita autonomo gisa ere.
Lineaz kanpo, migrazioen aplikazioa zure CI/CD ingurunera edo zure sistema-administratzaileen/inplementatzaileen sorbalda sendoetan utzi dezakezu. Horretarako, Liquibase komando-lerroa behar duzu . Modu honetan, beharrezkoak diren migrazio guztiak amaitu ondoren aplikazioa abiarazteko aukera izango da.
Irteera
Izan ere, datu-baseen migrazioekin lan egitean hainbat zulo gehiago daude, eta horietako askok sormen ikuspegia behar dute. Garrantzitsua da ulertzea tresna behar bezala erabiltzen baduzu, tranpa horietako gehienak saihestu daitezkeela. Zehazki, forma ezberdinetan zerrendatutako arazo guztiei aurre egin behar izan nien, eta horietako batzuk nire jambaren ondorio izan ziren. Funtsean, hori gertatzen da, noski, arreta faltagatik, baina batzuetan, tresna erabiltzeko gaitasun penalagatik.
Iturria: www.habr.com