Hindi pa nangyari noon, at heto na naman!
Sa aming susunod na proyekto, nagpasya kaming gamitin ang Liquibase sa simula pa lamang upang maiwasan ang mga problema sa hinaharap. Sa lumalabas, hindi lahat ng kabataang miyembro ng koponan ay alam kung paano ito gamitin nang tama. Nagdaos ako ng panloob na workshop, na pagkatapos ay nagpasya akong maging isang artikulo.
Kasama sa artikulo ang mga kapaki-pakinabang na tip at isang paglalarawan ng tatlong pinaka-halatang pitfalls na maaari mong mahulog kapag nagtatrabaho sa mga tool sa paglilipat ng relational database, sa partikular na Liquibase. Idinisenyo para sa mga developer ng Java sa Junior at Middle na antas; para sa mga mas may karanasang developer, maaaring interesado ito para sa pag-istruktura at pag-uulit ng malamang na alam na.
Ang Liquibase at Flyway ay ang pangunahing nakikipagkumpitensyang teknolohiya para sa paglutas ng mga problema sa pagkontrol ng bersyon ng mga istrukturang may kaugnayan sa mundo ng Java. Ang una ay ganap na libre, sa pagsasagawa ito ay madalas na pinili para sa paggamit, na ang dahilan kung bakit napili ang Liquibase bilang bayani ng publikasyon. Gayunpaman, ang ilan sa mga kasanayang inilarawan ay maaaring pangkalahatan, depende sa iyong arkitektura ng application.
Ang mga paglipat ng mga istrukturang may kaugnayan ay isang sapilitang paraan upang harapin ang mahinang flexibility ng mga tindahan ng relational na data. Sa panahon ng OOP fashion, ang istilo ng pagtatrabaho sa mga database ay nangangahulugang ilalarawan namin ang schema nang isang beses at hindi na ito muling hawakan. Ngunit ang katotohanan ay palaging nagbabago ang mga bagay, at ang mga pagbabago sa istraktura ng talahanayan ay kinakailangan nang madalas. Naturally, ang proseso mismo ay maaaring masakit at hindi kasiya-siya.
Hindi na ako lalalim sa paglalarawan ng teknolohiya at mga tagubilin para sa pagdaragdag ng library sa iyong proyekto; medyo ilang artikulo na ang naisulat sa paksang ito:
Bilang karagdagan, mayroon nang isang mahusay na artikulo sa paksa ng mga kapaki-pakinabang na tip:
Π‘ΠΎΠ²Π΅ΡΡ
Gusto kong ibahagi ang aking mga payo at komento, na ipinanganak sa pamamagitan ng pawis, dugo at sakit ng paglutas ng mga problema sa migration.
1. Bago simulan ang trabaho, dapat mong maging pamilyar sa seksyon ng pinakamahuhusay na kagawian sa Liquibase
ang mga simple ngunit napakahalagang bagay ay inilarawan, kung wala ang paggamit ng aklatan ay maaaring makapagpalubha sa iyong buhay. Halimbawa, ang isang hindi nakabalangkas na diskarte sa pamamahala ng mga pagbabago ay maaga o huli ay hahantong sa pagkalito at sirang paglilipat. Kung hindi ka maglalabas ng magkasabay na mga pagbabago sa istruktura ng database at lohika ng serbisyo, malaki ang posibilidad na hahantong ito sa mga pulang pagsubok o isang sirang kapaligiran. Bilang karagdagan, ang mga rekomendasyon para sa paggamit ng Liquibase sa opisyal na website ay naglalaman ng sugnay tungkol sa pagbuo at pagsubok ng mga rollback na script kasama ang mga pangunahing migration script. Well, sa artikulo Mayroong mga halimbawa ng code tungkol sa mga paglilipat at mekanismo ng rollback.
2. Kung nagsimula kang gumamit ng mga tool sa paglipat, huwag payagan ang mga manu-manong pagwawasto sa istraktura ng database
Sabi nga sa kasabihan: "Once Persil, always Persil." Kung ang base ng iyong aplikasyon ay magsisimulang pangasiwaan ng Liquibase, ang anumang mga manu-manong pagbabago ay agad na humahantong sa isang hindi pare-parehong estado, at ang antas ng tiwala sa mga changeset ay magiging zero. Kabilang sa mga potensyal na panganib ang ilang oras na ginugol sa pagpapanumbalik ng database; sa pinakamasamang sitwasyon, isang patay na server. Kung mayroon kang isang "old school" na Arkitekto ng DBA sa iyong koponan, matiyaga at maingat na ipaliwanag sa kanya kung gaano kasama ang mga mangyayari kung i-edit lang niya ang database ayon sa kanyang sariling pang-unawa mula sa isang conditional SQL Developer.
3. Kung ang changeset ay nai-push na sa repository, iwasan ang pag-edit
Kung ang isa pang developer ay gumawa ng isang pull at naglapat ng isang changeset, na kung saan ay i-edit sa ibang pagkakataon, tiyak na maaalala ka niya sa isang mabait na salita kapag nakatanggap siya ng isang error kapag sinimulan ang application. Kung ang pag-edit sa changeset sa anumang paraan ay tumagas sa pag-unlad, kakailanganin mong sundin ang madulas na slope ng mga hotfix. Ang kakanyahan ng problema ay nakasalalay sa pagpapatunay ng mga pagbabago sa pamamagitan ng hash sum - ang pangunahing mekanismo ng Liquibase. Kapag nag-e-edit ng changeset code, nagbabago ang halaga ng hash. Ang pag-edit ng mga pagbabago ay posible lamang kapag posible na i-deploy ang buong database mula sa simula nang hindi nawawala ang data. Sa kasong ito, ang refactoring ng SQL o XML code ay maaaring, sa kabaligtaran, gawing mas madali ang buhay at gawing mas nababasa ang mga paglilipat. Ang isang halimbawa ay isang sitwasyon kung saan, sa simula ng application, ang schema ng source database ay napagkasunduan sa loob ng team.
4. Magkaroon ng na-verify na mga backup ng database kung maaari
Dito, sa tingin ko, malinaw na ang lahat. Kung biglang hindi nagtagumpay ang paglipat, ang lahat ay maibabalik. Ang Liquibase ay may tool para sa pagbabalik ng mga pagbabago, ngunit ang mga rollback na script ay isinulat din ng developer mismo, at maaari silang magkaroon ng mga problema sa parehong posibilidad ng mga script ng pangunahing changeset. Nangangahulugan ito na kapaki-pakinabang na i-play ito nang ligtas sa mga backup sa anumang kaso.
5. Gumamit ng mga napatunayang backup ng database sa pagbuo, kung maaari
Kung hindi ito sumasalungat sa mga kontrata at privacy, walang personal na data sa database, at hindi ito tumitimbang ng hanggang dalawang araw - bago ito gamitin sa mga live na migration server, maaari mong suriin kung paano ito gagana sa makina ng developer at kalkulahin halos 100% ng mga potensyal na problema sa panahon ng paglipat.
6. Makipag-ugnayan sa ibang mga developer sa team
Sa isang maayos na proseso ng pag-unlad, alam ng lahat sa pangkat kung sino ang gumagawa ng ano. Sa katotohanan, madalas na hindi ito ang kaso, samakatuwid, kung naghahanda ka ng mga pagbabago sa istraktura ng database bilang bahagi ng iyong gawain, ipinapayong ipaalam din ito sa buong koponan. Kung ang isang tao ay gumagawa ng mga pagbabago nang magkatulad, dapat mong ayusin nang mabuti. Ito ay nagkakahalaga ng pakikipag-usap sa mga kasamahan pagkatapos ng trabaho, hindi lamang sa simula. Maraming potensyal na problema sa mga changeset ang maaaring malutas sa yugto ng pagsusuri ng code.
7. Pag-isipan kung ano ang iyong ginagawa!
Ito ay tila maliwanag na payo na naaangkop sa anumang sitwasyon. Gayunpaman, maraming problema ang maaaring naiwasan kung muling sinuri ng developer kung ano ang kanyang ginagawa at kung ano ang maaaring maapektuhan nito. Ang pagtatrabaho sa mga paglilipat ay palaging nangangailangan ng karagdagang pansin at katumpakan.
Mga bitag
Tingnan natin ngayon ang mga tipikal na bitag na maaari mong mahulog kung hindi mo susundin ang payo sa itaas, at ano, eksakto, ang dapat mong gawin?
Sitwasyon 1: Sinusubukan ng dalawang developer na magdagdag ng mga bagong pagbabago sa parehong oras
Nais ni Vasya at Petya na lumikha ng isang changeset na bersyon 4, nang hindi alam ang tungkol sa isa't isa. Gumawa sila ng mga pagbabago sa istraktura ng database at nagbigay ng pull request na may iba't ibang mga changeset file. Ang sumusunod na mekanismo ng pagkilos ay iminungkahi:
Paano magdesisyon
- Kahit papaano, dapat sumang-ayon ang mga kasamahan sa pagkakasunud-sunod kung saan dapat pumunta ang kanilang mga pagbabago, halimbawa, dapat munang ilapat ang Petin.
- Dapat idagdag ng isang tao ang pangalawa sa kanilang sarili at markahan ang changeset ni Vasya na may bersyon 5. Magagawa ito sa pamamagitan ng Cherry Pick o isang maayos na pagsasama.
- Pagkatapos ng mga pagbabago, dapat mong tiyak na suriin ang bisa ng mga pagkilos na ginawa.
Sa katunayan, ang mga mekanismo ng Liquibase ay magbibigay-daan sa iyo na magkaroon ng dalawang bersyon 4 na mga pagbabago sa repositoryo, upang maaari mong iwanan ang lahat ng bagay. Ibig sabihin, magkakaroon ka lang ng dalawang pagbabago sa bersyon 4 na may magkakaibang pangalan. Sa diskarteng ito, magiging napakahirap sa paglaon na mag-navigate sa mga bersyon ng database.
Bilang karagdagan, ang Liquibase, tulad ng tahanan ng mga hobbit, ay nagpapanatili ng maraming lihim. Ang isa sa mga ito ay ang validCheckSum key, na lumabas sa bersyon 1.7 at nagbibigay-daan sa iyong tumukoy ng wastong hash value para sa isang partikular na changeset, anuman ang nakaimbak sa database. Dokumentasyon sabi ng sumusunod:
Magdagdag ng checksum na itinuturing na wasto para sa changeSet na ito, anuman ang nakaimbak sa database. Pangunahing ginagamit kapag kailangan mong baguhin ang isang changeSet at ayaw mong magkaroon ng mga error sa mga database kung saan ito ay tumakbo na (hindi isang inirerekomendang pamamaraan)
Oo, oo, ang pamamaraang ito ay hindi inirerekomenda. Ngunit kung minsan ang isang malakas na light magician ay nakakabisa rin ng mga dark technique
Sitwasyon 2: Migration na nakadepende sa data
Ipagpalagay natin na wala kang kakayahang gumamit ng mga backup ng database mula sa mga live na server. Gumawa si Petya ng changeset, sinubukan ito nang lokal at, nang buong kumpiyansa na tama siya, gumawa ng pull request sa developer. Kung sakali, nilinaw ng pinuno ng proyekto kung nasuri ito ni Petya, at pagkatapos ay idinagdag ito. Ngunit nahulog ang deployment sa development server.
Sa katunayan, ito ay posible, at walang sinuman ang immune mula dito. Nangyayari ito kung ang mga pagbabago sa istraktura ng talahanayan ay nakatali sa partikular na data mula sa database. Malinaw, kung ang database ng Petya ay napuno lamang ng data ng pagsubok, kung gayon maaaring hindi nito saklawin ang lahat ng mga kaso ng problema. Halimbawa, kapag nagde-delete ng table, lumalabas na may mga record sa ibang table ng Foreign Key na nauugnay sa mga record sa tinatanggal. O kapag nagpapalit ng uri ng column, lumalabas na hindi 100% ng data ang maaaring ma-convert sa bagong uri.
Paano magdesisyon
- Sumulat ng mga espesyal na script na gagamitin nang isang beses kasama ng paglipat at dalhin ang data sa tamang form. Ito ay isang pangkalahatang paraan upang malutas ang problema ng paglilipat ng data sa mga bagong istruktura pagkatapos mag-apply ng mga paglilipat, ngunit ang isang bagay na katulad ay maaaring ilapat bago, sa mga espesyal na kaso. Ang landas na ito, siyempre, ay hindi palaging magagamit, dahil ang pag-edit ng data sa mga live na server ay maaaring mapanganib at maging mapanira.
- Ang isa pang mahirap na paraan ay ang pag-edit ng isang umiiral na changeset. Ang kahirapan ay ang lahat ng mga database kung saan ito nailapat na sa dati nitong anyo ay kailangang ibalik. Ito ay lubos na posible na ang buong backend team ay mapipilitang lokal na ilunsad ang database mula sa simula.
- At ang pinaka-unibersal na paraan ay ang ilipat ang problema sa data sa kapaligiran ng developer, muling likhain ang parehong sitwasyon at magdagdag ng bagong changeset, sa sira, na maiiwasan ang problema.
Sa pangkalahatan, mas magkapareho ang database sa komposisyon sa database ng production server, mas maliit ang pagkakataon na malayo ang mararating ng mga problema sa paglilipat. At, siyempre, bago ka magpadala ng changeset sa repository, dapat mong isipin nang maraming beses kung ito ay masira ang anumang bagay.
Sitwasyon 3. Nagsisimulang gamitin ang Liquibase matapos itong maging produksyon
Ipagpalagay na ang pinuno ng koponan ay humiling kay Petya na isama ang Liquibase sa proyekto, ngunit ang proyekto ay nasa produksyon na at mayroong isang umiiral na istraktura ng database.
Alinsunod dito, ang problema ay na sa anumang mga bagong server o developer machine, ang mga talahanayan na ito ay dapat na muling likhain mula sa simula, at ang umiiral na kapaligiran ay dapat manatili sa isang pare-parehong estado, handang tumanggap ng mga bagong pagbabago.
Paano magdesisyon
Mayroon ding ilang mga paraan:
- Ang una at pinaka-halata ay ang pagkakaroon ng isang hiwalay na script na dapat ilapat nang manu-mano kapag nagpasimula ng isang bagong kapaligiran.
- Ang pangalawa ay hindi gaanong halata, magkaroon ng Liquibase migration na nasa ibang Liquibase Context, at ilapat ito. Maaari kang magbasa nang higit pa tungkol sa Liquibase Context dito: . Sa pangkalahatan, ito ay isang kawili-wiling mekanismo na maaaring matagumpay na magamit, halimbawa, para sa pagsubok.
- Ang ikatlong landas ay binubuo ng ilang mga hakbang. Una, dapat gumawa ng paglipat para sa mga kasalukuyang talahanayan. Pagkatapos ay dapat itong ilapat sa ilang kapaligiran at sa gayon ay makukuha ang hash sum nito. Ang susunod na hakbang ay ang pagsisimula ng mga walang laman na talahanayan ng Liquibase sa aming hindi walang laman na server, at sa talahanayan na may kasaysayan ng paggamit ng mga changeset, maaari kang manu-manong maglagay ng tala tungkol sa "parang inilapat" na changeset na may mga pagbabago na mayroon na sa database . Kaya, sa isang umiiral na server, ang history countdown ay magsisimula mula sa bersyon 2, at lahat ng mga bagong environment ay magiging magkapareho.
Sitwasyon 4. Nagiging napakalaki ang mga migrasyon at walang oras upang makumpleto
Sa simula ng pagbuo ng serbisyo, bilang panuntunan, ginagamit ang Liquibase bilang isang panlabas na dependency, at ang lahat ng paglilipat ay pinoproseso kapag nagsimula ang aplikasyon. Gayunpaman, sa paglipas ng panahon, maaari kang madapa sa mga sumusunod na kaso:
- Ang mga migrasyon ay nagiging napakalaki at tumatagal ng mahabang panahon upang makumpleto.
- May pangangailangan para sa paglipat sa mga distributed na kapaligiran, halimbawa, sa ilang mga pagkakataon ng database server nang sabay-sabay.
Sa kasong ito, ang paglalapat ng mga paglilipat nang masyadong mahaba ay magreresulta sa isang timeout kapag nagsimula ang aplikasyon. Bukod pa rito, ang paglalapat ng mga paglilipat sa bawat instance ng application nang hiwalay ay maaaring magresulta sa iba't ibang mga server na hindi naka-sync.
Paano magdesisyon
Sa ganitong mga kaso, ang iyong proyekto ay malaki na, marahil ay isang pang-adulto, at ang Liquibase ay nagsisimulang kumilos bilang isang hiwalay na panlabas na tool. Ang katotohanan ay ang Liquibase bilang isang library ay pinagsama-sama sa isang jar file, at maaaring gumana bilang isang dependency sa loob ng isang proyekto o nang nakapag-iisa.
Sa standalone mode, maaari mong ipaubaya ang pagpapatupad ng mga paglilipat sa iyong CI/CD environment o sa matibay na balikat ng iyong mga system administrator at deployment specialist. Upang gawin ito kakailanganin mo ang Liquibase command line . Sa mode na ito, nagiging posible na ilunsad ang application pagkatapos maisagawa ang lahat ng kinakailangang paglilipat.
Pagbubuhos
Sa katunayan, maaaring magkaroon ng marami pang mga pitfalls kapag nagtatrabaho sa mga paglilipat ng database, at marami sa mga ito ay nangangailangan ng isang malikhaing diskarte. Mahalagang maunawaan na kung gagamitin mo nang tama ang tool, maiiwasan ang karamihan sa mga pitfalls na ito. Sa partikular, kinailangan kong harapin ang lahat ng nakalistang problema sa iba't ibang anyo, at ang ilan sa mga ito ay resulta ng aking mga pagkakamali. Kadalasan nangyayari ito, siyempre, dahil sa kawalan ng pansin, ngunit kung minsan dahil sa kawalan ng kakayahan ng kriminal na gamitin ang tool.
Pinagmulan: www.habr.com