Kuidas Liquibase'i abil endale jalga mitte tulistada

Seda pole kunagi juhtunud ja siin see jälle on!

Järgmise projekti puhul otsustasime algusest peale kasutada Liquibase'i, et tulevikus probleeme vältida. Nagu selgus, ei oska kõik noored meeskonnaliikmed seda õigesti kasutada. Tegin sisemise töötoa, mille otsustasin siis artikliks muuta.

See artikkel sisaldab kasulikke näpunäiteid ja kirjeldusi kolmest kõige ilmsemast lõksust, millesse võite sattuda relatsioonilise andmebaasi migratsioonitööriistadega, eriti Liquibase'iga töötades. Mõeldud juunior- ja kesktaseme Java-arendajatele, kogenumatele arendajatele võib see olla huvitav struktureerida ja korrata seda, mis on tõenäoliselt juba teada.

Liquibase ja Flyway on peamised konkureerivad tehnoloogiad relatsioonistruktuuride versioonikontrolli probleemide lahendamisel Java maailmas. Esimene on täiesti tasuta, praktikas valitakse seda sagedamini kasutamiseks, mistõttu valiti väljaande kangelaseks Liquibase. Mõned kirjeldatud tavad võivad olenevalt teie rakenduse arhitektuurist siiski olla üldised.

Relatsiooniline migratsioon on sunnitud viis relatsiooniandmete hoidlate nõrga paindlikkusega toimetulemiseks. OOP-i moeajastul tähendas andmebaasiga töötamise stiil seda, et me kirjeldame skeemi üks kord ja ei puuduta seda enam. Kuid reaalsus on alati see, et asjad muutuvad ja tabelite struktuuri muutmist on vaja üsna sageli. Loomulikult on protsess ise valus ja ebameeldiv.

Ma ei süvene teie projekti raamatukogu lisamise tehnoloogia kirjeldusse ja juhistesse, sellel teemal on kirjutatud piisavalt artikleid:

• Liquibase'i kasutamine andmebaasistruktuuri haldamiseks Spring Booti rakenduses. 1. osa
• Liquibase'i kasutamine andmebaasistruktuuri haldamiseks Spring Booti rakenduses. 2. osa
• Liquibase ja Maven
• Lähenemisviisid andmebaasi versioonide muutmiseks
• Spring MVC/Security, REST, Hibernate, Liquibase töötavad kahes reas

Lisaks oli kasulike näpunäidete teemal juba suurepärane artikkel:

• Liquibase'i kasutamine ilma peavaluta. 10 näpunäidet reaalsest arenduskogemusest

Советы

Tahan jagada oma nõuandeid ja kommentaare, mis on sündinud läbi rändeprobleemide lahendamise higi, vere ja valu.

1. Enne alustamist lugege läbi parimate tavade jaotis veebisait Liquibase

Там kirjeldatakse lihtsaid, kuid väga olulisi asju, ilma milleta võib raamatukogu kasutamine teie elu keerulisemaks muuta. Näiteks mittestrukturaalne lähenemine muudatuste haldamisele toob varem või hiljem kaasa segaduse ja katkised migratsioonid. Kui te ei juuruta samal ajal vastastikku sõltuvaid muudatusi andmebaasi struktuuris ja teenuste loogikas, siis on suur tõenäosus, et see toob kaasa punased testid või katkise keskkonna. Lisaks sisaldavad ametlikul veebisaidil Liquibase'i kasutamise soovitused lõiku tagasipööramisskriptide arendamise ja kontrollimise kohta koos peamiste migratsiooniskriptidega. Noh, artiklis https://habr.com/ru/post/178665/ seal on näiteid migratsiooni ja tagasipööramise mehhanismiga seotud koodidest.

2. Kui alustasite migratsioonitööriistade kasutamist, ärge lubage andmebaasi struktuuris käsitsi parandusi

Nagu öeldakse: "Kord Persil, alati Persil." Kui teie rakenduse baasi on hakatud haldama Liquibase'i tööriistad, põhjustavad kõik käsitsi tehtud muudatused koheselt ebajärjekindla oleku ja muudatuste kogumite usalduse tase muutub nulliks. Võimalikud riskid - andmebaasi taastamisele kulunud mitu tundi, halvimal juhul - surnud server. Kui teie meeskonnal on "vana kooli" DBA arhitekt, selgitage talle kannatlikult ja läbimõeldult, kui halvasti läheb, kui ta lihtsalt muudab andmebaasi tingimusliku SQL-arendaja abil omal moel.

3. Kui muudatuste komplekt on juba hoidlasse lükatud, vältige redigeerimist

Kui mõni teine ​​arendaja tõmbas ja rakendas muudatuste komplekti, mida hiljem redigeeritakse, mäletab ta teid kindlasti hea sõnaga, kui saab rakenduse käivitumisel veateate. Kui muudatuste komplekti redigeerimine lekib kuidagi arendusse, peate minema käigultparanduste libedale teele. Probleemi olemus seisneb muudatuste valideerimisel räsisumma järgi - Liquibase'i peamise mehhanismi järgi. Muudatuste komplekti koodi redigeerimisel muutub räsisumma. Muudatuste komplektide redigeerimine on võimalik ainult siis, kui on võimalik kogu andmebaasi nullist juurutada ilma andmeid kaotamata. Sel juhul võib SQL- või XML-koodi ümbertegemine, vastupidi, elu lihtsamaks muuta, migratsioonid loetavamaks muuta. Näiteks võib tuua olukorra, kus rakenduse käivitamisel koordineeriti lähteandmebaasi skeemi meeskonnas.

4. Võimalusel tehke andmebaasi kontrollitud varukoopiaid

Siin on minu arvates kõik selge. Kui ränne ootamatult ebaõnnestus, saab kõik tagasi saata. Liquibase'il on tagasipööramise tööriist, kuid tagasipööramisskriptid kirjutab ka arendaja ise ja nendega võib tekkida probleeme sama suure tõenäosusega kui põhimuutuste komplekti skriptides. See tähendab, et varukoopiatega ohutu mängimine on igal juhul kasulik.

5. Võimalusel kasutage arenduses kontrollitud andmebaasi varukoopiaid

Kui see lepingute ja privaatsusega vastuollu ei lähe, pole andmebaasis isikuandmeid ja need ei kaalu nagu kaks päikest – enne selle reaalajas migratsiooniserverites rakendamist saab kontrollida, kuidas see arendaja masinas töötab ja välja arvutada peaaegu 100% migratsiooni käigus tekkivad võimalikud probleemid.

6. Vestelge teiste meeskonna arendajatega

Hästi organiseeritud arendusprotsessis teavad kõik meeskonnaliikmed, kes mida teeb. Tegelikkuses see sageli nii ei ole, seega kui valmistate oma ülesande raames ette muudatusi andmebaasi struktuuris, on soovitatav sellest kogu meeskonda täiendavalt teavitada. Kui keegi teeb paralleelselt muudatusi, peaksite hoolikalt korraldama. Kolleegidega tasub suhelda ka töö lõpus, mitte ainult alguses. Paljusid võimalikke muudatuskomplektidega seotud probleeme saab lahendada koodi ülevaatuse etapis.

7. Mõtle, mida teed!

Pealtnäha iseenesestmõistetavad nõuanded, mis kehtivad igas olukorras. Paljusid probleeme oleks saanud aga vältida, kui arendaja oleks veel kord analüüsinud, mida ta teeb ja mida see mõjutada võib. Migratsioonidega töötamine nõuab alati erilist tähelepanu ja täpsust.

Lõksud

Vaatame nüüd tüüpilisi lõkse, millesse võite langeda, kui te ülaltoodud nõuandeid ei järgi, ja mida tuleks tegelikult teha?

Olukord 1. Kaks arendajat üritavad korraga lisada uusi muudatuste komplekte

Vasya ja Petya soovivad luua versiooni 4 muudatuste komplekti üksteisest teadmata. Nad tegid andmebaasi struktuuris muudatusi ja käivitasid tõmbamispäringu koos erinevate muudatuste komplekti failidega. Allpool pakutakse välja järgmine mehhanism:

Kuidas lahendada

1. Kuidagi peavad kolleegid kokku leppima, millises järjekorras nende muudatused peaksid minema, oletame, et kõigepealt tuleks rakendada Petin.
2. Üks inimene peaks valama teise sisse ja märkima Vasya muudatuste komplekti versiooniga 5. Seda saab teha Cherry Picki või korraliku liitmise kaudu.
3. Pärast muudatusi kontrollige kindlasti tehtud toimingute kehtivust.
   Tegelikult võimaldavad Liquibase'i mehhanismid hoida hoidlas kaks versiooni 4 muudatuste komplekti, nii et saate jätta kõik nii, nagu see on. See tähendab, et teil on lihtsalt kaks versiooni 4 erineva nimega versiooni. Sellise lähenemise korral muutub andmebaasi versioonides hiljem navigeerimine väga keeruliseks.

Lisaks hoiab Liquibase nagu hobitite kodudki palju saladusi. Üks neist on validCheckSum võti, mis on ilmunud alates versioonist 1.7 ja võimaldab määrata konkreetse muudatuste komplekti kehtiva räsiväärtuse, olenemata sellest, mis andmebaasis on salvestatud. Dokumentatsioon https://www.liquibase.org/documentation/changeset.html ütleb järgmist:

Lisage kontrollsumma, mida peetakse selle muudatuste komplekti jaoks kehtivaks, olenemata sellest, mis andmebaasis on salvestatud. Kasutatakse peamiselt siis, kui peate muutma ChangeSet'i ja ei soovi, et andmebaasides, kus see on juba käivitatud, tekiks vigu (ei ole soovitatav protseduur)

Jah, see pole soovitatav. Kuid mõnikord valdab tugev valgusvõlur ka tumedaid tehnikaid.

Juhtum 2: andmepõhine migratsioon

Oletame, et te ei saa kasutada reaalajas serveritest andmebaasi varukoopiaid. Petya lõi muudatuste komplekti, testis seda kohapeal ja täielikus veendumuses, et tal on õigus, esitas arendajale tõmbetaotluse. Igaks juhuks selgitas projektijuht, kas Petya kontrollis, ja valas siis sisse. Kuid arendusserveri juurutamine on langenud.

Tegelikult on see võimalik ja keegi pole selle eest kaitstud. See juhtub siis, kui tabelistruktuuri muudatused on kuidagi seotud andmebaasi konkreetsete andmetega. Ilmselgelt, kui Petya andmebaas on täidetud ainult testandmetega, ei pruugi see hõlmata kõiki probleemseid juhtumeid. Näiteks tabeli kustutamisel selgub, et teistes tabelites on välisvõtme järgi kirjeid, mis on seotud kustutatava kirjetega. Või veerutüüpi muutes selgub, et 100% andmetest ei saa uude tüüpi teisendada.

Kuidas lahendada

• Kirjutage spetsiaalsed skriptid, mida rakendatakse üks kord koos migreerimisega, ja viige andmed õigesse vormi. See on üldine viis andmete uutesse struktuuridesse ülekandmise probleemi lahendamiseks pärast migratsiooni rakendamist, kuid midagi sarnast saab erijuhtudel rakendada ka varem. See tee pole muidugi alati saadaval, sest andmete redigeerimine reaalajas serverites võib olla ohtlik ja isegi surmav.
• Teine keeruline viis on redigeerida olemasolevat muudatuste komplekti. Raskus seisneb selles, et kõik andmebaasid, kus seda olemasoleval kujul on juba rakendatud, tuleb taastada. On täiesti võimalik, et kogu taustaprogrammi meeskond on sunnitud andmebaasi kohapeal nullist üles kerima.
• Ja kõige universaalsem viis on andmeprobleemi ülekandmine arendaja keskkonda, sama olukorra uuesti loomine ja uue, katkise muudatuste komplekti lisamine, mis probleemist mööda läheb.
  

Üldiselt, mida rohkem on andmebaas oma koostiselt tootmisserveri andmebaasiga sarnane, seda väiksem on tõenäosus, et migratsiooniprobleemid jõuavad kaugele. Ja muidugi tuleks enne muudatuste hoidlasse saatmist mitu korda mõelda, kas see midagi rikub.

Olukord 3. Liquibase'i hakatakse kasutama pärast selle tootmist

Oletame, et meeskonna juht palus Petyal Liquibase'i projekti kaasata, kuid projekt on juba tootmises ja andmebaasis on juba olemasolev struktuur.

Sellest tulenevalt on probleem selles, et uutes serverites või arendajamasinates tuleb tabeliandmed nullist uuesti luua ja juba olemasolev keskkond peab jääma ühtsesse olekusse, olles valmis vastu võtma uusi muudatusi.

Kuidas lahendada

Samuti on mitu võimalust:

• Esimene ja kõige ilmsem on eraldi skripti olemasolu, mida tuleb uue keskkonna lähtestamisel käsitsi rakendada.
• Teine, vähem ilmne, on Liquibase'i migreerimine, mis on teises Liquibase'i kontekstis, ja selle rakendamine. Liquibase Contexti kohta saate rohkem lugeda siit: https://www.liquibase.org/documentation/contexts.html. Üldiselt on see huvitav mehhanism, mida saab edukalt rakendada näiteks testimiseks.
• Kolmas tee koosneb mitmest etapist. Esiteks tuleb olemasolevate tabelite jaoks luua migratsioon. Seejärel tuleb see mõnele keskkonnale rakendada ja nii saadakse selle räsisumma. Järgmise sammuna initsialiseerime tühjad Liquibase'i tabelid meie mittetühjas serveris ja saate käsitsi sisestada "nagu rakendatud" muudatuste komplekti kirje koos juba andmebaasis olevate muudatustega tabelisse muudatuste rakendamise ajalooga. Seega algab ajalugu juba olemasolevas serveris versioonist 2 ja kõik uued keskkonnad käituvad identselt.
  

4. stsenaarium: migratsioonid muutuvad tohutuks ja ei suuda sammu pidada

Teenuse arendamise alguses kasutatakse reeglina välise sõltuvusena Liquibase'i ning rakenduse käivitumisel töödeldakse kõiki migratsioone. Kuid aja jooksul võite komistada järgmistel juhtudel:

• Ränded muutuvad tohutuks ja nende lõpuleviimine võtab kaua aega.
• Hajutatud keskkondades on vaja migreerida, näiteks mitmel andmebaasiserveri eksemplaril korraga.
  Sel juhul põhjustab migratsioonide liiga pikaajaline rakendamine rakenduse käivitumisel ajalõpu. Samuti võib migratsiooni rakendamine rakenduse eksemplaripõhiselt põhjustada erinevate serverite sünkroonist väljasoleku.

Kuidas lahendada

Sellistel juhtudel on teie projekt juba suur, võib-olla isegi täiskasvanu, ja Liquibase hakkab toimima eraldi välise tööriistana. Fakt on see, et Liquibase kui teek on kokku pandud jar-failiks ja see võib töötada nii projektisisese sõltuvusena kui ka eraldiseisvana.

Võrguühenduseta saate jätta migratsioonirakenduse oma CI/CD keskkonnale või oma süsteemiadministraatorite/juurutajate tugevatele õlgadele. Selleks vajate Liquibase'i käsurida https://www.liquibase.org/documentation/command_line.html. Selles režiimis on võimalik rakendus käivitada pärast seda, kui kõik vajalikud migratsioonid on lõpule viidud.

Väljund

Tegelikult on andmebaaside migreerimisega töötamisel palju rohkem lõkse ja paljud neist nõuavad loomingulist lähenemist. Oluline on mõista, et kui kasutate tööriista õigesti, saab enamikku neist püünistest vältida. Täpsemalt pidin seisma silmitsi kõigi eri vormides loetletud probleemidega ja mõned neist olid minu jambide tagajärg. Põhimõtteliselt juhtub see muidugi tähelepanematuse tõttu, kuid mõnikord - tööriista kasutamise kuritegeliku suutmatuse tõttu.

Allikas: www.habr.com