Kurrë nuk ka ndodhur, dhe ja përsëri!
Në një projekt të ri, ne vendosëm të përdorim Liquibase që në fillim për të shmangur probleme në të ardhmen. Siç duket, jo të gjithë anëtarët e rinj të ekipit dinë ta përdorin atë siç duhet. Mbajta një punëtori të brendshme, të cilën më pas vendosa ta shndërroj në një artikull.
Artikulli pĂ«rmban kĂ«shilla tĂ« dobishme dhe njĂ« pĂ«rshkrim tĂ« tre grackave mĂ« tĂ« dukshme, nĂ« tĂ« cilat mund tĂ« bien ata qĂ« punojnĂ« me mjete pĂ«r migrimin e bazave tĂ« tĂ« dhĂ«nave relacionale, sidomos Liquibase. ĂshtĂ« e drejtuar pĂ«r zhvilluesit Java nĂ« nivelin Junior dhe Middle, ndĂ«rsa pĂ«r zhvilluesit mĂ« tĂ« pĂ«rvojshĂ«m mund tĂ« jetĂ« interesante pĂ«r tĂ« strukturuar dhe pĂ«rsĂ«ritur atĂ« qĂ«, me siguri, tashmĂ« e dinĂ«.
Liquibase dhe Flyway janë teknologjitë kryesore që konkurrojnë për zgjidhjen e problemeve të kontrollit të versioneve të strukturave relacionale në botën Java. E para është plotësisht falas dhe në praktikë shpesh zgjidhet për përdorim, prandaj edhe Liquibase është zgjedhur si hero i publikimit. Sidoqoftë, disa nga praktikat e përshkruara mund të jenë universale, në varësi të arhitekturës së aplikacionit tuaj.
Migrimi i struktura relacionale është një mënyrë e detyruar për të luftuar fleksibilitetin e dobët të depozitave të dhënash relacionale. Në epokën e modës për OOP, stili i punës me DB supozonte se ne do të përshkruajmë një herë skemën dhe nuk do ta prekni më. Por realiteti është gjithmonë i tillë që gjithçka ndryshon, dhe ndryshimet në strukturën e tabelave janë të nevojshme mjaft shpesh. Natyrisht, procesi është vetvetiu i dhimbshëm dhe i pakëndshëm.
Nuk do të thellohem në përshkrimin e teknologjisë dhe udhëzimet për shtimin e bibliotekës në projektin tim; për këtë temë janë shkruar mjaft artikuj:
Për më tepër, ka qenë një artikull i shkëlqyer mbi këshillat e dobishme:
KĂ«shilla
Dua të ndaj këshillat dhe komentet e mia, që kanë lindur përmes djersës, gjakut dhe dhimbjes së zgjidhjes së problemeve me migrimin.
1. Para të filloni, duhet të njiheni me seksionin e praktikave më të mira në Liquibase
përshkruhen gjëra të thjeshta, por shumë të rëndësishme, pa të cilat përdorimi i bibliotekës mund t'ju komplikojë jetën. Për shembull, një qasje e neshtër për menaxhimin e chanjset do të sjellë ngadalë konfuzion dhe migrime të prishura. Nëse ndryshimet e lidhura me njëra-tjetrën në strukturën e DB-së dhe logjikën e shërbimeve nuk aplikohen në të njëjtën kohë, ka një probabilitet të madh që kjo të çojë në teste të kuqe ose mjedis të prishur. Për më tepër, rekomandimet për përdorimin e Liquibase në faqen zyrtare përmbajnë një pikë për zhvillimin dhe kontrollin e skripteve të rollback-it së bashku me skripte të tjera kryesore të migrimit. Dhe në artikullin ka shembuj Kodi që lidhen me migrimet dhe mekanizmin e rollback.
2. NĂ«se keni filluar tĂ« pĂ«rdorni mjete migrimi â mos lejoni ndryshime manuale nĂ« strukturĂ«n e bazĂ«s sĂ« tĂ« dhĂ«nave.
Si thoni: "NjĂ« herĂ« Persil â gjithmonĂ« Persil". NĂ«se baza e aplikacionit tuaj ka filluar tĂ« menaxhohet nga Liquibase, çdo ndryshim manual menjĂ«herĂ« çon nĂ« njĂ« gjendje tĂ« papajtueshme, dhe niveli i besimit nĂ« çenset bĂ«het zero. Rreziqet e mundshme â disa orĂ« tĂ« humbura pĂ«r rikuperimin e bazĂ«s, nĂ« rastin mĂ« tĂ« keq â njĂ« server i shkatĂ«rruar. NĂ«se nĂ« ekipin tuaj ka njĂ« DBA Architect "tĂ« vjetĂ«r", shpjegoni me durim dhe me vĂ«mendje se si gjithçka do tĂ« shkojĂ« keq, nĂ«se ai thjesht editon bazĂ«n sipas dĂ«shires nga, pĂ«r shembull, SQL Developer.
3. Nëse çenseti tashmë është ngarkuar në repository, shmangni redaktimin
NĂ«se njĂ« zhvillues tjetĂ«r bĂ«nte njĂ« pull dhe aplikonte njĂ« set ndryshimesh qĂ« mĂ« vonĂ« do tĂ« redaktohet, ai do t'ju pĂ«rmendte me fjalĂ« tĂ« mira kur tĂ« marrĂ« njĂ« gabim gjatĂ« startimit tĂ« aplikacionit. NĂ«se redaktimi i setit tĂ« ndryshimeve ndonjĂ«herĂ« do tĂ« pĂ«rfundojĂ« nĂ« zhvillim, do tĂ« nevojitet tĂ« ecohet njĂ« rrugĂ« e vĂ«shtirĂ« me hotfixe. Thelbi i problemit qĂ«ndron nĂ« validimin e ndryshimeve sipas hash-it â mekanizmi kryesor i Liquibase. GjatĂ« redaktimit tĂ« kodit tĂ« setit tĂ« ndryshimeve, ndryshon hash-i. Redaktimi i setit tĂ« ndryshimeve Ă«shtĂ« i mundur vetĂ«m kur ka mundĂ«si pĂ«r tĂ« rivendosur tĂ« gjithĂ« bazĂ«n nga fillimi pa humbje tĂ« tĂ« dhĂ«nave. NĂ« kĂ«tĂ« rast, refaktorizimi i kodit SQL ose XML mund, pĂ«rkundrazi, tĂ« lehtĂ«sojĂ« jetĂ«n, duke e bĂ«rĂ« migrimin mĂ« tĂ« lexueshĂ«m. NjĂ« shembull mund tĂ« jetĂ« kur nĂ« fillimin e aplikacionit skema e bazĂ«s sĂ« tĂ« dhĂ«nave origjinale ishte e miratuar brenda ekipit.
4. Sigurohu që të kesh kopje rezervë të besueshme të bazave të të dhënave, nëse është e mundur
Këtu, mendoj, gjithçka është e qartë. Nëse ndonjëherë migrazha dështoi, gjithçka mund të kthehet mbrapsht. Në Liquibase ka një mjet për kthimin e ndryshimeve, por skriptet për kthimin e ndryshimeve shkruhen nga vetë zhvilluesi, dhe në to mund të ketë probleme me të njëjtën mundësi si në skriptet e setit kryesor të ndryshimeve. Kjo do të thotë se është e dobishme të kesh backup për çdo rast.
5. Përdor backup të verifikuara për bazat e të dhënave në zhvillim, nëse është e mundur.
NĂ«se kjo nuk Ă«shtĂ« nĂ« pĂ«rputhje me marrĂ«veshjet dhe privatĂ«sinĂ«, nĂ«se nĂ« bazĂ« nuk ka tĂ« dhĂ«na personale dhe nuk Ă«shtĂ« aq e rĂ«ndĂ« sa dy diellĂ« â para aplikimit nĂ« serverĂ«t e gjallĂ«, migrazha mund tĂ« kontrollohet se si funksionon nĂ« makinĂ«n e zhvilluesit dhe tĂ« llogaritet pothuajse 100% e problemeve tĂ« mundshme gjatĂ« migracionit.
6. Komuniko me zhvillues të tjerë në ekip.
NĂ« njĂ« proces zhvillimi tĂ« organizuar siç duhet, çdo anĂ«tar i ekipit di se çfarĂ« Ă«shtĂ« duke bĂ«rĂ«. NĂ« tĂ« vĂ«rtetĂ«, shpesh nuk Ă«shtĂ« kĂ«shtu, prandaj, nĂ«se po pĂ«rgatitni ndryshime nĂ« strukturĂ«n e bazĂ«s sĂ« tĂ« dhĂ«nave nĂ« kuadĂ«r tĂ« detyrĂ«s tuaj, Ă«shtĂ« e preferueshme tĂ« njoftoni gjithashtu tĂ« gjithĂ« ekipin. NĂ«se dikush tjetĂ«r po bĂ«n ndryshime nĂ« mĂ«nyrĂ« paralel, ju duhet tĂ« organizoheni me kujdes. ĂshtĂ« mirĂ« tĂ« komunikoni me kolegĂ«t edhe pas pĂ«rfundimit tĂ« punĂ«s, jo vetĂ«m nĂ« fillim. ShumĂ« probleme tĂ« mundshme me çensheti mund tĂ« zgjidhen nĂ« fazĂ«n e shqyrtimit tĂ« kodit.
7. Mendoni për atë që po bëni!
Duket si një këshillë e vetme, e aplikueshme në situata të ndryshme. Megjithatë, shumë probleme do të ishin evituar nëse zhvilluesi do të analizonte përsëri se çfarë po bën dhe çfarë ndikimi mund të ketë. Puna me migrimet gjithmonë kërkon vëmendje dhe kujdes të shtuar.
Kapaciteti
Tani le ta shqyrtojmë situata tipike në të cilat mund të bini në pritë nëse nuk i ndiqni këshillat e mësipërme dhe çfarë, në të vërtetë, duhet të bëni?
Situata 1. Dy zhvillues po përpiqen të shtojnë ndryshime të reja në të njëjtën kohë.
Vasja dhe Petja dëshirojnë të krijojnë një changset versi 4, pa e ditur njëri-tjetrin. Ata bënë ndryshime në strukturën e DB, dhe lëshuan një pull request, me skedarë të ndryshëm të changset-it. Më pas propozohet mekanizmi i mëposhtëm i veprimit:
Si të zgjidhni
- Në një mënyrë, kolegët duhet të bie dakord mbi rendin e aplikimit të changset-eve të tyre, le të themi, changset-i i Petës duhet të aplikohet i pari.
- Njëra prej tyre duhet të pajtojë tjetrin dhe të markojë changset-in e Vasës si versioni 5. Kjo mund të bëhet përmes Cherry Pick ose një bashkim të kujdesshëm.
- Pas ndryshimeve është e domosdoshme të kontrollohet vlefshmëria e veprimeve të kryera.
Në të vërtetë, mekanizmat e Liquibase do t'u lejojnë të kenë në repository dy changset-e të versionit 4, prandaj mund ta lini gjithçka siç është. Kështu, do të keni thjesht dy ndryshime të versionit 4 me emra të ndryshëm. Me këtë qasje, më vonë bëhet shumë e vështirë të orientoheni në versionet e bazës së të dhënave.
Për më tepër, Liquibase, si shtëpia e hobbitëve, mban shumë sekrete. Një prej tyre është çelësi validCheckSum, i cili shfaqet që nga versioni 1.7 dhe lejon të specificohet një vlerë valide hash për një set ndryshimesh, pavarësisht se çfarë është ruajtur në bazën e të dhënave. Dokumentacioni thotë si vijon:
Shto një kontroll që konsiderohet i valid për këtë set ndryshimesh, pavarësisht se çfarë ruhet në bazën e të dhënave. Përdoret kryesisht kur ke nevojë të ndryshosh një set ndryshimesh dhe nuk dëshiron që të hidhen gabime në bazat e të dhënave mbi të cilat ai tashmë ka funksionuar (nuk është një procedurë e rekomanduar)
Po-po, një procedurë e tillë nuk rekomandohet. Por ndonjëherë një magjistar i fortë zotëron edhe teknika të errëta.
Situata 2. Migrimi që varet nga të dhënat
Supozoni që nuk keni mundësi të përdorni kopje rezervë të bazave nga serverët e gjallë. Petja krijoi një set ndryshimesh, e kontrolloi atë lokal dhe me një besim të plotë në të vërtetën e tij bëri një kërkesë tërheqjeje për zhvillimin. Lideri i projektit për çdo rast e shqyrtoi, kontrolloi nëse Petja e kishte shqyrtuar, dhe pastaj e përfshiu. Por shpërndarja në serverin e zhvillimit dështoi.
NĂ« tĂ« vĂ«rtetĂ«, kjo Ă«shtĂ« e mundur, dhe askush nuk Ă«shtĂ« i sigurt nga kjo. Kjo ndodh nĂ« rastet kur modifikimet e strukturĂ«s sĂ« tabelave janĂ« ndonjĂ«herĂ« tĂ« lidhura me tĂ« dhĂ«na tĂ« caktuara nga DB. ĂshtĂ« e qartĂ« se, nĂ«se baza e tĂ« dhĂ«nave e Petrit Ă«shtĂ« plotĂ«sisht me tĂ« dhĂ«na testuese, ajo mund tĂ« mos mbulojĂ« tĂ« gjitha rastet problematike. PĂ«r shembull, gjatĂ« fshirjes sĂ« tabelĂ«s, rezulton se janĂ« regjistrime nĂ« tabela tĂ« tjera pĂ«rmes Foreign Key, tĂ« lidhura me regjistrimet nĂ« tĂ« fshirĂ«. Ose, gjatĂ« ndryshimit tĂ« llojit tĂ« kolonĂ«s, rezulton se jo 100% e tĂ« dhĂ«nave mund tĂ« konvertohen nĂ« llojin e ri.
Si të zgjidhni
- Të shkruhen skripte të veçanta, të cilat do të aplikohen një herë së bashku me migrimin dhe do të sjellin të dhënat në një formë të duhur. Kjo është një qasje e zakonshme për zgjidhjen e problemit të transferimit të të dhënave në strukturat e reja pas aplikimit të migrimeve, por diçka e ngjashme mund të aplikohet edhe para, në raste të veçanta. Kjo rrugë, natyrisht, nuk është gjithmonë e disponueshme, sepse të redaktosh të dhënat në serverët aktivë mund të jetë e rrezikshme dhe madje shkatërruese.
- NjĂ« mĂ«nyrĂ« tjetĂ«r e komplikuar Ă«shtĂ« tĂ« redaktoni setin ekzistues tĂ« ndryshimeve. Sfidimi Ă«shtĂ« se tĂ« gjitha DB-tĂ« ku ai Ă«shtĂ« aplikuar tashmĂ« do tĂ« duhet tĂ« rifillohen. ĂshtĂ« shumĂ« e mundshme qĂ« e gjithĂ« ekipi i backend-it do tĂ« detyrohet tĂ« pĂ«rditĂ«sojĂ« DB-nĂ« nga fillimi nĂ« mĂ«nyrĂ« lokale.
- Dhe mënyra më universale është të transferohet problemi me të dhënat në ambientin e zhvilluesit duke rikrijuar situatën e njëjtë dhe duke shtuar një set të ri ndryshimesh, deri në atë të shkatërruar, i cili do të lejojë përmirësimin e problemit.
Në përgjithësi, sa më shumë baza e të dhënave të jetë e ngjashme me bazën e serverit prodhues, aq më pak ka mundësi që problemet me migrimet të shpërndahen në mënyrë të gjerë. Dhe, sigurisht, para se të dërgoni setin e ndryshimeve në depo, është mirë të mendoni disa herë nëse do të thyejë ndonjë gjë.
Situata 3. Liquibase fillon të aplikohet vetëm pas daljes në prodhim.
Supozoni se lideri i ekipit i kërkoi Petrit të lidhë Liquibase në projekt, megjithatë projekti është tashmë në prodhim dhe ekziston një strukturë e dhënash.
Prandaj, problemi është që në çdo server të ri ose makinë zhvilluesi, të dhënat e këtyre tabelave duhet të rindërtohen nga e para, ndërsa mjedisi ekzistues duhet të mbahet në një gjendje konsistente, duke qenë gati për të pranuar çenshta të reja.
Si të zgjidhni
Këtu gjithashtu ka disa mënyra:
- E para dhe më e obvious është të kesh një skenar të veçantë, i cili duhet të zbatohet manualisht gjatë inicializimit të një ambienti të ri.
- E dyta â mĂ« pak e obvious, tĂ« kesh njĂ« migrim tĂ« Liquibase, i cili ndodhet nĂ« njĂ« Kontekst tjetĂ«r Liquibase, dhe ta aplikosh atĂ«. MĂ« shumĂ« mund tĂ« lexoni rreth Konteskteve tĂ« Liquibase kĂ«tu: . NĂ« pĂ«rgjithĂ«si, kjo Ă«shtĂ« njĂ« mekanizĂ«m interesant, qĂ« mund tĂ« aplikohet me sukses, pĂ«r shembull, pĂ«r testim.
- Një rrugë e tretë përbëhet nga disa hapa. Së pari, duhet të krijohet një migração për tabelat që ekzistojnë tashmë. Më pas, ajo duhet të aplikohet në ndonjë ambient dhe në këtë mënyrë do të merret hash-i i saj. Hapi tjetër është të inicializoni tabelat e zbrazta të Liquibase në serverin tonë të plotësuar, dhe në tabelën e historisë së përdorimit të ndryshimeve mund të futni manualisht një rekord për një ndryshim të 'aplikuar' siç duhet me ndryshimet që tashmë ekzistojnë në bazën e të dhënave. Në këtë mënyrë, në serverin që ekziston, historia do të fillojë nga versioni 2, dhe të gjithë ambientet e reja do të veprojnë njësoj.
Situata 4. Migracionet bëhen të mëdha dhe nuk arrijnë të përfundojnë.
Në fillim të zhvillimit të shërbimit, zakonisht, Liquibase përdoret si një varësi e jashtme, dhe të gjitha migracionet trajtohen gjatë fillimit të aplikacionit. Megjithatë, me kalimin e kohës, mund të hasni këto raste:
- Migracionet bëhen të mëdha dhe kryhen për një periudhë të gjatë.
- Shfaqet nevoja për migrim në ambiente të shpërndara, për shembull, në disa instanca të serverëve të DB në të njëjtën kohë.
Në këtë rast, aplikimi i zgjatur i migrimeve do të çojë në skadimin e kohës gjatë nisjes së aplikacionit. Për më tepër, aplikimi i migrimeve për çdo instancë të aplikacionit veçmas mund të sjellë që serverët të jenë në një gjendje të pasinkronizuar.
Si të zgjidhni
Në raste të tilla, projekti juaj është tashmë i madh, ndoshta edhe në moshën e tij, dhe Liquibase fillon të veprojë si një mjet i jashtëm i veçantë. Problemi është se Liquibase si bibliotekë grumbullohet në një skedar jar dhe mund të funksionojë si një varësi brenda projektit, ashtu si dhe autonomisht.
Në modalitetin autonom, mund të ngarkoni aplikimin e migrimeve në mjedisin tuaj CI/CD ose në duar të forta të administratorëve tuaj të sistemeve/ekspertëve të implementimit. Për këtë, do të nevojitet linja e komandës së Liquibase. Në këtë modalitet, krijohet mundësia për të nisur aplikacionin pas përfundimit të të gjitha migrimeve të nevojshme.
PĂ«rfundim
NĂ« tĂ« vĂ«rtetĂ«, ka shumĂ« mĂ« tepĂ«r kurthe kur punoni me migrime tĂ« DB, dhe shumĂ« prej tyre kĂ«rkojnĂ« qasje kreative. ĂshtĂ« e rĂ«ndĂ«sishme tĂ« kuptohet se nĂ«se pĂ«rdoret siç duhet, shumica e kĂ«tyre kurtheve mund tĂ« shmangen. Konkretisht, unĂ« kam hasur tĂ« gjitha kĂ«to probleme nĂ« forma tĂ« ndryshme, dhe disa nga ato ishin rezultat i gabimeve tĂ« mia. Kryesisht ndodhin pĂ«r shkak tĂ« moskujdesit, por ndonjĂ«herĂ« - pĂ«r shkak tĂ« paaftĂ«sisĂ« kriminele pĂ«r tĂ« pĂ«rdorur mjetin.
Burimi: habr.com
