როგორ ავიცილოთ თავიდან ფეხის სროლა Liquibase-ის გამოყენებით

აქამდე არასდროს მომხდარა და აი, ისევ წავედით!

ჩვენს შემდეგ პროექტზე, თავიდანვე გადავწყვიტეთ გამოგვეყენებინა Liquibase, რათა თავიდან ავიცილოთ პრობლემები მომავალში. როგორც ირკვევა, გუნდის ყველა ახალგაზრდა წევრმა არ იცის როგორ გამოიყენოს ის სწორად. გავმართე შიდა სემინარი, რომელიც შემდეგ გადავწყვიტე სტატიად გადამექცია.

სტატიაში მოცემულია სასარგებლო რჩევები და სამი ყველაზე აშკარა ხარვეზის აღწერა, რომლებშიც შეიძლება მოხვდეთ მონაცემთა ბაზის მიგრაციის ინსტრუმენტებთან მუშაობისას, კერძოდ, Liquibase. შექმნილია Java დეველოპერებისთვის უმცროს და საშუალო დონეზე; უფრო გამოცდილი დეველოპერებისთვის ის შეიძლება იყოს საინტერესო სტრუქტურირება და გამეორება, რაც, სავარაუდოდ, უკვე ცნობილია.

Liquibase და Flyway არის ძირითადი კონკურენტი ტექნოლოგიები ჯავის სამყაროში რელაციური სტრუქტურების ვერსიების კონტროლის პრობლემების გადასაჭრელად. პირველი სრულიად უფასოა, პრაქტიკაში მას ყველაზე ხშირად ირჩევენ გამოსაყენებლად, რის გამოც პუბლიკაციის გმირად აირჩიეს Liquibase. თუმცა, ზოგიერთი აღწერილი პრაქტიკა შეიძლება იყოს უნივერსალური, თქვენი აპლიკაციის არქიტექტურიდან გამომდინარე.

ურთიერთობითი სტრუქტურების მიგრაცია იძულებითი გზაა ურთიერთობის მონაცემთა მაღაზიების სუსტ მოქნილობასთან გამკლავებისთვის. OOP მოდის ეპოქაში მონაცემთა ბაზებთან მუშაობის სტილი ნიშნავდა იმას, რომ ჩვენ ერთხელ აღვწერდით სქემას და აღარ შევეხებოდით მას. მაგრამ რეალობა ყოველთვის არის, რომ ყველაფერი იცვლება და ცხრილის სტრუქტურაში ცვლილებები საკმაოდ ხშირად არის საჭირო. ბუნებრივია, თავად პროცესი შეიძლება იყოს მტკივნეული და უსიამოვნო.

მე არ ჩავუღრმავდები თქვენს პროექტში ბიბლიოთეკის დამატების ტექნოლოგიისა და ინსტრუქციების აღწერას; ამ თემაზე დაიწერა საკმაოდ ბევრი სტატია:

• Liquibase-ის გამოყენება Spring Boot აპლიკაციაში მონაცემთა ბაზის სტრუქტურის სამართავად. Ნაწილი 1
• Liquibase-ის გამოყენება Spring Boot აპლიკაციაში მონაცემთა ბაზის სტრუქტურის სამართავად. Ნაწილი 2
• Liquibase და Maven
• მიდგომები ვერსიების მონაცემთა ბაზის ცვლილებებისადმი
• ჩვენ ვიწყებთ Spring MVC/Security, REST, Hibernate, Liquibase ორ ხაზზე

გარდა ამისა, უკვე იყო შესანიშნავი სტატია სასარგებლო რჩევების თემაზე:

• Liquibase-ის გამოყენება თავის ტკივილის გარეშე. 10 რჩევა განვითარების რეალური გამოცდილებიდან

Советы

მინდა გაგიზიაროთ ჩემი რჩევები და კომენტარები, რომლებიც მიგრაციასთან დაკავშირებული პრობლემების გადაჭრის ოფლით, სისხლითა და ტკივილით დაიბადა.

1. მუშაობის დაწყებამდე უნდა გაეცნოთ საუკეთესო პრაქტიკის განყოფილებას ონლაინი Liquibase

Там აღწერილია მარტივი, მაგრამ ძალიან მნიშვნელოვანი რამ, რომლის გარეშეც ბიბლიოთეკის გამოყენებამ შეიძლება გაართულოს თქვენი ცხოვრება. მაგალითად, ცვლილებების მართვის არასტრუქტურირებული მიდგომა ადრე თუ გვიან გამოიწვევს დაბნეულობას და გაფუჭებულ მიგრაციას. თუ თქვენ არ განახორციელებთ ურთიერთდამოკიდებულ ცვლილებებს მონაცემთა ბაზის სტრუქტურასა და სერვისის ლოგიკაში ერთდროულად, დიდია ალბათობა იმისა, რომ ეს გამოიწვევს წითელ ტესტებს ან გაფუჭებულ გარემოს. გარდა ამისა, ოფიციალურ ვებსაიტზე Liquibase-ის გამოყენების რეკომენდაციები შეიცავს პუნქტს უკან დაბრუნების სკრიპტების შემუშავებისა და ტესტირების შესახებ მთავარ მიგრაციის სკრიპტებთან ერთად. კარგად, სტატიაში https://habr.com/ru/post/178665/ არსებობს კოდის მაგალითები მიგრაციებთან და უკან დაბრუნების მექანიზმთან დაკავშირებით.

2. თუ დაიწყებთ მიგრაციის ხელსაწყოების გამოყენებას, არ დაუშვათ ხელით შესწორებები მონაცემთა ბაზის სტრუქტურაში

როგორც ნათქვამია: "ერთხელ Persil, ყოველთვის Persil." თუ თქვენი აპლიკაციის ბაზის მართვა დაიწყება Liquibase-ის მიერ, ნებისმიერი მექანიკური ცვლილება დაუყოვნებლივ იწვევს არათანმიმდევრულ მდგომარეობას და ცვლილებების ნაკრებისადმი ნდობის დონე ნულოვანი ხდება. პოტენციური რისკები მოიცავს მონაცემთა ბაზის აღდგენაზე დახარჯულ რამდენიმე საათს; უარეს შემთხვევაში, მკვდარი სერვერი. თუ თქვენს გუნდში გყავთ „ძველი სკოლის“ DBA არქიტექტორი, მოთმინებით და გააზრებულად აუხსენით მას, რა ცუდი იქნება, თუ ის უბრალოდ დაარედაქტირებს მონაცემთა ბაზას პირობითი SQL Developer-ის საკუთარი გაგებით.

3. თუ ცვლილებები უკვე შეტანილია საცავში, მოერიდეთ რედაქტირებას

თუ სხვა დეველოპერმა შეასრულა ცვლილებები და გამოიყენა ცვლილებები, რომელიც მოგვიანებით იქნება რედაქტირებული, ის აუცილებლად გაგახსენდებათ კეთილი სიტყვით, როდესაც მიიღებს შეცდომას აპლიკაციის გაშვებისას. თუ ცვლილებების ნაკრების რედაქტირება როგორღაც გაჟონავს განვითარებაში, თქვენ მოგიწევთ მიჰყვეთ ცხელი გამოსწორებების მოლიპულ ფერდობს. პრობლემის არსი ემყარება ცვლილებების დადასტურებას ჰეშ ჯამით - Liquibase-ის მთავარი მექანიზმი. ცვლილებების კოდის რედაქტირებისას ჰეშის რაოდენობა იცვლება. ცვლილებების ნაკრების რედაქტირება შესაძლებელია მხოლოდ მაშინ, როდესაც შესაძლებელია მონაცემთა დაკარგვის გარეშე მთელი მონაცემთა ბაზის ნულიდან განლაგება. ამ შემთხვევაში, SQL ან XML კოდის რეფაქტორირებამ შეიძლება, პირიქით, გააადვილოს ცხოვრება და უფრო იკითხება მიგრაცია. მაგალითი იქნება სიტუაცია, როდესაც განაცხადის დაწყებისას, გუნდში შეთანხმებული იყო წყაროს მონაცემთა ბაზის სქემა.

4. თუ ეს შესაძლებელია, გადაამოწმეთ მონაცემთა ბაზის სარეზერვო ასლები

აქ, ვფიქრობ, ყველაფერი ნათელია. თუ მოულოდნელად მიგრაცია წარუმატებელი აღმოჩნდა, ყველაფერი შეიძლება უკან დაბრუნდეს. Liquibase-ს აქვს ცვლილებების უკან დაბრუნების ინსტრუმენტი, მაგრამ უკან დაბრუნების სკრიპტები ასევე იწერება თავად დეველოპერის მიერ და მათ შეიძლება ჰქონდეთ პრობლემები იგივე ალბათობით, როგორც ძირითადი ცვლილებების სკრიპტები. ეს ნიშნავს, რომ ნებისმიერ შემთხვევაში სასარგებლოა მისი უსაფრთხოდ თამაში სარეზერვო ასლებით.

5. თუ ეს შესაძლებელია, გამოიყენეთ დადასტურებული მონაცემთა ბაზის სარეზერვო ასლები განვითარების პროცესში

თუ ეს არ ეწინააღმდეგება კონტრაქტებს და კონფიდენციალურობას, მონაცემთა ბაზაში არ არის პერსონალური მონაცემები და ის არ იწონის ორ მზეს - სანამ მის პირდაპირ მიგრაციის სერვერებზე გამოიყენებთ, შეგიძლიათ შეამოწმოთ როგორ იმუშავებს იგი დეველოპერის აპარატზე და გამოთვალოთ მიგრაციის დროს პოტენციური პრობლემების თითქმის 100%.

6. დაუკავშირდით გუნდის სხვა დეველოპერებს

კარგად ორგანიზებული განვითარების პროცესში, გუნდში ყველამ იცის, ვინ რას აკეთებს. სინამდვილეში, ეს ხშირად ასე არ არის, ამიტომ, თუ თქვენ ამზადებთ ცვლილებებს მონაცემთა ბაზის სტრუქტურაში, როგორც თქვენი ამოცანის ნაწილი, მიზანშეწონილია ამის შესახებ დამატებით აცნობოთ მთელ გუნდს. თუ ვინმე პარალელურად ცვლის ცვლილებებს, ფრთხილად უნდა მოაწყოთ. ღირს კოლეგებთან კომუნიკაცია სამუშაოს დასრულების შემდეგ და არა მხოლოდ დასაწყისში. ცვლილებების კომპლექტებთან დაკავშირებული ბევრი პოტენციური პრობლემა შეიძლება მოგვარდეს კოდის განხილვის ეტაპზე.

7. დაფიქრდი რას აკეთებ!

როგორც ჩანს, ცხადი რჩევაა, რომელიც ნებისმიერ სიტუაციას ეხება. თუმცა, ბევრი პრობლემის თავიდან აცილება შეიძლებოდა, თუ დეველოპერი კიდევ ერთხელ გაანალიზებდა რას აკეთებდა და რაზე შეიძლება გავლენა იქონიოს. მიგრაციებთან მუშაობა ყოველთვის მოითხოვს დამატებით ყურადღებას და სიზუსტეს.

ხაფანგები

მოდით ახლა გადავხედოთ ტიპურ ხაფანგებს, რომლებშიც შეიძლება მოხვდეთ, თუ არ მიჰყვებით ზემოთ მოცემულ რჩევებს და კონკრეტულად რა უნდა გააკეთოთ?

სიტუაცია 1: ორი დეველოპერი ცდილობს დაამატოს ახალი ცვლილებები ერთდროულად

ვასიას და პეტიას სურთ შექმნან ცვლილებების ვერსია 4, ერთმანეთის შესახებ ცოდნის გარეშე. მათ შეიტანეს ცვლილებები მონაცემთა ბაზის სტრუქტურაში და გასცეს pull მოთხოვნა სხვადასხვა ცვლილებების ფაილებით. შემოთავაზებულია მოქმედების შემდეგი მექანიზმი:

როგორ გადავწყვიტოთ

1. რატომღაც, კოლეგებმა უნდა შეთანხმდნენ იმაზე, თუ რა თანმიმდევრობით უნდა წავიდეს მათი ცვლილებები, მაგალითად, პირველ რიგში პეტინი უნდა იქნას გამოყენებული.
2. ვინმემ უნდა დაუმატოს მეორე საკუთარ თავს და მონიშნოს ვასის ცვლილებები მე-5 ვერსიით. ეს შეიძლება გაკეთდეს Cherry Pick-ის ან სუფთა შერწყმის გზით.
3. ცვლილებების შემდეგ აუცილებლად უნდა შეამოწმოთ განხორციელებული ქმედებების მართებულობა.
   სინამდვილეში, Liquibase მექანიზმები საშუალებას მოგცემთ გქონდეთ 4 ვერსიის ორი ცვლილება საცავში, ასე რომ თქვენ შეგიძლიათ დატოვოთ ყველაფერი ისე, როგორც არის. ანუ, თქვენ უბრალოდ გექნებათ ორი ცვლილება 4 ვერსიაში სხვადასხვა სახელებით. ამ მიდგომით, მოგვიანებით ძალიან რთული ხდება მონაცემთა ბაზის ვერსიებზე ნავიგაცია.

გარდა ამისა, Liquibase, ისევე როგორც ჰობიტების სახლი, ბევრ საიდუმლოს ინახავს. ერთ-ერთი მათგანი არის validCheckSum გასაღები, რომელიც გამოჩნდა 1.7 ვერსიაში და საშუალებას გაძლევთ მიუთითოთ სწორი ჰეშის მნიშვნელობა კონკრეტული ცვლილებების ნაკრებისთვის, მიუხედავად იმისა, თუ რა ინახება მონაცემთა ბაზაში. დოკუმენტაცია https://www.liquibase.org/documentation/changeset.html ამბობს შემდეგს:

დაამატეთ საკონტროლო ჯამი, რომელიც ითვლება ძალაში ამ ცვლილების ნაკრებისთვის, მიუხედავად იმისა, თუ რა ინახება მონაცემთა ბაზაში. გამოიყენება ძირითადად მაშინ, როდესაც თქვენ გჭირდებათ ცვლილებების ნაკრების შეცვლა და არ გსურთ შეცდომების დაშვება მონაცემთა ბაზებზე, რომლებზეც ის უკვე გაშვებულია (არ არის რეკომენდებული პროცედურა)

დიახ, დიახ, ეს პროცედურა არ არის რეკომენდებული. მაგრამ ზოგჯერ ძლიერი სინათლის ჯადოქარი ასევე ფლობს ბნელ ტექნიკას

სიტუაცია 2: მიგრაცია, რომელიც დამოკიდებულია მონაცემებზე

დავუშვათ, რომ თქვენ არ გაქვთ შესაძლებლობა გამოიყენოთ მონაცემთა ბაზის სარეზერვო ასლები ცოცხალი სერვერებიდან. პეტიამ შექმნა ცვლილებები, გამოსცადა იგი ადგილობრივად და, სრული დარწმუნებით, რომ მართალი იყო, დეველოპერს მიმართა თხოვნით. ყოველი შემთხვევისთვის, პროექტის წამყვანმა განმარტა, შეამოწმა თუ არა პეტიამ იგი და შემდეგ დაამატა. მაგრამ განვითარების სერვერზე განლაგება დაეცა.

სინამდვილეში, ეს შესაძლებელია და არავინ არის დაზღვეული ამისგან. ეს ხდება იმ შემთხვევაში, თუ ცხრილის სტრუქტურის ცვლილებები გარკვეულწილად არის მიბმული მონაცემთა ბაზის კონკრეტულ მონაცემებთან. ცხადია, თუ პეტიას მონაცემთა ბაზა ივსება მხოლოდ ტესტის მონაცემებით, მაშინ ის შეიძლება არ მოიცავდეს ყველა პრობლემურ შემთხვევას. მაგალითად, ცხრილის წაშლისას აღმოჩნდება, რომ სხვა ცხრილებში არის ჩანაწერები Foreign Key-ით, რომლებიც დაკავშირებულია წაშლილში ჩანაწერებთან. ან სვეტის ტიპის შეცვლისას აღმოჩნდება, რომ მონაცემების 100% ახალ ტიპზე ვერ გადაიყვანება.

როგორ გადავწყვიტოთ

• დაწერეთ სპეციალური სკრიპტები, რომლებიც გამოყენებული იქნება ერთხელ მიგრაციასთან ერთად და შეიტანეთ მონაცემები სათანადო ფორმაში. ეს არის მიგრაციის გამოყენების შემდეგ მონაცემების ახალ სტრუქტურებში გადაცემის პრობლემის გადაჭრის ზოგადი გზა, მაგრამ მსგავსი რამ შეიძლება გამოყენებულ იქნას ადრე, განსაკუთრებულ შემთხვევებში. ეს გზა, რა თქმა უნდა, ყოველთვის არ არის ხელმისაწვდომი, რადგან ცოცხალ სერვერებზე მონაცემების რედაქტირება შეიძლება საშიში და დამანგრეველიც კი იყოს.
• კიდევ ერთი რთული გზა არის არსებული ცვლილებების რედაქტირება. სირთულე იმაში მდგომარეობს, რომ ყველა მონაცემთა ბაზა, სადაც ის უკვე იქნა გამოყენებული არსებული სახით, უნდა აღდგეს. სავსებით შესაძლებელია, რომ მთელი backend გუნდი იძულებული იყოს ლოკალურად განათავსოს მონაცემთა ბაზა ნულიდან.
• და ყველაზე უნივერსალური გზაა მონაცემების პრობლემის გადატანა დეველოპერის გარემოში, იგივე სიტუაციის ხელახლა შექმნა და ახალი ცვლილებების დამატება, გაფუჭებულზე, რომელიც აცილებს პრობლემას.
  

ზოგადად, რაც უფრო მეტია მონაცემთა ბაზა მსგავსი შემადგენლობით წარმოების სერვერის მონაცემთა ბაზასთან, მით ნაკლებია შანსი იმისა, რომ მიგრაციასთან დაკავშირებული პრობლემები შორს წავიდეს. და, რა თქმა უნდა, სანამ ცვლილებების საცავში გაგზავნით, რამდენჯერმე უნდა იფიქროთ, დაარღვევს თუ არა რაიმეს.

სიტუაცია 3. Liquibase გამოყენებას იწყებს წარმოებაში შესვლის შემდეგ

დავუშვათ, გუნდის ხელმძღვანელმა სთხოვა პეტიას პროექტში Liquibase-ის ჩართვა, მაგრამ პროექტი უკვე წარმოებაშია და არსებობს მონაცემთა ბაზის არსებული სტრუქტურა.

შესაბამისად, პრობლემა ის არის, რომ ნებისმიერ ახალ სერვერზე ან დეველოპერ მანქანაზე, ეს ცხრილები თავიდან უნდა იქნეს შექმნილი, ხოლო არსებული გარემო უნდა დარჩეს თანმიმდევრულ მდგომარეობაში, მზად იყოს ახალი ცვლილებების ნაკრების მისაღებად.

როგორ გადავწყვიტოთ

ასევე არსებობს რამდენიმე გზა:

• პირველი და ყველაზე აშკარა არის ცალკეული სკრიპტის არსებობა, რომელიც ხელით უნდა იქნას გამოყენებული ახალი გარემოს ინიციალიზაციისას.
• მეორე ნაკლებად აშკარაა, გქონდეთ Liquibase მიგრაცია, რომელიც სხვა Liquibase კონტექსტშია და გამოიყენეთ იგი. შეგიძლიათ მეტი წაიკითხოთ Liquibase Context-ის შესახებ აქ: https://www.liquibase.org/documentation/contexts.html. ზოგადად, ეს არის საინტერესო მექანიზმი, რომელიც შეიძლება წარმატებით იქნას გამოყენებული, მაგალითად, ტესტირებისთვის.
• მესამე გზა რამდენიმე საფეხურისგან შედგება. პირველ რიგში, უნდა შეიქმნას მიგრაცია არსებული ცხრილებისთვის. შემდეგ ის უნდა იქნას გამოყენებული რაიმე გარემოში და ამგვარად მიიღება მისი ჰეშის ჯამი. შემდეგი ნაბიჯი არის ცარიელი Liquibase ცხრილების ინიციალიზაცია ჩვენს არა ცარიელ სერვერზე და ცვლილებების გამოყენების ისტორიის ცხრილში შეგიძლიათ ხელით განათავსოთ ჩანაწერი "თითქოს გამოყენებული" ცვლილებების შესახებ მონაცემთა ბაზაში უკვე არსებული ცვლილებებით. . ამრიგად, არსებულ სერვერზე ისტორიის ათვლა დაიწყება მე-2 ვერსიიდან და ყველა ახალი გარემო იდენტურად მოიქცევა.
  

სიტუაცია 4. მიგრაცია ხდება უზარმაზარი და არ აქვს დრო დასრულებას

სერვისის განვითარების დასაწყისში, როგორც წესი, Liquibase გამოიყენება როგორც გარე დამოკიდებულება და ყველა მიგრაცია მუშავდება განაცხადის დაწყებისას. თუმცა, დროთა განმავლობაში, თქვენ შეიძლება წააწყდეთ შემდეგ შემთხვევებს:

• მიგრაციები უზარმაზარი ხდება და დასრულებას დიდი დრო სჭირდება.
• საჭიროა მიგრაცია განაწილებულ გარემოში, მაგალითად, მონაცემთა ბაზის სერვერის რამდენიმე ინსტანციაზე ერთდროულად.
  ამ შემთხვევაში, მიგრაციების ძალიან ხანგრძლივად გამოყენება გამოიწვევს აპლიკაციის დაწყების ვადას. გარდა ამისა, აპლიკაციის თითოეულ ინსტანციაზე მიგრაციის გამოყენებამ შეიძლება გამოიწვიოს სხვადასხვა სერვერების სინქრონიზაცია.

როგორ გადავწყვიტოთ

ასეთ შემთხვევებში, თქვენი პროექტი უკვე დიდია, შესაძლოა ზრდასრულიც კი, და Liquibase იწყებს მოქმედებას, როგორც ცალკე გარე ინსტრუმენტი. ფაქტია, რომ Liquibase, როგორც ბიბლიოთეკა, შედგენილია jar ფაილში და შეუძლია იმუშაოს როგორც დამოკიდებულება პროექტის ფარგლებში ან დამოუკიდებლად.

დამოუკიდებელ რეჟიმში, შეგიძლიათ მიგრაციის განხორციელება თქვენს CI/CD გარემოში ან თქვენი სისტემის ადმინისტრატორებისა და განლაგების სპეციალისტების ძლიერ მხრებზე დატოვოთ. ამისათვის დაგჭირდებათ Liquibase ბრძანების ხაზი https://www.liquibase.org/documentation/command_line.html. ამ რეჟიმში, შესაძლებელი ხდება აპლიკაციის გაშვება მას შემდეგ, რაც განხორციელდება ყველა საჭირო მიგრაცია.

გამოყვანის

სინამდვილეში, მონაცემთა ბაზის მიგრაციებთან მუშაობისას შეიძლება კიდევ ბევრი ხარვეზი იყოს და ბევრი მათგანი მოითხოვს შემოქმედებით მიდგომას. მნიშვნელოვანია გვესმოდეს, რომ თუ იყენებთ ხელსაწყოს სწორად, ამ ხარვეზების უმეტესობის თავიდან აცილებაა შესაძლებელი. კონკრეტულად, ყველა ჩამოთვლილ პრობლემასთან გამკლავება სხვადასხვა ფორმით მომიწია და ზოგიერთი მათგანი ჩემი შეცდომის შედეგი იყო. ძირითადად ეს ხდება, რა თქმა უნდა, უყურადღებობის გამო, მაგრამ ხანდახან ინსტრუმენტის გამოყენების კრიმინალური უუნარობის გამო.

წყარო: www.habr.com