Nuk ka ndodhur kurrë më parë, dhe ja ku po shkojmë përsëri!
Në projektin tonë të ardhshëm, vendosëm të përdorim Liquibase që në fillim për të shmangur problemet në të ardhmen. Siç rezulton, jo të gjithë anëtarët e rinj të ekipit dinë ta përdorin atë siç duhet. Kam mbajtur një seminar të brendshëm, të cilin më pas vendosa ta kthej në një artikull.
Artikulli përfshin këshilla të dobishme dhe një përshkrim të tre grackave më të dukshme në të cilat mund të bini kur punoni me mjetet e migrimit të bazës së të dhënave relacionale, në veçanti Liquibase. Projektuar për zhvilluesit Java në nivelet Junior dhe Middle; për zhvilluesit më me përvojë mund të jetë me interes për strukturimin dhe përsëritjen e asaj që ka shumë të ngjarë tashmë të njohur.
Liquibase dhe Flyway janë teknologjitë kryesore konkurruese për zgjidhjen e problemeve të kontrollit të versioneve të strukturave relacionale në botën Java. E para është plotësisht falas, në praktikë zgjidhet më shpesh për përdorim, prandaj Liquibase u zgjodh si heroi i botimit. Megjithatë, disa nga praktikat e përshkruara mund të jenë universale, në varësi të arkitekturës së aplikacionit tuaj.
Migrimet e strukturave relacionale janë një mënyrë e detyruar për t'u marrë me fleksibilitetin e dobët të ruajtjes së të dhënave relacionale. Në epokën e modës OOP, stili i punës me bazat e të dhënave nënkuptonte që ne ta përshkruanim skemën një herë dhe të mos e preknim më. Por realiteti është gjithmonë se gjërat ndryshojnë, dhe ndryshimet në strukturën e tabelës kërkohen mjaft shpesh. Natyrisht, vetë procesi mund të jetë i dhimbshëm dhe i pakëndshëm.
Nuk do të hyj më thellë në përshkrimin e teknologjisë dhe udhëzimeve për shtimin e një biblioteke në projektin tuaj; janë shkruar mjaft artikuj për këtë temë:
Për më tepër, tashmë kishte një artikull të shkëlqyeshëm mbi temën e këshillave të dobishme:
Советы
Dua të ndaj këshillat dhe komentet e mia, të cilat kanë lindur me djersën, gjakun dhe dhimbjen e zgjidhjes së problemeve me migrimin.
1. Para se të filloni punën, duhet të njiheni me seksionin e praktikave më të mira 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 pastrukturuar për menaxhimin e grupeve të ndryshimeve herët a vonë do të çojë në konfuzion dhe migrime të prishura. Nëse nuk bëni ndryshime të varura reciproke në strukturën e bazës së të dhënave dhe logjikën e shërbimit në të njëjtën kohë, ekziston një probabilitet i lartë që kjo të çojë në teste të kuqe ose një mjedis të prishur. Për më tepër, rekomandimet për përdorimin e Liquibase në faqen zyrtare të internetit përmbajnë një klauzolë në lidhje me zhvillimin dhe testimin e skripteve të rikthimit së bashku me skriptet kryesore të migrimit. Epo, në artikull Ka shembuj kodesh në lidhje me migrimet dhe mekanizmin e rikthimit.
2. Nëse filloni të përdorni mjetet e migrimit, mos lejoni korrigjime manuale në strukturën e bazës së të dhënave
Siç thotë shprehja: "Një herë Persil, gjithmonë Persil". Nëse baza e aplikacionit tuaj fillon të menaxhohet nga Liquibase, çdo ndryshim manual çon menjëherë në një gjendje jokonsistente dhe niveli i besimit në grupet e ndryshimeve bëhet zero. Rreziqet e mundshme përfshijnë disa orë të shpenzuara për të rivendosur bazën e të dhënave; në skenarin më të keq, një server i vdekur. Nëse keni një arkitekt DBA "të vjetër" në ekipin tuaj, shpjegojini atij me durim dhe mendim se sa të këqija do të jenë gjërat nëse ai thjesht redakton bazën e të dhënave sipas kuptimit të tij nga një Zhvillues i kushtëzuar SQL.
3. Nëse grupi i ndryshimeve është futur tashmë në depo, shmangni modifikimin
Nëse një zhvillues tjetër ka bërë një tërheqje dhe ka aplikuar një grup ndryshimesh, i cili më vonë do të modifikohet, ai patjetër do t'ju kujtojë me një fjalë të mirë kur të marrë një gabim kur fillon aplikacionin. Nëse redaktimi i grupit të ndryshimeve rrjedh disi në zhvillim, do t'ju duhet të ndiqni rrugën e rrëshqitshme të korrigjimeve të drejtpërdrejta. Thelbi i problemit qëndron në vërtetimin e ndryshimeve nga shuma hash - mekanizmi kryesor i Liquibase. Kur redaktoni kodin e ndryshimeve, sasia e hash-it ndryshon. Redaktimi i grupeve të ndryshimeve është i mundur vetëm kur është e mundur të vendoset e gjithë baza e të dhënave nga e para pa humbur të dhëna. Në këtë rast, rifaktorimi i kodit SQL ose XML, përkundrazi, mund ta bëjë jetën më të lehtë dhe t'i bëjë migrimet më të lexueshme. Një shembull do të ishte një situatë ku, në fillim të aplikacionit, skema e bazës së të dhënave burimore ishte rënë dakord brenda ekipit.
4. Keni verifikuar kopje rezervë të bazës së të dhënave nëse është e mundur
Këtu, mendoj, gjithçka është e qartë. Nëse papritmas migrimi ishte i pasuksesshëm, gjithçka mund të kthehet. Liquibase ka një mjet për rikthimin e ndryshimeve, por skriptet e rikthimit shkruhen gjithashtu nga vetë zhvilluesi dhe ato mund të kenë probleme me të njëjtën probabilitet si skriptet e grupit kryesor të ndryshimeve. Kjo do të thotë se është e dobishme ta luani atë të sigurt me kopje rezervë në çdo rast.
5. Përdorni kopje rezervë të provuar të bazës së të dhënave në zhvillim, nëse është e mundur
Nëse kjo nuk bie ndesh me kontratat dhe privatësinë, nuk ka të dhëna personale në bazën e të dhënave dhe nuk peshon sa dy diell - përpara se ta përdorni në serverët e migrimit të drejtpërdrejtë, mund të kontrolloni se si do të funksionojë në makinën e zhvilluesit dhe të llogarisni pothuajse 100% e problemeve të mundshme gjatë migrimit.
6. Komunikoni me zhvilluesit e tjerë në ekip
Në një proces zhvillimi të organizuar mirë, të gjithë në ekip e dinë se kush po bën çfarë. Në realitet, shpesh nuk është kështu, prandaj, nëse jeni duke përgatitur ndryshime në strukturën e bazës së të dhënave si pjesë e detyrës suaj, këshillohet që të njoftoni gjithashtu të gjithë ekipin për këtë. Nëse dikush po bën ndryshime paralelisht, duhet të organizoheni me kujdes. Ia vlen të komunikosh me kolegët pas përfundimit të punës, jo vetëm në fillim. Shumë probleme të mundshme me ndryshimet mund të zgjidhen në fazën e rishikimit të kodit.
7. Mendoni për atë që po bëni!
Do të duket si këshillë e vetëkuptueshme që vlen për çdo situatë. Megjithatë, shumë probleme mund të ishin shmangur nëse zhvilluesi do të kishte analizuar edhe një herë se çfarë po bënte dhe çfarë mund të ndikonte. Puna me migrimet kërkon gjithmonë vëmendje dhe saktësi shtesë.
Kurthe
Le të shohim tani kurthet tipike në të cilat mund të bini nëse nuk ndiqni këshillat e mësipërme dhe çfarë saktësisht duhet të bëni?
Situata 1: Dy zhvillues po përpiqen të shtojnë grupe të reja ndryshimesh në të njëjtën kohë
Vasya dhe Petya duan të krijojnë një version 4 të ndryshimeve, pa ditur për njëri-tjetrin. Ata bënë ndryshime në strukturën e bazës së të dhënave dhe lëshuan një kërkesë tërheqëse me skedarë të ndryshëm ndryshimesh. Propozohet mekanizmi i mëposhtëm i veprimit:
Si të vendosni
- Në njëfarë mënyre, kolegët duhet të bien dakord për rendin në të cilin duhet të shkojnë ndryshimet e tyre, për shembull, së pari duhet të aplikohet Petin.
- Dikush duhet t'i shtojë vetes të dytën dhe të shënojë grupin e ndryshimeve të Vasya-s me versionin 5. Kjo mund të bëhet përmes Cherry Pick ose një bashkim të rregullt.
- Pas ndryshimeve, duhet të kontrolloni patjetër vlefshmërinë e veprimeve të ndërmarra.
Në fakt, mekanizmat Liquibase do t'ju lejojnë të keni dy ndryshime të versionit 4 në depo, kështu që ju mund të lini gjithçka ashtu siç është. Kjo do të thotë, thjesht do të keni dy ndryshime në versionin 4 me emra të ndryshëm. Me këtë qasje, më vonë bëhet shumë e vështirë për të lundruar në versionet e bazës së të dhënave.
Përveç kësaj, Liquibase, si shtëpia e hobitëve, ruan shumë sekrete. Njëri prej tyre është çelësi validCheckSum, i cili u shfaq në versionin 1.7 dhe ju lejon të specifikoni një vlerë të vlefshme hash për një grup të caktuar ndryshimesh, pavarësisht nga ajo që ruhet në bazën e të dhënave. Dokumentacioni thotë sa vijon:
Shtoni një shumë kontrolli që konsiderohet e vlefshme për këtë grup ndryshimesh, pavarësisht se çfarë ruhet në bazën e të dhënave. Përdoret kryesisht kur ju duhet të ndryshoni një grup ndryshimesh dhe nuk dëshironi që gabimet të hidhen në bazat e të dhënave në të cilat është ekzekutuar tashmë (jo një procedurë e rekomanduar)
Po, po, kjo procedurë nuk rekomandohet. Por ndonjëherë një magjistar i fortë i dritës zotëron gjithashtu teknikat e errëta
Situata 2: Migrimi që varet nga të dhënat
Le të supozojmë se nuk keni aftësinë të përdorni kopje rezervë të bazës së të dhënave nga serverët e drejtpërdrejtë. Petya krijoi një grup ndryshimesh, e testoi atë në nivel lokal dhe, me besim të plotë se kishte të drejtë, i bëri një kërkesë për tërheqje zhvilluesit. Për çdo rast, drejtuesi i projektit sqaroi nëse Petya e kishte kontrolluar dhe më pas e shtoi. Por vendosja në serverin e zhvillimit ra.
Në fakt, kjo është e mundur dhe askush nuk është i imunizuar nga kjo. Kjo ndodh nëse modifikimet në strukturën e tabelës janë disi të lidhura me të dhëna specifike nga baza e të dhënave. Natyrisht, nëse baza e të dhënave e Petya është e mbushur vetëm me të dhëna testimi, atëherë ajo mund të mos mbulojë të gjitha rastet e problemit. Për shembull, kur fshihet një tabelë, rezulton se ka regjistrime në tabela të tjera nga çelësi i huaj që kanë të bëjnë me regjistrimet në atë që fshihet. Ose kur ndryshoni një lloj kolone, rezulton se jo 100% e të dhënave mund të konvertohen në llojin e ri.
Si të vendosni
- Shkruani skriptet speciale që do të përdoren një herë së bashku me migrimin dhe sillni të dhënat në formën e duhur. Kjo është një mënyrë e përgjithshme për të zgjidhur problemin e transferimit të të dhënave në struktura të reja pas aplikimit të migrimeve, por diçka e ngjashme mund të aplikohet më parë, në raste të veçanta. Kjo rrugë, natyrisht, nuk është gjithmonë e disponueshme, sepse redaktimi i të dhënave në serverët e drejtpërdrejtë mund të jetë i rrezikshëm dhe madje edhe shkatërrues.
- Një mënyrë tjetër e vështirë është të redaktoni një grup ndryshimesh ekzistuese. Vështirësia është se të gjitha bazat e të dhënave ku ajo tashmë është aplikuar në formën e saj ekzistuese do të duhet të restaurohen. Është shumë e mundur që i gjithë ekipi i backend-it të detyrohet të nxjerrë në nivel lokal bazën e të dhënave nga e para.
- Dhe mënyra më universale është transferimi i problemit me të dhënat në mjedisin e zhvilluesit, duke rikrijuar të njëjtën situatë dhe duke shtuar një grup të ri ndryshimesh, në atë të prishur, i cili do ta anashkalojë problemin.
Në përgjithësi, sa më shumë baza e të dhënave të jetë e ngjashme në përbërje me bazën e të dhënave të serverit të prodhimit, aq më pak shanse që problemet me migrimet të shkojnë larg. Dhe, sigurisht, përpara se të dërgoni një grup ndryshimesh në depo, duhet të mendoni disa herë nëse do të prishë ndonjë gjë.
Situata 3. Liquibase fillon të përdoret pasi të hyjë në prodhim
Supozoni se drejtuesi i ekipit i kërkoi Petya të përfshijë Liquibase në projekt, por projekti tashmë është në prodhim dhe ekziston një strukturë ekzistuese e bazës së të dhënave.
Prandaj, problemi është se në çdo server të ri ose makineri zhvilluesi, këto tabela duhet të rikrijohen nga e para, dhe mjedisi ekzistues duhet të mbetet në një gjendje konsistente, gati për të pranuar ndryshime të reja.
Si të vendosni
Ekzistojnë gjithashtu disa mënyra:
- E para dhe më e dukshme është të kesh një skrip të veçantë që duhet të aplikohet manualisht kur inicializon një mjedis të ri.
- E dyta është më pak e dukshme, keni një migrim Liquibase që është në një kontekst tjetër Liquibase dhe zbatojeni atë. Mund të lexoni më shumë rreth Liquibase Context këtu: . Në përgjithësi, ky është një mekanizëm interesant që mund të përdoret me sukses, për shembull, për testim.
- Rruga e tretë përbëhet nga disa hapa. Së pari, duhet të krijohet një migrim për tabelat ekzistuese. Pastaj duhet të aplikohet në ndonjë mjedis dhe kështu do të merret shuma e tij hash. Hapi tjetër është të inicializoni tabelat boshe Liquibase në serverin tonë jo bosh, dhe në tabelën me historikun e përdorimit të grupeve të ndryshimeve, mund të vendosni manualisht një rekord në lidhje me grupin e ndryshimeve "sikur të aplikohet" me ndryshimet tashmë ekzistuese në bazën e të dhënave. . Kështu, në një server ekzistues, numërimi mbrapsht i historisë do të fillojë nga versioni 2 dhe të gjitha mjediset e reja do të sillen në mënyrë identike.
Situata 4. Migrimet bëhen të mëdha dhe nuk kanë kohë për të përfunduar
Në fillim të zhvillimit të shërbimit, si rregull, Liquibase përdoret si një varësi e jashtme dhe të gjitha migrimet përpunohen kur fillon aplikacioni. Sidoqoftë, me kalimin e kohës, mund të hasni në rastet e mëposhtme:
- Migrimet bëhen të mëdha dhe kërkojnë shumë kohë për t'u përfunduar.
- Ekziston nevoja për migrim në mjedise të shpërndara, për shembull, në disa raste të serverëve të bazës së të dhënave në të njëjtën kohë.
Në këtë rast, aplikimi i migrimeve për një kohë të gjatë do të rezultojë në një afat kohor kur të fillojë aplikacioni. Për më tepër, aplikimi i migrimeve në secilin shembull aplikacioni veç e veç mund të rezultojë që serverë të ndryshëm të jenë jashtë sinkronizimit.
Si të vendosni
Në raste të tilla, projekti juaj është tashmë i madh, ndoshta edhe një i rritur, dhe Liquibase fillon të veprojë si një mjet i veçantë i jashtëm. Fakti është se Liquibase si një bibliotekë është përpiluar në një skedar jar dhe mund të funksionojë si një varësi brenda një projekti ose në mënyrë të pavarur.
Në modalitetin e pavarur, mund ta lini zbatimin e migrimeve në mjedisin tuaj CI/CD ose në supet e forta të administratorëve të sistemit tuaj dhe specialistëve të vendosjes. Për ta bërë këtë do t'ju duhet linja e komandës Liquibase . Në këtë mënyrë, bëhet e mundur nisja e aplikacionit pasi të jenë kryer të gjitha migrimet e nevojshme.
Prodhim
Në fakt, mund të ketë shumë më tepër gracka kur punoni me migrimin e bazës së të dhënave, dhe shumë prej tyre kërkojnë një qasje krijuese. Është e rëndësishme të kuptoni se nëse e përdorni mjetin në mënyrë korrekte, shumica e këtyre grackave mund të shmangen. Konkretisht, të gjitha problemet e listuara më është dashur t'i trajtoj në forma të ndryshme dhe disa prej tyre kanë qenë rezultat i gabimeve të mia. Kryesisht kjo ndodh, natyrisht, për shkak të pavëmendjes, por ndonjëherë për shkak të paaftësisë kriminale për të përdorur mjetin.
Burimi: www.habr.com