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
