Ilgari hech qachon sodir bo'lmagan va biz yana boramiz!
Keyingi loyihamizda biz kelajakda muammolarni oldini olish uchun Liquibase-dan foydalanishga qaror qildik. Ma'lum bo'lishicha, barcha yosh jamoa a'zolari undan to'g'ri foydalanishni bilishmaydi. Men ichki seminar o'tkazdim, keyin uni maqolaga aylantirishga qaror qildim.
Maqolada foydali maslahatlar va relyatsion ma'lumotlar bazasini ko'chirish vositalari, xususan Liquibase bilan ishlashda duch kelishingiz mumkin bo'lgan uchta eng aniq tuzoqning tavsifi mavjud. Kichik va o'rta darajadagi Java dasturchilari uchun mo'ljallangan; ko'proq tajribali dasturchilar uchun u allaqachon ma'lum bo'lgan narsalarni tuzish va takrorlash uchun qiziqarli bo'lishi mumkin.
Liquibase va Flyway Java dunyosidagi relyatsion tuzilmalarning versiyalarni boshqarish muammolarini hal qilish uchun asosiy raqobatdosh texnologiyalardir. Birinchisi mutlaqo bepul, amalda u ko'pincha foydalanish uchun tanlanadi, shuning uchun Liquibase nashrning qahramoni sifatida tanlangan. Biroq, tavsiflangan ba'zi amaliyotlar ilovangiz arxitekturasiga qarab universal bo'lishi mumkin.
Aloqaviy tuzilmalarning ko'chishi relyatsion ma'lumotlar do'konlarining zaif moslashuvchanligi bilan kurashishning majburiy usulidir. OOP modasi davrida ma'lumotlar bazalari bilan ishlash uslubi biz sxemani bir marta tasvirlab berishimizni va unga boshqa tegmasligimizni anglatardi. Ammo haqiqat shundaki, har doim narsalar o'zgaradi va jadval tuzilishini o'zgartirish tez-tez talab qilinadi. Tabiiyki, jarayonning o'zi og'riqli va yoqimsiz bo'lishi mumkin.
Men texnologiyaning tavsifi va loyihangizga kutubxona qo'shish bo'yicha ko'rsatmalarga chuqurroq kirmayman; ushbu mavzu bo'yicha bir nechta maqolalar yozilgan:
Bundan tashqari, foydali maslahatlar mavzusida allaqachon ajoyib maqola bor edi:
Maslahatlar
Migratsiya bilan bog‘liq muammolarni hal etishda ter, qon va azob bilan tug‘ilgan maslahat va mulohazalarim bilan o‘rtoqlashmoqchiman.
1. Ishni boshlashdan oldin, eng yaxshi amaliyotlar bo'limi bilan tanishishingiz kerak Liquibaza
oddiy, lekin juda muhim narsalar tasvirlangan, ularsiz kutubxonadan foydalanish hayotingizni murakkablashtirishi mumkin. Misol uchun, o'zgarishlar to'plamini boshqarishda tuzilmagan yondashuv ertami-kechmi chalkashliklarga va buzilgan migratsiyaga olib keladi. Agar siz bir vaqtning o'zida ma'lumotlar bazasi tuzilishi va xizmat mantiqiga o'zaro bog'liq o'zgarishlar kiritmasangiz, bu qizil sinovlarga yoki buzilgan muhitga olib kelishi ehtimoli yuqori. Bundan tashqari, rasmiy veb-saytda Liquibase-dan foydalanish bo'yicha tavsiyalar asosiy migratsiya skriptlari bilan birga orqaga qaytarish skriptlarini ishlab chiqish va sinovdan o'tkazish haqida bandni o'z ichiga oladi. Xo'sh, maqolada Migratsiya va orqaga qaytarish mexanizmiga oid kod misollari mavjud.
2. Agar siz migratsiya vositalaridan foydalanishni boshlasangiz, ma'lumotlar bazasi tuzilmasida qo'lda tuzatishlarga ruxsat bermang
“Bir marta Persil, doim Persil” deganlaridek. Agar ilovangiz bazasi Liquibase tomonidan boshqarila boshlasa, qo'lda qilingan har qanday o'zgarishlar darhol nomuvofiq holatga olib keladi va o'zgarishlar to'plamiga ishonch darajasi nolga aylanadi. Potensial xavflar ma'lumotlar bazasini tiklash uchun bir necha soat sarflashni o'z ichiga oladi; eng yomon holatda, o'lik server. Agar sizning jamoangizda "eski maktab" DBA arxitektori bo'lsa, agar u shartli SQL dasturchisidan ma'lumotlar bazasini o'z tushunchasiga ko'ra tahrir qilsa, vaziyat qanchalik yomon bo'lishini sabr bilan va o'ylab tushuntiring.
3. Agar o'zgarishlar to'plami allaqachon omborga kiritilgan bo'lsa, tahrirlashdan saqlaning
Agar boshqa ishlab chiquvchi tortib olsa va keyinroq tahrir qilinadigan o'zgarishlar to'plamini qo'llasa, u ilovani ishga tushirishda xatolikka yo'l qo'yganida sizni albatta yaxshi so'z bilan eslaydi. Agar o'zgarishlar to'plamini tahrirlash qandaydir tarzda ishlab chiqilsa, siz tuzatishlarning silliq qiyaliklarini kuzatishingiz kerak bo'ladi. Muammoning mohiyati Liquibase-ning asosiy mexanizmi - xesh summasi bo'yicha o'zgarishlarni tekshirishga asoslangan. O'zgarishlar to'plami kodini tahrirlashda xesh miqdori o'zgaradi. O'zgarishlar to'plamini tahrirlash faqat ma'lumotlarni yo'qotmasdan butun ma'lumotlar bazasini noldan joylashtirish mumkin bo'lganda mumkin. Bunday holda, SQL yoki XML kodini qayta tiklash, aksincha, hayotni osonlashtirishi va migratsiyani o'qishni osonlashtirishi mumkin. Masalan, dasturning boshida manba ma'lumotlar bazasi sxemasi jamoada kelishilgan vaziyat bo'lishi mumkin.
4. Iloji bo'lsa, tasdiqlangan ma'lumotlar bazasi zahiralariga ega bo'ling
Bu erda, menimcha, hamma narsa aniq. Agar to'satdan migratsiya muvaffaqiyatsiz bo'lsa, hamma narsani qaytarish mumkin. Liquibase-da o'zgarishlarni orqaga qaytarish vositasi mavjud, ammo orqaga qaytarish skriptlari ham ishlab chiquvchining o'zi tomonidan yoziladi va ular asosiy o'zgarishlar to'plamining skriptlari bilan bir xil ehtimollik bilan muammolarga duch kelishi mumkin. Bu har qanday holatda ham zaxira nusxalari bilan xavfsiz o'ynash foydali ekanligini anglatadi.
5. Agar iloji bo'lsa, ishlab chiqishda tasdiqlangan ma'lumotlar bazasi zaxiralaridan foydalaning
Agar bu shartnomalar va maxfiylikka zid bo'lmasa, ma'lumotlar bazasida shaxsiy ma'lumotlar yo'q va uning og'irligi ikki quyoshga teng emas - uni jonli migratsiya serverlarida ishlatishdan oldin, siz ishlab chiquvchining mashinasida qanday ishlashini tekshirishingiz va hisoblashingiz mumkin. migratsiya paytida yuzaga kelishi mumkin bo'lgan muammolarning deyarli 100%.
6. Jamoadagi boshqa ishlab chiquvchilar bilan muloqot qiling
Yaxshi tashkil etilgan rivojlanish jarayonida jamoadagi har bir kishi kim nima qilayotganini biladi. Aslida, bu ko'pincha bunday emas, shuning uchun agar siz o'zingizning vazifangizning bir qismi sifatida ma'lumotlar bazasi tuzilishiga o'zgartirishlar tayyorlayotgan bo'lsangiz, bu haqda butun jamoani qo'shimcha ravishda xabardor qilish tavsiya etiladi. Agar kimdir parallel ravishda o'zgarishlarni amalga oshirayotgan bo'lsa, ehtiyotkorlik bilan tartibga solishingiz kerak. Ishning boshida emas, balki ishni tugatgandan so'ng hamkasblar bilan muloqot qilish arziydi. O'zgarishlar to'plami bilan bog'liq ko'plab muammolarni kodni ko'rib chiqish bosqichida hal qilish mumkin.
7. Nima qilayotganingizni o'ylab ko'ring!
Bu har qanday vaziyatda qo'llaniladigan o'z-o'zidan ravshan maslahat kabi ko'rinadi. Biroq, agar ishlab chiquvchi nima qilayotganini va bu nima ta'sir qilishi mumkinligini yana bir bor tahlil qilsa, ko'p muammolardan qochish mumkin edi. Migratsiya bilan ishlash har doim qo'shimcha e'tibor va aniqlikni talab qiladi.
Tuzoqlar
Keling, yuqoridagi maslahatlarga amal qilmasangiz, qanday tuzoqqa tushib qolishingiz mumkinligini ko'rib chiqaylik va aynan nima qilish kerak?
Vaziyat 1: Ikki ishlab chiquvchi bir vaqtning o'zida yangi o'zgarishlar to'plamini qo'shishga harakat qilmoqda
Vasya va Petya bir-birlari haqida bilmagan holda o'zgarishlar to'plamining 4-versiyasini yaratmoqchi. Ular ma'lumotlar bazasi tuzilishiga o'zgartirishlar kiritdilar va turli xil o'zgarishlar to'plami fayllari bilan tortib olish so'rovini chiqardilar. Quyidagi harakat mexanizmi taklif etiladi:
Qanday qaror qilish kerak
- Qanday bo'lmasin, hamkasblar o'zlarining o'zgarishlar to'plami qanday tartibda borishi kerakligi haqida kelishib olishlari kerak, masalan, birinchi navbatda Petin qo'llanilishi kerak.
- Kimdir ikkinchisini o'ziga qo'shishi va Vasyaning o'zgarishlar to'plamini 5-versiya bilan belgilashi kerak. Bu Cherry Pick yoki toza birlashma orqali amalga oshirilishi mumkin.
- O'zgarishlardan so'ng, siz amalga oshirilgan harakatlarning haqiqiyligini tekshirishingiz kerak.
Aslida, Liquibase mexanizmlari sizga omborda ikkita versiya 4 o'zgarishlar to'plamiga ega bo'lishga imkon beradi, shuning uchun siz hamma narsani avvalgidek qoldirishingiz mumkin. Ya'ni, sizda turli nomlar bilan 4-versiyaga ikkita o'zgartirish kiritiladi. Ushbu yondashuv bilan, keyinchalik ma'lumotlar bazasi versiyalarida harakat qilish juda qiyin bo'ladi.
Bundan tashqari, Liquibase, hobbitlarning uyi kabi, ko'plab sirlarni saqlaydi. Ulardan biri validCheckSum kaliti bo'lib, u 1.7 versiyasida paydo bo'lgan va ma'lumotlar bazasida nima saqlanganidan qat'i nazar, ma'lum bir o'zgarishlar to'plami uchun haqiqiy xesh qiymatini belgilash imkonini beradi. Hujjatlar quyidagilarni aytadi:
Ma'lumotlar bazasida nima saqlanganidan qat'i nazar, ushbu o'zgartirish to'plami uchun haqiqiy deb hisoblangan nazorat summasini qo'shing. Asosan, siz o'zgartirish to'plamini o'zgartirishingiz kerak bo'lganda va u allaqachon ishlagan ma'lumotlar bazalarida xatolar paydo bo'lishini istamasangiz ishlatiladi (tavsiya etilgan protsedura emas)
Ha, ha, bu protsedura tavsiya etilmaydi. Ammo ba'zida kuchli yorug'lik sehrgar ham qorong'u texnikani o'zlashtiradi
Vaziyat 2: Ma'lumotlarga bog'liq migratsiya
Aytaylik, sizda jonli serverlardan maʼlumotlar bazasi zahira nusxalaridan foydalanish imkoniyati yoʻq. Petya o'zgarishlar to'plamini yaratdi, uni mahalliy sinovdan o'tkazdi va u to'g'ri ekanligiga to'liq ishonch bilan ishlab chiquvchiga tortish so'rovini yubordi. Har holda, loyiha rahbari Petya buni tekshirgan yoki yo'qligini aniqlab berdi va keyin uni qo'shib qo'ydi. Ammo ishlab chiqish serverida joylashtirish pasayib ketdi.
Aslida, bu mumkin va hech kim bundan himoyalanmaydi. Jadval tuzilmasidagi o'zgartirishlar ma'lumotlar bazasidan ma'lum ma'lumotlar bilan bog'langan bo'lsa, bu sodir bo'ladi. Shubhasiz, agar Petya ma'lumotlar bazasi faqat test ma'lumotlari bilan to'ldirilgan bo'lsa, unda u barcha muammoli holatlarni qamrab olmasligi mumkin. Misol uchun, jadvalni o'chirishda, tashqi kalit bo'yicha boshqa jadvallarda o'chirilayotgan yozuvlarga tegishli yozuvlar mavjudligi ma'lum bo'ladi. Yoki ustun turini o'zgartirganda, ma'lumotlarning 100% ham yangi turga aylantirilishi mumkin emas.
Qanday qaror qilish kerak
- Migratsiya bilan birga bir marta ishlatiladigan maxsus skriptlarni yozing va ma'lumotlarni kerakli shaklga keltiring. Bu migratsiyani qo'llaganidan keyin ma'lumotlarni yangi tuzilmalarga o'tkazish muammosini hal qilishning umumiy usuli, ammo shunga o'xshash narsa alohida holatlarda oldin qo'llanilishi mumkin. Bu yo'l, albatta, har doim ham mavjud emas, chunki jonli serverlarda ma'lumotlarni tahrirlash xavfli va hatto halokatli bo'lishi mumkin.
- Yana bir qiyin usul mavjud o'zgarishlar to'plamini tahrirlashdir. Qiyinchilik shundaki, u allaqachon mavjud shaklda qo'llanilgan barcha ma'lumotlar bazalarini tiklash kerak bo'ladi. Butun backend jamoasi ma'lumotlar bazasini noldan mahalliy ravishda chiqarishga majbur bo'lishi mumkin.
- Va eng universal usul - ma'lumotlar bilan bog'liq muammolarni ishlab chiquvchining muhitiga o'tkazish, xuddi shu vaziyatni qayta yaratish va muammoni chetlab o'tadigan buzilganiga yangi o'zgartirishlar to'plamini qo'shish.
Umuman olganda, ma'lumotlar bazasi ishlab chiqarish serveri ma'lumotlar bazasiga qanchalik o'xshash bo'lsa, migratsiya bilan bog'liq muammolar uzoqqa borish ehtimoli shunchalik kam bo'ladi. Va, albatta, o'zgarishlar to'plamini omborga yuborishdan oldin, u biror narsani buzadimi yoki yo'qmi, deb bir necha bor o'ylab ko'rishingiz kerak.
Vaziyat 3. Liquibase ishlab chiqarishga kirgandan keyin ishlatila boshlaydi
Aytaylik, jamoa rahbari Petyadan Liquibase-ni loyihaga qo'shishni so'radi, lekin loyiha allaqachon ishlab chiqarishda va mavjud ma'lumotlar bazasi tuzilmasi mavjud.
Shunga ko'ra, muammo shundaki, har qanday yangi serverlar yoki ishlab chiquvchi mashinalarda ushbu jadvallar noldan qayta yaratilishi kerak va mavjud muhit yangi o'zgarishlar to'plamini qabul qilishga tayyor holda izchil holatda qolishi kerak.
Qanday qaror qilish kerak
Bundan tashqari, bir necha usullar mavjud:
- Birinchi va eng aniq - yangi muhitni ishga tushirishda qo'lda qo'llanilishi kerak bo'lgan alohida skriptga ega bo'lish.
- Ikkinchisi unchalik aniq emas, boshqa Liquibase kontekstida bo'lgan Liquibase migratsiyasiga ega bo'ling va uni qo'llang. Liquibase konteksti haqida ko'proq ma'lumotni bu erda o'qishingiz mumkin: . Umuman olganda, bu, masalan, sinov uchun muvaffaqiyatli ishlatilishi mumkin bo'lgan qiziqarli mexanizm.
- Uchinchi yo'l bir necha bosqichlardan iborat. Birinchidan, mavjud jadvallar uchun migratsiya yaratilishi kerak. Keyin u qandaydir muhitga qo'llanilishi kerak va shu bilan uning xesh summasi olinadi. Keyingi qadam, bo'sh bo'lmagan serverimizda bo'sh Liquibase jadvallarini ishga tushirishdir va o'zgarishlar to'plamidan foydalanish tarixi bilan jadvalda siz ma'lumotlar bazasida allaqachon mavjud bo'lgan o'zgarishlar bilan "qo'llaniladigan" o'zgarishlar to'g'risida qo'lda yozuv qo'yishingiz mumkin. . Shunday qilib, mavjud serverda tarixni ortga hisoblash 2-versiyadan boshlanadi va barcha yangi muhitlar xuddi shunday harakat qiladi.
Vaziyat 4. Migratsiya juda katta bo'lib qoladi va yakunlashga vaqtlari yo'q
Xizmatni ishlab chiqishning boshida, qoida tariqasida, Liquibase tashqi bog'liqlik sifatida ishlatiladi va dastur boshlanganda barcha migratsiyalar qayta ishlanadi. Biroq, vaqt o'tishi bilan siz quyidagi holatlarga duch kelishingiz mumkin:
- Migratsiya juda katta bo'lib, yakunlanishi uzoq vaqt talab etadi.
- Taqsimlangan muhitlarda, masalan, bir vaqtning o'zida bir nechta ma'lumotlar bazasi serverlarida migratsiyaga ehtiyoj bor.
Bunday holda, migratsiyani juda uzoq vaqt davomida qo'llash, dastur boshlanganda vaqt tugashiga olib keladi. Bundan tashqari, migratsiyani har bir ilova misoliga alohida qo‘llash turli serverlarning sinxronlashtirilmasligiga olib kelishi mumkin.
Qanday qaror qilish kerak
Bunday hollarda, sizning loyihangiz allaqachon katta, ehtimol hatto kattalar va Liquibase alohida tashqi vosita sifatida ishlay boshlaydi. Gap shundaki, Liquibase kutubxona sifatida jar fayliga tuzilgan va loyiha ichida yoki mustaqil ravishda qaramlik sifatida ishlashi mumkin.
Mustaqil rejimda siz CI/CD muhitiga yoki tizim ma'murlari va joylashtirish bo'yicha mutaxassislarning kuchli yelkalariga ko'chirishni amalga oshirishni qoldirishingiz mumkin. Buni amalga oshirish uchun sizga Liquibase buyruq qatori kerak bo'ladi . Ushbu rejimda barcha kerakli migratsiyalar amalga oshirilgandan so'ng dasturni ishga tushirish mumkin bo'ladi.
xulosa
Darhaqiqat, ma'lumotlar bazasi migratsiyasi bilan ishlashda yana ko'plab tuzoqlar bo'lishi mumkin va ularning ko'pchiligi ijodiy yondashuvni talab qiladi. Agar siz vositadan to'g'ri foydalansangiz, ushbu tuzoqlarning ko'pchiligidan qochishingiz mumkinligini tushunish muhimdir. Xususan, men sanab o'tilgan barcha muammolarni turli shakllarda hal qilishim kerak edi va ularning ba'zilari mening xatolarimning natijasi edi. Ko'pincha bu, albatta, e'tiborsizlik tufayli sodir bo'ladi, lekin ba'zida jinoiy vositadan foydalana olmaslik tufayli.
Manba: www.habr.com