Það gerðist aldrei, og hér er það aftur!
Í næsta verkefni okkar ákváðum við að nota Liquibase frá upphafi til að forðast vandamál í framtíðinni. Eins og það kom í ljós, vita ekki allir ungir liðsmenn hvernig á að nota það rétt. Ég gerði innri vinnustofu sem ég ákvað síðan að breyta í grein.
Greinin inniheldur gagnlegar ábendingar og lýsingu á þremur augljósustu gildrunum sem þú getur fallið í þegar þú vinnur með flutningsverkfæri til gagnagrunna, einkum Liquibase. Hannað fyrir Java forritara á yngri og miðstigi; fyrir reyndari forritara gæti það verið áhugavert að skipuleggja og endurtaka það sem líklegast er þegar vitað.
Liquibase og Flyway eru helstu samkeppnistækni til að leysa útgáfustýringarvandamál tengslabygginga í Java heiminum. Sá fyrsti er algjörlega ókeypis, í reynd er hann oftast valinn til notkunar, þess vegna var Liquibase valinn hetja útgáfunnar. Hins vegar geta sumar aðferðirnar sem lýst er verið alhliða, allt eftir forritaarkitektúr þínum.
Flutningar tengslabygginga eru þvinguð leið til að takast á við veikan sveigjanleika gagnaverslana. Á tímum OOP tísku þýddi vinnustíllinn að vinna með gagnagrunna að við myndum lýsa stefinu einu sinni og ekki snerta það aftur. En raunveruleikinn er alltaf sá að hlutirnir breytast og breytingar á töfluskipaninni eru nauðsynlegar nokkuð oft. Auðvitað er ferlið sjálft sársaukafullt og óþægilegt.
Ég mun ekki fara dýpra í lýsingu á tækninni og leiðbeiningum um að bæta bókasafni við verkefnið þitt; allmargar greinar hafa verið skrifaðar um þetta efni:
Að auki var nú þegar frábær grein um efni gagnlegar ráðleggingar:
Советы
Ég vil deila ráðum mínum og athugasemdum, sem fæddust í gegnum svita, blóð og sársauka við að leysa vandamál með fólksflutninga.
1. Áður en þú byrjar ættir þú að lesa kaflann um bestu starfsvenjur um Liquibase
einföldum en mjög mikilvægum hlutum er lýst, án þeirra getur notkun bókasafnsins flækt líf þitt. Til dæmis mun óskipulögð nálgun við að stjórna breytingasettum fyrr eða síðar leiða til ruglings og bilaðra flutninga. Ef þú setur ekki fram gagnkvæmt háðar breytingar á uppbyggingu gagnagrunnsins og rökfræði þjónustu á sama tíma, þá eru miklar líkur á að þetta leiði til rauðra prófa eða bilaðs umhverfis. Að auki innihalda ráðleggingar um notkun Liquibase á opinberu vefsíðunni ákvæði um þróun og prófun á afturköllunarforskriftum ásamt helstu flutningsskriftum. Jæja, í greininni Það eru kóðadæmi varðandi flutninga og afturköllunarkerfi.
2. Ef þú byrjar að nota flutningsverkfæri skaltu ekki leyfa handvirkar leiðréttingar á uppbyggingu gagnagrunnsins
Eins og orðatiltækið segir: "Einu sinni Persil, alltaf Persil." Ef byrjað er að stjórna grunni forritsins þíns af Liquibase verkfærum, leiða allar handvirkar breytingar samstundis til ósamræmis ástands og traust á breytingasettum verður núll. Hugsanleg áhætta - nokkrum klukkustundum varið í að endurheimta gagnagrunninn, í versta falli - dauður netþjónn. Ef teymið þitt er með "gamla skóla" DBA arkitekt, útskýrðu þolinmóður og yfirvegað fyrir honum hversu slæmt það verður ef hann breytir gagnagrunninum á sinn hátt frá skilyrta SQL Developer.
3. Ef breytingasettinu hefur þegar verið ýtt í geymsluna skaltu forðast að breyta
Ef annar þróunaraðili gerði aðdraganda og beitti breytingarsetti, sem síðar verður breytt, mun hann örugglega muna eftir þér með góðu orði þegar hann fær villu þegar forritið er ræst. Ef breyting á breytingasettinu lekur einhvern veginn út í þróun, verður þú að fylgja hálum brekkum flýtileiðréttinga. Kjarni vandans hvílir á staðfestingu breytinga með kjötkássasummu - aðalkerfi Liquibase. Þegar breytasettkóðanum er breytt breytist kjötkássasumman. Breyting á breytingasettum er aðeins möguleg þegar hægt er að dreifa öllum gagnagrunninum frá grunni án þess að tapa gögnum. Í þessu tilviki getur endurþáttun SQL eða XML kóðans þvert á móti gert lífið auðveldara og gert flutninga læsilegri. Sem dæmi má nefna aðstæður þar sem við upphaf umsóknarinnar var samið um skema frumgagnagrunnsins innan teymisins.
4. Hafa staðfest afrit af gagnagrunni ef mögulegt er
Hér held ég að allt sé á hreinu. Ef skyndilega tókst ekki flutningurinn er hægt að skila öllu til baka. Liquibase er með rollback tól, en rollback forskriftirnar eru einnig skrifaðar af forritaranum sjálfum og geta þau átt í vandræðum með sömu líkur og í helstu breytingaforskriftum. Þetta þýðir að það er gagnlegt að spila það öruggt með öryggisafritum í öllum tilvikum.
5. Notaðu staðfest afrit af gagnagrunni í þróun ef mögulegt er
Ef þetta stangast ekki á við samninga og friðhelgi einkalífsins, þá eru engin persónuleg gögn í gagnagrunninum og hann vegur ekki eins mikið og tvær sólir - áður en þú notar það á lifandi flutningsþjónum geturðu athugað hvernig það virkar á vél þróunaraðilans og reiknað út næstum 100% hugsanlegra vandamála við fólksflutninga.
6. Spjallaðu við aðra forritara í teyminu
Í vel skipulögðu þróunarferli vita allir í teyminu hver er að gera hvað. Í raun og veru er þetta oft ekki raunin, þess vegna, ef þú ert að undirbúa breytingar á uppbyggingu gagnagrunnsins sem hluta af verkefni þínu, er ráðlegt að tilkynna öllu teyminu til viðbótar um þetta. Ef einhver er að gera breytingar samhliða ættirðu að skipuleggja vandlega. Það er þess virði að eiga samskipti við samstarfsmenn jafnvel í lok vinnu, ekki aðeins í upphafi. Hægt er að leysa mörg hugsanleg vandamál með breytingarsett á stigi endurskoðunar kóða.
7. Hugsaðu um hvað þú ert að gera!
Það virðist vera sjálfsagt ráð sem á við hvaða aðstæður sem er. Hins vegar hefði verið hægt að komast hjá mörgum vandamálum ef framkvæmdaraðili hefði enn og aftur greint hvað hann væri að gera og hvaða áhrif það gæti haft. Vinna við fólksflutninga krefst alltaf frekari athygli og nákvæmni.
Gildrur
Við skulum nú skoða dæmigerðar gildrur sem þú getur fallið í ef þú fylgir ekki ráðleggingunum hér að ofan, og hvað nákvæmlega ættir þú að gera?
Staða 1. Tveir forritarar eru að reyna að bæta við nýjum breytingum á sama tíma
Vasya og Petya vilja búa til útgáfu 4 breytingasett án þess að vita af hvort öðru. Þeir gerðu breytingar á uppbyggingu gagnagrunnsins og sendu út dráttarbeiðni með mismunandi breytingaskrám. Eftirfarandi verkunarmáti er lagt til hér að neðan:
Hvernig á að leysa
- Einhvern veginn verða samstarfsmenn að koma sér saman um í hvaða röð breytingarstillingar þeirra eiga að fara, segjum að Petin eigi að beita fyrst.
- Einhver ætti að bæta þeirri seinni við sig og merkja breytingarsett Vasya með útgáfu 5. Þetta er hægt að gera í gegnum Cherry Pick eða snyrtilega sameiningu.
- Eftir breytingar ættirðu örugglega að athuga réttmæti aðgerðanna sem gripið hefur verið til.
Reyndar munu Liquibase kerfin leyfa þér að hafa tvær útgáfur 4 breytingasett í geymslunni, svo þú getur skilið allt eftir eins og það er. Það er, þú munt einfaldlega hafa tvær breytingar á útgáfu 4 með mismunandi nöfnum. Með þessari nálgun verður seinna mjög erfitt að vafra um gagnagrunnsútgáfurnar.
Að auki geymir Liquibase, eins og heimili hobbita, fullt af leyndarmálum. Einn þeirra er validCheckSum lykillinn, sem birtist í útgáfu 1.7 og gerir þér kleift að tilgreina gilt kjötkássagildi fyrir tiltekið breytingasett, óháð því hvað er vistað í gagnagrunninum. Skjöl segir eftirfarandi:
Bættu við eftirlitsummu sem telst gild fyrir þetta breytingasett, óháð því hvað er vistað í gagnagrunninum. Notað fyrst og fremst þegar þú þarft að breyta changeSet og vilt ekki að villum sé kastað í gagnagrunna sem það hefur þegar keyrt á (ekki mælt með aðferð)
Já, þetta er ekki mælt með því. En stundum nær sterkur ljóstöframaður líka tökum á myrkri tækni.
Tilvik 2: Gagnadrifinn flutningur
Gerum ráð fyrir að þú hafir ekki getu til að nota öryggisafrit af gagnagrunni frá lifandi netþjónum. Petya bjó til breytingarsett, prófaði það á staðnum og, með fullri vissu um að hann hefði rétt fyrir sér, lagði hann fram beiðni til framkvæmdaraðilans. Til öryggis skýrði verkefnastjórinn hvort Petya hafi athugað það og hellti því síðan inn. En dreifingin á þróunarþjóninum hefur fallið.
Í raun er þetta hægt og enginn er ónæmur fyrir þessu. Þetta gerist ef breytingar á töfluskipulaginu eru á einhvern hátt bundnar við ákveðin gögn úr gagnagrunninum. Augljóslega, ef gagnagrunnur Petya er aðeins fylltur með prófunargögnum, þá gæti hann ekki tekið til allra vandamála. Til dæmis þegar töflu er eytt kemur í ljós að það eru færslur í öðrum töflum eftir Foreign Key sem tengjast færslum í þeirri sem verið er að eyða. Eða þegar skipt er um dálkategund kemur í ljós að ekki er hægt að breyta 100% af gögnunum yfir í nýja gerð.
Hvernig á að leysa
- Skrifaðu sérstakar forskriftir sem verða notaðar einu sinni ásamt flutningnum og færðu gögnin á réttan hátt. Þetta er almenn leið til að leysa vandamálið við að flytja gögn yfir í ný mannvirki eftir að hafa beitt flutningum, en eitthvað svipað má beita áður, í sérstökum tilvikum. Þessi leið er auðvitað ekki alltaf tiltæk, því að breyta gögnum á netþjónum í beinni getur verið hættulegt og jafnvel banvænt.
- Önnur erfið leið er að breyta núverandi breytingarsetti. Vandinn er sá að endurheimta þarf alla gagnagrunna þar sem það hefur þegar verið notað í núverandi mynd. Það er alveg mögulegt að allt bakendateymið neyðist til að rúlla gagnagrunninum út á staðnum frá grunni.
- Og alhliða leiðin er að flytja vandamálið með gögnin yfir í umhverfi þróunaraðilans, endurskapa sömu aðstæður og bæta við nýjum breytingum, við það bilaða, sem mun sniðganga vandamálið.
Almennt séð, því meira sem gagnagrunnurinn er svipaður í samsetningu og gagnagrunni framleiðsluþjónsins, því minni líkur á að vandamál með flutninga nái langt. Og auðvitað, áður en þú sendir breytingarsett í geymsluna, ættir þú að hugsa nokkrum sinnum hvort það muni brjóta eitthvað.
Staða 3. Liquibase byrjar að nota eftir að það fer í framleiðslu
Segjum sem svo að liðsstjórinn hafi beðið Petya að taka Liquibase með í verkefnið, en verkefnið er nú þegar í framleiðslu og það er til gagnagrunnsuppbygging.
Í samræmi við það er vandamálið að á öllum nýjum netþjónum eða þróunarvélum verður að endurskapa þessar töflur frá grunni og núverandi umhverfi verður að vera í stöðugu ástandi, tilbúið til að samþykkja nýjar breytingar.
Hvernig á að leysa
Það eru líka nokkrar leiðir:
- Fyrsta og augljósasta er að hafa sérstakt handrit sem þarf að nota handvirkt þegar nýtt umhverfi er frumstillt.
- Annað er minna augljóst, farðu með Liquibase flutning sem er í öðru Liquibase samhengi og notaðu það. Þú getur lesið meira um Liquibase Context hér: . Almennt séð er þetta áhugavert kerfi sem hægt er að nota með góðum árangri, til dæmis til að prófa.
- Þriðja leiðin samanstendur af nokkrum skrefum. Fyrst verður að búa til flutning fyrir núverandi töflur. Þá verður að beita því á eitthvað umhverfi og þannig verður hasssumma þess fengin. Næsta skref er að frumstilla tómar Liquibase töflur á þjóninum okkar sem er ekki tómur, og í töflunni með sögu notkunar á breytingasettum er hægt að setja handvirkt skrá um „eins og beitt“ breytingasettinu með breytingum sem þegar eru til í gagnagrunninum . Þannig, á núverandi netþjóni, mun niðurtalning sögunnar hefjast frá útgáfu 2 og öll ný umhverfi munu hegða sér eins.
Staða 4. Fólksflutningar verða miklir og hafa ekki tíma til að ljúka
Í upphafi þjónustuþróunar er Liquibase að jafnaði notað sem ytri háð og allar flutningar eru unnar þegar forritið byrjar. Hins vegar, með tímanum, gætir þú lent í eftirfarandi tilvikum:
- Fólksflutningar verða miklir og taka langan tíma að ljúka.
- Það er þörf á flutningi í dreifðu umhverfi, til dæmis á nokkrum tilfellum gagnagrunnsþjóna samtímis.
Í þessu tilviki mun það að beita flutningum í of langan tíma leiða til þess að tíminn lýkur þegar forritið byrjar. Að auki getur það að beita flutningum á hvert forritstilvik fyrir sig leitt til þess að mismunandi netþjónar séu ekki samstilltir.
Hvernig á að leysa
Í slíkum tilfellum er verkefnið þitt þegar stórt, kannski fullorðinn, og Liquibase byrjar að virka sem sérstakt ytra tæki. Staðreyndin er sú að Liquibase sem bókasafn er sett saman í jar skrá og getur virkað sem ósjálfstæði innan verkefnis eða sjálfstætt.
Ótengdur geturðu skilið beitingu flutninga í CI/CD umhverfið þitt eða á sterkar axlir stjórnenda/dreifenda þinna. Til að gera þetta þarftu Liquibase skipanalínuna . Í þessum ham verður hægt að ræsa forritið eftir að allar nauðsynlegar flutningar hafa verið framkvæmdar.
Output
Reyndar geta verið miklu fleiri gildrur þegar unnið er með gagnaflutninga og margar þeirra krefjast skapandi nálgunar. Það er mikilvægt að skilja að ef þú notar tólið rétt er hægt að forðast flestar þessar gildrur. Nánar tiltekið þurfti ég að takast á við öll upptalin vandamál í mismunandi myndum og sum þeirra voru afleiðing af mistökum mínum. Aðallega gerist þetta, auðvitað, vegna athyglisbrests, en stundum vegna glæpsamlegs vanhæfni til að nota tólið.
Heimild: www.habr.com