Nikdy predtým sa to nestalo a je to tu znova!
Pri našom ďalšom projekte sme sa rozhodli použiť Liquibase od úplného začiatku, aby sme sa vyhli problémom v budúcnosti. Ako sa ukazuje, nie všetci mladí členovia tímu ho vedia správne používať. Uskutočnil som interný workshop, ktorý som sa potom rozhodol premeniť na článok.
Článok obsahuje užitočné tipy a popis troch najzrejmejších úskalí, do ktorých sa môžete dostať pri práci s nástrojmi na migráciu relačných databáz, najmä s Liquibase. Navrhnuté pre vývojárov Java na úrovni Junior a Middle; pre skúsenejších vývojárov môže byť zaujímavé pre štruktúrovanie a zopakovanie toho, čo je pravdepodobne už známe.
Liquibase a Flyway sú hlavné konkurenčné technológie na riešenie problémov správy verzií relačných štruktúr vo svete Java. Prvý z nich je úplne zadarmo, v praxi sa najčastejšie volí na použitie, a preto bol za hrdinu publikácie vybraný Liquibase. Niektoré z popísaných postupov však môžu byť univerzálne v závislosti od architektúry vašej aplikácie.
Migrácie relačných štruktúr sú núteným spôsobom, ako sa vysporiadať so slabou flexibilitou relačných dátových skladov. V ére módy OOP štýl práce s databázami znamenal, že schému opíšeme raz a už sa jej nedotkneme. Ale realita je vždy taká, že veci sa menia a zmeny v štruktúre tabuľky sú potrebné pomerne často. Prirodzene, samotný proces môže byť bolestivý a nepríjemný.
Nebudem zachádzať hlbšie do popisu technológie a pokynov na pridanie knižnice do vášho projektu, na túto tému bolo napísaných pomerne veľa článkov:
Okrem toho tu už bol vynikajúci článok na tému užitočných tipov:
Советы
Chcem sa podeliť o svoje rady a pripomienky, ktoré sa zrodili cez pot, krv a bolesť pri riešení problémov s migráciou.
1. Pred začatím práce by ste sa mali oboznámiť so sekciou osvedčených postupov Liquibase
sú popísané jednoduché, ale veľmi dôležité veci, bez ktorých vám používanie knižnice môže skomplikovať život. Napríklad neštruktúrovaný prístup k správe sád zmien skôr či neskôr povedie k zmätku a nefunkčným migráciám. Ak súčasne nezavediete vzájomne závislé zmeny v štruktúre databázy a servisnej logike, je vysoká pravdepodobnosť, že to povedie k červeným testom alebo narušeniu prostredia. Okrem toho odporúčania na používanie Liquibase na oficiálnej webovej stránke obsahujú klauzulu o vývoji a testovaní skriptov návratu spolu s hlavnými skriptami migrácie. No v článku Existujú príklady kódu týkajúce sa migrácií a mechanizmu vrátenia.
2. Ak začnete používať migračné nástroje, nepovoľte manuálne opravy v štruktúre databázy
Ako sa hovorí: "Raz Persil, navždy Persil." Ak základ vašej aplikácie začne spravovať Liquibase, akékoľvek manuálne zmeny okamžite vedú k nekonzistentnému stavu a úroveň dôvery v sady zmien bude nulová. Medzi potenciálne riziká patrí niekoľko hodín strávených obnovou databázy, v najhoršom prípade mŕtvy server. Ak máte vo svojom tíme architekta DBA zo „starej školy“, trpezlivo a premyslene mu vysvetlite, aké zlé veci budú, ak jednoducho upraví databázu podľa vlastného chápania od podmieneného SQL Developera.
3. Ak už bola sada zmien vložená do úložiska, vyhnite sa úpravám
Ak iný vývojár urobil ťah a aplikoval changeset, ktorý bude neskôr upravovaný, určite si na vás spomenie milým slovom, keď dostane chybu pri spustení aplikácie. Ak úprava changesetu nejakým spôsobom prenikne do vývoja, budete musieť sledovať klzký svah hotfixov. Podstata problému spočíva vo validácii zmien pomocou hash súčtu - hlavného mechanizmu Liquibase. Pri úprave kódu changesetu sa zmení množstvo hash. Úprava changesetov je možná len vtedy, keď je možné nasadiť celú databázu od začiatku bez straty dát. V tomto prípade môže refaktorovanie SQL alebo XML kódu, naopak, uľahčiť život a urobiť migrácie čitateľnejšie. Príkladom môže byť situácia, keď sa pri štarte aplikácie v rámci tímu dohodla schéma zdrojovej databázy.
4. Ak je to možné, majte overené zálohy databázy
Tu je, myslím, všetko jasné. Ak bola migrácia náhle neúspešná, všetko sa dá vrátiť späť. Liquibase má nástroj na vrátenie zmien, ale skripty na vrátenie zmien si píše aj sám vývojár a môžu mať problémy s rovnakou pravdepodobnosťou ako skripty hlavného changesetu. To znamená, že v každom prípade je užitočné hrať na istotu so zálohami.
5. Ak je to možné, pri vývoji používajte osvedčené zálohy databáz
Ak to nie je v rozpore so zmluvami a súkromím, v databáze nie sú žiadne osobné údaje a neváži ani dve slnká - pred použitím na serveroch živej migrácie si môžete skontrolovať, ako to bude fungovať na počítači vývojára a vypočítať takmer 100 % potenciálnych problémov počas migrácie.
6. Komunikujte s ostatnými vývojármi v tíme
V dobre organizovanom procese vývoja každý v tíme vie, kto čo robí. V skutočnosti to tak často nie je, preto ak v rámci svojej úlohy pripravujete zmeny v štruktúre databázy, je vhodné na to dodatočne upozorniť celý tím. Ak niekto robí zmeny súbežne, mali by ste sa starostlivo zorganizovať. S kolegami sa oplatí komunikovať aj po skončení práce, nielen na začiatku. Mnoho potenciálnych problémov so sadami zmien možno vyriešiť vo fáze preskúmania kódu.
7. Premýšľajte o tom, čo robíte!
Zdalo by sa, že ide o samozrejmú radu, ktorá platí v každej situácii. Mnohým problémom by sa však dalo predísť, keby vývojár ešte raz analyzoval, čo robí a čo to môže ovplyvniť. Práca s migráciami si vždy vyžaduje dodatočnú pozornosť a presnosť.
pasce
Poďme sa teraz pozrieť na typické pasce, do ktorých sa môžete dostať, ak sa nebudete riadiť vyššie uvedenými radami, a čo presne by ste mali robiť?
Situácia 1: Dvaja vývojári sa pokúšajú pridať nové sady zmien súčasne
Vasya a Petya chcú vytvoriť sadu zmien verzie 4 bez toho, aby o sebe navzájom vedeli. Urobili zmeny v štruktúre databázy a vydali požiadavku na stiahnutie s rôznymi súbormi changesetov. Navrhuje sa nasledujúci mechanizmus účinku:
Ako sa rozhodnúť
- Kolegovia sa musia nejako dohodnúť na poradí, v akom majú prejsť ich changesety, napríklad Petin by sa mal aplikovať ako prvý.
- Niekto by si mal pridať druhý a označiť Vasyov changeset verziou 5. Dá sa to urobiť pomocou Cherry Pick alebo úhľadným zlúčením.
- Po zmenách by ste mali určite skontrolovať platnosť vykonaných opatrení.
Mechanizmy Liquibase vám v skutočnosti umožnia mať v úložisku dve sady zmien verzie 4, takže môžete nechať všetko tak, ako je. To znamená, že budete mať jednoducho dve zmeny verzie 4 s rôznymi názvami. S týmto prístupom je neskôr veľmi ťažké orientovať sa vo verziách databázy.
Okrem toho Liquibase, podobne ako domov hobitov, ukrýva mnoho tajomstiev. Jedným z nich je kľúč validCheckSum, ktorý sa objavil vo verzii 1.7 a umožňuje určiť platnú hodnotu hash pre konkrétny changeset bez ohľadu na to, čo je uložené v databáze. Dokumentácia hovorí nasledovné:
Pridajte kontrolný súčet, ktorý sa považuje za platný pre túto sadu zmien, bez ohľadu na to, čo je uložené v databáze. Používa sa predovšetkým vtedy, keď potrebujete zmeniť sadu zmien a nechcete, aby sa v databázach, na ktorých už bežal, vyskytli chyby (nie je to odporúčaný postup)
Áno, áno, tento postup sa neodporúča. Ale niekedy silný svetelný mág ovláda aj tmavé techniky
Situácia 2: Migrácia, ktorá závisí od údajov
Predpokladajme, že nemáte možnosť používať zálohy databázy zo živých serverov. Petya vytvoril changeset, otestoval ho lokálne a s plnou istotou, že mal pravdu, podal vývojárovi požiadavku na stiahnutie. Pre každý prípad vedúci projektu objasnil, či to Peťa skontroloval, a potom to pridal. Nasadenie na vývojovom serveri však padlo.
V skutočnosti je to možné a nikto voči tomu nie je imúnny. Stáva sa to vtedy, ak sú úpravy štruktúry tabuľky nejakým spôsobom spojené s konkrétnymi údajmi z databázy. Je zrejmé, že ak je databáza Petya naplnená iba testovacími údajmi, nemusí pokrývať všetky problémové prípady. Napríklad pri odstraňovaní tabuľky sa ukáže, že v iných tabuľkách podľa cudzieho kľúča sú záznamy, ktoré súvisia so záznamami v tej, ktorá sa odstraňuje. Alebo pri zmene typu stĺpca sa ukáže, že nie 100 % údajov sa dá previesť na nový typ.
Ako sa rozhodnúť
- Napíšte špeciálne skripty, ktoré sa použijú raz spolu s migráciou a uvedú údaje do správnej formy. Toto je všeobecný spôsob, ako vyriešiť problém prenosu údajov do nových štruktúr po aplikovaní migrácií, ale niečo podobné možno v špeciálnych prípadoch použiť aj predtým. Táto cesta, samozrejme, nie je vždy dostupná, pretože úprava údajov na živých serveroch môže byť nebezpečná a dokonca deštruktívna.
- Ďalším náročným spôsobom je úprava existujúceho changesetu. Problém je v tom, že všetky databázy, v ktorých už bol aplikovaný vo svojej existujúcej forme, budú musieť byť obnovené. Je celkom možné, že celý backendový tím bude nútený lokálne spustiť databázu od začiatku.
- A najuniverzálnejším spôsobom je preniesť problém s údajmi do prostredia vývojára, vytvoriť rovnakú situáciu a pridať nový changeset do poškodeného, čím sa problém obíde.
Vo všeobecnosti platí, že čím viac sa databáza svojím zložením podobá na databázu produkčného servera, tým je menšia šanca, že problémy s migráciou zájdu ďaleko. A, samozrejme, pred odoslaním changesetu do repozitára by ste si mali niekoľkokrát premyslieť, či niečo nepokazí.
Situácia 3. Liquibase sa začína používať po uvedení do výroby
Predpokladajme, že vedúci tímu požiadal Petyu, aby do projektu zahrnula Liquibase, ale projekt je už vo výrobe a existuje existujúca štruktúra databázy.
Problém je teda v tom, že na všetkých nových serveroch alebo vývojárskych počítačoch musia byť tieto tabuľky vytvorené od začiatku a existujúce prostredie musí zostať v konzistentnom stave, pripravené prijať nové sady zmien.
Ako sa rozhodnúť
Existuje tiež niekoľko spôsobov:
- Prvým a najzrejmejším je mať samostatný skript, ktorý sa musí použiť manuálne pri inicializácii nového prostredia.
- Druhá je menej zrejmá, mať migráciu Liquibase, ktorá je v inom kontexte Liquibase, a použiť ju. Viac o kontexte Liquibase si môžete prečítať tu: . Vo všeobecnosti ide o zaujímavý mechanizmus, ktorý sa dá úspešne použiť napríklad na testovanie.
- Tretia cesta pozostáva z niekoľkých krokov. Najprv je potrebné vytvoriť migráciu pre existujúce tabuľky. Potom sa musí aplikovať na nejaké prostredie a tak sa získa jeho hash súčet. Ďalším krokom je inicializácia prázdnych tabuliek Liquibase na našom neprázdnom serveri a do tabuľky s históriou používania changesetov môžete manuálne vložiť záznam o „ako keby aplikovanom“ changesete so zmenami, ktoré už v databáze existujú. . Na existujúcom serveri sa teda odpočítavanie histórie začne od verzie 2 a všetky nové prostredia sa budú správať rovnako.
Situácia 4. Migrácie sú obrovské a nemajú čas na dokončenie
Na začiatku vývoja služby sa Liquibase spravidla používa ako externá závislosť a všetky migrácie sa spracujú pri spustení aplikácie. Postupom času však môžete naraziť na nasledujúce prípady:
- Migrácia je obrovská a trvá dlho, kým sa dokončí.
- Existuje potreba migrácie v distribuovaných prostrediach, napríklad na niekoľkých inštanciách databázového servera súčasne.
V tomto prípade aplikácia migrácií na príliš dlhú dobu povedie k vypršaniu časového limitu pri spustení aplikácie. Okrem toho aplikácia migrácií na každú inštanciu aplikácie samostatne môže viesť k tomu, že rôzne servery nebudú synchronizované.
Ako sa rozhodnúť
V takýchto prípadoch je váš projekt už veľký, možno aj dospelý a Liquibase začína pôsobiť ako samostatný externý nástroj. Faktom je, že Liquibase ako knižnica je zostavená do súboru jar a môže fungovať ako závislosť v rámci projektu alebo samostatne.
V samostatnom režime môžete implementáciu migrácií ponechať na prostredie CI/CD alebo na silné ramená vašich systémových administrátorov a špecialistov na nasadenie. Na to budete potrebovať príkazový riadok Liquibase . V tomto režime je možné spustiť aplikáciu po vykonaní všetkých potrebných migrácií.
Výkon
V skutočnosti môže byť pri práci s migráciami databáz oveľa viac nástrah a mnohé z nich si vyžadujú kreatívny prístup. Je dôležité pochopiť, že ak používate nástroj správne, väčšine z týchto nástrah sa dá vyhnúť. Konkrétne som sa musel vysporiadať so všetkými vymenovanými problémami v rôznych formách a niektoré z nich boli výsledkom mojich chýb. Väčšinou sa to deje, samozrejme, kvôli nepozornosti, ale niekedy kvôli trestnej neschopnosti použiť nástroj.
Zdroj: hab.com