Tidak pernah berlaku sebelum ini, dan di sini kita pergi lagi!
Pada projek kami yang seterusnya, kami memutuskan untuk menggunakan Liquibase dari awal lagi untuk mengelakkan masalah pada masa hadapan. Ternyata, tidak semua ahli pasukan muda tahu cara menggunakannya dengan betul. Saya mengadakan bengkel dalaman, yang kemudian saya putuskan untuk dijadikan artikel.
Artikel itu termasuk petua berguna dan penerangan tentang tiga perangkap paling jelas yang boleh anda hadapi apabila bekerja dengan alat pemindahan pangkalan data hubungan, khususnya Liquibase. Direka untuk pembangun Java di peringkat Junior dan Pertengahan; untuk pembangun yang lebih berpengalaman mungkin menarik untuk menstruktur dan mengulangi perkara yang kemungkinan besar sudah diketahui.
Liquibase dan Flyway ialah teknologi bersaing utama untuk menyelesaikan masalah kawalan versi struktur hubungan di dunia Java. Yang pertama adalah percuma sepenuhnya, dalam praktiknya ia paling kerap dipilih untuk digunakan, itulah sebabnya Liquibase dipilih sebagai wira penerbitan. Walau bagaimanapun, beberapa amalan yang diterangkan mungkin universal, bergantung pada seni bina aplikasi anda.
Penghijrahan struktur hubungan adalah cara paksa untuk menangani fleksibiliti storan data hubungan yang lemah. Dalam era fesyen OOP, gaya bekerja dengan pangkalan data bermakna kami akan menerangkan skema sekali dan tidak menyentuhnya lagi. Tetapi realitinya sentiasa perkara berubah, dan perubahan pada struktur jadual diperlukan agak kerap. Sememangnya, proses itu sendiri boleh menyakitkan dan tidak menyenangkan.
Saya tidak akan mendalami perihalan teknologi dan arahan untuk menambahkan perpustakaan pada projek anda; beberapa artikel telah ditulis mengenai topik ini:
Di samping itu, sudah ada artikel yang sangat baik mengenai topik petua berguna:
Π‘ΠΎΠ²Π΅ΡΡ
Saya ingin berkongsi nasihat dan komen saya, yang lahir melalui keringat, darah dan kesakitan menyelesaikan masalah dengan hijrah.
1. Sebelum memulakan kerja, anda harus membiasakan diri dengan bahagian amalan terbaik mengenai Liquibase
perkara yang mudah tetapi sangat penting diterangkan, tanpa menggunakan perpustakaan boleh merumitkan hidup anda. Sebagai contoh, pendekatan tidak berstruktur untuk mengurus set perubahan lambat laun akan membawa kepada kekeliruan dan migrasi yang rosak. Jika anda tidak melancarkan perubahan yang saling bergantung kepada struktur pangkalan data dan logik perkhidmatan pada masa yang sama, terdapat kebarangkalian tinggi bahawa ini akan membawa kepada ujian merah atau persekitaran yang rosak. Selain itu, pengesyoran untuk menggunakan Liquibase di tapak web rasmi mengandungi klausa tentang pembangunan dan ujian skrip rollback bersama-sama dengan skrip pemindahan utama. Nah, dalam artikel itu Terdapat contoh kod mengenai migrasi dan mekanisme pemulangan semula.
2. Jika anda mula menggunakan alat migrasi, jangan benarkan pembetulan manual dalam struktur pangkalan data
Seperti kata pepatah: "Sekali Persil, sentiasa Persil." Jika pangkalan aplikasi anda mula diuruskan oleh Liquibase, sebarang perubahan manual serta-merta membawa kepada keadaan tidak konsisten dan tahap kepercayaan dalam set perubahan menjadi sifar. Risiko yang berpotensi termasuk beberapa jam yang dibelanjakan untuk memulihkan pangkalan data; dalam senario kes terburuk, pelayan mati. Jika anda mempunyai Arkitek DBA "sekolah lama" dalam pasukan anda, terangkan kepadanya dengan sabar dan teliti betapa buruknya keadaan jika dia hanya mengedit pangkalan data mengikut pemahamannya sendiri daripada Pembangun SQL bersyarat.
3. Jika set perubahan telah ditolak ke dalam repositori, elakkan daripada mengedit
Jika pembangun lain membuat tarikan dan menggunakan set perubahan, yang kemudiannya akan diedit, dia pasti akan mengingati anda dengan kata-kata yang baik apabila dia menerima ralat semasa memulakan aplikasi. Jika pengeditan set perubahan entah bagaimana bocor ke dalam pembangunan, anda perlu mengikut cerun licin pembaikan terkini. Intipati masalah terletak pada pengesahan perubahan oleh jumlah hash - mekanisme utama Liquibase. Apabila mengedit kod set perubahan, jumlah cincang berubah. Mengedit set perubahan boleh dilakukan hanya apabila mungkin untuk menggunakan seluruh pangkalan data dari awal tanpa kehilangan data. Dalam kes ini, pemfaktoran semula kod SQL atau XML boleh, sebaliknya, menjadikan kehidupan lebih mudah dan menjadikan migrasi lebih mudah dibaca. Contohnya ialah situasi di mana, pada permulaan aplikasi, skema pangkalan data sumber telah dipersetujui dalam pasukan.
4. Mempunyai sandaran pangkalan data yang disahkan jika boleh
Di sini, saya fikir, semuanya jelas. Jika tiba-tiba penghijrahan tidak berjaya, semuanya boleh dikembalikan semula. Liquibase mempunyai alat untuk mengembalikan perubahan, tetapi skrip rollback juga ditulis oleh pembangun sendiri, dan mereka boleh menghadapi masalah dengan kebarangkalian yang sama seperti skrip set perubahan utama. Ini bermakna ia berguna untuk bermain selamat dengan sandaran dalam apa jua keadaan.
5. Gunakan sandaran pangkalan data yang terbukti dalam pembangunan, jika boleh
Jika ini tidak bercanggah dengan kontrak dan privasi, tiada data peribadi dalam pangkalan data, dan ia tidak seberat dua matahari - sebelum menggunakannya pada pelayan migrasi langsung, anda boleh menyemak cara ia berfungsi pada mesin pembangun dan mengira hampir 100% masalah yang berpotensi semasa migrasi.
6. Berkomunikasi dengan pembangun lain dalam pasukan
Dalam proses pembangunan yang teratur, semua orang dalam pasukan tahu siapa yang melakukan apa. Pada hakikatnya, ini selalunya tidak berlaku, oleh itu, jika anda sedang menyediakan perubahan pada struktur pangkalan data sebagai sebahagian daripada tugas anda, adalah dinasihatkan untuk memaklumkan kepada seluruh pasukan tentang perkara ini. Jika seseorang membuat perubahan secara selari, anda harus mengatur dengan teliti. Berbaloi untuk berkomunikasi dengan rakan sekerja selepas selesai kerja, bukan hanya pada permulaan. Banyak masalah yang berpotensi dengan set perubahan boleh diselesaikan pada peringkat semakan kod.
7. Fikirkan tentang apa yang anda lakukan!
Ia kelihatan seperti nasihat yang jelas yang terpakai untuk sebarang keadaan. Walau bagaimanapun, banyak masalah boleh dielakkan jika pembangun sekali lagi menganalisis perkara yang dia lakukan dan apa yang boleh menjejaskannya. Bekerja dengan migrasi sentiasa memerlukan perhatian dan ketepatan tambahan.
Perangkap
Sekarang mari kita lihat perangkap biasa yang anda boleh jatuh ke dalam jika anda tidak mengikut nasihat di atas, dan apa sebenarnya yang perlu anda lakukan?
Situasi 1: Dua pembangun cuba menambah set perubahan baharu pada masa yang sama
Vasya dan Petya mahu mencipta set perubahan versi 4, tanpa mengetahui satu sama lain. Mereka membuat perubahan pada struktur pangkalan data dan mengeluarkan permintaan tarik dengan fail set perubahan yang berbeza. Mekanisme tindakan berikut dicadangkan:
Bagaimana untuk membuat keputusan
- Entah bagaimana, rakan sekerja mesti bersetuju dengan susunan perubahan mereka, contohnya, Petin harus digunakan terlebih dahulu.
- Seseorang harus menambah yang kedua kepada diri mereka sendiri dan menandakan set perubahan Vasya dengan versi 5. Ini boleh dilakukan melalui Cherry Pick atau gabungan yang kemas.
- Selepas perubahan, anda pasti perlu menyemak kesahihan tindakan yang diambil.
Malah, mekanisme Liquibase akan membolehkan anda mempunyai dua set perubahan versi 4 dalam repositori, supaya anda boleh meninggalkan segala-galanya seperti sedia ada. Iaitu, anda hanya akan mempunyai dua perubahan pada versi 4 dengan nama yang berbeza. Dengan pendekatan ini, ia kemudiannya menjadi sangat sukar untuk menavigasi versi pangkalan data.
Di samping itu, Liquibase, seperti rumah hobbit, menyimpan banyak rahsia. Salah satunya ialah kunci validCheckSum, yang muncul dalam versi 1.7 dan membolehkan anda menentukan nilai cincang yang sah untuk set perubahan tertentu, tanpa mengira apa yang disimpan dalam pangkalan data. Dokumentasi mengatakan perkara berikut:
Tambahkan jumlah semak yang dianggap sah untuk changeSet ini, tanpa mengira apa yang disimpan dalam pangkalan data. Digunakan terutamanya apabila anda perlu menukar changeSet dan tidak mahu ralat dilemparkan pada pangkalan data yang telah dijalankan (bukan prosedur yang disyorkan)
Ya, ya, prosedur ini tidak disyorkan. Tetapi kadangkala ahli silap mata yang kuat juga menguasai teknik gelap
Situasi 2: Migrasi yang bergantung pada data
Katakan anda tidak mempunyai keupayaan untuk menggunakan sandaran pangkalan data daripada pelayan langsung. Petya mencipta set perubahan, mengujinya secara tempatan dan, dengan penuh keyakinan bahawa dia betul, membuat permintaan tarik kepada pembangun. Untuk berjaga-jaga, ketua projek menjelaskan sama ada Petya telah menyemaknya, dan kemudian menambahkannya. Tetapi penggunaan pada pelayan pembangunan jatuh.
Sebenarnya, ini mungkin, dan tiada siapa yang kebal daripada ini. Ini berlaku jika pengubahsuaian pada struktur jadual entah bagaimana terikat dengan data tertentu daripada pangkalan data. Jelas sekali, jika pangkalan data Petya hanya diisi dengan data ujian, maka ia mungkin tidak meliputi semua kes masalah. Sebagai contoh, apabila memadamkan jadual, ternyata terdapat rekod dalam jadual lain oleh Foreign Key yang berkaitan dengan rekod dalam jadual yang sedang dipadamkan. Atau apabila menukar jenis lajur, ternyata tidak 100% data boleh ditukar kepada jenis baharu.
Bagaimana untuk membuat keputusan
- Tulis skrip khas yang akan digunakan sekali bersama-sama dengan migrasi dan bawa data ke dalam bentuk yang betul. Ini adalah cara umum untuk menyelesaikan masalah pemindahan data ke struktur baharu selepas menggunakan migrasi, tetapi sesuatu yang serupa boleh digunakan sebelum ini, dalam kes khas. Laluan ini, sudah tentu, tidak selalu tersedia, kerana mengedit data pada pelayan langsung boleh berbahaya dan bahkan merosakkan.
- Satu lagi cara yang sukar ialah mengedit set perubahan sedia ada. Kesukarannya ialah semua pangkalan data yang telah digunakan dalam bentuk sedia ada perlu dipulihkan. Ada kemungkinan keseluruhan pasukan bahagian belakang akan dipaksa untuk melancarkan pangkalan data secara tempatan dari awal.
- Dan cara yang paling universal ialah memindahkan masalah dengan data ke persekitaran pembangun, mencipta semula situasi yang sama dan menambah set perubahan baharu, kepada yang rosak, yang akan memintas masalah itu.
Secara umum, lebih banyak pangkalan data adalah serupa dalam komposisi dengan pangkalan data pelayan pengeluaran, semakin kecil kemungkinan masalah dengan migrasi akan pergi jauh. Dan, sudah tentu, sebelum anda menghantar set perubahan ke repositori, anda harus berfikir beberapa kali sama ada ia akan memecahkan apa-apa.
Situasi 3. Liquibase mula digunakan selepas ia mula dikeluarkan
Katakan ketua pasukan meminta Petya untuk memasukkan Liquibase dalam projek itu, tetapi projek itu sudah dalam pengeluaran dan terdapat struktur pangkalan data sedia ada.
Sehubungan itu, masalahnya ialah pada mana-mana pelayan baharu atau mesin pembangun, jadual ini mesti dicipta semula dari awal, dan persekitaran sedia ada mesti kekal dalam keadaan yang konsisten, bersedia untuk menerima set perubahan baharu.
Bagaimana untuk membuat keputusan
Terdapat juga beberapa cara:
- Yang pertama dan paling jelas ialah mempunyai skrip berasingan yang mesti digunakan secara manual apabila memulakan persekitaran baharu.
- Yang kedua adalah kurang jelas, mempunyai penghijrahan Liquibase yang berada dalam Konteks Liquibase yang lain, dan gunakannya. Anda boleh membaca lebih lanjut mengenai Konteks Liquibase di sini: . Secara umum, ini adalah mekanisme menarik yang boleh digunakan dengan jayanya, sebagai contoh, untuk ujian.
- Laluan ketiga terdiri daripada beberapa langkah. Pertama, migrasi mesti dibuat untuk jadual sedia ada. Kemudian ia mesti digunakan pada beberapa persekitaran dan dengan itu jumlah cincangnya akan diperolehi. Langkah seterusnya ialah untuk memulakan jadual Liquibase kosong pada pelayan bukan kosong kami, dan dalam jadual dengan sejarah penggunaan set perubahan, anda boleh secara manual meletakkan rekod tentang set perubahan "seolah-olah digunakan" dengan perubahan yang telah sedia ada dalam pangkalan data . Oleh itu, pada pelayan sedia ada, kira detik sejarah akan bermula dari versi 2, dan semua persekitaran baharu akan berkelakuan sama.
Situasi 4. Penghijrahan menjadi besar dan tidak mempunyai masa untuk diselesaikan
Pada permulaan pembangunan perkhidmatan, sebagai peraturan, Liquibase digunakan sebagai pergantungan luar, dan semua migrasi diproses apabila aplikasi bermula. Walau bagaimanapun, dari masa ke masa, anda mungkin terjumpa kes berikut:
- Penghijrahan menjadi besar dan mengambil masa yang lama untuk diselesaikan.
- Terdapat keperluan untuk penghijrahan dalam persekitaran yang diedarkan, sebagai contoh, pada beberapa contoh pelayan pangkalan data secara serentak.
Dalam kes ini, penggunaan migrasi terlalu lama akan mengakibatkan tamat masa apabila aplikasi bermula. Selain itu, menggunakan migrasi pada setiap contoh aplikasi secara berasingan boleh mengakibatkan pelayan yang berbeza tidak segerak.
Bagaimana untuk membuat keputusan
Dalam kes sedemikian, projek anda sudah besar, mungkin juga dewasa, dan Liquibase mula bertindak sebagai alat luaran yang berasingan. Hakikatnya ialah Liquibase sebagai perpustakaan disusun ke dalam fail balang, dan boleh berfungsi sebagai kebergantungan dalam projek atau secara bebas.
Dalam mod kendiri, anda boleh menyerahkan pelaksanaan migrasi kepada persekitaran CI/CD anda atau kepada bahu kuat pentadbir sistem dan pakar penempatan anda. Untuk melakukan ini, anda memerlukan baris arahan Liquibase . Dalam mod ini, ia menjadi mungkin untuk melancarkan aplikasi selepas semua migrasi yang diperlukan telah dijalankan.
Output
Malah, terdapat banyak lagi perangkap apabila bekerja dengan migrasi pangkalan data, dan kebanyakannya memerlukan pendekatan kreatif. Adalah penting untuk memahami bahawa jika anda menggunakan alat dengan betul, kebanyakan perangkap ini boleh dielakkan. Secara khusus, saya terpaksa menangani semua masalah yang disenaraikan dalam bentuk yang berbeza, dan beberapa daripadanya adalah hasil daripada kesilapan saya. Selalunya ini berlaku, tentu saja, disebabkan oleh ketidakpedulian, tetapi kadang-kadang disebabkan oleh ketidakupayaan jenayah untuk menggunakan alat tersebut.
Sumber: www.habr.com