Kungsi pernah kajadian, sareng di dieu urang balik deui!
Dina proyék kami salajengna, urang mutuskeun pikeun ngagunakeun Liquibase ti mimiti pikeun ngahindarkeun masalah dina mangsa nu bakal datang. Tétéla, henteu sadaya anggota tim ngora terang kumaha ngagunakeunana leres. Kuring ngayakeun workshop internal, nu lajeng mutuskeun pikeun ngahurungkeun kana artikel.
Tulisan éta kalebet tip anu mangpaat sareng pedaran ngeunaan tilu pitfalls anu paling atra anu anjeun tiasa digolongkeun nalika damel sareng alat migrasi database relational, khususna Liquibase. Dirancang pikeun pamekar Java dina tingkat Junior sareng Tengah; pikeun pamekar anu langkung berpengalaman, éta tiasa dipikaresep pikeun nyusun struktur sareng ngulang naon anu paling dipikaresep parantos dipikanyaho.
Liquibase sareng Flyway mangrupikeun téknologi pesaing utama pikeun ngarengsekeun masalah kontrol versi ngeunaan struktur relasional di dunya Java. Anu kahiji lengkep gratis, dina prakna éta paling sering dipilih pikeun dianggo, naha éta Liquibase dipilih salaku pahlawan publikasi. Nanging, sababaraha prakték anu dijelaskeun tiasa universal, gumantung kana arsitéktur aplikasi anjeun.
Migrasi struktur relational mangrupakeun cara kapaksa nungkulan kalenturan lemah toko data relational. Dina jaman fashion OOP, gaya gawé bareng database hartina urang bakal ngajelaskeun skéma sakali teu noél deui. Tapi kanyataanana sok yén hal robah, sarta parobahan struktur tabel diperlukeun rada mindeng. Alami, prosésna sorangan tiasa nyeri sareng teu pikaresepeun.
Abdi moal langkung lebet kana pedaran téknologi sareng petunjuk pikeun nambihan perpustakaan kana proyék anjeun; sababaraha tulisan anu parantos ditulis dina topik ieu:
Salaku tambahan, parantos aya tulisan anu saé dina topik tip anu mangpaat:
tips
Abdi hoyong bagikeun saran sareng koméntar kuring, anu dilahirkeun ku kesang, getih sareng nyeri pikeun ngarengsekeun masalah hijrah.
1. Sateuacan ngawitan damel, anjeun kedah familiarize diri sareng bagian prakték pangsaéna dina Liquibase
hal basajan tapi pohara penting digambarkeun, tanpa nu ngagunakeun perpustakaan bisa ngahesekeun hirup anjeun. Salaku conto, pendekatan anu henteu terstruktur pikeun ngatur parobihan bakal gancang-gancang ngakibatkeun kabingungan sareng migrasi rusak. Mun anjeun teu gulung kaluar parobahan silih gumantung kana struktur database jeung logika layanan dina waktos anu sareng, aya kamungkinan luhur yén ieu bakal ngakibatkeun tés beureum atawa lingkungan rusak. Salaku tambahan, saran pikeun ngagunakeun Liquibase dina halaman wéb resmi ngandung klausa ngeunaan pamekaran sareng uji skrip rollback sareng skrip migrasi utama. Muhun, dina artikel Aya conto kode ngeunaan migrasi sareng mékanisme rollback.
2. Lamun mimiti ngagunakeun parabot migrasi, teu ngidinan koréksi manual dina struktur database
Salaku nyebutkeun nyebutkeun: "Sakali Persil, salawasna Persil." Upami dasar aplikasi anjeun mimiti dikokolakeun ku Liquibase, perobahan manual naon waé langsung ngakibatkeun kaayaan anu teu konsisten, sareng tingkat kapercayaan kana parobahan janten nol. Poténsi résiko kalebet sababaraha jam nyéépkeun deui pangkalan data; dina skenario anu paling parah, server paéh. Upami Anjeun gaduh hiji "sakola heubeul" DBA Arsiték dina tim anjeun, sabar tur thoughtfully ngajelaskeun ka anjeunna kumaha goréng hal bakal lamun manehna ngan saukur ngédit database nurutkeun pamahaman sorangan ti developer SQL kondisional.
3. Lamun changeset geus kadorong kana Repository, ulah ngédit
Lamun pamekar sejen dijieun tarikan jeung nerapkeun changeset a, nu engké bakal diédit, anjeunna pasti bakal nginget anjeun kalayan kecap alus nalika anjeunna narima kasalahan nalika ngamimitian aplikasi. Upami éditan parobahan kumaha waé bocor kana pamekaran, anjeun kedah nuturkeun lamping hotfix anu leueur. Intina masalah rests on validasi parobahan ku jumlah hash - mékanisme utama Liquibase. Nalika ngédit kodeu robah, jumlah hash robih. Ngédit changesets ngan mungkin lamun kasebut nyaéta dimungkinkeun pikeun nyebarkeun sakabeh database ti scratch tanpa kaleungitan data. Dina hal ieu, refactoring kodeu SQL atawa XML bisa, sabalikna, nyieun hirup leuwih gampang jeung nyieun migrasi leuwih dibaca. Hiji conto bakal kaayaan dimana, dina mimiti aplikasi, skéma tina database sumber ieu sapuk kana dina tim.
4. Geus diverifikasi cadangan database lamun mungkin
Di dieu, Jigana, sagalana jelas. Lamun ujug-ujug migrasi éta gagal, sagalana bisa balik deui. Liquibase boga alat pikeun rolling deui parobahan, tapi naskah rollback ogé ditulis ku pamekar sorangan, jeung maranéhna bisa boga masalah jeung probabiliti sarua salaku Aksara tina changeset utama. Ieu ngandung harti yén éta téh mangpaat pikeun muterkeunana aman jeung cadangan dina sagala hal.
5. Paké kabuktian cadangan database dina ngembangkeun, lamun mungkin
Upami ieu henteu bertentangan sareng kontrak sareng privasi, teu aya data pribadi dina pangkalan data, sareng henteu beuratna saloba dua panonpoé - sateuacan dianggo dina server migrasi langsung, anjeun tiasa pariksa kumaha éta bakal tiasa dianggo dina mesin pamekar sareng ngitung ampir 100% tina masalah poténsial salila migrasi.
6. Komunikasi sareng pamekar séjén dina tim
Dina prosés pangwangunan anu teratur, sadayana dina tim terang saha anu ngalakukeun naon. Dina kanyataanana, ieu téh mindeng teu jadi, ku kituna, lamun Nyiapkeun parobahan struktur database salaku bagian tina tugas anjeun, éta sasaena pikeun tambahan ngabéjaan ka sakabéh tim ngeunaan ieu. Lamun batur nyieun parobahan paralel, Anjeun kudu taliti ngatur. Éta patut komunikasi sareng kolega saatos réngsé padamelan, sanés ngan ukur di awal. Seueur masalah poténsial sareng parobihan tiasa direngsekeun dina tahap ulasan kode.
7. Pikirkeun naon anu anjeun lakukeun!
Ieu bakal sigana nasehat timer dibuktikeun nu manglaku ka situasi naon wae. Nanging, seueur masalah anu tiasa dihindari upami pamekar sakali deui nganalisis naon anu anjeunna laksanakeun sareng naon anu tiasa mangaruhan. Gawe sareng migrasi salawasna merlukeun perhatian tambahan sarta akurasi.
Perangkap
Hayu urang ayeuna ningali bubu has anu anjeun tiasa digolongkeun upami anjeun henteu nuturkeun naséhat di luhur, sareng naon anu kedah anjeun laksanakeun?
Situasi 1: Dua pamekar nyobian nambahkeun parobahan anyar dina waktos anu sareng
Vasya sareng Petya hoyong ngadamel vérsi 4 parobahan, tanpa terang masing-masing. Aranjeunna ngadamel parobihan kana struktur pangkalan data sareng ngaluarkeun pamenta tarik kalayan file parobihan anu béda. Mékanisme tindakan ieu diusulkeun:
Kumaha mutuskeun
- Kumaha bae, kolega kudu satuju dina urutan nu robah maranéhanana kudu indit, contona, Petin kudu dilarapkeun munggaran.
- Aya anu kedah nambihan anu kadua pikeun dirina sareng cirian parobihan Vasya kalayan versi 5. Ieu tiasa dilakukeun ku Cherry Pick atanapi gabungan anu rapih.
- Saatos parobihan, anjeun pasti kedah pariksa validitas tindakan anu dilakukeun.
Kanyataanna, mékanisme Liquibase bakal ngidinan Anjeun pikeun mibanda dua versi 4 changesets dina gudang, jadi Anjeun bisa ninggalkeun sagalana sakumaha anu kasebut. Nyaéta, anjeun ngan saukur bakal gaduh dua parobihan kana versi 4 kalayan nami anu béda. Kalayan pendekatan ieu, engké janten sesah pisan pikeun napigasi versi database.
Salaku tambahan, Liquibase, sapertos bumi hobbit, ngajaga seueur rahasia. Salah sahijina nyaéta konci validCheckSum, anu muncul dina versi 1.7 sareng ngamungkinkeun anjeun pikeun nangtukeun nilai hash anu sah pikeun set parobihan khusus, henteu paduli naon anu disimpen dina pangkalan data. Dokuméntasi nyebutkeun kieu:
Tambahkeun checksum anu dianggap valid pikeun changeSet ieu, paduli naon anu disimpen dina database. Dipaké utamina nalika anjeun kedah ngarobih changeSet sareng henteu hoyong kasalahan dialungkeun dina pangkalan data anu parantos dijalankeun (sanés prosedur anu disarankeun)
Leres, enya, prosedur ieu henteu disarankeun. Tapi kadang pesulap cahaya anu kuat ogé ngawasaan téknik poék
Situasi 2: Migrasi anu gumantung kana data
Hayu urang anggap anjeun teu boga kamampuhan pikeun ngagunakeun cadangan database ti server live. Petya nyiptakeun changeset, nguji éta sacara lokal sareng, kalayan kayakinan pinuh yén anjeunna leres, ngadamel pamundut tarik ka pamekar. Ngan bisi, kalungguhan proyék netelakeun naha Petya geus dipariksa deui, lajeng ditambahkeun. Tapi deployment dina server ngembangkeun murag.
Nyatana, ieu mungkin, sareng teu aya anu kebal tina ieu. Ieu kajadian lamun modifikasi kana struktur tabel kumaha bae dihijikeun ka data husus tina database. Jelas, upami pangkalan data Petya dieusi ngan ukur ku data tés, maka éta moal nutupan sadaya kasus masalah. Contona, nalika mupus hiji méja, tétéla yén aya rékaman dina tabel séjén ku Key Asing nu patali jeung rékaman dina hiji keur dihapus. Atanapi nalika ngarobih jinis kolom, tétéla henteu 100% data tiasa dirobih kana jinis énggal.
Kumaha mutuskeun
- Tulis skrip khusus anu bakal dianggo sakali sareng migrasi sareng bawa data kana bentuk anu leres. Ieu cara umum pikeun ngajawab masalah nransferkeun data kana struktur anyar sanggeus nerapkeun migrasi, tapi hal sarupa bisa dilarapkeun sateuacan, dina kasus husus. Jalur ieu, tangtosna, henteu salawasna sayogi, sabab ngédit data dina server langsung tiasa bahaya sareng malah ngarusak.
- Cara anu sesah sanésna nyaéta ngédit set parobihan anu tos aya. Kasusahna nyaéta yén sadaya pangkalan data anu parantos diterapkeun dina bentuk anu tos aya kedah dibalikeun deui. Ieu rada mungkin yen sakabeh tim backend bakal kapaksa lokal gulung kaluar database ti scratch.
- Sareng cara anu paling universal nyaéta nransferkeun masalah sareng data ka lingkungan pamekar, nyiptakeun deui kaayaan anu sami sareng nambihan set énggal, ka anu rusak, anu bakal ngaleungitkeun masalah.
Sacara umum, beuki database sarua dina komposisi jeung database server produksi, nu kirang kasempetan nu masalah sareng migrasi bakal balik jauh. Sareng, tangtosna, sateuacan ngirim parobihan kana gudang, anjeun kedah mikir sababaraha kali naha éta bakal ngarusak nanaon.
Situasi 3. Liquibase mimiti dipaké sanggeus eta mana kana produksi
Anggap pimpinan tim naroskeun Petya ngalebetkeun Liquibase dina proyék éta, tapi proyék éta parantos aya dina produksi sareng aya struktur database anu tos aya.
Sasuai, masalahna nyaeta dina sagala server anyar atawa mesin pamekar, tabel ieu kudu recreated ti scratch, jeung lingkungan nu aya kudu tetep dina kaayaan konsisten, siap nampa parobahan anyar.
Kumaha mutuskeun
Aya ogé sababaraha cara:
- Anu kahiji sareng anu paling atra nyaéta gaduh skrip anu misah anu kedah diterapkeun sacara manual nalika ngamimitian lingkungan énggal.
- Anu kadua kirang écés, gaduh migrasi Liquibase anu aya dina Konteks Liquibase anu sanés, sareng nerapkeunana. Anjeun tiasa maca langkung seueur ngeunaan Konteks Liquibase di dieu: . Sacara umum, ieu téh mékanisme metot nu bisa hasil dipaké, contona, pikeun nguji.
- Jalur katilu diwangun ku sababaraha léngkah. Kahiji, migrasi kudu dijieun pikeun tabel aya. Lajeng eta kudu dilarapkeun ka sababaraha lingkungan sahingga jumlah hash na bakal diala. Lengkah saterusna nyaéta pikeun ngamimitian tabel Liquibase kosong dina server non-kosong urang, sarta dina tabel kalawan sajarah pamakean parobahan, anjeun tiasa sacara manual nyimpen catetan ngeunaan "saolah-olah dilarapkeun" changeset kalawan parobahan geus aya dina database. . Janten, dina server anu tos aya, undur sajarah bakal ngamimitian ti versi 2, sareng sadaya lingkungan énggal bakal kalakuanana idéntik.
Situasi 4. Migrasi jadi badag sarta teu boga waktu pikeun ngalengkepan
Dina awal ngembangkeun jasa, sakumaha aturan, Liquibase dipaké salaku kagumantungan éksternal, sarta sakabeh migrasi diolah nalika aplikasi dimimitian. Nanging, kana waktosna, anjeun tiasa mendakan kasus-kasus di handap ieu:
- Migrasi janten ageung sareng peryogi waktos kanggo réngsé.
- Aya anu peryogi pikeun migrasi dina lingkungan disebarkeun, contona, dina sababaraha instansi server database sakaligus.
Dina hal ieu, nerapkeun migrasi anu lami teuing bakal nyababkeun waktos béak nalika aplikasi dimimitian. Salaku tambahan, nerapkeun migrasi ka unggal conto aplikasi sacara misah tiasa nyababkeun server anu béda teu sinkron.
Kumaha mutuskeun
Dina kasus kawas, proyék anjeun geus badag, malah meureun sawawa, sarta Liquibase mimiti meta salaku alat éksternal misah. Kanyataanna nyaéta Liquibase salaku perpustakaan disusun kana file jar, sareng tiasa dianggo salaku kagumantungan dina proyék atanapi mandiri.
Dina modeu mandiri, anjeun tiasa ngantepkeun palaksanaan migrasi ka lingkungan CI/CD anjeun atanapi kana taktak kuat pangurus sistem sareng spesialis deployment anjeun. Jang ngalampahkeun ieu anjeun bakal peryogi garis paréntah Liquibase . Dina modeu ieu, anjeun tiasa ngaluncurkeun aplikasi saatos sadaya migrasi anu diperyogikeun parantos dilaksanakeun.
kacindekan
Kanyataanna, tiasa aya seueur deui pitfalls nalika damel sareng migrasi database, sareng seueur di antarana anu peryogi pendekatan kreatif. Kadé ngartos yen lamun ngagunakeun alat nu bener, lolobana pitfalls ieu bisa dihindari. Husus, kuring kungsi nungkulan sagala masalah didaptarkeun dina bentuk béda, sarta sawatara di antarana éta hasil tina kasalahan kuring. Lolobana ieu kajadian, tangtosna, alatan inattention, tapi kadang alatan henteu mampuh kriminal ngagunakeun alat.
sumber: www.habr.com