Ora tau kedaden sadurunge, lan kene maneh!
Ing proyek sabanjure, kita mutusake nggunakake Liquibase saka wiwitan supaya ora ana masalah ing mangsa ngarep. Ternyata, ora kabeh anggota tim enom ngerti carane nggunakake kanthi bener. Aku nganakake lokakarya internal, banjur aku mutusake kanggo ngowahi dadi artikel.
Artikel kasebut kalebu tips sing migunani lan katrangan babagan telung pitfalls sing paling jelas sing bisa sampeyan lakoni nalika nggarap alat migrasi database relasional, utamane Liquibase. Dirancang kanggo pangembang Jawa ing tingkat Junior lan Menengah; kanggo pangembang sing luwih berpengalaman, bisa uga narik kawigaten kanggo nyusun struktur lan mbaleni apa sing wis dingerteni.
Liquibase lan Flyway minangka teknologi saingan utama kanggo ngrampungake masalah kontrol versi struktur relasional ing jagad Jawa. Sing pisanan pancen gratis, ing praktik kasebut paling asring dipilih kanggo digunakake, mula Liquibase dipilih minangka pahlawan publikasi. Nanging, sawetara praktik sing diterangake bisa uga universal, gumantung saka arsitektur aplikasi sampeyan.
Migrasi struktur relasional minangka cara sing dipeksa kanggo ngatasi keluwesan panyimpenan data relasional sing lemah. Ing jaman mode OOP, gaya nggarap database tegese kita bakal njlèntrèhaké skema sapisan lan ora ndemek maneh. Nanging kasunyatane tansah owah-owahan, lan owah-owahan ing struktur meja dibutuhake asring. Alami, proses kasebut bisa nglarani lan ora nyenengake.
Aku ora bakal luwih jero babagan katrangan babagan teknologi lan instruksi kanggo nambah perpustakaan menyang proyek sampeyan; sawetara artikel wis ditulis babagan topik iki:
Kajaba iku, wis ana artikel sing apik babagan topik tips sing migunani:
Tip
Aku pengin nuduhake saran lan komentar, sing lair liwat kringet, getih lan nyeri kanggo ngrampungake masalah karo migrasi.
1. Sadurunge miwiti karya, sampeyan kudu familiarize dhewe karo bagean laku paling apik ing Liquibase
prasaja nanging penting banget diterangake, tanpa nggunakake perpustakaan bisa complicate urip. Contone, pendekatan sing ora terstruktur kanggo ngatur owah-owahan bakal cepet utawa mengko nyebabake kebingungan lan migrasi sing rusak. Yen sampeyan ora muter owah-owahan bebarengan gumantung ing struktur database lan logika layanan ing wektu sing padha, ana kemungkinan dhuwur sing iki bakal mimpin kanggo tes abang utawa lingkungan rusak. Kajaba iku, rekomendasi kanggo nggunakake Liquibase ing situs web resmi ngemot klausa babagan pangembangan lan uji coba skrip rollback bebarengan karo skrip migrasi utama. Inggih, ing artikel Ana conto kode babagan migrasi lan mekanisme rollback.
2. Yen sampeyan miwiti nggunakake alat migrasi, aja ngidini koreksi manual ing struktur database
Kaya sing diarani: "Once Persil, always Persil." Yen basis aplikasi sampeyan wiwit dikelola dening Liquibase, owah-owahan manual apa wae langsung nyebabake kahanan sing ora konsisten, lan tingkat kepercayaan ing owah-owahan dadi nol. Potensi risiko kalebu sawetara jam kanggo mulihake database; ing skenario paling awon, server mati. Yen sampeyan duwe Arsitek DBA "sekolah lawas" ing tim sampeyan, kanthi sabar lan temen-temen nerangake marang dheweke kepiye kedadeyan sing ala yen dheweke mung nyunting database miturut pangerten dhewe saka Pangembang SQL sing kondisional.
3. Yen changeset wis di-push menyang repositori, supaya editing
Yen pangembang liyane digawe narik lan Applied changeset, kang mengko bakal diowahi, mesthi bakal ngelingi sampeyan karo tembung apik nalika nampa kesalahan nalika miwiti aplikasi. Yen nyunting changeset piye wae bocor menyang pembangunan, sampeyan kudu ngetutake slope hotfix sing lunyu. Inti masalah kasebut ana ing validasi owah-owahan kanthi jumlah hash - mekanisme utama Liquibase. Nalika nyunting kode changeset, jumlah hash diganti. Ngowahi pangowahan mung bisa ditindakake nalika bisa nyebarake kabeh database saka awal tanpa kelangan data. Ing kasus iki, refactoring kode SQL utawa XML bisa, ing nalisir, nggawe urip luwih gampang lan nggawe migrasi luwih bisa diwaca. Conto bakal dadi kahanan ing ngendi, ing wiwitan aplikasi, skema basis data sumber disepakati ing tim.
4. Wis diverifikasi serep database yen bisa
Ing kene, aku mikir, kabeh wis jelas. Yen dumadakan migrasi ora kasil, kabeh bisa bali maneh. Liquibase wis alat kanggo muter maneh owah-owahan, nanging Tulisan rollback uga ditulis dening pangembang piyambak, lan padha bisa duwe masalah karo kemungkinan padha karo Tulisan saka changeset utama. Iki tegese iku migunani kanggo muter aman karo serep ing kasus.
5. Gunakake serep database buktiaken ing pembangunan, yen bisa
Yen iki ora mbantah kontrak lan privasi, ora ana data pribadhi ing basis data, lan ora bobote nganti rong srengenge - sadurunge nggunakake ing server migrasi langsung, sampeyan bisa mriksa cara kerjane ing mesin pangembang lan ngitung meh 100% masalah potensial nalika migrasi.
6. Komunikasi karo pangembang liyane ing tim
Ing proses pangembangan sing wis diatur kanthi apik, kabeh wong ing tim ngerti sapa sing nindakake apa. Ing kasunyatan, iki asring ora kedadeyan, mula, yen sampeyan lagi nyiapake owah-owahan ing struktur database minangka bagean saka tugas sampeyan, luwih becik menehi kabar marang kabeh tim babagan iki. Yen ana wong sing nggawe owah-owahan kanthi podo karo, sampeyan kudu ngatur kanthi ati-ati. Iku worth komunikasi karo kolega sawise rampung karya, ora mung ing wiwitan. Akeh masalah potensial karo owah-owahan bisa ditanggulangi ing tahap review kode.
7. Gatekna apa sing kok lakoni!
Iku bakal katon kaya saran sing bisa ditrapake kanggo kahanan apa wae. Nanging, akeh masalah sing bisa dihindari yen pangembang maneh nganalisa apa sing ditindakake lan apa sing bisa ditindakake. Nggarap migrasi tansah mbutuhake perhatian lan akurasi tambahan.
Perangkap
Ayo saiki ndeleng jebakan khas sing bisa sampeyan tindakake yen sampeyan ora ngetutake saran ing ndhuwur, lan apa sing kudu sampeyan lakoni?
Kahanan 1: Loro pangembang nyoba nambah owah-owahan anyar ing wektu sing padha
Vasya lan Petya pengin nggawe changeset versi 4, tanpa ngerti saben liyane. Dheweke nggawe owah-owahan ing struktur database lan ngetokake panjaluk tarik karo file changeset sing beda. Mekanisme tumindak ing ngisor iki diusulake:
Carane ngatasi
- Piye wae, kolega kudu setuju karo urutan owah-owahan sing kudu ditindakake, umpamane, Petin kudu ditrapake dhisik.
- Wong kudu nambah sing nomer loro kanggo awake dhewe lan menehi tandha owah-owahan Vasya kanthi versi 5. Iki bisa ditindakake liwat Cherry Pick utawa gabungan sing rapi.
- Sawise owah-owahan, sampeyan kudu mriksa kesahihan tumindak sing ditindakake.
Nyatane, mekanisme Liquibase bakal ngidini sampeyan duwe rong versi 4 owah-owahan ing gudang, supaya sampeyan bisa ninggalake kabeh. Yaiku, sampeyan mung bakal duwe rong owah-owahan ing versi 4 kanthi jeneng sing beda. Kanthi pendekatan iki, mengko dadi angel banget kanggo navigasi versi database.
Kajaba iku, Liquibase, kaya omah hobbit, nyimpen akeh rahasia. Salah sijine yaiku kunci validCheckSum, sing katon ing versi 1.7 lan ngidini sampeyan nemtokake nilai hash sing bener kanggo set pangowahan tartamtu, preduli saka apa sing disimpen ing database. Dokumentasi ngandika ing ngisor iki:
Tambah checksum sing dianggep bener kanggo changeSet iki, preduli saka apa sing disimpen ing database. Digunakake utamane nalika sampeyan kudu ngganti changeSet lan ora pengin kesalahan dibuwang ing database sing wis ditindakake (dudu prosedur sing disaranake)
Ya, ya, prosedur iki ora dianjurake. Nanging kadhangkala pesulap cahya sing kuwat uga nguwasani teknik peteng
Kahanan 2: Migrasi sing gumantung saka data
Ayo nganggep sampeyan ora duwe kemampuan kanggo nggunakake serep database saka server urip. Petya nggawe changeset, dites sacara lokal lan, kanthi yakin manawa dheweke bener, nggawe panjaluk tarik menyang pangembang. Yen ngono, pimpinan proyek njlentrehake manawa Petya wis mriksa, banjur ditambahake. Nanging penyebaran ing server pangembangan ambruk.
Nyatane, iki bisa ditindakake, lan ora ana sing kebal saka iki. Iki kedadeyan yen modifikasi struktur tabel disambungake karo data tartamtu saka database. Temenan, yen database Petya mung diisi karo data tes, mula bisa uga ora nutupi kabeh kasus masalah. Contone, nalika mbusak tabel, dadi metu sing ana cathetan ing tabel liyane dening Foreign Key sing ana hubungane karo cathetan ing siji dibusak. Utawa nalika ngganti jinis kolom, ternyata ora 100% data bisa diowahi dadi jinis anyar.
Carane ngatasi
- Tulis skrip khusus sing bakal digunakake bebarengan karo migrasi lan nggawa data menyang wangun sing tepat. Iki minangka cara umum kanggo ngatasi masalah nransfer data menyang struktur anyar sawise nglamar migrasi, nanging sing padha bisa ditrapake sadurunge, ing kasus khusus. Path iki, mesthi, ora tansah kasedhiya, amarga data nyunting ing server urip bisa mbebayani lan malah ngrusak.
- Cara liya sing angel yaiku ngowahi set pangowahan sing wis ana. Kangelan iku kabeh database ngendi iku wis Applied ing wangun sing wis ana kudu dibalèkaké. Sampeyan bisa uga yen kabeh tim backend bakal dipeksa kanggo muter database lokal saka awal.
- Lan cara sing paling universal yaiku nransfer masalah karo data menyang lingkungan pangembang, nggawe maneh kahanan sing padha lan nambah set pangowahan anyar, menyang sing rusak, sing bakal ngatasi masalah kasebut.
UmumΓ©, luwih akeh basis data sing padha karo komposisi database server produksi, luwih cilik kemungkinan masalah karo migrasi bakal adoh. Lan, mesthine, sadurunge ngirim changeset menyang repositori, sampeyan kudu mikir kaping pirang-pirang apa bakal ngrusak apa wae.
Kahanan 3. Liquibase wiwit digunakake sawise dadi produksi
Upamane pimpinan tim njaluk Petya nyakup Liquibase ing proyek kasebut, nanging proyek kasebut wis ana ing produksi lan ana struktur database sing wis ana.
Patut, masalah iku ing sembarang server anyar utawa mesin pangembang, tabel iki kudu recreated saka ngeruk, lan lingkungan ana kudu tetep ing negara konsisten, siap kanggo nampa changesets anyar.
Carane ngatasi
Ana uga sawetara cara:
- Pisanan lan paling jelas yaiku nduwe skrip kapisah sing kudu ditrapake kanthi manual nalika miwiti lingkungan anyar.
- Kapindho kurang ketok, duwe migrasi Liquibase sing ana ing Konteks Liquibase liyane, lan aplikasi. Sampeyan bisa maca liyane babagan Konteks Liquibase ing kene: . UmumΓ©, iki minangka mekanisme sing menarik sing bisa digunakake kanthi sukses, umpamane, kanggo tes.
- Path katelu kasusun saka sawetara langkah. Pisanan, migrasi kudu digawe kanggo tabel sing ana. Banjur kudu ditrapake ing sawetara lingkungan lan kanthi mangkono jumlah hash bakal dipikolehi. Langkah sabanjure yaiku miwiti tabel Liquibase kosong ing server sing ora kosong, lan ing tabel kanthi riwayat panggunaan owah-owahan, sampeyan bisa ngrekam kanthi manual babagan owah-owahan "kaya ditrapake" kanthi owah-owahan sing wis ana ing database. . Mangkono, ing server sing wis ana, countdown sejarah bakal diwiwiti saka versi 2, lan kabeh lingkungan anyar bakal tumindak identik.
Kahanan 4. Migrasi dadi gedhe lan ora duwe wektu kanggo ngrampungake
Ing wiwitan pangembangan layanan, minangka aturan, Liquibase digunakake minangka ketergantungan eksternal, lan kabeh migrasi diproses nalika aplikasi diwiwiti. Nanging, liwat wektu, sampeyan bisa nemoni kasus ing ngisor iki:
- Migrasi dadi gedhe lan butuh wektu suwe kanggo rampung.
- Ana perlu kanggo migrasi ing lingkungan mbagekke, contone, ing sawetara kedadean database server bebarengan.
Ing kasus iki, nglamar migrasi sing dawa banget bakal nyebabake wektu entek nalika aplikasi diwiwiti. Kajaba iku, nglamar migrasi menyang saben instance aplikasi kanthi kapisah bisa nyebabake server sing beda ora sinkron.
Carane ngatasi
Ing kasus kasebut, proyek sampeyan wis gedhe, bisa uga diwasa, lan Liquibase wiwit tumindak minangka alat eksternal sing kapisah. Kasunyatane yaiku Liquibase minangka perpustakaan dikompilasi dadi file jar, lan bisa digunakake minangka ketergantungan ing sawijining proyek utawa kanthi mandiri.
Ing mode mandiri, sampeyan bisa ninggalake implementasine migrasi menyang lingkungan CI/CD utawa menyang pundhak kuat administrator sistem lan spesialis penyebaran. Kanggo nindakake iki, sampeyan butuh baris perintah Liquibase . Ing mode iki, bisa mbukak aplikasi sawise kabeh migrasi sing dibutuhake wis ditindakake.
kesimpulan
Nyatane, bisa uga ana akeh pitfalls nalika nggarap migrasi database, lan akeh sing mbutuhake pendekatan kreatif. Penting kanggo ngerti yen sampeyan nggunakake alat kasebut kanthi bener, sebagian besar pitfalls kasebut bisa dihindari. Khusus, aku kudu ngatasi kabeh masalah sing kadhaptar ing macem-macem formulir, lan sawetara minangka akibat saka kesalahanku. Biasane iki kedadeyan, mesthi, amarga ora nggatekake, nanging kadhangkala amarga ora bisa nggunakake alat kasebut.
Source: www.habr.com