Kurrë nuk ka qenë, dhe ja përsëri!
Në një projekt të ri, vendosëm të përdorim Liquibase nga fillimi, për të shmangur probleme të ardhshme. Siç u duk, jo të gjithë anëtarët e rinj të ekipit dinë ta përdorin atë siç duhet. Unë mbajta një punëtori të brendshme, të cilën më pas vendosa ta shndërroj në një artikull.
Artikulli pĂ«rfshin kĂ«shilla tĂ« dobishme dhe pĂ«rshkrimin e tre kurthĂ«ve mĂ« tĂ« dukshme nĂ« tĂ« cilat mund tĂ« bjerĂ« punĂ«s duke punuar me mjetet e migrimit tĂ« strukturave tĂ« bazave tĂ« tĂ« dhĂ«nave relacional, nĂ« veçanti Liquibase. ĂshtĂ« e destinuar pĂ«r zhvillues Java tĂ« nivelit Junior dhe Middle, pĂ«r zhvilluesit mĂ« tĂ« pĂ«rvojshĂ«m mund tĂ« jetĂ« interesante pĂ«r strukturoimin dhe pĂ«rkujtimin e asaj qĂ«, shumĂ« tĂ« ngjarĂ«, tashmĂ« Ă«shtĂ« e njohur.
Liquibase dhe Flyway janë teknologjitë kryesore konkuruese për zgjidhjen e detyrave të kontrollit të versioneve të strukturave relacionale në botën Java. E para është krejtësisht falas dhe në praktikë shpesh zgjidhet më shumë për t'u përdorur, prandaj Liquibase është zgjedhur si hero i publikimit. 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 domosdoshme për të luftuar fleksibilitetin e dobët të depozitave të dhënash relacional. Në epokën e modës për OOP, stili i punës me DB nënkuptonte që ne do ta përshkruanim schemën një herë dhe nuk do ta preknim më. Por realiteti gjithmonë është se gjithçka ndryshon, dhe ndryshimet në strukturën e tabelave kërkohen mjaft shpesh. Natyrisht, procesi vetë mund të jetë i dhimbshëm dhe i pakëndshëm.
Nuk do të thellohem në përshkrimin e teknologjisë dhe udhëzimeve për shtimin e bibliotekës në projektin tuaj, për këtë temë janë shkruar mjaft artikuj:
Për më tepër, tashmë ka pasur një artikull të shkëlqyer mbi këshillat e dobishme:
KĂ«shillat
Dua të ndaj këshillat dhe komentet e mia, të cilat lindi përmes djersës, gjakut dhe dhimbjes së zgjidhjes së problemeve me migrimin.
1. Para punës duhet të njohim 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 komplikohet jeta. Për shembull, një qasje e pa-strukturuar ndaj menaxhimit të çensiseteve do të sjellë në një moment konfuzion dhe migrime të prishura. Nëse miratoni ndryshime të ndërlidhura në strukturën e DB dhe logjikën e shërbimeve nuk njëkohësisht, ka një probabilitet të madh që kjo të çojë në teste të kuqe ose një ambient të prishur. Për më tepër, rekomandimet për përdorimin e Liquibase në faqen zyrtare përmbajnë një pikë në lidhje me zhvillimin dhe verifikimin e skripteve të rihapjes së bashkë me skriptet kryesore të migrimit. Për më tepër, në artikull janë shembuj kodi që i referohen migrimeve dhe mekanizmit të rihapjes.
2. Nëse keni filluar të përdorni mjetet e migrimit - mos lejoni korrigjime manuale në strukturën e bazës
Siç thonĂ«: «NjĂ« herĂ« Persil - gjithmonĂ« Persil». NĂ«se baza e aplikacionit tuaj ka filluar tĂ« menaxhohet nga mjetet Liquibase - çdo ndryshim manual çon menjĂ«herĂ« nĂ« njĂ« gjendje tĂ« pa konsoliduar dhe niveli i besimit nĂ« çensiset bĂ«het zero. Rreziqet potenciale - disa orĂ« tĂ« humbura pĂ«r tĂ« rikuperuar bazĂ«n, nĂ« mĂ«nyrĂ«n mĂ« tĂ« keqe - njĂ« server i shkatĂ«rruar. NĂ«se ekipi juaj ka njĂ« DBA Arkitekt âtĂ« vjetĂ«râ, shpjegojini me durim dhe me mendje se si gjithçka do tĂ« shkojĂ« keq, nĂ«se ai thjesht editojĂ« bazĂ«n sipas dĂ«shirĂ«s sĂ« tij nga njĂ« SQL Developer tĂ« supozuar.
3. Nëse çenseti tashmë është dërguar në depot, shmangni editimin
Nëse një zhvillues tjetër ka bërë pull dhe ka aplikuar çensetin, i cili më vonë do të redaktohet, - ai sigurisht do t'ju kujtojë me fjalë të mira, kur të marrë një gabim gjatë fillimit të aplikacionit. Nëse editimi i çensetit ndonjëherë kalon në këndin e zhvillimit - do të duhet të ecni një rrugë të rrezikshme të hotfixeve. Natyra e problemit ndikon në validimin e ndryshimeve sipas vlerës së hash-it - mekanizmi kryesor i Liquibase. Me editimin e kodit të çensetit, vlera e hash-it ndryshon. Editimi i çenseteve është i mundur vetëm kur ka mundësi të ktheni të gjithë bazën nga e para pa humbje të të dhënave. Në këtë rast, ristrukturimi i kodit SQL ose XML mund, përkundrazi, t'i lehtësojë jetën, duke e bërë migrimin më të lexueshëm. Një shembull mund të jetë situata kur në fillim të aplikacionit skema fillestare e DB u miratua brenda ekipit.
4. Keni kopje të verifikuara të bazave të të dhënave, nëse është e mundur
Këtu, mendoj, është e qartë. Në rast se migrimi nuk sukcesion, gjithçka mund të rikthehet. Në Liquibase ka një mjet për të rikthyer ndryshimet, por skriptet për rikthimin i shkruan gjithashtu zhvilluesi dhe ato mund të kenë probleme me të njëjtën probabilitet si skriptet e sets çështjes kryesore. Kjo do të thotë se është e dobishme të kesh kopje rezervë në çdo rast.
5. Përdorni kopje të verifikuara të bazave të të dhënave në zhvillim, nëse është e mundur
Nëse nuk është në kundërshtim me kontratat dhe privatësinë, nëse baza nuk ka të dhëna personale, dhe ajo nuk peshon si dy diell - para aplikimit në serverët e gjallë të migrimit mund të kontrollosh se si do të funksionojë në makinën e zhvilluesit dhe të llogaritësh pothuajse 100% problemet potenciale gjatë migrimit.
6. Komunikoni me zhvilluesit e tjerë në ekip
NĂ« njĂ« proces tĂ« organizuar mirĂ« tĂ« zhvillimit, tĂ« gjithĂ« nĂ« ekip e dinĂ« se kush Ă«shtĂ« i angazhuar me çfarĂ«. NĂ« realitet, shpesh nuk Ă«shtĂ« kĂ«shtu, kĂ«shtu qĂ«, nĂ«se nĂ« kuadĂ«r tĂ« detyrĂ«s tuaj po pĂ«rgatisni ndryshime nĂ« strukturĂ«n e bazĂ«s sĂ« tĂ« dhĂ«nave, Ă«shtĂ« e dĂ«shirueshme tĂ« njoftoni pĂ«r kĂ«tĂ« tĂ« gjithĂ« ekipin. NĂ«se dikush bĂ«n ndryshime paralelisht - duhet tĂ« organizoheni me kujdes. ĂshtĂ« mirĂ« tĂ« komunikoni me kolegĂ«t dhe pas pĂ«rfundimit tĂ« punĂ«s, jo vetĂ«m nĂ« fillim. ShumĂ« probleme potenciale me sets çështjesh 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 vetëkuptueshme, e aplikueshme në çdo situatë. Megjithatë, shumë probleme do të kishin shpëtuar nëse zhvilluesi do të kishte analizuar përsëri atë që po bën dhe se çfarë mund të ndikojë. Puna me migrimet gjithmonë kërkon vëmendje dhe kujdes shtesë.
Rafting
Le të shqyrtojmë tani kurthe tipike, në të cilat mund të bini nëse nuk ndiqni këshillat e mësipërme, dhe çfarë duhet të bëni?
Situata 1. Dy zhvillues po përpiqen të shtojnë sets çështjesh të reja njëkohësisht
Vasja dhe Petja duan të krijojnë setin çështjesh të versionit 4, pa e ditur njëri-tjetrin. Ata kanë bërë ndryshime në strukturën e bazës së të dhënave dhe kanë paraqitur një kërkesë për tërheqje, me skedarë të ndryshëm të sets çështjesh. Më pas propozohet mekanizmi i mëposhtëm për veprim:
Si të zgjidhni
- Dhe në njëfarë mënyre, kolegët duhet të bien dakord se në cilin rend duhet të shkojnë sets çështjesh të tyre, për shembull, ai i Petës duhet të aplikohet i pari.
- Një person duhet të shtihet për të derdhur të dytin te vetja dhe të shënojë changset-in e Vasis me versionin 5. Kjo mund të bëhet përmes Cherry Pick ose një merge të përshtatshëm.
- Pas ndryshimeve, është thelbësore të kontrolloni vlefshmërinë e veprimeve të kryera.
Në të vërtetë, mekanizmat e Liquibase do t'ju lejojnë të keni në repository dy changset-e të versionit 4, kështu që mund ta lini gjithçka siç është. Kështu që ju do të keni dy ndryshime të versionit 4 me emra të ndryshëm. Me këtë qasje, bëhet shumë e vështirë të orientoheni në versionet e databazës në të ardhmen.
Për më tepër, Liquibase, si shtëpia e hobitëve, ruan shumë sekrete. Një prej tyre është çelësi validCheckSum, i cili u shfaq me versionin 1.7 dhe lejon të tregoni një vlerë të vlefshme hash për një changset të caktuar, pavarësisht nga ajo që ruhet në databazë. Dokumentacioni thotë të mëposhtme:
Shto një checksum që konsiderohet i vlefshëm për këtë changeSet, pavarësisht se çfarë ruhet në databazë. Përdoret kryesisht kur duhet të ndryshoni një changeSet dhe nuk dëshironi që të hidhen gabime në databaza mbi të cilat ka funksionuar tashmë (nuk është një procedurë e rekomanduar)
Po, një procedurë e tillë nuk rekomandohet. Por ndonjëherë një magjistar i ndritur zotëron edhe teknikat e errëta.
Situata 2. Migrimi që varet nga të dhënat
Supozoni se nuk keni mundësi të përdorni kopje rezervë të bazave nga serverët aktivë. Petja krijoi changset-in, e kontrolloi lokalish dhe me një besim të plotë në të drejtën e tij bëri pull request në zhvillim. Lideri i projektit për çdo rast e sqaroi, kontrolloi nëse Petja e kishte verifikuar, dhe më pas e derdhi. Por shpërndarja në serverin e zhvillimit u ndal.
NĂ« fakt, kjo Ă«shtĂ« e mundur, dhe askush nuk Ă«shtĂ« i sigurt nga kjo. Kjo ndodh nĂ« rastin kur modifikimet e strukturĂ«s sĂ« tabelave janĂ« ndonjĂ«herĂ« tĂ« lidhura me tĂ« dhĂ«na tĂ« caktuara nga DB-ja. ĂshtĂ« e qartĂ« se, nĂ«se databaza e PetĂ«s Ă«shtĂ« mbushur vetĂ«m me tĂ« dhĂ«na testuese, atĂ«herĂ« ajo nuk mund tĂ« mbulojĂ« tĂ« gjitha rastet problematike. PĂ«r shembull, kur fshihet njĂ« tabelĂ«, del se ka regjistrime nĂ« tabela tĂ« tjera pĂ«rmes Foreign Key, tĂ« lidhura me regjistrimet nĂ« tabelĂ«n e fshirĂ«. Ose, kur ndodhet ndryshimi i tipit tĂ« kolonĂ«s, zbulohet se jo 100% e tĂ« dhĂ«nave mund tĂ« konvertohen nĂ« tipin e ri.
Si të zgjidhni
- Të shkruani skripte speciale që do të aplikohen një herë së bashku me migrimin dhe do të sjellin të dhënat në formën e duhur. Ky ë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 edhe përpara, në raste të veçanta. Kjo mënyrë, sigurisht, nuk është gjithmonë në dispozicion, pasi redaktimi i të dhënave në serverët aktiv mund të jetë i rrezikshëm dhe madje shkatërrues.
- Një tjetër mënyrë e komplikuar është të redaktoni changset ekzistuese. Kompleksiteti qëndron në faktin se të gjitha DB-të, ku ai është aplikuar në formën e tij ekzistuese, do të duhet të rikthehen. Mund të ndodhë që e gjithë ekipi i backend-it të jetë i detyruar të nisë lokalisht DB-në nga zero.
- Dhe rruga më universale është të transferoni problemin me të dhënat në ambientin e zhvilluesit duke rigjeneruar të njëjtën situatë dhe duke shtuar një changset të ri, përpara atij të prishur, i cili do të lejojë të anashtrohet problemi.
Në përgjithësi, sa më shumë që baza e të dhënave të ngjajë me bazën e serverit në prodhim, aq më pak shanse ka që problemet me migrimet të ndodhin në thellësi. Dhe, sigurisht, para se të dërgoni changset në repositor, duhet të mendoni disa herë nëse ai do të thyejë diçka.
Situata 3. Liquibase fillon të aplikohet vetëm pas daljes në prodhim.
Supozoni se lideri i ekipit iu kërkoi Petrit të lidhte Liquibase në projekt, megjithatë projekti është tashmë në prodhim dhe ekziston një strukturë e bazës së dhënave që është krijuar më parë.
Për pasojë, problemi konsiston në faktin se në çdo server të ri ose makinat e zhvilluesve, të dhënat e këtyre tabelave duhet të rigjenerohen nga zero, dhe mjedisi ekzistues duhet të mbetet në një gjendje konsistente, duke qenë i gatshëm të pranojë changset e reja.
Si të zgjidhni
Këtu gjithashtu ka disa rrugë:
- E para dhe më e dukshme është të keni një skript të veçantë, i cili duhet të aplikohet manualisht gjatë inicializimit të një ambienti të ri.
- E dyta â mĂ« pak e dukshme, tĂ« keni njĂ« migrim Liquibase, i cili ndodhet nĂ« njĂ« tjetĂ«r Kontekst Liquibase, dhe ta aplikoni atĂ«. MĂ« shumĂ« rreth Kontekstit tĂ« Liquibase mund tĂ« lexoni kĂ«tu: . NĂ« pĂ«rgjithĂ«si, ky Ă«shtĂ« njĂ« mekanizĂ«m interesante, i cili mund tĂ« aplikohet me sukses, pĂ«r shembull, pĂ«r testim.
- Rruga e tretë përbëhet nga disa hapa. Fillimisht, duhet të krijohet një migrim për tabelat ekzistuese. Më pas, ajo duhet të aplikohet në një ambient dhe kështu do të merret hash-suma e saj. Hapi i ardhshëm është të inicializoni në serverin tonë jo të zbrazët tabelat e zbrazëta të Liquibase, dhe në tabelën me historinë e zbatimit të setëve të ndryshimeve, mund të vendosni manualisht një regjistër për një set ndryshimesh "siç do të ishte aplikuar" me ndryshimet që tashmë ekzistojnë në bazë. Kështu, në serverin ekzistues, historia do të fillojë nga versioni 2, dhe të gjithë ambientet e reja do të veprojnë njësoj.
Situata 4. Migrimet bëhen të mëdha dhe nuk përfundojnë në kohë.
Në fillim të zhvillimit të shërbimit, zakonisht, Liquibase përdoret si një varësi ekstern, dhe të gjitha migrimet trajtohen gjatë startimit të aplikacionit. Megjithatë, me kalimin e kohës mund të përballeni me rastet e çiftëzuara:
- Migrimet bëhen të mëdha dhe zgjatin për një kohë të gjatë.
- Ndjehet nevoja për migrim në ambiente të shpërndara, le të themi, në disa instancat e serverëve të DB njëkohësisht.
Në një rast të tillë, zbatimi i gjatë i migrimeve do të çojë në skadimin e kohës gjatë startimit të aplikacionit. Për më tepër, zbatimi i migrimeve për çdo instancë të aplikacionit veçmas mund të çojë në situata ku serverët e ndryshëm janë në një gjendje jo sinkron.
Si të zgjidhni
Në raste të tilla, projekti juaj është tashmë i madh, ndoshta madje i rritur, dhe Liquibase fillon të veprojë si një mjet i veçantë dhe i jashtëm. E vërteta është se Liquibase si bibliotekë paketizohet në një skedar jar, dhe mund të funksionojë si një varësi brenda projektit, si edhe në mënyrë autonome.
Në një modalitet autonom, mund të ngarkohet zbatimi i migrimeve në ambientin tuaj CI/CD ose në supet e forta të administratorëve të sistemeve tuaj specialistë për shpërndarjen. Për këtë do të nevojitet komanda e linjës së komandave të Liquibase. . Në një modalitet të tillë, krijohet mundësia për të nisur aplikacionin vetëm pasi të jenë kryer të gjitha migrimet e nevojshme.
PĂ«rfundimi
NĂ« tĂ« vĂ«rtetĂ«, ka shumĂ« mĂ« tepĂ«r kapĂ«se kur punoni me migrrimet e DB, dhe shumĂ« prej tyre kĂ«rkojnĂ« njĂ« qasje kreative. ĂshtĂ« e rĂ«ndĂ«sishme tĂ« kuptoni se nĂ«se pĂ«rdorni instrumentin siç duhet, shumica e kĂ«tyre kapĂ«seve do tĂ« mund t'i shmangni. Konkretisht, unĂ« kam hasur nĂ« tĂ« gjitha kĂ«to probleme nĂ« forma tĂ« ndryshme, dhe disa prej tyre kanĂ« qenĂ« rezultat i gabimeve tĂ« mia. Kryesisht ndodhin pĂ«r shkak tĂ« mungesĂ«s sĂ« vĂ«mendjes, por ndonjĂ«herĂ« pĂ«r shkak tĂ« paaftĂ«sisĂ« kriminale pĂ«r tĂ« pĂ«rdorur instrumentin.
Burimi: habr.com
