Како да избегнете пуцање у ногу користећи Ликуибасе

Никада се раније није десило, и ево нас поново!

На нашем следећем пројекту одлучили смо да користимо Ликуибасе од самог почетка како бисмо избегли проблеме у будућности. Како се испоставило, не знају сви млади чланови тима како да га правилно користе. Одржао сам интерну радионицу, коју сам потом одлучио да претворим у чланак.

Чланак укључује корисне савете и опис три најочигледније замке у које можете упасти када радите са алатима за миграцију релационих база података, посебно Ликуибасе. Дизајниран за Јава програмере на јуниорском и средњем нивоу; за искусније програмере може бити од интереса за структурирање и понављање онога што је највероватније већ познато.

Ликуибасе и Фливаи су главне конкурентске технологије за решавање проблема контроле верзија релационих структура у свету Јава. Први је потпуно бесплатан, у пракси се најчешће бира за употребу, због чега је Ликуибасе изабран за јунака публикације. Међутим, неке од описаних пракси могу бити универзалне, у зависности од архитектуре ваше апликације.

Миграције релационих структура су присилан начин да се носи са слабом флексибилношћу релационих складишта података. У ери ООП моде, стил рада са базама података је подразумевао да ћемо једном описати шему и да је више не додирујемо. Али стварност је увек да се ствари мењају, а промене структуре табеле су потребне прилично често. Наравно, сам процес може бити болан и непријатан.

Нећу улазити дубље у опис технологије и упутства за додавање библиотеке вашем пројекту; на ову тему је написано доста чланака:

• Коришћење Ликуибасе-а за управљање структуром базе података у Спринг Боот апликацији. Део 1
• Коришћење Ликуибасе-а за управљање структуром базе података у Спринг Боот апликацији. Део 2
• Ликуибасе и Мавен
• Приступи променама базе података о верзијама
• Покрећемо Спринг МВЦ/Сецурити, РЕСТ, Хибернате, Ликуибасе у два реда

Поред тога, већ је постојао одличан чланак на тему корисних савета:

• Коришћење Ликуибасе-а без главобоље. 10 савета из стварног развојног искуства

Советы

Желим да поделим своје савете и коментаре који су се родили кроз зној, крв и бол решавања проблема са миграцијама.

1. Пре него што почнете са радом, требало би да се упознате са одељком о најбољим праксама Онлине Ликуибасе

Тамо описане су једноставне, али веома важне ствари, без којих коришћење библиотеке може да закомпликује ваш живот. На пример, неструктурирани приступ управљању скуповима промена ће пре или касније довести до забуне и покварених миграција. Ако у исто време не уведете међусобно зависне промене структуре базе података и логике услуге, постоји велика вероватноћа да ће то довести до црвених тестова или неисправног окружења. Поред тога, препоруке за коришћење Ликуибасе-а на званичном сајту садрже клаузулу о развоју и тестирању скрипти за враћање, заједно са главним скриптама за миграцију. Па, у чланку https://habr.com/ru/post/178665/ Постоје примери кода који се односе на миграције и механизам враћања.

2. Ако почнете да користите алате за миграцију, немојте дозволити ручне исправке у структури базе података

Како се каже: "Једном Персил, увек Персил." Ако Ликуибасе почне да управља базом ваше апликације, све ручне промене одмах доводе до недоследног стања, а ниво поверења у скупове промена постаје нула. Потенцијални ризици укључују неколико сати проведених на обнављању базе података; у најгорем случају, мртав сервер. Ако у свом тиму имате ДБА архитекту „старе школе“, стрпљиво и промишљено му објасните колико ће ствари бити лоше ако он једноставно уређује базу података према сопственом разумевању условног СКЛ програмера.

3. Ако је скуп промена већ гурнут у спремиште, избегавајте уређивање

Ако је други програмер направио повлачење и применио сет измена, који ће касније бити уређен, сигурно ће вас запамтити лепом речју када добије грешку при покретању апликације. Ако уређивање скупа промена некако процури у развој, мораћете да пратите клизав терен хитних исправки. Суштина проблема почива на валидацији промена хеш сумом - главни механизам Ликуибасе-а. Приликом уређивања кода скупа промена, хеш износ се мења. Уређивање скупова измена је могуће само када је могуће применити целу базу података од нуле без губитка података. У овом случају, рефакторисање СКЛ или КСМЛ кода може, напротив, олакшати живот и учинити миграције читљивијим. Пример би била ситуација у којој је, на почетку апликације, унутар тима договорена шема изворне базе података.

4. Имајте верификоване резервне копије базе података ако је могуће

Овде је, мислим, све јасно. Ако је миграција изненада била неуспешна, све се може вратити назад. Ликуибасе има алатку за враћање измена, али скрипте за враћање такође пише сам програмер и могу имати проблема са истом вероватноћом као и скрипте главног скупа измена. То значи да је у сваком случају корисно играти на сигурно са резервним копијама.

5. Користите проверене резервне копије базе података у развоју, ако је могуће

Ако ово није у супротности са уговорима и приватношћу, нема личних података у бази података, а није ни тешка као два сунца - пре употребе на серверима за миграцију уживо, можете проверити како ће то радити на машини програмера и израчунати скоро 100% потенцијалних проблема током миграције.

6. Комуницирајте са другим програмерима у тиму

У добро организованом процесу развоја, сви у тиму знају ко шта ради. У стварности то често није случај, стога, ако припремате измене у структури базе података као део свог задатка, препоручљиво је да о томе додатно обавестите цео тим. Ако неко паралелно прави промене, треба се пажљиво организовати. Вреди комуницирати са колегама након завршетка посла, а не само на почетку. Многи потенцијални проблеми са скуповима измена могу се решити у фази прегледа кода.

7. Размислите о томе шта радите!

То би изгледало као очигледан савет који се односи на сваку ситуацију. Међутим, многи проблеми су се могли избећи да је програмер још једном анализирао шта ради и на шта би то могло да утиче. Рад са миграцијама увек захтева додатну пажњу и тачност.

Трапс

Хајде сада да погледамо типичне замке у које можете да упаднете ако не следите горенаведене савете, и шта би, тачно, требало да урадите?

Ситуација 1: Два програмера покушавају да додају нове скупове измена у исто време

Васја и Петја желе да направе сет промена верзије 4, а да не знају једно за друго. Направили су измене у структури базе података и издали захтев за повлачење са различитим датотекама скупова промена. Предлаже се следећи механизам деловања:

Како одлучити

1. На неки начин, колеге морају да се договоре о редоследу којим би њихови сетови промена требало да иду, на пример, прво треба применити Петин.
2. Неко би требао себи додати другу и означити Васјин сет измена са верзијом 5. Ово се може урадити преко Цхерри Пицк-а или уредно спајање.
3. Након промена, свакако треба да проверите валидност предузетих радњи.
   У ствари, Ликуибасе механизми ће вам омогућити да имате два сета промена верзије 4 у спремишту, тако да можете оставити све како јесте. То јест, једноставно ћете имати две промене у верзији 4 са различитим именима. Са овим приступом, касније постаје веома тешко кретати се по верзијама базе података.

Поред тога, Ликуибасе, као и дом хобита, чува многе тајне. Један од њих је валидЦхецкСум кључ, који се појавио у верзији 1.7 и омогућава вам да наведете исправну хеш вредност за одређени скуп промена, без обзира на то шта је ускладиштено у бази података. Документација https://www.liquibase.org/documentation/changeset.html каже следеће:

Додајте контролни збир који се сматра важећим за овај скуп промена, без обзира на то шта је ускладиштено у бази података. Користи се првенствено када треба да промените цхангеСет и не желите да се појаве грешке у базама података на којима је већ покренут (није препоручена процедура)

Да, да, овај поступак се не препоручује. Али понекад јак светлосни маг такође савлада мрачне технике

Ситуација 2: Миграција која зависи од података

Претпоставимо да немате могућност да користите резервне копије базе података са живих сервера. Петиа је направио сет измена, тестирао га локално и, са пуним уверењем да је у праву, упутио захтев за повлачење програмеру. За сваки случај, вођа пројекта је разјаснио да ли је Петја то проверио, а затим додао. Али примена на развојном серверу је пала.

У ствари, то је могуће, и нико није имун од овога. Ово се дешава ако су измене структуре табеле на неки начин везане за одређене податке из базе података. Очигледно, ако је Петјина база података попуњена само подацима теста, онда можда неће покривати све случајеве проблема. На пример, приликом брисања табеле испоставља се да у другим табелама постоје записи по страном кључу који су повезани са записима у оној која се брише. Или када се промени тип колоне, испада да се не може 100% података конвертовати у нови тип.

Како одлучити

• Напишите посебне скрипте које ће се користити једном заједно са миграцијом и доведите податке у одговарајући облик. Ово је општи начин да се реши проблем преноса података у нове структуре након примене миграција, али нешто слично се може применити и пре, у посебним случајевима. Овај пут, наравно, није увек доступан, јер уређивање података на живим серверима може бити опасно, па чак и деструктивно.
• Још један тежак начин је да уредите постојећи скуп промена. Тешкоћа је у томе што ће све базе података у којима је већ примењена у постојећем облику морати да се рестаурирају. Сасвим је могуће да ће цео бацкенд тим бити приморан да локално уведе базу података од нуле.
• А најуниверзалнији начин је да се проблем са подацима пренесе у окружење програмера, поново креирајући исту ситуацију и додајући нови скуп промена, на покварени, који ће заобићи проблем.
  

Уопштено говорећи, што је база података по саставу слична бази података производног сервера, мање су шансе да ће проблеми са миграцијама отићи далеко. И, наравно, пре него што пошаљете сет измена у спремиште, требало би да размислите неколико пута да ли ће нешто покварити.

Ситуација 3. Ликуибасе почиње да се користи након што крене у производњу

Претпоставимо да је вођа тима замолио Петју да укључи Ликуибасе у пројекат, али пројекат је већ у производњи и постоји постојећа структура базе података.

Сходно томе, проблем је у томе што на свим новим серверима или машинама за развојне програмере ове табеле морају бити поново креиране од нуле, а постојеће окружење мора остати у конзистентном стању, спремно да прихвати нове скупове измена.

Како одлучити

Такође постоји неколико начина:

• Први и најочигледнији је да имате засебну скрипту која се мора применити ручно приликом иницијализације новог окружења.
• Други је мање очигледан, имате Ликуибасе миграцију која је у другом Ликуибасе контексту и примените је. Више о Ликуибасе контексту можете прочитати овде: https://www.liquibase.org/documentation/contexts.html. Генерално, ово је занимљив механизам који се може успешно користити, на пример, за тестирање.
• Трећи пут се састоји од неколико корака. Прво, мора се направити миграција за постојеће табеле. Затим се мора применити на неко окружење и тако ће се добити његов хеш збир. Следећи корак је иницијализација празних Ликуибасе табела на нашем непразном серверу, а у табелу са историјом коришћења скупова промена можете ручно да унесете запис о „као примењеном“ скупу измена са променама које већ постоје у бази података. . Дакле, на постојећем серверу, одбројавање историје почиње од верзије 2, а сва нова окружења ће се понашати идентично.
  

Ситуација 4. Миграције постају огромне и немају времена да се заврше

На почетку развоја сервиса, по правилу, Ликуибасе се користи као екстерна зависност, а све миграције се обрађују када се апликација покрене. Међутим, временом можете наићи на следеће случајеве:

• Миграције постају огромне и потребно им је много времена да се заврше.
• Постоји потреба за миграцијом у дистрибуираним окружењима, на пример, на неколико инстанци сервера базе података истовремено.
  У овом случају, предуго примена миграција ће довести до временског ограничења када се апликација покрене. Поред тога, примена миграције на сваку инстанцу апликације посебно може довести до несинхронизације различитих сервера.

Како одлучити

У таквим случајевима, ваш пројекат је већ велики, можда чак и одрасла особа, а Ликуибасе почиње да делује као посебан спољни алат. Чињеница је да се Ликуибасе као библиотека компајлира у јар датотеку и може да ради као зависност у оквиру пројекта или независно.

У самосталном режиму, можете препустити имплементацију миграција на ваше ЦИ/ЦД окружење или на јака рамена ваших систем администратора и стручњака за примену. Да бисте то урадили, биће вам потребна командна линија Ликуибасе https://www.liquibase.org/documentation/command_line.html. У овом режиму постаје могуће покренути апликацију након што се обаве све неопходне миграције.

Излаз

У ствари, може бити много више замки када радите са миграцијама базе података, а многе од њих захтевају креативан приступ. Важно је разумети да ако правилно користите алат, већина ових замки се може избећи. Наиме, морао сам да се носим са свим наведеним проблемима у различитим облицима, а неки од њих су резултат мојих грешака. Углавном се то дешава, наравно, због непажње, али понекад и због криминалне немогућности коришћења алата.

Извор: ввв.хабр.цом