Kuidas mitte endale jalga tulistada, kasutades Liquibase

Kuni pole kunagi olnud, ja nüüd on see jälle kohal!

Ühes meie projektis otsustasime alustada Liquibase'i kasutamist, et vältida tuleviku probleeme. Selgus, et mitte kõik noored meeskonnaliikmed ei oska seda õigesti kasutada. Korraldasin sise-workshop'i, mille otsustasin hiljem artikliks muuta.

Artikkel sisaldab kasulikke näpunäiteid ja kirjeldust kolmest selgest lõksust, millesse võib sattuda, töötades rikka andmebaasi migratsiooni tööriistadega, eeskätt Liquibase'iga. Suunatud Java arendajatele, kes on tasemel Junior ja Middle; kogenumate arendajate jaoks võib see olla huvitav struktuuri ja korduse jaoks, mida nad tõenäoliselt juba tunnevad.

Liquibase ja Flyway on peamised konkurentsitehnoloogiad rikka struktuuri versioonihalduse probleemide lahendamiseks Java maailmas. Esimene on täielikult tasuta ja seda valitakse praktikas sagedamini, seetõttu on Liquibase valitud selle väljaande kangelaseks. Siiski võivad mõned kirjeldatud praktikad olla universaalsed, sõltuvalt teie rakenduse arhitektuurist.

Rikka struktuuri migratsioonid on sunnitud meetod, mis aitab võidelda rikka andmehoidjate madala paindlikkuse vastu. OOP stiilis eeldas, et me kirjeldame skeemi ühe korra ja ei puutu sellesse enam. Kuid reaalsus on alati selline, et kõik muutub ja lauatabelite struktuuri muutmise vajadus tekib piisavalt sageli. Loomulikult võib see protsess olla valus ja ebameeldiv.

Ma ei hakka tehnoloogiat süvitsi lahkama ega selgitama, kuidas oma projektis raamatukogusid lisada; selle kohta on kirjutatud piisavalt artikleid:

• Liquibase'i kasutamine andmebaasi struktuuri haldamiseks Spring Boot rakenduses. Osa 1
• Liquibase'i kasutamine andmebaasi struktuuri haldamiseks Spring Boot rakenduses. Osa 2
• Liquibase ja Maven
• Andmebaasi muudatuste versioonimise lähenemisviisid
• Startime Spring MVC/Security, REST, Hibernate, Liquibase kahe käsuga

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

• Liquibase'i kasutamine ilma peavaludeta. 10 näpunäidet reaalsest arendusest

Nõuanded

Soovin jagada oma nõuandeid ja kommentaare, mis on sündinud vaeva, vere ja valude kaudu migratsiooniprobleemide lahendamisel.

1. Enne töö alustamist tuleb tutvuda parimate praktika jaotisega veebisaidil Liquibase

Seal Kirjeldatakse lihtsaid, kuid väga olulisi asju, ilma milleta võib raamatukogu kasutamine muuta teie elu keeruliseks. Näiteks struktuuri muutuste haldamise struktureerimata lähenemine toob varem või hiljem kaasa segaduse ja katkenud migratsioonid. Kui andmebaasi struktuuri ja teenuste loogika omavahel sõltuvad muudatused ei toimu samal ajal, siis on suur tõenäosus, et see toob kaasa punased testid või katkenud keskkonna. Lisaks sisaldavad Liquibase'i ametliku saidi soovitused punkti rollback skriptide arendamise ja testimise kohta koos peamiste migratsiooniskeemidega. Ja artiklis https://habr.com/ru/post/178665/ on koodinäiteid, mis käsitlevad migratsioone ja rollback mehhanismi.

2. Kui olete alustanud migratsioonivahendite kasutamist – ärge lubage käsitsi muudatusi andmebaasi struktuuris.

Nagu öeldakse: "Üks kord Persil – alati Persil". Kui teie rakenduse andmebaasi hakkab haldama Liquibase, siis toovad kõik käsitsi tehtud muudatused kiiresti kaasa mittejärjepideva seisundi ja muudatusseente usaldusväärsus langeb nulli. Potentsiaalsed riskid – mitu tundi andmebaasi taastamise peale, halvemal juhul – purustatud server. Kui teie meeskonnas on "vanakooli" DBA arhitekt, siis selgitage talle kannatlikult ja hoolikalt, kui halb kõik muutub, kui ta lihtsalt muudab andmebaasi oma arusaamise järgi näiteks SQL Developeris.

3. Kui muudatusseen on juba repole edastatud, vältige redigeerimist.

Kui teine arendaja tegi pulli ja rakendas muudatusseente, mida hiljem muudetakse, siis ütleb ta teile kindlasti häid sõnu, kui saab veateate rakenduse käivitamisel. Kui muudatusseene redigeerimine kuidagi lekib arendusse, tuleb minna libedal teel hotfixide suunas. Probleemi sisu põhineb muudatuste valideerimisel hash-summa järgi – Liquibase'i põhimehhanism. Muudatusseene koodi redigeerimisel muutub hash-summa. Muudatusseene redigeerimine on võimalik ainult siis, kui on võimalik andmebaasi anda nullist ilma andmeid kaotamata. Sellisel juhul võib SQL või XML koodi refaktoorimine vastupidi elu lihtsamaks teha ja muudatused arusaadavamaks muuta. Näiteks võib olukord olla selline, et rakenduse käivitamisel oli algse andmebaasi skeem meeskonnas kooskõlastatud.

4. Omada kontrollitud andmebaasi varukoopiad, kui see on võimalik

Siin on kõik arusaadav. Kui migratsioon peaks mingil põhjusel ebaõnnestuma, saab kõik tagasi tuua. Liquibase'is on muudatuste tagasivõtmise tööriist, kuid tagasivõtmise skripte kirjutab samuti arendaja, ja nendes võivad olla samasugused probleemid nagu põhichangeseti skriptides. See tähendab, et varukoopiaid tehes on alati kasulik ettevaatus.

5. Kasuta kontrollitud andmebaasi varukoopiaid arenduses, kui see on võimalik

Kui see ei ole vastuolus lepingute ja privaatsusega, andmebaasis ei ole isikuandmeid ja see ei kaalugi kaks korda rohkem kui kaks päikest — enne, kui migratsioonid elusserverites rakendatakse, saab kontrollida, kuidas see töötaks arendaja masinal, ja tuvastada peaaegu 100% potentsiaalsest migratsiooniprobleemide hulgast.

6. Suhtle teiste arendajatega meeskonnas

Korrektselt korraldatud arendusprotsessis teavad kõik meeskonna liikmed, kellel on millised ülesanded. Tõeliselt ei ole sageli nii, seega kui valmistate oma ülesande raames andmebaasi struktuuris muudatusi, on soovitatav teavitada sellest kogu meeskonda. Kui keegi teeb muudatusi paralleelselt — peaksite ettevaatlikult organiseerima. Koostöölistega on oluline suhelda ka pärast töö lõpetamist, mitte ainult alguses. Paljusid potentsiaalseid probleeme chensetitega saab lahendada koodide ülevaatamise etapis.

7. Mõtle, mida teed!

Tundub, et see on ilmne nõuanne, mis kehtib igas olukorras. Siiski oleks paljusid probleeme saanud vältida, kui arendaja oleks veel kord analüsinud, mida ta teeb ja mis sellele võib mõju avaldada. Töö migratsioonidega nõuab alati suuremat tähelepanu ja hoolikust.

Lõksud

Käesolevaga uurime tüüpilisi lõkse, millesse võib sattuda, kui ei järgita ülaltoodud nõuandeid, ja mis siis tõeliselt teha.

Situatsioon 1. Kaks arendajat üritavad samaaegselt lisada uusi changesete

Vasya ja Petya soovivad luua changest versiooni 4, teadmata üksteisest. Nad tegid muudatusi andmebaasi struktuuris ja esitasid pull requesti, erinevate chengeseti failidega. Edasi pakutakse järgmisi meetmeid:

Kuidas lahendada

1. Kolleegid peavad kuidagi kokku leppima, millises järjekorras nende chengesetid peaksid minema, oletame, et Petja oma peaks olema esimesena.
2. Keegi peab teise koodiga liitma ja märkima Vaasi muudatuse versiooni 5. Selle saab teha läbi Cherry Pick või hoolika merge'i.
3. Pärast muudatusi tuleb kindlasti kontrollida tegemiste kehtivust.
   Tegelikult lubavad Liquibase'i mehhanismid, et hoidlas oleks kaks muudatusetappi versiooniga 4, seega võib kõik jätta nagu on. See tähendab, et teil on lihtsalt kaks muudatust versiooniga 4 erinevate nimedega. Sellise lähenemisega muutub hiljem andmebaasi versioonide jälgimine väga keeruliseks.

Lisaks, Liquibase, nagu hobitite kodu, hoiab endas palju saladusi. Üks neist on validCheckSum võti, mis ilmus versiooniga 1.7 ja võimaldab määrata kehtiva räsisumma väärtuse teatud muudatusetappi, sõltumata sellest, mis andmebaasis on. Dokumentatsioon https://www.liquibase.org/documentation/changeset.html ütleb järgmist:

Lisa räsisumma, mida peetakse selle muudatusetapi jaoks kehtivaks, olenemata sellest, mis andmebaasis on. Kasutatakse peamiselt siis, kui peate muudatusetappi muutma ja ei soovi vigu tekitada andmebaasides, kus see on juba käivitunud (mitte soovitatav protseduur)

Jah, see protseduur ei ole soovitatav. Kuid mõnikord valdab tugev hele mustkunstnik ka tumedaid tehnikaid

Situatsioon 2. Migratsioon, mis sõltub andmetest

Oletame, et teil pole võimalik kasutada elavate serverite varukoopiaid. Petja lõi muudatusetapi, kontrollis seda kohalikult ja tegi täie kindlusega oma õiguses pull request'i arendusserverisse. Projekti juht selgitas igaks juhuks, kas Petja on seda kontrollinud, ja seejärel ta sulandas. Kuid arendamine arendusserveris kukkus kokku.

Tegelikult on see võimalik ja keegi ei ole sellest kaitstud. See juhtub juhul, kui tabeli struktuuri muudatused on mingil moel seotud konkreetsete andmetega andmebaasist. On ilmne, et kui Petja andmebaas on täidetud ainult testandmetega, siis ei pruugi see katta kõiki probleemseid olukordi. Näiteks tabeli kustutamisel selgub, et muudes tabelites on andmeid, mis on seotud kustutatavate andmetega Foreign Key kaudu. Või kui veeru tüüp muutub, selgub, et mitte 100% andmetest ei saa uuele tüübile ümber muuta.

Kuidas lahendada

• Kirjutage spetsiaalsed skriptid, mis rakendatakse korra koos migreerimisega ja viivad andmed nõutud vormi. See on üldine lahendus andmete üleviimise probleemile uutesse struktuuridesse pärast migratsioonide rakendamist, kuid midagi sarnast võib rakendada ka enne, erijuhtudel. Selline tee ei ole siiski alati kergesti kättesaadav, kuna andmete redigeerimine reaalajas serverites võib olla ohtlik ja isegi hukatuslik.
• Teine keeruline tee on olemasoleva muudatuskomplekti redigeerimine. Probleem seisneb selles, et kõik andmebaasid, kuhu see praegusel kujul juba rakendati, tuleb taastada. On täiesti võimalik, et kogu tagasiside meeskond peab kohapeal andmebaasi nullist uuesti rakendama.
• Ja kõige universaalsem tee on andmeprobleemi üleviimine arendaja keskkonda, samas luues sama olukorra ja lisades uue muudatuskomplekti, milles on probleem lahendatud.
  

Üldiselt, mida rohkem andmebaasi sisu sarnaneb tootmisserveri andmebaasiga, seda väiksem on tõenäosus, et migratsioonide probleemid probleemid kaugele levivad. Ja loomulikult, enne muudatuskomplekti saatmist hoidlasse tasub mitu korda mõelda, kas see ei rikuta midagi.

Situatsioon 3. Liquibase hakkab rakenduma juba pärast tootmisse minekut.

Oletame, et meeskonna juht palus Petjal liita projekti Liquibase, kuid projekt on juba tootmises ja olemas on juba moodustatud andmebaasi struktuur.

Sellegipoolest seisneb probleem selles, et kõigil uutel serveritel või arendajate arvutitel peavad andme tabelid olema loodud nullist ning juba olemasolev keskkond peab jääma järjepidevaks, olles valmis vastu võtma uusi muudatuskomplekte.

Kuidas lahendada

Siin on samuti mitu teed:

• Esimene ja kõige ilmsem on kasutada eraldi skripti, mis peab olema käsitsi rakendatud uue keskkonna algatamisel.
• Teine — vähem ilmne, on omada Liquibase migratsiooni, mis asub teises Liquibase kontekstis ja seda rakendada. Täiendavat teavet Liquibase konteksti kohta leiate siit: https://www.liquibase.org/documentation/contexts.html. Üldiselt on see huvitav mehhanism, mida saab edukalt kasutada näiteks testimiseks.
• Kolmas tee koosneb mitmest sammust. Esiteks tuleb luua migratsioon juba olemasolevate tabelite jaoks. Seejärel peab see olema rakendatud mingis keskkonnas ja nii saadakse selle hash-summa. Järgmiseks sammuks on meie mitte tühi server, kus algatada tühjad Liquibase tabelid ning ajaloo tabelisse rakendatud muudatuste kohta saab käsitsi lisada kirje 'nagu oleks rakendatud' muudatuse kohta juba olemasolevates andmebaasi muudatustes. Nii hakkab ajalugu eksisteerivas serveris versioonist 2 ning kõik uued keskkonnad käituvad identiteetselt.
  

Senaarium 4. Migratsioonid muutuvad tohututeks ja ei jõua lõpetada.

Teenuse arendamise alguses kasutatakse reeglina Liquibase't välist sõltuvusena ning kõik migratsioonid töödeldakse rakenduse käivitamisel. Kuid aja jooksul võite kokku puutuda järgmiste juhtumitega:

• Migratsioonid muutuvad tohutuks ja võtavad kaua aega.
• Tekib vajadus migratsioonide järele jaotatud keskkondades, näiteks mitmes andmebaasi serveri instantsis samaaegselt.
  Sellisel juhul liiga pika migratsiooni rakendamine toob kaasa rakenduse käivitamisel aegumise. Lisaks võivad migratsioonide rakendamine iga rakenduse instantsi jaoks eraldi viia olukorrani, kus erinevad serverid on sünkroonitud olekusse.

Kuidas lahendada

Sellistes juhtumites on teie projekt juba suur, võib-olla lausa täiskasvanud, ja Liquibase hakkab toimima kui eraldi väline tööriist. Asi on selles, et Liquibase kogutakse jar-failiks ja see võib töötada kas sõltuvusena projektis või iseseisvalt.

Iseseisvas režiimis on võimalik migratsioonide rakendamine jätta teie CI/CD keskkonna või tugevate süsteemihaldurite õlgadele. Selleks on vajalik Liquibase käsurea tööriist. https://www.liquibase.org/documentation/command_line.html. Sellises režiimis on võimalik rakendust käivitada alles pärast seda, kui kõik vajalikud migratsioonid on läbi viidud.

Kokkuvõte

Tegelikult võib andmebaasi migratsioonide käigus olla palju rohkem lõkse, millest paljusid tuleb läheneda loominguliselt. On oluline mõista, et kui tööriista õigesti kasutada, siis saab enamik neist lõksudest vältida. Isiklikult olen ma erinevates vormides kokku puutunud kõigi nimetatud probleemidega, ja mõned nendest tulid minu enda vigadest. Peamiselt juhtub see tähelepanematuse tõttu, kuid mõnikord – kuritegeliku oskamise tõttu tööriista kasutamisel.

Allikas: habr.com