ProHoster > Blogs > Administrācija > Kā izvairīties no ŔauŔanas sev kājā, izmantojot Liquibase

Kā izvairīties no ŔauŔanas sev kājā, izmantojot Liquibase

Nekad agrāk nav noticis, un mēs atkal!

Nākamajā projektā mēs nolēmām izmantot Liquibase jau no paÅ”a sākuma, lai izvairÄ«tos no problēmām nākotnē. Kā izrādās, ne visi jaunie komandas biedri prot to pareizi lietot. Es rÄ«koju iekŔējo semināru, kuru pēc tam nolēmu pārvērst par rakstu.

Rakstā ir iekļauti noderÄ«gi padomi un apraksts par trim acÄ«mredzamākajām kļūmēm, kurās varat iekrist, strādājot ar relāciju datu bāzes migrācijas rÄ«kiem, jo ā€‹ā€‹Ä«paÅ”i ar Liquibase. Paredzēts Java izstrādātājiem junioru un vidējā lÄ«menÄ«; pieredzējuŔākiem izstrādātājiem tas var bÅ«t interesants, lai strukturētu un atkārtotu to, kas, visticamāk, jau ir zināms.

Kā izvairīties no ŔauŔanas sev kājā, izmantojot Liquibase

Liquibase un Flyway ir galvenās konkurējoŔās tehnoloÄ£ijas relāciju struktÅ«ru versiju kontroles problēmu risināŔanai Java pasaulē. Pirmais ir pilnÄ«gi bezmaksas, praksē visbiežāk tiek izvēlēts lietoÅ”anai, tāpēc par izdevuma varoni tika izvēlēts Liquibase. Tomēr dažas no aprakstÄ«tajām praksēm var bÅ«t universālas atkarÄ«bā no jÅ«su lietojumprogrammas arhitektÅ«ras.

Relāciju struktÅ«ru migrācija ir piespiedu veids, kā tikt galā ar relāciju datu krātuvju vājo elastÄ«bu. OOP modes laikmetā darba stils ar datu bāzēm nozÄ«mēja, ka mēs vienreiz aprakstām shēmu un vairs nepieskaramies tai. Taču realitāte vienmēr ir tāda, ka lietas mainās, un tabulas struktÅ«ras izmaiņas ir nepiecieÅ”amas diezgan bieži. Protams, pats process var bÅ«t sāpÄ«gs un nepatÄ«kams.

Es neiedziļināŔos tehnoloÄ£ijas aprakstā un instrukcijās bibliotēkas pievienoÅ”anai jÅ«su projektam; par Å”o tēmu ir rakstÄ«ts diezgan daudz rakstu:

Turklāt jau bija lielisks raksts par noderīgu padomu tēmu:

Š”Š¾Š²ŠµŃ‚Ń‹

Vēlos padalÄ«ties ar saviem padomiem un komentāriem, kas dzimuÅ”i caur migrācijas problēmu risināŔanas sviedriem, asinÄ«m un sāpēm.

1. Pirms darba uzsākÅ”anas jums jāiepazÄ«stas ar labākās prakses sadaļu TieÅ”saistē Liquibase

Tur ir aprakstÄ«tas vienkārÅ”as, bet ļoti svarÄ«gas lietas, bez kurām bibliotēkas lietoÅ”ana var sarežģīt dzÄ«vi. Piemēram, nestrukturēta pieeja izmaiņu kopu pārvaldÄ«bai agrāk vai vēlāk radÄ«s neskaidrÄ«bas un migrācijas traucējumus. Ja vienlaikus neievieÅ”at savstarpēji atkarÄ«gas izmaiņas datu bāzes struktÅ«rā un pakalpojuma loÄ£ikā, pastāv liela varbÅ«tÄ«ba, ka tas novedÄ«s pie sarkaniem testiem vai bojātas vides. Turklāt ieteikumos par Liquibase lietoÅ”anu oficiālajā vietnē ir ietverta klauzula par atcelÅ”anas skriptu izstrādi un testÄ“Å”anu kopā ar galvenajiem migrācijas skriptiem. Nu, rakstā https://habr.com/ru/post/178665/ Ir kodu piemēri attiecÄ«bā uz migrāciju un atcelÅ”anas mehānismu.

2. Ja sākat izmantot migrācijas rīkus, neatļaujiet manuālas korekcijas datu bāzes struktūrā

Kā saka: "Vienmēr Persils, vienmēr Persils." Ja jÅ«su lietojumprogrammas bāzi sāk pārvaldÄ«t Liquibase, visas manuālās izmaiņas nekavējoties noved pie nekonsekventa stāvokļa un izmaiņu kopu uzticÄ«bas lÄ«menis kļūst nulle. Iespējamie riski ietver vairākas stundas, kas pavadÄ«tas, atjaunojot datubāzi; sliktākajā gadÄ«jumā - miris serveris. Ja jÅ«su komandā ir ā€œvecās skolasā€ DBA arhitekts, pacietÄ«gi un pārdomāti paskaidrojiet viņam, cik slikti bÅ«s, ja viņŔ vienkārÅ”i rediģēs datubāzi atbilstoÅ”i savai izpratnei no nosacÄ«tā SQL izstrādātāja.

3. Ja izmaiņu kopa jau ir ievietota repozitorijā, izvairieties no rediģēŔanas

Ja kāds cits izstrādātājs veica vilkÅ”anu un pielietoja izmaiņu kopu, kas vēlāk tiks rediģēta, viņŔ noteikti atcerēsies jÅ«s ar labu vārdu, kad saņems kļūdu, startējot programmu. Ja izmaiņu kopas rediģēŔana kaut kādā veidā nonāk attÄ«stÄ«bā, jums bÅ«s jāseko labojumfailu slidenajai nogāzei. Problēmas bÅ«tÄ«ba balstās uz izmaiņu validāciju ar hash summu - galveno Liquibase mehānismu. Rediģējot izmaiņu kopas kodu, mainās jaukÅ”anas apjoms. Izmaiņu kopu rediģēŔana ir iespējama tikai tad, ja ir iespējams izvietot visu datu bāzi no nulles, nezaudējot datus. Å ajā gadÄ«jumā SQL vai XML koda pārstrukturÄ“Å”ana var, gluži pretēji, atvieglot dzÄ«vi un padarÄ«t migrācijas lasāmākas. Piemērs varētu bÅ«t situācija, kad lietojumprogrammas sākumā komandas ietvaros tika saskaņota avota datu bāzes shēma.

4. Ja iespējams, pārbaudiet datu bāzes dublējumus

Å eit, manuprāt, viss ir skaidrs. Ja pēkŔņi migrācija bija neveiksmÄ«ga, visu var atgriezt atpakaļ. Liquibase ir rÄ«ks izmaiņu atgrieÅ”anai, taču arÄ« atcelÅ”anas skriptus raksta pats izstrādātājs, un tiem var rasties problēmas ar tādu paÅ”u varbÅ«tÄ«bu kā galvenās izmaiņu kopas skriptiem. Tas nozÄ«mē, ka jebkurā gadÄ«jumā ir lietderÄ«gi droÅ”i spēlēt ar dublējumkopijām.

5. Ja iespējams, izstrādē izmantojiet pārbaudītas datu bāzes dublējumkopijas

Ja tas nav pretrunā ar lÄ«gumiem un privātumu, datu bāzē nav personas datu, un tas nesver tik daudz kā divas saules - pirms to izmantoÅ”anas tieÅ”raides migrācijas serveros varat pārbaudÄ«t, kā tas darbosies izstrādātāja maŔīnā un aprēķināt gandrÄ«z 100% iespējamo problēmu migrācijas laikā.

6. Sazinieties ar citiem komandas izstrādātājiem

Labi organizētā attÄ«stÄ«bas procesā visi komandā zina, kas ko dara. Reāli tas tā bieži nenotiek, tādēļ, ja sava uzdevuma ietvaros gatavojat izmaiņas datu bāzes struktÅ«rā, ieteicams par to papildus informēt visu komandu. Ja kāds paralēli veic izmaiņas, jums rÅ«pÄ«gi jāorganizē. Ir vērts sazināties ar kolēģiem pēc darba pabeigÅ”anas, ne tikai sākumā. Daudzas iespējamās problēmas ar izmaiņu kopām var atrisināt koda pārskatÄ«Å”anas posmā.

7. Padomā, ko dari!

Å Ä·iet, ka tas ir paÅ”saprotams padoms, kas attiecas uz jebkuru situāciju. Tomēr no daudzām problēmām varēja izvairÄ«ties, ja izstrādātājs bÅ«tu vēlreiz analizējis, ko viņŔ dara un ko tas varētu ietekmēt. Darbs ar migrācijām vienmēr prasa papildu uzmanÄ«bu un precizitāti.

Slazdi

Tagad apskatÄ«sim tipiskos slazdus, ā€‹ā€‹kuros varat iekrist, ja neievērosiet iepriekÅ” minētos ieteikumus, un kas tieÅ”i jums bÅ«tu jādara?

1. situācija: divi izstrādātāji vienlaikus mēģina pievienot jaunas izmaiņu kopas

Kā izvairīties no ŔauŔanas sev kājā, izmantojot Liquibase
Vasja un Petja vēlas izveidot izmaiņu kopas 4. versiju, nezinot viens par otru. Viņi veica izmaiņas datu bāzes struktÅ«rā un izdeva izvilkÅ”anas pieprasÄ«jumu ar dažādiem izmaiņu kopas failiem. Tiek piedāvāts Ŕāds darbÄ«bas mehānisms:

Kā atrisināt

  1. Kolēģiem kaut kā jāvienojas, kādā secībā jāiet viņu izmaiņu kopas, piemēram, vispirms jāpiemēro Petins.
  2. Kādam vajadzētu pievienot sev otro un atzÄ«mēt Vasjas izmaiņu kopu ar versiju 5. To var izdarÄ«t, izmantojot Cherry Pick vai glÄ«tu sapludināŔanu.
  3. Pēc izmaiņām noteikti jāpārbauda veikto darbību pamatotība.
    Faktiski Liquibase mehānismi ļaus jums repozitorijā izveidot divas 4. versijas izmaiņu kopas, lai jÅ«s varētu atstāt visu kā ir. Tas nozÄ«mē, ka jums vienkārÅ”i bÅ«s divas izmaiņas 4. versijā ar dažādiem nosaukumiem. Izmantojot Å”o pieeju, vēlāk kļūst ļoti grÅ«ti orientēties datu bāzes versijās.

Turklāt Liquibase, tāpat kā hobitu mājvieta, glabā daudz noslēpumu. Viena no tām ir validCheckSum atslēga, kas parādÄ«jās 1.7 versijā un ļauj norādÄ«t derÄ«gu jaucējvērtÄ«bu konkrētai izmaiņu kopai neatkarÄ«gi no datubāzē saglabātā. Dokumentācija https://www.liquibase.org/documentation/changeset.html saka sekojoÅ”o:

Pievienojiet kontrolsummu, kas tiek uzskatÄ«ta par derÄ«gu Å”ai izmaiņu kopai neatkarÄ«gi no datu bāzē saglabātā. Izmanto galvenokārt tad, kad jāmaina ChangeSet un nevēlaties, lai kļūdas tiktu parādÄ«tas datu bāzēs, kurās tas jau ir palaists (nav ieteicama procedÅ«ra).

Jā, jā, Ŕī procedÅ«ra nav ieteicama. Bet dažreiz spēcÄ«gs gaismas burvis pārvalda arÄ« tumŔās tehnikas

2. situācija: migrācija, kas ir atkarÄ«ga no datiem

Kā izvairīties no ŔauŔanas sev kājā, izmantojot Liquibase

Pieņemsim, ka jums nav iespējas izmantot datu bāzes dublējumus no tieÅ”ajiem serveriem. Petja izveidoja izmaiņu kopu, pārbaudÄ«ja to lokāli un, bÅ«dams pilnÄ«bā pārliecināts, ka viņam ir taisnÄ«ba, iesniedza izstrādātājam izvilkÅ”anas pieprasÄ«jumu. Katram gadÄ«jumam projekta vadÄ«tājs noskaidroja, vai Petja to ir pārbaudÄ«jis, un pēc tam pievienoja. Taču izvietoÅ”ana izstrādes serverÄ« samazinājās.

PatiesÄ«bā tas ir iespējams, un neviens nav pasargāts no tā. Tas notiek, ja tabulas struktÅ«ras izmaiņas ir kaut kādā veidā saistÄ«tas ar konkrētiem datiem no datu bāzes. AcÄ«mredzot, ja Petjas datu bāze ir aizpildÄ«ta tikai ar testa datiem, tā var neaptvert visus problēmu gadÄ«jumus. Piemēram, dzÄ“Å”ot tabulu, izrādās, ka citās tabulās pēc ārējās atslēgas ir ieraksti, kas ir saistÄ«ti ar ierakstiem tajā, kas tiek dzēsta. Vai arÄ« mainot kolonnas veidu, izrādās, ka ne 100% datu var konvertēt uz jauno tipu.

Kā atrisināt

  • Uzrakstiet Ä«paÅ”us skriptus, kas tiks izmantoti vienreiz kopā ar migrāciju, un izveidojiet datus pareizajā formā. Å is ir vispārÄ«gs veids, kā atrisināt datu pārsÅ«tÄ«Å”anas uz jaunām struktÅ«rām problēmu pēc migrācijas piemēroÅ”anas, taču kaut ko lÄ«dzÄ«gu var izmantot arÄ« iepriekÅ”, Ä«paÅ”os gadÄ«jumos. Å is ceļŔ, protams, ne vienmēr ir pieejams, jo datu rediģēŔana tieÅ”raides serveros var bÅ«t bÄ«stama un pat postoÅ”a.
  • Vēl viens sarežģīts veids ir rediģēt esoÅ”u izmaiņu kopu. GrÅ«tÄ«bas ir tādas, ka bÅ«s jāatjauno visas datu bāzes, kurās tas jau ir lietots esoÅ”ajā formā. PilnÄ«gi iespējams, ka visa aizmugursistēmas komanda bÅ«s spiesta lokāli izvērst datubāzi no nulles.
  • Un universālākais veids ir datu problēmas pārsÅ«tÄ«Å”ana uz izstrādātāja vidi, atkārtoti izveidojot to paÅ”u situāciju un bojātajai pievienojot jaunu izmaiņu kopu, kas apies problēmu.
    Kā izvairīties no ŔauŔanas sev kājā, izmantojot Liquibase

Kopumā, jo vairāk datu bāzes sastāvs ir lÄ«dzÄ«gāks ražoÅ”anas servera datu bāzei, jo mazāka iespēja, ka problēmas ar migrāciju nonāks tālu. Un, protams, pirms izmaiņu kopas nosÅ«tÄ«Å”anas uz repozitoriju, vairākas reizes jāpadomā, vai tā kaut ko nesabojās.

Situācija 3. Liquibase sāk lietot pēc tam, kad tā nonāk ražoÅ”anā

Pieņemsim, ka komandas vadÄ«tājs lÅ«dza Petju iekļaut projektā Liquibase, taču projekts jau tiek ražots un ir esoÅ”a datu bāzes struktÅ«ra.

AttiecÄ«gi problēma ir tā, ka visos jaunos serveros vai izstrādātāju maŔīnās Ŕīs tabulas ir jāizveido no jauna, un esoÅ”ajai videi jāpaliek konsekventā stāvoklÄ«, kas ir gatavs pieņemt jaunas izmaiņu kopas.

Kā atrisināt

Ir arī vairāki veidi:

  • Pirmais un acÄ«mredzamākais ir atseviŔķs skripts, kas jāpielieto manuāli, inicializējot jaunu vidi.
  • Otrais ir mazāk acÄ«mredzams, izmantojiet Liquibase migrāciju, kas atrodas citā Liquibase kontekstā, un lietojiet to. Vairāk par Liquibase Context varat lasÄ«t Å”eit: https://www.liquibase.org/documentation/contexts.html. Kopumā tas ir interesants mehānisms, ko var veiksmÄ«gi izmantot, piemēram, testÄ“Å”anai.
  • TreÅ”ais ceļŔ sastāv no vairākiem soļiem. Pirmkārt, ir jāizveido migrācija esoÅ”ajām tabulām. Tad tas ir jāpiemēro kādai videi un tādējādi tiks iegÅ«ta tās jaucējsumma. Nākamais solis ir inicializēt tukÅ”as Liquibase tabulas mÅ«su netukŔā serverÄ«, un tabulā ar izmaiņu kopu izmantoÅ”anas vēsturi varat manuāli ievietot ierakstu par izmaiņu kopu ā€œit kā lietotuā€ ar izmaiņām, kas jau ir datu bāzē. . Tādējādi esoÅ”ajā serverÄ« vēstures atpakaļskaitÄ«Å”ana sāksies no 2. versijas, un visas jaunās vides darbosies identiski.
    Kā izvairīties no ŔauŔanas sev kājā, izmantojot Liquibase

Situācija 4. Migrācijas kļūst milzīgas, un tām nav laika pabeigt

Pakalpojuma izstrādes sākumā Liquibase parasti tiek izmantota kā ārēja atkarÄ«ba, un visas migrācijas tiek apstrādātas lietojumprogrammas startÄ“Å”anas brÄ«dÄ«. Tomēr laika gaitā jÅ«s varat paklupt uz Ŕādiem gadÄ«jumiem:

  • Migrācijas kļūst milzÄ«gas, un to pabeigÅ”ana prasa ilgu laiku.
  • Ir nepiecieÅ”ama migrācija sadalÄ«tās vidēs, piemēram, vairākos datu bāzes servera gadÄ«jumos vienlaikus.
    Tādā gadÄ«jumā, piemērojot migrāciju pārāk ilgi, lietojumprogrammas startÄ“Å”anas laikā iestāsies taimauts. Turklāt, piemērojot migrāciju katrai lietojumprogrammas gadÄ«jumam atseviŔķi, dažādi serveri var bÅ«t nesinhronizēti.

Kā atrisināt

Šādos gadÄ«jumos jÅ«su projekts jau ir liels, iespējams, pat pieauguÅ”ais, un Liquibase sāk darboties kā atseviŔķs ārējs rÄ«ks. Fakts ir tāds, ka Liquibase kā bibliotēka tiek apkopota jar failā un var darboties kā atkarÄ«ba projekta ietvaros vai neatkarÄ«gi.

AtseviŔķā režīmā migrācijas ievieÅ”anu varat atstāt savas CI/CD vides vai sistēmas administratoru un izvietoÅ”anas speciālistu spēcÄ«go pleciem. Lai to izdarÄ«tu, jums bÅ«s nepiecieÅ”ama Liquibase komandrinda https://www.liquibase.org/documentation/command_line.html. Å ajā režīmā lietojumprogrammu kļūst iespējams palaist pēc tam, kad ir veiktas visas nepiecieÅ”amās migrācijas.

secinājums

PatiesÄ«bā, strādājot ar datu bāzu migrÄ“Å”anu, var bÅ«t daudz vairāk kļūmju, un daudzām no tām ir nepiecieÅ”ama radoÅ”a pieeja. Ir svarÄ«gi saprast, ka, pareizi izmantojot rÄ«ku, lielāko daļu no Ŕīm nepilnÄ«bām var izvairÄ«ties. Konkrēti, man bija jārisina visas uzskaitÄ«tās problēmas dažādās formās, un dažas no tām bija manu kļūdu rezultāts. Pārsvarā tas notiek, protams, neuzmanÄ«bas dēļ, bet dažreiz arÄ« noziedzÄ«gas nespējas izmantot rÄ«ku.

Avots: www.habr.com

Pievieno komentāru