It is noait bard, en hjir is it wer!
Op it folgjende projekt besleaten wy Liquibase fan it begjin ôf te brûken om problemen yn 'e takomst te foarkommen. Sa die bliken, net alle jonge teamleden witte hoe't se it korrekt brûke. Ik die in ynterne workshop, dy't ik doe besleat om in artikel te meitsjen.
Dit artikel omfettet nuttige tips en beskriuwingen fan trije fan 'e meast foar de hân lizzende falkûlen wêryn jo kinne falle as jo wurkje mei relasjonele databankmigraasje-ark, Liquibase yn it bysûnder. Untworpen foar Java-ûntwikkelders fan Junior en Middelnivo, foar mear erfarne ûntwikkelders kin it ynteressant wêze foar it strukturearjen en werheljen fan wat nei alle gedachten al bekend is.
Liquibase en Flyway binne de wichtichste konkurrearjende technologyen foar it oplossen fan de problemen fan ferzjekontrôle fan relasjonele struktueren yn 'e Java-wrâld. De earste is folslein fergees, yn 'e praktyk wurdt it faker keazen foar gebrûk, en dêrom waard Liquibase keazen as de held fan' e publikaasje. Guon fan 'e beskreaune praktiken kinne lykwols generysk wêze, ôfhinklik fan de arsjitektuer fan jo applikaasje.
Relaasjemigraasjes binne in twongen manier om te gean mei de swakke fleksibiliteit fan relaasjegegevenswinkels. Yn it tiidrek fan moade foar OOP betsjutte de styl fan wurkjen mei de databank dat wy it skema ienris beskriuwe en it net wer oanreitsje. Mar de realiteit is altyd dat dingen feroarje, en feroaringen yn 'e struktuer fan tabellen binne frij faak nedich. Fansels, it proses sels is pynlik en onaangenaam.
Ik sil net ferdjipje yn 'e beskriuwing fan' e technology en ynstruksjes foar it tafoegjen fan de bibleteek oan jo projekt, genôch artikels binne skreaun oer dit ûnderwerp:
Derneist wie d'r al in geweldich artikel oer it ûnderwerp fan nuttige tips:
Tips
Ik wol myn advys en opmerkings diele, dy't berne binne troch it swit, bloed en pine fan it oplossen fan problemen mei migraasje.
1. Foardat jo begjinne, moatte jo lêze de best practices seksje op Liquibase
ienfâldige, mar heul wichtige dingen wurde beskreaun, sûnder dat it gebrûk fan 'e bibleteek jo libben komplisearje kin. Bygelyks, in net-strukturele oanpak fan feroaringsetbehear sil ier of letter liede ta betizing en brutsen migraasjes. As jo gjin ûnderling ôfhinklike wizigingen yn 'e struktuer fan' e databank en de logika fan tsjinsten tagelyk rôlje, dan is d'r in hege kâns dat dit sil liede ta reade testen of in brutsen omjouwing. Derneist befetsje de oanbefellings foar it brûken fan Liquibase op 'e offisjele webside in paragraaf oer de ûntwikkeling en ferifikaasje fan rollback-skripts tegearre mei de wichtichste migraasjeskripts. No, yn it artikel d'r binne foarbylden fan koade yn ferbân mei migraasjes en it rollback-meganisme.
2. As jo begûn te brûken migraasje ark, net tastean hânmjittich korreksjes yn de databank struktuer
As it sprekwurd seit: "Ienris Persil, altyd Persil." As de basis fan jo applikaasje begon te wurde beheard troch Liquibase-ark, liede alle hânmjittige wizigingen direkt ta in inkonsistente steat, en it nivo fan fertrouwen yn feroaringsets wurdt nul. Potinsjele risiko's - ferskate oeren bestege oan it werstellen fan de database, yn it slimste gefal - in deade tsjinner. As jo team in "âlde skoalle" DBA-arsjitekt hat, ferklearje him geduldich en yntelligint hoe min dingen sille wêze as hy de database gewoan op syn eigen manier bewurket fan 'e betingsten SQL-ûntwikkelder.
3. As de wizigingset al nei de repository ferstjoerd is, foarkomme dan bewurkjen
As in oare ûntwikkelder in wizigingset luts en tapast dy't letter sil wurde bewurke, sil hy jo perfoarst ûnthâlde mei in freonlik wurd as hy in flater ûntfangt as de applikaasje begjint. As it bewurkjen fan de wizigingset op ien of oare manier yn ûntwikkeling lekt, sille jo de glêde helling fan hotfixes moatte delgean. De essinsje fan it probleem leit op 'e falidaasje fan feroaringen troch hash-som - it haadmeganisme fan Liquibase. By it bewurkjen fan de feroaringsetkoade feroaret de hash-som. It bewurkjen fan wizigingen is allinich mooglik as it mooglik is om de folsleine databank fanôf it begjin yn te setten sûnder gegevens te ferliezen. Yn dit gefal kin it refactorearjen fan SQL of XML-koade, krekt oarsom, it libben makliker meitsje, migraasjes lêsber meitsje. In foarbyld soe in situaasje wêze as, oan it begjin fan 'e applikaasje, it skema fan' e boarnedatabase binnen it team koördinearre waard.
4. Hawwe ferifiearre databank backups as mooglik
Hjir, tink ik, is alles dúdlik. As de migraasje ynienen net slagge, kin alles weromjûn wurde. Liquibase hat in rollback ark, mar de rollback skripts wurde ek skreaun troch de ûntwikkelder sels, en se kinne hawwe problemen mei deselde kâns as yn de wichtichste feroarings set skripts. Dit betsjut dat it feilich spielje mei backups yn alle gefallen nuttich is.
5. Brûk ferifiearre databank backups yn ûntwikkeling as mooglik
As dit gjin kontrakten en privacy tsjinsprekt, binne d'r gjin persoanlike gegevens yn 'e databank, en it weaget net as twa sinnen - foardat jo it tapasse op live migraasjeservers, kinne jo kontrolearje hoe't it wurket op' e masine fan 'e ûntwikkelder en hast 100% berekkenje fan mooglike problemen by migraasje.
6. Petear mei oare ûntwikkelders op it team
Yn in goed organisearre ûntwikkelingsproses wit elkenien yn it team wa't wat docht. Yn 'e realiteit is dit faaks net it gefal, dus as jo wizigingen yn' e databankstruktuer tariede as ûnderdiel fan jo taak, is it oan te rieden om it heule team hjirboppe te melden. As immen feroaringen parallel makket, moatte jo soarchfâldich organisearje. It is it wurdich om te kommunisearjen mei kollega's sels oan 'e ein fan it wurk, net allinich by it begjin. In protte potinsjele problemen mei feroaringsets kinne wurde oplost by it poadium foar koadebeoardieling.
7. Tink wat jo dogge!
Blykber fanselssprekkend advys fan tapassing op elke situaasje. In protte problemen koenen lykwols foarkommen wurde as de ûntwikkelder nochris analysearre hie wat hy die en wat it kin beynfloedzje. Wurkje mei migraasjes freget altyd ekstra oandacht en krektens.
Traps
Litte wy no sjen nei de typyske fallen wêryn jo kinne falle as jo it advys hjirboppe net folgje, en wat moat der eins dien wurde?
Situaasje 1. Twa ûntwikkelders besykje tagelyk nije feroarings ta te foegjen
Vasya en Petya wolle in ferzje 4-feroaringset meitsje sûnder oer elkoar te witten. Se makken feroarings oan 'e databankstruktuer, en rôle in pull-fersyk út, mei ferskate feroaringsbestannen. It folgjende meganisme wurdt hjirûnder foarsteld:
Hoe oplosse
- Op ien of oare manier moatte kollega's it iens wurde oer de folchoarder wêryn't har wizigingen moatte gean, lit ús sizze dat Petin earst moat wurde tapast.
- Ien persoan moat de oare yngiet en Vasya's feroaringset markearje mei ferzje 5. Dit kin dien wurde fia Cherry Pick of in kreaze gearfoeging.
- Soargje nei de wizigingen de jildigens fan 'e nommen aksjes te kontrolearjen.
Yn feite kinne de Liquibase-meganismen jo twa ferzje 4-feroaringsets hawwe yn 'e repository, sadat jo alles kinne litte sa't it is. Dat is, jo sille gewoan twa ferzjes fan ferzje 4 hawwe mei ferskate nammen. Mei dizze oanpak wurde databankferzjes letter tige lestich te navigearjen.
Derneist hâldt Liquibase, lykas de huzen fan hobbits, in protte geheimen. Ien fan har is de validCheckSum-kaai, dy't sûnt ferzje 1.7 ferskynd is en jo in jildige hashwearde kinne opjaan foar in spesifike feroaringset, nettsjinsteande wat yn 'e databank is opslein. Dokumintaasje seit it folgjende:
Foegje in kontrôlesum ta dy't jildich wurdt beskôge foar dizze feroaringSet, nettsjinsteande wat is opslein yn 'e databank. Foaral brûkt as jo in feroaringSet feroarje moatte en net wolle dat flaters wurde smiten op databases wêrop it al útfierd is (net in oanrikkemandearre proseduere)
Ja, dit is net oan te rieden. Mar soms behearsket in sterke ljochttsjoender ek tsjustere techniken.
Gefal 2: Data-oandreaune migraasje
Litte wy sizze dat jo gjin database-backups kinne brûke fan live servers. Petya makke in feroaringset, testte it lokaal, en mei folslein fertrouwen dat hy gelyk hie, die in pull-fersyk oan de ûntwikkelder. Foar it gefal dúdlik makke de projektlieder oft Petya it kontrolearre, en joech it dan yn. Mar de ynset op 'e ûntwikkelingstsjinner is fallen.
Yn feite is dit mooglik, en gjinien is immun fan dit. Dit bart as wizigingen oan 'e tabelstruktuer op ien of oare manier ferbûn binne oan spesifike gegevens út' e databank. Fansels, as de databank fan Petya fol is mei allinich testgegevens, dan kin it miskien net alle probleemgefallen dekke. Bygelyks, as jo in tabel wiskje, docht bliken dat d'r records binne yn oare tabellen troch Foreign Key ferbûn mei records yn 'e ien dy't wiske wurdt. Of by it feroarjen fan it kolomtype, docht bliken dat net 100% fan 'e gegevens konvertearre wurde kinne nei it nije type.
Hoe oplosse
- Skriuw spesjale skripts dy't ien kear sille wurde tapast tegearre mei de migraasje en bring de gegevens yn 'e goede foarm. Dit is in algemiene manier om it probleem op te lossen fan it oerdragen fan gegevens nei nije struktueren nei it tapassen fan migraasjes, mar wat ferlykber kin earder tapast wurde, yn spesjale gefallen. Dit paad is fansels net altyd beskikber, om't it bewurkjen fan gegevens op live servers gefaarlik en sels fataal kin wêze.
- In oare lestige manier is om in besteande wizigingset te bewurkjen. De swierrichheid is dat alle databases dêr't it al yn de besteande foarm tapast is, weromset wurde moatte. It is goed mooglik dat it hiele backend-team twongen wurdt om de databank lokaal fanôf it begjin op te rollen.
- En de meast universele manier is it gegevensprobleem oer te bringen nei de omjouwing fan 'e ûntwikkelders, deselde situaasje opnij oanmeitsje en in nije wizigingset taheakje, oan in brutsen ien, dy't it probleem sil omgean.
Yn 't algemien, hoe mear de databank yn gearstalling ferlykber is mei de databank fan' e produksjetsjinner, hoe minder wierskynlik dat problemen mei migraasjes fier gean. En, fansels, foardat jo de wizigingset nei it repository stjoere, moatte jo ferskate kearen tinke as it wat sil brekke.
Situaasje 3. Liquibase begjint te brûken neidat it yn produksje giet
Stel dat de teamlieder Petya frege om Liquibase yn it projekt op te nimmen, mar it projekt is al yn produksje en d'r is in al besteande databankstruktuer.
Dêrtroch is it probleem dat op alle nije servers of ûntwikkelmasines de tabelgegevens fanôf it begjin moatte wurde oanmakke, en de al besteande omjouwing moat yn in konsekwinte steat bliuwe, ree om nije feroarings te akseptearjen.
Hoe oplosse
D'r binne ek ferskate manieren:
- De earste en meast foar de hân lizzende is om in apart skript te hawwen dat mei de hân tapast wurde moat by it inisjalisearjen fan in nije omjouwing.
- De twadde, minder fanselssprekkend, is om in Liquibase-migraasje te hawwen dy't yn in oare Liquibase-kontekst is en it tapasse. Jo kinne hjir mear lêze oer Liquibase Context: . Yn 't algemien is dit in nijsgjirrich meganisme dat mei súkses tapast wurde kin, bygelyks foar testen.
- It tredde paad bestiet út ferskate stappen. Earst moat in migraasje makke wurde foar besteande tabellen. Dan moat it wurde tapast op guon omjouwing en sa sil syn hash-som wurde krigen. De folgjende stap is it inisjalisearjen fan lege Liquibase-tabellen op ús net-lege tsjinner, en jo kinne in record fan in "as as tapast" wizigingset mei de wizigingen al yn 'e databank yn' e tabel pleatse mei de skiednis fan it tapassen fan wizigingsets. Sa sil op in al besteande server de skiednis begjinne fan ferzje 2, en alle nije omjouwings sille identyk gedrage.
Senario 4: Migraasjes wurde enoarm en kinne net byhâlde
Oan it begjin fan tsjinstûntwikkeling wurdt Liquibase yn 'e regel brûkt as in eksterne ôfhinklikens, en alle migraasjes wurde ferwurke as de applikaasje begjint. Lykwols, nei ferrin fan tiid, kinne jo stroffelje oer de folgjende gefallen:
- Migraasjes wurde enoarm en duorje in lange tiid om te foltôgjen.
- D'r is needsaak om te migrearjen yn ferdielde omjouwings, bygelyks op ferskate eksimplaren fan databanktsjinners tagelyk.
Yn dit gefal sil it tapassen fan migraasjes foar te lang resultearje yn in time-out as de applikaasje begjint. Ek it tapassen fan migraasjes op basis fan in applikaasje-eksimplaar kin resultearje yn ferskate servers dy't yn in net syngronisearre steat binne.
Hoe oplosse
Yn sokke gefallen is jo projekt al grut, miskien sels in folwoeksene, en Liquibase begjint te hanneljen as in apart ekstern ark. It feit is dat Liquibase, as bibleteek, wurdt gearstald yn in jar-bestân, en kin wurkje as in ôfhinklikheid binnen it projekt, lykas selsstannich.
Offline kinne jo de tapassing fan migraasjes ferlitte nei jo CI / CD-omjouwing of oan 'e sterke skouders fan jo sysadmins / ynsetters. Om dit te dwaan, hawwe jo de Liquibase kommandorigel nedich . Yn dizze modus wurdt it mooglik om de applikaasje te starten neidat alle nedige migraasjes binne foltôge.
konklúzje
Yn feite binne d'r folle mear falkûlen by it wurkjen mei databasemigraasjes, en in protte fan harren fereaskje in kreative oanpak. It is wichtich om te begripen dat as jo it ark goed brûke, de measte fan dizze trapen kinne wurde foarkommen. Spesifyk, ik moast face alle problemen neamd yn ferskillende foarmen, en guon fan harren wiene it gefolch fan myn jambs. Yn prinsipe bart dit, fansels, troch ûnoplettendheid, mar soms - troch it kriminele ûnfermogen om it ark te brûken.
Boarne: www.habr.com