Niekada nebuvo nutikę anksčiau, ir mes vėl!
Kitame savo projekte nusprendėme nuo pat pradžių naudoti „Liquibase“, kad išvengtume problemų ateityje. Pasirodo, ne visi jaunieji komandos nariai moka tai teisingai naudoti. Surengiau vidinį seminarą, kurį vėliau nusprendžiau paversti straipsniu.
Straipsnyje pateikiami naudingi patarimai ir trijų akivaizdžiausių spąstų, į kuriuos galite patekti dirbdami su reliacinės duomenų bazės perkėlimo įrankiais, ypač „Liquibase“, aprašymas. Sukurta jaunesniojo ir vidutinio lygio Java kūrėjams; labiau patyrusiems kūrėjams gali būti įdomu struktūrizuoti ir pakartoti tai, kas greičiausiai jau žinoma.
Liquibase ir Flyway yra pagrindinės konkuruojančios technologijos, sprendžiančios reliacinių struktūrų versijų valdymo problemas Java pasaulyje. Pirmasis yra visiškai nemokamas, praktiškai dažniausiai pasirenkamas naudoti, todėl leidinio herojumi buvo pasirinkta Liquibase. Tačiau kai kurios aprašytos praktikos gali būti universalios, atsižvelgiant į jūsų taikomosios programos architektūrą.
Reliacinių struktūrų perkėlimas yra priverstinis būdas susidoroti su silpnu reliacinių duomenų saugyklų lankstumu. OOP mados eroje darbo su duomenų bazėmis stilius reiškė, kad schemą aprašome vieną kartą ir daugiau jos neliesime. Tačiau realybė visada yra tokia, kad viskas keičiasi ir lentelės struktūrą keisti reikia gana dažnai. Natūralu, kad pats procesas gali būti skausmingas ir nemalonus.
Aš nesigilinsiu į technologijos aprašymą ir instrukcijas, kaip pridėti biblioteką prie jūsų projekto; šia tema buvo parašyta nemažai straipsnių:
Be to, jau buvo puikus straipsnis naudingų patarimų tema:
Советы
Noriu pasidalinti savo patarimais ir komentarais, kurie gimė per prakaitą, kraują ir skausmą sprendžiant migracijos problemas.
1. Prieš pradėdami dirbti, turėtumėte susipažinti su geriausios praktikos skyriumi Liquibase
aprašomi paprasti, bet labai svarbūs dalykai, be kurių naudojimasis biblioteka gali apsunkinti gyvenimą. Pavyzdžiui, nestruktūrizuotas požiūris į pakeitimų rinkinių valdymą anksčiau ar vėliau sukels painiavą ir nutrūks migracijos. Jei tuo pačiu metu neišleisite tarpusavyje susijusių duomenų bazės struktūros ir paslaugų logikos pakeitimų, yra didelė tikimybė, kad tai sukels raudonus testus arba sugadins aplinką. Be to, rekomendacijose naudoti Liquibase oficialioje svetainėje yra sąlyga apie atšaukimo scenarijų kūrimą ir testavimą kartu su pagrindiniais perkėlimo scenarijais. Na, straipsnyje Yra kodų pavyzdžių, susijusių su perkėlimu ir grąžinimo mechanizmu.
2. Jei pradėsite naudoti perkėlimo įrankius, neleiskite duomenų bazės struktūros rankiniu būdu taisyti
Kaip sakoma: „Kartą Persil, visada Persil“. Jei jūsų programos bazę pradeda tvarkyti „Liquibase“, bet kokie rankiniai pakeitimai iš karto sukelia nenuoseklią būseną, o pasitikėjimo pakeitimų rinkiniais lygis tampa nulinis. Galima rizika apima kelias valandas, praleistas atkuriant duomenų bazę; blogiausiu atveju – neveikiantis serveris. Jei jūsų komandoje yra „senosios mokyklos“ DBA architektas, kantriai ir apgalvotai paaiškinkite jam, kaip bus blogai, jei jis paprasčiausiai redaguotų duomenų bazę pagal savo supratimą iš sąlyginio SQL kūrėjo.
3. Jei pakeitimų rinkinys jau buvo įstumtas į saugyklą, venkite redaguoti
Jei kitas kūrėjas pasitraukė ir pritaikė pakeitimų rinkinį, kuris vėliau bus redaguojamas, jis tikrai prisimins jus geru žodžiu, kai paleidžiant programą gaus klaidą. Jei redaguojant pakeitimų rinkinį kažkaip nutekės į plėtrą, turėsite sekti slidžią karštųjų pataisų nuolydį. Problemos esmė remiasi pokyčių patvirtinimu maišos suma – pagrindiniu Liquibase mechanizmu. Redaguojant pakeitimų rinkinio kodą, maišos suma pasikeičia. Redaguoti pakeitimų rinkinius galima tik tada, kai įmanoma įdiegti visą duomenų bazę nuo nulio neprarandant duomenų. Tokiu atveju SQL arba XML kodo pertvarkymas gali, priešingai, palengvinti gyvenimą ir padaryti migracijas skaitomesnę. Pavyzdys galėtų būti situacija, kai programos pradžioje komandoje buvo susitarta dėl šaltinio duomenų bazės schemos.
4. Jei įmanoma, turėkite patikrintas duomenų bazės atsargines kopijas
Čia, manau, viskas aišku. Jei staiga migracija buvo nesėkminga, viską galima grąžinti atgal. „Liquibase“ turi įrankį pakeitimams grąžinti, tačiau atšaukimo scenarijus taip pat rašo pats kūrėjas ir jie gali turėti problemų su tokia pat tikimybe, kaip ir pagrindinio pakeitimų rinkinio scenarijai. Tai reiškia, kad bet kuriuo atveju naudinga žaisti saugiai su atsarginėmis kopijomis.
5. Jei įmanoma, kurdami naudokite patikrintas duomenų bazės atsargines kopijas
Jei tai neprieštarauja sutartims ir privatumui, duomenų bazėje nėra asmeninių duomenų, o ir ji sveria ne tiek, kiek dvi saulutės – prieš naudodami tiesioginiuose migracijos serveriuose, galite pasitikrinti, kaip tai veiks kūrėjo mašinoje ir paskaičiuoti. beveik 100 % galimų problemų migracijos metu.
6. Bendraukite su kitais komandos kūrėjais
Gerai organizuotame kūrimo procese visi komandos nariai žino, kas ką daro. Tiesą sakant, dažnai taip nėra, todėl, jei ruošiatės duomenų bazės struktūros pakeitimus, kaip dalį savo užduoties, patartina apie tai papildomai pranešti visai komandai. Jei kas nors lygiagrečiai atlieka pakeitimus, turėtumėte atidžiai organizuoti. Bendrauti su kolegomis verta baigus darbą, o ne tik pradžioje. Daugelis galimų problemų, susijusių su pakeitimų rinkiniais, gali būti išspręstos kodo peržiūros etape.
7. Pagalvokite apie tai, ką darote!
Atrodytų, kaip savaime suprantamas patarimas, tinkantis bet kokiai situacijai. Tačiau daugelio problemų būtų buvę galima išvengti, jei kūrėjas dar kartą būtų išanalizavęs, ką daro ir ką tai gali paveikti. Darbas su migracijomis visada reikalauja papildomo dėmesio ir tikslumo.
Spąstai
Dabar pažvelkime į tipinius spąstus, į kuriuos galite patekti, jei nesilaikysite anksčiau pateiktų patarimų, ir ką tiksliai turėtumėte daryti?
1 situacija: du kūrėjai vienu metu bando pridėti naujų pakeitimų rinkinių
Vasya ir Petya nori sukurti 4 pakeitimų rinkinio versiją, nežinodami vienas apie kitą. Jie atliko duomenų bazės struktūros pakeitimus ir pateikė ištraukimo užklausą su skirtingais pakeitimų rinkinių failais. Siūlomas toks veikimo mechanizmas:
Kaip išspręsti
- Kažkaip kolegos turi susitarti, kokia tvarka turėtų vykti jų pakeitimų rinkiniai, pavyzdžiui, pirmiausia reikia pritaikyti Petin.
- Kažkas turėtų pridėti antrąjį prie savęs ir pažymėti Vasya pakeitimų rinkinį su 5 versija. Tai galima padaryti per Cherry Pick arba tvarkingą sujungimą.
- Po pakeitimų būtinai patikrinkite atliktų veiksmų pagrįstumą.
Tiesą sakant, „Liquibase“ mechanizmai leis saugykloje turėti du 4 versijos pakeitimų rinkinius, todėl galėsite palikti viską taip, kaip yra. Tai reiškia, kad turėsite du 4 versijos pakeitimus skirtingais pavadinimais. Taikant šį metodą, vėliau tampa labai sunku naršyti duomenų bazės versijose.
Be to, Liquibase, kaip ir hobitų namai, saugo daug paslapčių. Vienas iš jų yra raktas validCheckSum, kuris pasirodė 1.7 versijoje ir leidžia nurodyti galiojančią maišos reikšmę konkrečiam pakeitimų rinkiniui, neatsižvelgiant į tai, kas yra saugoma duomenų bazėje. Dokumentacija sako taip:
Pridėkite kontrolinę sumą, kuri laikoma galiojančia šiam pakeitimų rinkiniui, neatsižvelgiant į tai, kas saugoma duomenų bazėje. Visų pirma naudojamas, kai reikia pakeisti pakeitimų rinkinį ir nenorite, kad duomenų bazėse, kuriose jis jau paleistas, būtų rodomos klaidos (nerekomenduojama procedūra)
Taip, taip, ši procedūra nerekomenduojama. Tačiau kartais stiprus šviesos magas įvaldo ir tamsiąsias technikas
2 situacija: perkėlimas, kuris priklauso nuo duomenų
Tarkime, kad neturite galimybės naudoti duomenų bazių atsarginių kopijų iš tiesioginių serverių. Petya sukūrė pakeitimų rinkinį, išbandė jį vietoje ir, visiškai įsitikinęs, kad jis teisus, pateikė kūrėjui prašymą. Tik tuo atveju projekto vadovas paaiškino, ar Petya jį patikrino, ir tada pridėjo. Tačiau diegimas kūrimo serveryje sumažėjo.
Tiesą sakant, tai įmanoma, ir niekas nėra nuo to apsaugotas. Taip atsitinka, jei lentelės struktūros pakeitimai yra kažkaip susieti su konkrečiais duomenų bazės duomenimis. Akivaizdu, kad jei Petya duomenų bazė užpildyta tik bandymų duomenimis, ji gali neaprėpti visų probleminių atvejų. Pavyzdžiui, ištrinant lentelę, paaiškėja, kad kitose lentelėse yra įrašų pagal svetimą raktą, kurie yra susiję su įrašais ištrinamoje. Arba pakeitus stulpelio tipą paaiškėja, kad ne 100% duomenų galima konvertuoti į naują tipą.
Kaip išspręsti
- Parašykite specialius scenarijus, kurie bus naudojami vieną kartą kartu su perkėlimu, ir perkelkite duomenis į tinkamą formą. Tai yra bendras būdas išspręsti duomenų perkėlimo į naujas struktūras problemą pritaikius migracijas, tačiau kažkas panašaus gali būti taikoma ir anksčiau, ypatingais atvejais. Šis kelias, žinoma, ne visada pasiekiamas, nes duomenų redagavimas tiesioginiuose serveriuose gali būti pavojingas ir netgi destruktyvus.
- Kitas sudėtingas būdas yra redaguoti esamą pakeitimų rinkinį. Sunkumas yra tas, kad visos duomenų bazės, kuriose ji jau buvo pritaikyta esama forma, turės būti atkurtos. Visai įmanoma, kad visa backend komanda bus priversta vietoje įdiegti duomenų bazę nuo nulio.
- O universaliausias būdas yra perkelti problemą su duomenimis į kūrėjo aplinką, atkuriant tą pačią situaciją ir pridedant naują pakeitimų rinkinį, sugedusį, kuris apeis problemą.
Apskritai, kuo duomenų bazė savo sudėtimi panašesnė į gamybinės serverio duomenų bazę, tuo mažesnė tikimybė, kad problemos, susijusios su perkėlimu, bus toli. Ir, žinoma, prieš siųsdami pakeitimų rinkinį į saugyklą, turėtumėte keletą kartų pagalvoti, ar jis ką nors sugadins.
3 situacija. Liquibase pradedama naudoti pradėjus gaminti
Tarkime, komandos vadovas paprašė Petya įtraukti Liquibase į projektą, tačiau projektas jau gaminamas ir yra esama duomenų bazės struktūra.
Atitinkamai, problema ta, kad visuose naujuose serveriuose ar kūrėjų mašinose šios lentelės turi būti atkurtos nuo nulio, o esama aplinka turi išlikti nuoseklios būsenos, pasirengusi priimti naujus pakeitimų rinkinius.
Kaip išspręsti
Taip pat yra keletas būdų:
- Pirmasis ir akivaizdžiausias dalykas yra turėti atskirą scenarijų, kuris turi būti taikomas rankiniu būdu inicijuojant naują aplinką.
- Antrasis yra mažiau akivaizdus, turėkite „Liquibase“ perkėlimą, kuris yra kitame „Liquibase“ kontekste, ir taikykite jį. Daugiau apie Liquibase kontekstą galite perskaityti čia: . Apskritai tai įdomus mechanizmas, kurį galima sėkmingai panaudoti, pavyzdžiui, testavimui.
- Trečiasis kelias susideda iš kelių žingsnių. Pirmiausia reikia sukurti esamų lentelių perkėlimą. Tada jis turi būti pritaikytas tam tikrai aplinkai ir taip bus gauta jos maišos suma. Kitas žingsnis – inicijuoti tuščias „Liquibase“ lenteles mūsų netuščiame serveryje, o lentelėje su pakeitimų rinkinių naudojimo istorija galite rankiniu būdu įdėti įrašą apie „tarsi pritaikytą“ pakeitimų rinkinį su pakeitimais, kurie jau yra duomenų bazėje. . Taigi esamame serveryje istorijos atgalinis skaičiavimas prasidės nuo 2 versijos, o visos naujos aplinkos veiks vienodai.
Situacija 4. Migracijos tampa didžiulės ir nespėja užbaigti
Paslaugos kūrimo pradžioje, kaip taisyklė, Liquibase naudojama kaip išorinė priklausomybė, o visos migracijos apdorojamos paleidus programą. Tačiau laikui bėgant galite susidurti su šiais atvejais:
- Migracijos tampa didžiulės ir užtrunka ilgai.
- Reikia migracijos paskirstytoje aplinkoje, pavyzdžiui, keliuose duomenų bazės serverio egzemplioriuose vienu metu.
Tokiu atveju per ilgai taikant perkėlimą, programai paleidus baigsis laikas. Be to, taikant perkėlimą kiekvienam programos egzemplioriui atskirai, skirtingi serveriai gali būti nesinchronizuoti.
Kaip išspręsti
Tokiais atvejais jūsų projektas jau yra didelis, galbūt net suaugęs, o Liquibase pradeda veikti kaip atskiras išorinis įrankis. Faktas yra tas, kad Liquibase kaip biblioteka yra sukompiliuota į jar failą ir gali veikti kaip priklausomybė projekte arba atskirai.
Atskiru režimu perkėlimų įgyvendinimą galite palikti savo CI/CD aplinkai arba tvirtiems sistemos administratorių ir diegimo specialistų pečiams. Norėdami tai padaryti, jums reikės „Liquibase“ komandinės eilutės . Šiuo režimu programą galima paleisti atlikus visus būtinus perkėlimus.
Produkcija
Tiesą sakant, dirbant su duomenų bazių perkėlimu gali būti daug daugiau spąstų, ir daugeliui jų reikia kūrybiško požiūrio. Svarbu suprasti, kad jei įrankį naudosite teisingai, daugumos šių spąstų galima išvengti. Tiksliau, aš turėjau spręsti visas išvardytas problemas įvairiomis formomis, o kai kurios iš jų buvo mano klaidų pasekmė. Dažniausiai taip nutinka, žinoma, dėl neatidumo, bet kartais ir dėl nusikalstamo nesugebėjimo naudotis įrankiu.
Šaltinis: www.habr.com