Bu, heç vaxt olmamışdı və yenə də budur!
Növbəti layihədə gələcəkdə problemlərin qarşısını almaq üçün Liquibase-dən istifadə etməyə qərar verdik. Məlum oldu ki, komandanın bütün gənc üzvləri ondan düzgün istifadə etməyi bilmirlər. Daxili seminar keçirdim, sonra onu məqaləyə çevirmək qərarına gəldim.
Bu məqalədə relational verilənlər bazası miqrasiya alətləri, xüsusən də Liquibase ilə işləyərkən düşə biləcəyiniz ən aşkar tələlərdən üçünün faydalı məsləhətləri və təsvirləri daxildir. Kiçik və Orta səviyyəli Java tərtibatçıları üçün nəzərdə tutulmuşdur, daha təcrübəli tərtibatçılar üçün artıq məlum olanı strukturlaşdırmaq və təkrarlamaq maraqlı ola bilər.
Liquibase və Flyway Java dünyasında əlaqəli strukturların versiyaya nəzarət problemlərinin həlli üçün əsas rəqabət texnologiyalarıdır. Birincisi tamamilə pulsuzdur, praktikada istifadə üçün daha çox seçilir, buna görə də Liquibase nəşrin qəhrəmanı seçildi. Bununla belə, təsvir edilən təcrübələrdən bəziləri tətbiqinizin arxitekturasından asılı olaraq ümumi ola bilər.
Əlaqəli miqrasiya əlaqə məlumat anbarlarının zəif çevikliyi ilə məşğul olmaq üçün məcburi bir yoldur. OOP üçün moda dövründə verilənlər bazası ilə işləmə tərzi o demək idi ki, biz sxemi bir dəfə təsvir edəcəyik və ona bir daha toxunmayacağıq. Ancaq reallıq həmişə budur ki, hər şey dəyişir və cədvəllərin strukturunda dəyişikliklər olduqca tez-tez tələb olunur. Təbii ki, prosesin özü ağrılı və xoşagəlməzdir.
Texnologiyanın təsvirini və kitabxananı layihənizə əlavə etmək üçün təlimatları araşdırmayacağam, bu mövzuda kifayət qədər məqalələr yazılmışdır:
Bundan əlavə, faydalı məsləhətlər mövzusunda artıq əla bir məqalə var idi:
Советы
Köçlə bağlı problemlərin həllinin tərindən, qanından, əzabından doğan məsləhət və şərhlərimi bölüşmək istəyirəm.
1. Başlamazdan əvvəl ən yaxşı təcrübələr bölməsini oxumalısınız Liquibase
sadə, lakin çox vacib şeylər təsvir olunur, onsuz kitabxanadan istifadə həyatınızı çətinləşdirə bilər. Məsələn, dəyişikliklərin idarə edilməsinə qeyri-struktur yanaşma gec-tez çaşqınlığa və pozulmuş miqrasiyaya səbəb olacaq. Verilənlər bazasının strukturunda və xidmətlərin məntiqində bir-birindən asılı dəyişiklikləri eyni vaxtda həyata keçirməsəniz, bunun qırmızı testlərə və ya pozulmuş mühitə səbəb olacağı ehtimalı yüksəkdir. Bundan əlavə, rəsmi veb saytında Liquibase-dən istifadə üçün tövsiyələrdə əsas miqrasiya skriptləri ilə birlikdə geri qaytarma skriptlərinin inkişafı və yoxlanılması haqqında bir paraqraf var. Yaxşı, məqalədə miqrasiya və geri qaytarma mexanizmi ilə bağlı kod nümunələri var.
2. Əgər miqrasiya alətlərindən istifadə etməyə başlamısınızsa, verilənlər bazası strukturunda əl ilə düzəlişlərə icazə verməyin
Necə deyərlər: “Bir dəfə Persil, həmişə Persil”. Tətbiqinizin bazası Liquibase alətləri tərəfindən idarə olunmağa başlayıbsa, hər hansı əl ilə edilən dəyişikliklər dərhal uyğunsuz vəziyyətə gətirib çıxarır və dəyişikliklər dəstlərinə etibar səviyyəsi sıfıra enir. Potensial risklər - verilənlər bazasının bərpasına bir neçə saat sərf olunur, ən pis halda - ölü server. Əgər komandanızın "köhnə məktəb" DBA Memarı varsa, o, şərti SQL Tərtibatçısından verilənlər bazasını özünəməxsus şəkildə redaktə etsə, işlərin necə pis olacağını ona səbirlə və düşünərək izah edin.
3. Dəyişikliklər dəsti artıq depoya köçürülübsə, redaktə etməkdən çəkinin
Başqa bir tərtibatçı daha sonra redaktə ediləcək bir dəyişiklik dəstini çəkib tətbiq etsə, tətbiq başlayanda bir səhv aldıqda sizi mütləq xoş sözlə xatırlayacaqdır. Dəyişikliklər dəstini redaktə etmək birtəhər inkişafa sızarsa, düzəlişlərin sürüşkən yamacından aşağı enməli olacaqsınız. Problemin mahiyyəti Liquibase-in əsas mexanizmi olan hash sum ilə dəyişikliklərin doğrulanmasına əsaslanır. Dəyişiklik kodunu redaktə edərkən hash cəmi dəyişir. Dəyişikliklər dəstlərinin redaktə edilməsi yalnız bütün verilənlər bazasını sıfırdan məlumatları itirmədən yerləşdirmək mümkün olduqda mümkündür. Bu halda, SQL və ya XML kodunun refaktorinqi, əksinə, həyatı asanlaşdıra, miqrasiyanı daha oxunaqlı edə bilər. Tətbiqin başlanğıcında mənbə verilənlər bazasının sxeminin komanda daxilində əlaqələndirildiyi bir vəziyyət nümunə ola bilər.
4. Mümkünsə, verilənlər bazası ehtiyat nüsxələrini yoxlayın
Burada, məncə, hər şey aydındır. Birdən miqrasiya uğursuz olarsa, hər şeyi geri qaytarmaq olar. Liquibase-in geri qaytarma aləti var, lakin geri qaytarma skriptləri də tərtibatçının özü tərəfindən yazılır və onlar əsas dəyişiklik dəsti skriptlərində olduğu kimi eyni ehtimalla problemlə üzləşə bilər. Bu o deməkdir ki, ehtiyat nüsxələri ilə təhlükəsiz oynamaq istənilən halda faydalıdır.
5. Mümkünsə, inkişaf zamanı təsdiqlənmiş verilənlər bazası ehtiyat nüsxələrindən istifadə edin
Bu, müqavilələrə və məxfiliyə zidd deyilsə, verilənlər bazasında heç bir şəxsi məlumat yoxdur və iki günəş kimi çəkisi yoxdur - onu canlı miqrasiya serverlərində tətbiq etməzdən əvvəl, onun tərtibatçının maşınında necə işlədiyini yoxlaya və demək olar ki, 100% hesablaya bilərsiniz. miqrasiya zamanı mümkün problemlər.
6. Komandadakı digər tərtibatçılarla söhbət edin
Yaxşı təşkil edilmiş inkişaf prosesində komandadakı hər kəs kimin nə etdiyini bilir. Əslində, bu, çox vaxt belə deyil, buna görə də, əgər siz öz tapşırığınızın bir hissəsi kimi verilənlər bazası strukturunda dəyişikliklər hazırlayırsınızsa, bu barədə bütün komandaya əlavə məlumat vermək məsləhətdir. Kimsə paralel olaraq dəyişikliklər edirsə, diqqətlə təşkil etməlisiniz. Həmkarları ilə nəinki başlanğıcda, hətta işin sonunda da ünsiyyət qurmağa dəyər. Dəyişikliklər dəstləri ilə bağlı bir çox potensial problemlər kodun nəzərdən keçirilməsi mərhələsində həll edilə bilər.
7. Nə etdiyinizi düşünün!
Hər hansı bir vəziyyətə uyğun görünən aydın məsləhət. Bununla belə, tərtibatçı bir daha nə etdiyini və bunun nəyə təsir edə biləcəyini təhlil etsəydi, bir çox problemdən qaçınmaq olardı. Miqrasiya ilə işləmək həmişə əlavə diqqət və dəqiqlik tələb edir.
Tuzakları
İndi yuxarıdakı tövsiyələrə əməl etməsəniz düşə biləcəyiniz tipik tələlərə baxaq və əslində nə etmək lazımdır?
Vəziyyət 1. İki tərtibatçı eyni vaxtda yeni dəyişikliklər dəstləri əlavə etməyə çalışır
Vasya və Petya bir-birindən xəbərsiz 4-cü versiya dəyişikliklər dəsti yaratmaq istəyirlər. Onlar verilənlər bazası strukturunda dəyişikliklər etdilər və müxtəlif dəyişikliklər dəsti faylları ilə bir çəkmə sorğusu təqdim etdilər. Aşağıda aşağıdakı mexanizm təklif olunur:
Necə qərar vermək
- Birtəhər, həmkarlar dəyişikliklərin hansı ardıcıllıqla getməsi barədə razılığa gəlməlidirlər, deyək ki, ilk növbədə Petin tətbiq edilməlidir.
- Bir şəxs digərini tökməli və Vasyanın dəyişikliklər dəstini 5-ci versiya ilə qeyd etməlidir. Bu, Albalı Pik və ya səliqəli birləşmə vasitəsilə edilə bilər.
- Dəyişikliklərdən sonra görülən tədbirlərin etibarlılığını yoxlamağı unutmayın.
Əslində, Liquibase mexanizmləri depoda iki versiya 4 dəyişiklik dəstinə sahib olmağa imkan verəcək, beləliklə, hər şeyi olduğu kimi tərk edə bilərsiniz. Yəni, siz sadəcə olaraq 4-cü versiyanın müxtəlif adlarla iki reviziyasına sahib olacaqsınız. Bu yanaşma ilə verilənlər bazası versiyaları sonradan naviqasiya etmək çox çətinləşir.
Bundan əlavə, Liquibase, hobbitlərin evləri kimi, bir çox sirləri saxlayır. Onlardan biri validCheckSum açarıdır ki, o, 1.7 versiyasından bəri yaranıb və verilənlər bazasında nəyin saxlanmasından asılı olmayaraq, müəyyən dəyişikliklər dəsti üçün etibarlı hash dəyərini təyin etməyə imkan verir. Sənədlər aşağıdakıları deyir:
Verilənlər bazasında nəyin saxlanmasından asılı olmayaraq, bu dəyişiklik dəsti üçün etibarlı hesab edilən yoxlama məbləğini əlavə edin. Əsasən dəyişiklik dəstini dəyişdirmək lazım olduqda və onun artıq işlədiyi verilənlər bazasında xətaların atılmasını istəmədikdə istifadə olunur (tövsiyə olunan prosedur deyil)
Bəli, bu tövsiyə edilmir. Ancaq bəzən güclü işıq sehrbazı qaranlıq texnikaları da mənimsəyir.
Məsələn 2: Məlumata əsaslanan miqrasiya
Deyək ki, canlı serverlərdən verilənlər bazası ehtiyat nüsxələrindən istifadə edə bilməzsiniz. Petya bir dəyişiklik dəsti yaratdı, onu yerli olaraq sınaqdan keçirdi və haqlı olduğuna tam əminliklə tərtibatçıya çəkmə sorğusu etdi. Hər halda, layihə rəhbəri Petyanın yoxlayıb-yoxlamadığını aydınlaşdırdı və sonra içəri tökdü. Lakin inkişaf serverində yerləşdirmə aşağı düşdü.
Əslində bu mümkündür və heç kim bundan sığortalanmayıb. Bu, cədvəl strukturunun modifikasiyaları bir şəkildə verilənlər bazasından xüsusi məlumatlarla əlaqəli olduqda baş verir. Aydındır ki, Petyanın verilənlər bazası yalnız test məlumatları ilə doludursa, o zaman bütün problemli halları əhatə etməyə bilər. Məsələn, cədvəli silərkən, silinəndəki qeydlərlə əlaqəli Xarici Açar tərəfindən digər cədvəllərdə qeydlərin olduğu ortaya çıxır. Və ya sütun tipini dəyişdirərkən məlum olur ki, verilənlərin 100%-i yeni tipə çevrilə bilməz.
Necə qərar vermək
- Köçmə ilə birlikdə bir dəfə tətbiq olunacaq xüsusi skriptləri yazın və məlumatları lazımi formaya gətirin. Bu, miqrasiya tətbiq edildikdən sonra məlumatların yeni strukturlara ötürülməsi problemini həll etmək üçün ümumi bir yoldur, lakin buna bənzər bir şey əvvəllər, xüsusi hallarda tətbiq oluna bilər. Bu yol, əlbəttə ki, həmişə mövcud deyil, çünki canlı serverlərdə məlumatların redaktəsi təhlükəli və hətta ölümcül ola bilər.
- Başqa bir çətin yol, mövcud dəyişikliklər dəstini redaktə etməkdir. Çətinlik ondadır ki, artıq mövcud formada tətbiq edilmiş bütün verilənlər bazaları bərpa edilməlidir. Tamamilə mümkündür ki, bütün backend komandası verilənlər bazasını sıfırdan yerli olaraq yığmağa məcbur olacaq.
- Və ən universal yol, məlumat problemini tərtibatçının mühitinə ötürmək, eyni vəziyyəti yenidən yaratmaq və problemdən yan keçəcək yeni bir dəyişiklik dəsti əlavə etməkdir.
Ümumiyyətlə, verilənlər bazası istehsal serveri verilənlər bazasına nə qədər çox oxşardırsa, miqrasiya ilə bağlı problemlərin uzağa getmə ehtimalı bir o qədər azdır. Və əlbəttə ki, dəyişikliklər dəstini depoya göndərməzdən əvvəl, onun nəyisə pozub-dağıdmayacağı barədə bir neçə dəfə düşünməlisiniz.
Vəziyyət 3. Liquibase istehsala keçdikdən sonra istifadə olunmağa başlayır
Tutaq ki, komanda lideri Petyadan Liquibase-i layihəyə daxil etməyi xahiş etdi, lakin layihə artıq istehsaldadır və artıq mövcud verilənlər bazası strukturu var.
Müvafiq olaraq, problem hər hansı yeni serverlərdə və ya tərtibatçı maşınlarında cədvəl məlumatları sıfırdan yenidən yaradılmalı və artıq mövcud mühit yeni dəyişikliklər dəstlərini qəbul etməyə hazır olmaqla ardıcıl vəziyyətdə qalmalıdır.
Necə qərar vermək
Bir neçə yol da var:
- Birinci və ən aydın olanı, yeni mühiti işə salarkən əl ilə tətbiq edilməli olan ayrıca skriptin olmasıdır.
- İkincisi, daha az aşkar olan, fərqli Liquibase Kontekstində olan Liquibase miqrasiyasına sahib olmaq və onu tətbiq etməkdir. Liquibase Context haqqında daha ətraflı burada oxuya bilərsiniz: . Ümumiyyətlə, bu, məsələn, sınaq üçün uğurla tətbiq oluna bilən maraqlı bir mexanizmdir.
- Üçüncü yol bir neçə addımdan ibarətdir. Birincisi, mövcud cədvəllər üçün miqrasiya yaradılmalıdır. Sonra onu hansısa mühitə tətbiq etmək lazımdır və beləliklə onun hash məbləği əldə ediləcək. Növbəti addım boş olmayan serverimizdə boş Liquibase cədvəllərini işə salmaqdır və siz verilənlər bazasında olan dəyişikliklərlə “sanki tətbiq olunan” dəyişikliklər dəstinin qeydini dəyişiklik dəstlərinin tətbiqi tarixçəsi olan cədvələ əl ilə yerləşdirə bilərsiniz. Beləliklə, artıq mövcud serverdə tarix 2-ci versiyadan başlayacaq və bütün yeni mühitlər eyni şəkildə davranacaq.
Ssenari 4: Miqrasiyalar çoxalır və davam edə bilmir
Xidmətin inkişafının başlanğıcında, bir qayda olaraq, Liquibase xarici asılılıq kimi istifadə olunur və tətbiq başlayanda bütün köçlər işlənir. Ancaq zaman keçdikcə aşağıdakı hallarla qarşılaşa bilərsiniz:
- Miqrasiyalar nəhəng olur və başa çatdırmaq üçün uzun vaxt tələb olunur.
- Paylanmış mühitlərdə, məsələn, eyni zamanda verilənlər bazası serverlərinin bir neçə nümunəsində miqrasiyaya ehtiyac var.
Bu halda, miqrasiyaların çox uzun müddətə tətbiq edilməsi, tətbiqin başlaması ilə nəticələnəcək. Həmçinin, hər bir tətbiq nümunəsi əsasında miqrasiyaların tətbiqi müxtəlif serverlərin sinxronizasiya edilməmiş vəziyyətdə olması ilə nəticələnə bilər.
Necə qərar vermək
Belə hallarda, layihəniz artıq böyükdür, bəlkə də bir yetkindir və Liquibase ayrıca xarici alət kimi fəaliyyət göstərməyə başlayır. Məsələ burasındadır ki, Liquibase bir kitabxana olaraq jar faylına yığılıb və layihə çərçivəsində həm müstəqil, həm də asılılıq kimi işləyə bilər.
Oflayn olaraq siz köçürmələrin tətbiqini CI/CD mühitinizə və ya sistem rəhbərlərinizin/yerləşdiricilərinizin güclü çiyinlərinə buraxa bilərsiniz. Bunu etmək üçün sizə Liquibase əmr xətti lazımdır . Bu rejimdə bütün lazımi köçürmələr tamamlandıqdan sonra tətbiqi işə salmaq mümkün olur.
Buraxılış
Əslində, verilənlər bazası miqrasiyaları ilə işləyərkən daha çox tələlər var və onların bir çoxu yaradıcı yanaşma tələb edir. Aləti düzgün istifadə etsəniz, bu tələlərin çoxunun qarşısını almaq olar. Konkret olaraq, müxtəlif formalarda sadalanan bütün problemlərlə üzləşməli oldum və onların bəziləri mənim tıxaclarımın nəticəsi idi. Əsasən, bu, əlbəttə ki, diqqətsizlik səbəbindən baş verir, lakin bəzən - alətdən istifadə edə bilməməsi səbəbindən.
Mənbə: www.habr.com