Sut i beidio â saethu eich hun yn y droed gan ddefnyddio Liquibase

Erioed wedi digwydd o'r blaen, a dyma ni'n mynd eto!

Ar ein prosiect nesaf, penderfynom ddefnyddio Liquibase o'r cychwyn cyntaf i osgoi problemau yn y dyfodol. Fel mae'n digwydd, nid yw pob aelod ifanc o'r tîm yn gwybod sut i'w ddefnyddio'n gywir. Cynhaliais weithdy mewnol, a phenderfynais wedyn ei droi'n erthygl.

Mae'r erthygl yn cynnwys awgrymiadau defnyddiol a disgrifiad o'r tri pheryglon mwyaf amlwg y gallwch chi syrthio iddynt wrth weithio gydag offer mudo cronfa ddata perthynol, yn enwedig Liquibase. Wedi'i gynllunio ar gyfer datblygwyr Java ar lefelau Iau a Chanol; i ddatblygwyr mwy profiadol efallai y bydd o ddiddordeb i strwythuro ac ailadrodd yr hyn sy'n fwyaf tebygol o fod yn hysbys.

Sut i beidio â saethu eich hun yn y droed gan ddefnyddio Liquibase

Liquibase a Flyway yw'r prif dechnolegau cystadleuol ar gyfer datrys problemau rheoli fersiynau o strwythurau perthynol yn y byd Java. Mae'r un cyntaf yn hollol rhad ac am ddim, yn ymarferol fe'i dewisir amlaf i'w ddefnyddio, a dyna pam y dewiswyd Liquibase fel arwr y cyhoeddiad. Fodd bynnag, gall rhai o'r arferion a ddisgrifir fod yn gyffredinol, yn dibynnu ar bensaernïaeth eich cais.

Mae mudo strwythurau perthynol yn ffordd orfodol o ddelio â hyblygrwydd gwan storfeydd data perthynol. Yn oes ffasiwn OOP, roedd yr arddull o weithio gyda chronfeydd data yn golygu y byddem yn disgrifio'r sgema unwaith ac yn peidio â chyffwrdd ag ef eto. Ond y gwir amdani bob amser yw bod pethau'n newid, ac mae angen newidiadau i strwythur y bwrdd yn eithaf aml. Yn naturiol, gall y broses ei hun fod yn boenus ac yn annymunol.

Nid af yn ddyfnach i'r disgrifiad o'r dechnoleg a'r cyfarwyddiadau ar gyfer ychwanegu llyfrgell at eich prosiect; mae cryn dipyn o erthyglau wedi'u hysgrifennu ar y pwnc hwn:

Yn ogystal, roedd erthygl wych eisoes ar y pwnc o awgrymiadau defnyddiol:

Советы

Rwyf am rannu fy nghyngor a’m sylwadau, a gafodd eu geni drwy’r chwys, gwaed a phoen o ddatrys problemau ymfudo.

1. Cyn dechrau gweithio, dylech ymgyfarwyddo â'r adran arferion gorau ar Ar-lein Liquibase

Yno disgrifir pethau syml ond pwysig iawn, a hebddynt gall defnyddio'r llyfrgell gymhlethu'ch bywyd. Er enghraifft, bydd dull anstrwythuredig o reoli setiau newid yn hwyr neu'n hwyrach yn arwain at ddryswch a mudo toredig. Os na fyddwch yn cyflwyno newidiadau cyd-ddibynnol i strwythur y gronfa ddata a rhesymeg y gwasanaeth ar yr un pryd, mae'n debygol iawn y bydd hyn yn arwain at brofion coch neu amgylchedd sydd wedi torri. Yn ogystal, mae argymhellion ar gyfer defnyddio Liquibase ar y wefan swyddogol yn cynnwys cymal am ddatblygu a phrofi sgriptiau dychwelyd ynghyd â'r prif sgriptiau mudo. Wel, yn yr erthygl https://habr.com/ru/post/178665/ Ceir enghreifftiau cod ynghylch mudo a'r mecanwaith dychwelyd.

2. Os byddwch chi'n dechrau defnyddio offer mudo, peidiwch â chaniatáu cywiriadau â llaw yn strwythur y gronfa ddata

Fel y dywed y dywediad: “Unwaith Persil, bob amser Persil.” Os bydd sylfaen eich cais yn dechrau cael ei reoli gan Liquibase, bydd unrhyw newidiadau â llaw ar unwaith yn arwain at gyflwr anghyson, a bydd lefel yr ymddiriedaeth mewn setiau newid yn sero. Ymhlith y risgiau posibl mae sawl awr a dreulir yn adfer y gronfa ddata; yn y sefyllfa waethaf, gweinydd marw. Os oes gennych chi Bensaer DBA “hen ysgol” ar eich tîm, eglurwch yn amyneddgar ac yn feddylgar iddo pa mor ddrwg fydd pethau os bydd yn syml yn golygu'r gronfa ddata yn unol â'i ddealltwriaeth ei hun gan Ddatblygwr SQL amodol.

3. Os yw'r changeset eisoes wedi'i gwthio i'r ystorfa, osgoi golygu

Pe bai datblygwr arall yn tynnu ac wedi cymhwyso set o newidiadau, a fydd yn cael ei olygu'n ddiweddarach, bydd yn bendant yn eich cofio â gair caredig pan fydd yn derbyn gwall wrth gychwyn y cais. Os yw golygu'r set newidiadau rywsut yn gollwng i mewn i ddatblygiad, bydd yn rhaid i chi ddilyn llethr llithrig yr atebion poeth. Mae hanfod y broblem yn dibynnu ar ddilysu newidiadau trwy swm hash - prif fecanwaith Liquibase. Wrth olygu'r cod changeset, mae swm yr hash yn newid. Dim ond pan fydd yn bosibl defnyddio'r gronfa ddata gyfan o'r dechrau heb golli data y mae'n bosibl golygu setiau newidiadau. Yn yr achos hwn, gall ailffactorio'r cod SQL neu XML, i'r gwrthwyneb, wneud bywyd yn haws a gwneud mudo yn fwy darllenadwy. Enghraifft o hyn fyddai sefyllfa lle, ar ddechrau'r cais, y cytunwyd ar sgema'r gronfa ddata ffynonellau o fewn y tîm.

4. Wedi gwirio copïau wrth gefn o'r gronfa ddata os yn bosibl

Yma, rwy'n meddwl, mae popeth yn glir. Os bu'r mudo yn aflwyddiannus yn sydyn, gellir dychwelyd popeth yn ôl. Mae gan Liquibase offeryn ar gyfer treiglo newidiadau yn ôl, ond mae'r sgriptiau dychwelyd hefyd yn cael eu hysgrifennu gan y datblygwr ei hun, a gallant gael problemau gyda'r un tebygolrwydd â sgriptiau'r prif newidiadau. Mae hyn yn golygu ei bod yn ddefnyddiol ei chwarae'n ddiogel gyda chopïau wrth gefn mewn unrhyw achos.

5. Defnyddiwch gronfeydd wrth gefn profedig wrth eu datblygu, os yn bosibl

Os nad yw hyn yn gwrth-ddweud contractau a phreifatrwydd, nid oes unrhyw ddata personol yn y gronfa ddata, ac nid yw'n pwyso cymaint â dau haul - cyn ei ddefnyddio ar weinyddion mudo byw, gallwch wirio sut y bydd yn gweithio ar beiriant y datblygwr a chyfrifo bron i 100% o'r problemau posibl yn ystod mudo.

6. Cyfathrebu â datblygwyr eraill ar y tîm

Mewn proses ddatblygu drefnus, mae pawb ar y tîm yn gwybod pwy sy'n gwneud beth. Mewn gwirionedd, nid yw hyn yn aml yn wir, felly, os ydych yn paratoi newidiadau i strwythur y gronfa ddata fel rhan o'ch tasg, fe'ch cynghorir i hysbysu'r tîm cyfan am hyn hefyd. Os yw rhywun yn gwneud newidiadau ochr yn ochr, dylech drefnu'n ofalus. Mae’n werth cyfathrebu â chydweithwyr ar ôl gorffen gwaith, nid dim ond ar y dechrau. Gellir datrys llawer o broblemau posibl gyda setiau newidiadau yn ystod y cam adolygu cod.

7. Meddyliwch am yr hyn yr ydych yn ei wneud!

Byddai'n ymddangos fel cyngor hunan-amlwg sy'n berthnasol i unrhyw sefyllfa. Fodd bynnag, gellid bod wedi osgoi llawer o broblemau pe bai'r datblygwr unwaith eto wedi dadansoddi'r hyn yr oedd yn ei wneud a'r hyn y gallai effeithio arno. Mae gweithio gyda mudo bob amser yn gofyn am sylw a chywirdeb ychwanegol.

Trapiau

Edrychwn yn awr ar y trapiau nodweddiadol y gallwch syrthio iddynt os na ddilynwch y cyngor uchod, a beth, yn union, y dylech ei wneud?

Sefyllfa 1: Mae dau ddatblygwr yn ceisio ychwanegu setiau newid newydd ar yr un pryd

Sut i beidio â saethu eich hun yn y droed gan ddefnyddio Liquibase
Mae Vasya a Petya eisiau creu fersiwn changeet 4, heb wybod am ei gilydd. Gwnaethant newidiadau i strwythur y gronfa ddata a chyhoeddwyd cais tynnu gyda gwahanol ffeiliau changeset. Cynigir y mecanwaith gweithredu canlynol:

Sut i benderfynu

  1. Rhywsut, rhaid i gydweithwyr gytuno ar y drefn y dylai eu changesets fynd, er enghraifft, dylid defnyddio Petin yn gyntaf.
  2. Dylai rhywun ychwanegu'r ail un at eu hunain a nodi newidiadau Vasya gyda fersiwn 5. Gellir gwneud hyn trwy Cherry Pick neu gyfuniad taclus.
  3. Ar ôl newidiadau, dylech yn bendant wirio dilysrwydd y camau a gymerwyd.
    Mewn gwirionedd, bydd mecanweithiau Liquibase yn caniatáu ichi gael dwy set o newidiadau fersiwn 4 yn y gadwrfa, felly gallwch chi adael popeth fel y mae. Hynny yw, yn syml, bydd gennych ddau newid i fersiwn 4 gydag enwau gwahanol. Gyda'r dull hwn, mae'n dod yn anodd iawn llywio'r fersiynau cronfa ddata yn ddiweddarach.

Yn ogystal, mae Liquibase, fel cartref y hobbits, yn cadw llawer o gyfrinachau. Un ohonynt yw'r allwedd validCheckSum, a ymddangosodd yn fersiwn 1.7 ac sy'n eich galluogi i nodi gwerth hash dilys ar gyfer set newid benodol, waeth beth sy'n cael ei storio yn y gronfa ddata. Dogfennaeth https://www.liquibase.org/documentation/changeset.html yn dweud y canlynol:

Ychwanegu siec sy'n cael ei ystyried yn ddilys ar gyfer y changeSet hwn, waeth beth sy'n cael ei storio yn y gronfa ddata. Fe'i defnyddir yn bennaf pan fydd angen i chi newid changeSet a ddim eisiau i wallau gael eu taflu ar gronfeydd data y mae eisoes wedi rhedeg arnynt (nid gweithdrefn a argymhellir)

Ydy, ie, nid yw'r weithdrefn hon yn cael ei hargymell. Ond weithiau mae consuriwr golau cryf hefyd yn meistroli technegau tywyll

Sefyllfa 2: Mudo sy'n dibynnu ar ddata

Sut i beidio â saethu eich hun yn y droed gan ddefnyddio Liquibase

Gadewch i ni dybio nad oes gennych y gallu i ddefnyddio copïau wrth gefn cronfa ddata o weinyddion byw. Creodd Petya set newid, ei brofi'n lleol a, gyda hyder llawn ei fod yn iawn, gwnaeth gais tynnu i'r datblygwr. Rhag ofn, eglurodd arweinydd y prosiect a oedd Petya wedi ei wirio, ac yna ei ychwanegu. Ond gostyngodd y defnydd ar y gweinydd datblygu.

Mewn gwirionedd, mae hyn yn bosibl, ac nid oes neb yn imiwn rhag hyn. Mae hyn yn digwydd os yw addasiadau i strwythur y tabl wedi'u cysylltu rywsut â data penodol o'r gronfa ddata. Yn amlwg, os yw cronfa ddata Petya wedi'i llenwi â data prawf yn unig, yna efallai na fydd yn cwmpasu pob achos problemus. Er enghraifft, wrth ddileu tabl, mae'n ymddangos bod cofnodion mewn tablau eraill yn ôl Allwedd Dramor sy'n gysylltiedig â chofnodion yn yr un sy'n cael ei ddileu. Neu wrth newid math o golofn, mae'n ymddangos na ellir trosi 100% o'r data i'r math newydd.

Sut i benderfynu

  • Ysgrifennwch sgriptiau arbennig a fydd yn cael eu defnyddio unwaith ynghyd â'r mudo a dod â'r data i'r ffurf gywir. Mae hon yn ffordd gyffredinol o ddatrys y broblem o drosglwyddo data i strwythurau newydd ar ôl cymhwyso mudo, ond gellir cymhwyso rhywbeth tebyg o'r blaen, mewn achosion arbennig. Nid yw'r llwybr hwn, wrth gwrs, bob amser ar gael, oherwydd gall golygu data ar weinyddion byw fod yn beryglus a hyd yn oed yn ddinistriol.
  • Ffordd anodd arall yw golygu set o newidiadau sy'n bodoli eisoes. Yr anhawster yw y bydd yn rhaid adfer yr holl gronfeydd data lle y'i defnyddiwyd eisoes yn ei ffurf bresennol. Mae'n ddigon posibl y bydd y tîm ôl-wyneb cyfan yn cael eu gorfodi i gyflwyno'r gronfa ddata yn lleol o'r newydd.
  • A'r ffordd fwyaf cyffredinol yw trosglwyddo'r broblem gyda'r data i amgylchedd y datblygwr, gan ail-greu'r un sefyllfa ac ychwanegu set newid newydd, i'r un sydd wedi torri, a fydd yn osgoi'r broblem.
    Sut i beidio â saethu eich hun yn y droed gan ddefnyddio Liquibase

Yn gyffredinol, po fwyaf y mae'r gronfa ddata yn debyg o ran cyfansoddiad i gronfa ddata'r gweinydd cynhyrchu, y lleiaf o siawns y bydd problemau gyda mudo yn mynd yn bell. Ac, wrth gwrs, cyn i chi anfon changeset i'r ystorfa, dylech feddwl sawl gwaith a fydd yn torri unrhyw beth.

Sefyllfa 3. Mae Liquibase yn dechrau cael ei ddefnyddio ar ôl iddo ddechrau cynhyrchu

Tybiwch fod arweinydd y tîm wedi gofyn i Petya gynnwys Liquibase yn y prosiect, ond mae'r prosiect eisoes yn cael ei gynhyrchu ac mae strwythur cronfa ddata yn bodoli eisoes.

Yn unol â hynny, y broblem yw bod yn rhaid ail-greu'r tablau hyn o'r dechrau ar unrhyw weinyddion neu beiriannau datblygwr newydd, a rhaid i'r amgylchedd presennol aros mewn cyflwr cyson, yn barod i dderbyn setiau newydd.

Sut i benderfynu

Mae yna hefyd sawl ffordd:

  • Y cyntaf a'r mwyaf amlwg yw cael sgript ar wahân y mae'n rhaid ei chymhwyso â llaw wrth gychwyn amgylchedd newydd.
  • Mae'r ail yn llai amlwg, cael mudo Liquibase sydd mewn Cyd-destun Liquibase arall, a'i gymhwyso. Gallwch ddarllen mwy am Liquibase Context yma: https://www.liquibase.org/documentation/contexts.html. Yn gyffredinol, mae hwn yn fecanwaith diddorol y gellir ei ddefnyddio'n llwyddiannus, er enghraifft, ar gyfer profi.
  • Mae'r trydydd llwybr yn cynnwys sawl cam. Yn gyntaf, rhaid creu ymfudiad ar gyfer tablau presennol. Yna mae'n rhaid ei gymhwyso i rai amgylchedd ac felly bydd ei swm hash yn cael ei sicrhau. Y cam nesaf yw cychwyn tablau Liquibase gwag ar ein gweinydd nad yw'n wag, ac yn y tabl gyda hanes y defnydd o setiau newid, gallwch chi roi cofnod â llaw am y set newidiadau “fel pe bai'n cael ei gymhwyso” gyda newidiadau sydd eisoes yn bodoli yn y gronfa ddata . Felly, ar weinydd presennol, bydd y cyfrif hanes yn dechrau o fersiwn 2, a bydd pob amgylchedd newydd yn ymddwyn yn union yr un fath.
    Sut i beidio â saethu eich hun yn y droed gan ddefnyddio Liquibase

Y Sefyllfa 4. Mae ymfudiadau'n mynd yn enfawr ac nid oes ganddynt amser i'w cwblhau

Ar ddechrau datblygiad y gwasanaeth, fel rheol, defnyddir Liquibase fel dibyniaeth allanol, a phrosesir pob mudo pan fydd y cais yn dechrau. Fodd bynnag, dros amser, efallai y byddwch yn baglu ar yr achosion canlynol:

  • Mae mudo yn dod yn enfawr ac yn cymryd amser hir i'w gwblhau.
  • Mae angen mudo mewn amgylcheddau gwasgaredig, er enghraifft, ar sawl achlysur gweinydd cronfa ddata ar yr un pryd.
    Yn yr achos hwn, bydd cymhwyso ymfudiadau am gyfnod rhy hir yn arwain at derfyn amser pan fydd y cais yn dechrau. Yn ogystal, gall cymhwyso ymfudiadau i bob achos cais ar wahân arwain at wahanol weinyddion yn mynd allan o gysoni.

Sut i benderfynu

Mewn achosion o'r fath, mae eich prosiect eisoes yn fawr, efallai hyd yn oed oedolyn, ac mae Liquibase yn dechrau gweithredu fel offeryn allanol ar wahân. Y ffaith yw bod Liquibase fel llyfrgell yn cael ei lunio mewn ffeil jar, a gall weithio fel dibyniaeth o fewn prosiect neu'n annibynnol.

Yn y modd annibynnol, gallwch adael gweithredu mudo i'ch amgylchedd CI / CD neu i ysgwyddau cryf gweinyddwyr eich system ac arbenigwyr lleoli. I wneud hyn bydd angen llinell orchymyn Liquibase https://www.liquibase.org/documentation/command_line.html. Yn y modd hwn, mae'n dod yn bosibl lansio'r cais ar ôl i'r holl fudiadau angenrheidiol gael eu gwneud.

Allbwn

Mewn gwirionedd, gall fod llawer mwy o beryglon wrth weithio gyda mudo cronfeydd data, ac mae llawer ohonynt yn gofyn am ddull creadigol. Mae'n bwysig deall, os ydych chi'n defnyddio'r offeryn yn gywir, y gellir osgoi'r rhan fwyaf o'r peryglon hyn. Yn benodol, roedd yn rhaid i mi ddelio â'r holl broblemau a restrwyd mewn gwahanol ffurfiau, ac roedd rhai ohonynt yn ganlyniad i'm camgymeriadau. Yn bennaf mae hyn yn digwydd, wrth gwrs, oherwydd diffyg sylw, ond weithiau oherwydd anallu troseddol i ddefnyddio'r offeryn.

Ffynhonnell: hab.com

Ychwanegu sylw