Мурда эч качан болгон эмес, эми биз дагы барабыз!
Кийинки долбоордо биз келечекте көйгөйлөрдү болтурбоо үчүн Liquibaseти колдонууну чечтик. Көрүнүп тургандай, аны туура колдонууну бардык эле жаш бригада мүчөлөрү биле беришпейт. Мен ички семинар өткөрдүм, анан аны макалага айлантууну чечтим.
Макалада пайдалуу кеңештер жана реляциялык маалымат базасын көчүрүү инструменттери, атап айтканда Liquibase менен иштөөдө туш боло турган эң айкын үч тузактын сүрөттөлүшү камтылган. Жаш жана орто деңгээлдеги Java иштеп чыгуучулары үчүн иштелип чыккан, ал тажрыйбалуу иштеп чыгуучулар үчүн белгилүү болгон нерсени түзүүгө жана кайталоого кызыкдар болушу мүмкүн.
Liquibase жана Flyway Java дүйнөсүндөгү реляциялык структуралардын версиясын башкаруу маселелерин чечүү үчүн атаандашкан негизги технологиялар болуп саналат. Биринчиси толугу менен акысыз, иш жүзүндө ал көбүнчө колдонуу үчүн тандалат, ошондуктан Liquibase басылманын каарманы катары тандалган. Бирок, сүрөттөлгөн кээ бир практикалар колдонмоңуздун архитектурасына жараша универсалдуу болушу мүмкүн.
Реляциялык структуралардын миграциясы реляциялык маалыматтар кампаларынын начар ийкемдүүлүгү менен күрөшүүнүн аргасыз жолу болуп саналат. OOP мода доорунда, маалымат базалары менен иштөө стили биз схеманы бир жолу сүрөттөп, ага кайра тийбей турганыбызды билдирген. Бирок чындык ар дайым нерселер өзгөрүп турат, жана үстөл структурасын өзгөртүү абдан көп талап кылынат. Албетте, процесстин өзү оор жана жагымсыз болушу мүмкүн.
Мен технологиянын сүрөттөлүшүнө терең кирбейм жана бул тема боюнча бир нече макалалар жазылган:
Мындан тышкары, пайдалуу кеңештер темасында сонун макала бар эле:
шарттары
Миграция көйгөйлөрүн чечүүнүн тер, каны, азабы менен жаралган кеп-кеңештерим менен бөлүшкүм келет.
1. Жумушка киришерден мурун, эң мыкты тажрыйбалар бөлүмү менен таанышыңыз Liquibase
жөнөкөй, бирок абдан маанилүү нерселер сүрөттөлгөн, ансыз китепкананы колдонуу жашооңузду татаалдантат. Мисалы, өзгөртүүлөр топтомун башкарууга структураланбаган мамиле эртеби-кечпи башаламандыкка жана бузулган миграцияга алып келет. Эгер сиз бир эле учурда маалымат базасынын түзүмүнө жана кызмат логикасына өз ара көз каранды өзгөртүүлөрдү киргизбесеңиз, бул кызыл сыноолорго же бузулган чөйрөгө алып келиши ыктымал. Кошумчалай кетсек, расмий веб-сайтта Liquibaseди колдонуу боюнча сунуштар негизги миграция скрипттери менен бирге артка кайтаруу скрипттерин иштеп чыгуу жана тестирлөө жөнүндө пунктту камтыйт. Ооба, макалада Миграцияларга жана артка кайтаруу механизмине байланыштуу код мисалдары бар.
2. Эгерде сиз миграция куралдарын колдоно баштасаңыз, маалымат базасынын түзүмүндө кол менен оңдоолорго жол бербеңиз
«Бир жолу Персил, ар дайым Персил» дегендей. Эгерде сиздин тиркемеңиздин базасы Liquibase тарабынан башкарылса, кол менен жасалган бардык өзгөртүүлөр дароо ыраатсыз абалга алып келет жана өзгөртүүлөр топтомуна ишеним деңгээли нөлгө айланат. Потенциалдуу тобокелдиктерге эң начар сценарийде, өлгөн серверде маалымат базасын калыбына келтирүүгө кеткен бир нече саат кирет; Эгерде сиздин командаңызда "эски мектеп" DBA архитектору болсо, ага сабырдуулук жана ойлонуу менен түшүндүрүп бериңиз, эгерде ал жай гана шарттуу SQL Иштеп чыгуучусунан өз түшүнүгү боюнча маалымат базасын түзөтсө.
3. Эгерде өзгөртүүлөр топтому репозиторийге киргизилген болсо, түзөтүүдөн качыңыз
Эгерде башка иштеп чыгуучу тарттырып, кийинчерээк түзөтүлө турган өзгөртүүлөр топтомун колдонсо, ал тиркемени баштоодо ката келгенде, сизди жылуу сөз менен эстейт. Эгерде өзгөртүүлөр топтомун түзөтүү кандайдыр бир жол менен иштеп чыгууга агып кетсе, сиз оңдоолордун тайгалак жолун ээрчишиңиз керек болот. Көйгөйдүн маңызы Liquibase негизги механизми - хэш суммасы боюнча өзгөртүүлөрдү валидацияга таянат. Өзгөртүү кодун түзөтүүдө хэштин суммасы өзгөрөт. Өзгөртүүлөр топтомун түзөтүү, маалыматтарды жоготпостон, бардык маалымат базасын нөлдөн баштап жайылтуу мүмкүн болгондо гана мүмкүн болот. Бул учурда, SQL же XML кодун рефакторинг, тескерисинче, жашоону жеңилдетип, миграцияны окумдуураак кыла алат. Мисал, колдонмонун башталышында, булак базасынын схемасы команданын ичинде макулдашылган жагдай болот.
4. Мүмкүн болсо, маалыматтар базасынын камдык көчүрмөлөрүн текшериңиз
Бул жерде, менимче, баары түшүнүктүү. Эгер күтүлбөгөн жерден миграция ийгиликсиз болуп калса, бардыгын артка кайтарууга болот. Liquibase-де өзгөртүүлөрдү артка жылдыруу куралы бар, бирок артка кайтаруу скрипттерин иштеп чыгуучунун өзү да жазат жана аларда негизги өзгөртүүлөр топтомунун скрипттери сыяктуу эле ыктымалдуулук менен көйгөйлөр болушу мүмкүн. Бул ар кандай учурда камдык көчүрмөлөр менен коопсуз ойноо пайдалуу экенин билдирет.
5. Мүмкүн болсо, иштеп чыгууда далилденген маалыматтар базасынын резервдик көчүрмөлөрүн колдонуңуз
Эгерде бул келишимдерге жана купуялуулукка карама-каршы келбесе, анда маалымат базасында жеке маалыматтар жок жана анын салмагы эки күнгө жетпесе - аны жандуу миграция серверлеринде колдонуудан мурун, аны иштеп чыгуучунун машинасында кантип иштээрин текшерип, эсептей аласыз. миграция учурунда мүмкүн болуучу көйгөйлөрдүн дээрлик 100%.
6. Командадагы башка иштеп чыгуучулар менен баарлашыңыз
Жакшы уюштурулган өнүгүү процессинде командадагы ар бир адам ким эмне кылып жатканын билет. Чындыгында, бул көп учурда андай эмес, ошондуктан, эгерде сиз өзүңүздүн тапшырмаңыздын бир бөлүгү катары маалымат базасынын түзүмүн өзгөртүүнү даярдап жатсаңыз, бул тууралуу бүтүндөй командага кошумча кабарлоо сунушталат. Кимдир бирөө параллелдүү өзгөртүүлөрдү киргизип жатса, кылдаттык менен уюштуруу керек. Кесиптештер менен иштин башында эле эмес, аяктагандан кийин баарлашуу керек. Өзгөртүү топтомдорунун көптөгөн потенциалдуу көйгөйлөрүн кодду карап чыгуу баскычында чечсе болот.
7. Эмне кылып жатканыңды ойлон!
Бул кандайдыр бир кырдаалга тиешелүү өзүн-өзү айкын кеңеш сыяктуу көрүнөт. Бирок, иштеп чыгуучу дагы бир жолу эмне кылып жатканын жана ал эмнеге таасир этиши мүмкүн экенин талдап чыкса, көптөгөн көйгөйлөрдүн алдын алса болмок. Миграциялар менен иштөө ар дайым кошумча көңүл бурууну жана тактыкты талап кылат.
тузак
Келгиле, эми жогорудагы кеңештерди аткарбасаңыз, сиз түшүп калышы мүмкүн болгон типтүү тузактарды карап көрөлү жана эмне кылуу керек?
Кырдаал 1: Эки иштеп чыгуучу бир эле учурда жаңы өзгөртүүлөр топтомун кошууга аракет кылып жатышат
Вася менен Петя бири-бири жөнүндө билбестен, 4-версиясын өзгөртүүнү каалашат. Алар маалымат базасынын түзүмүнө өзгөртүүлөрдү киргизип, ар кандай өзгөртүүлөр топтому файлдары менен тартуу өтүнүчүн чыгарышты. Иш-аракеттин төмөнкү механизми сунушталат:
Кантип чечиш керек
- Кандайдыр бир жол менен, кесиптештер алардын өзгөртүүлөр топтому барышы керек тартиби жөнүндө макулдашышы керек, мисалы, Петин биринчи колдонулушу керек.
- Кимдир бирөө өзүнө экинчисин кошуп, Васянын өзгөртүүлөр топтомун 5 версиясы менен белгилеши керек. Муну Cherry Pick же тыкан бириктирүү аркылуу жасаса болот.
- Өзгөртүүлөрдөн кийин, сөзсүз түрдө аткарылган иш-аракеттердин тууралыгын текшерүү керек.
Чындыгында, Liquibase механизмдери репозиторийде эки версия 4 өзгөртүүлөр топтомуна ээ болууга мүмкүндүк берет, андыктан бардыгын ошол бойдон калтыра аласыз. Башкача айтканда, сиз жөн гана ар кандай аталыштар менен 4-версияга эки өзгөртүүгө ээ болосуз. Бул ыкма менен кийинчерээк маалымат базасынын версияларында багыттоо өтө кыйын болуп калат.
Мындан тышкары, Liquibase хоббиттердин үйү сыяктуу көптөгөн сырларды сактайт. Алардын бири - validCheckSum ачкычы, ал 1.7 версиясында пайда болгон жана маалымат базасында сакталган нерсеге карабастан, белгилүү бир өзгөртүүлөр топтому үчүн жарактуу хэш маанисин көрсөтүүгө мүмкүндүк берет. Документация мындай дейт:
Маалыматтар базасында сакталган нерсеге карабастан, бул өзгөртүү топтому үчүн жарактуу деп эсептелген текшерүү суммасын кошуңуз. Негизинен өзгөртүүлөр топтомун өзгөртүү керек болгондо колдонулат жана ал мурунтан эле иштетилген маалымат базаларында каталардын чыгышын каалабаңыз (сунушталган процедура эмес)
Ооба, ооба, бул жол-жобосу сунушталбайт. Бирок кээде күчтүү жарык сыйкырчы да караңгы ыкмаларды өздөштүрүп алат
Кырдаал 2: Маалыматтарга көз каранды болгон миграция
Келгиле, сизде жандуу серверлерден маалымат базасынын резервдик көчүрмөлөрүн колдонуу мүмкүнчүлүгү жок деп ойлойлу. Петя өзгөртүүлөр топтомун түзүп, аны жергиликтүү деңгээлде сынап көрдү жана анын туура экенине толук ишенип, иштеп чыгуучуга тартуу өтүнүчүн жасады. Болбосо, долбоордун жетекчиси Петя текшерип-текшербегенин тактап, анан кошуп койду. Бирок иштеп чыгуу серверинде жайгаштыруу төмөндөдү.
Чындыгында, бул мүмкүн, жана эч ким мындан иммундук эмес. Бул таблицанын структурасына өзгөртүүлөр кандайдыр бир жол менен маалымат базасынан белгилүү бир маалыматтар менен байланышкан болсо болот. Албетте, Петянын маалымат базасы сыноо маалыматтары менен гана толтурулган болсо, анда ал бардык көйгөйлүү учурларды камтый албайт. Мисалы, таблицаны жок кылууда, чет өлкөлүк ачкычтын башка таблицаларында жок кылынган жазууларга тиешелүү жазуулар бар экени белгилүү болот. Же мамычанын түрүн өзгөрткөндө, маалыматтардын 100% жаңы түргө айландырууга болбойт экен.
Кантип чечиш керек
- Миграция менен бирге бир жолу колдонула турган атайын скрипттерди жазыңыз жана маалыматтарды тийиштүү формага келтириңиз. Бул миграцияны колдонгондон кийин маалыматтарды жаңы структураларга өткөрүп берүү маселесин чечүүнүн жалпы жолу, бирок ушуга окшош нерсени өзгөчө учурларда мурда колдонсо болот. Бул жол, албетте, дайыма эле жеткиликтүү боло бербейт, анткени түз серверлердеги маалыматтарды түзөтүү кооптуу жана ал тургай кыйратуучу болушу мүмкүн.
- Дагы бир татаал жолу - учурдагы өзгөртүүлөр топтомун түзөтүү. Кыйынчылык, ал буга чейин анын учурдагы түрүндө колдонулган бардык маалымат базалары калыбына келтирилиши керек болот. Бүткүл backend командасы маалымат базасын нөлдөн баштап жергиликтүү түрдө жайылтууга аргасыз болушу толук мүмкүн.
- Жана эң универсалдуу жол - бул маалымат менен болгон көйгөйдү иштеп чыгуучунун чөйрөсүнө өткөрүп берүү, ошол эле кырдаалды кайра түзүү жана көйгөйдү айланып өтүүчү бузулганга жаңы өзгөртүүлөр топтомун кошуу.
Жалпысынан, маалымат базасы курамы боюнча өндүрүш серверинин маалымат базасына канчалык окшош болсо, миграция көйгөйлөрү ошончолук азыраак болот. Анан, албетте, репозиторийге өзгөртүүлөр топтомун жөнөтүүдөн мурун, ал бир нерсени бузуп алабы же жокпу, бир нече жолу ойлонушуңуз керек.
Кырдаал 3. Liquibase өндүрүшкө киргенден кийин колдонула баштайт
Команданын жетекчиси Петядан Liquibase-ди долбоорго кошууну суранды дейли, бирок долбоор буга чейин өндүрүштө жана базанын түзүмү бар.
Демек, көйгөй бардык жаңы серверлерде же иштеп чыгуучу машиналарда бул таблицалар нөлдөн баштап кайра түзүлүшү керек жана учурдагы чөйрө жаңы өзгөртүүлөр топтомун кабыл алууга даяр ырааттуу абалда калышы керек.
Кантип чечиш керек
Ошондой эле бир нече жолдору бар:
- Биринчи жана эң айкын - жаңы чөйрөнү инициализациялоодо кол менен колдонула турган өзүнчө скриптке ээ болуу.
- Экинчиси анча айкын эмес, башка Liquibase контекстинде болгон Liquibase миграциясына ээ болуп, аны колдонуңуз. Liquibase Context жөнүндө кененирээк бул жерден окуй аласыз: . Жалпысынан алганда, бул, мисалы, тестирлөө үчүн ийгиликтүү колдонулушу мүмкүн кызыктуу механизми болуп саналат.
- Үчүнчү жол бир нече этаптан турат. Биринчиден, учурдагы таблицалар үчүн миграция түзүлүшү керек. Андан кийин ал кандайдыр бир чөйрөгө колдонулушу керек жана ошентип анын хэш суммасы алынат. Кийинки кадам - бош эмес серверибизде бош Liquibase таблицаларын инициализациялоо жана өзгөртүүлөр топтомун колдонуу тарыхы бар таблицага маалымат базасында мурунтан эле бар болгон өзгөртүүлөр менен "колдонулгандай" өзгөртүүлөр топтому жөнүндө кол менен жазууну киргизе аласыз. Ошентип, учурдагы серверде тарыхты артка эсептөө 2-версиядан башталат жана бардык жаңы чөйрөлөр бирдей иштейт.
Кырдаал 4. Миграциялар чоң болуп, аягына чыгууга убакыт жок
Кызматты иштеп чыгуунун башында, эреже катары, Liquibase тышкы көз карандылык катары колдонулат жана тиркеме башталганда бардык миграциялар иштетилет. Бирок, убакыттын өтүшү менен, сиз төмөнкү учурларда чалынышы мүмкүн:
- Миграциялар чоң болуп, бүтүшү үчүн көп убакыт талап кылынат.
- Бөлүштүрүлгөн чөйрөлөрдө, мисалы, бир эле учурда бир нече маалыматтар базасынын серверинде миграцияга муктаждык бар.
Бул учурда, көчүрүү өтө узакка колдонулса, колдонмо башталганда күтүү аяктайт. Кошумчалай кетсек, көчүрүүлөрдү ар бир колдонмо инстанциясына өзүнчө колдонуу ар кандай серверлердин шайкештештирилбей калышына алып келиши мүмкүн.
Кантип чечиш керек
Мындай учурларда, сиздин долбоор мурунтан эле чоң, балким, ал тургай, бойго жеткен, жана Liquibase өзүнчө тышкы курал катары иштей баштайт. Чындыгында Liquibase китепкана катары jar файлына түзүлгөн жана долбоордун ичинде же өз алдынча көз карандылык катары иштей алат.
Өз алдынча режимде сиз CI/CD чөйрөңүзгө же системалык администраторлоруңуздун жана жайылтуу боюнча адистердин күчтүү ийиндерине көчүрүүнү ишке ашыра аласыз. Бул үчүн сизге Liquibase буйрук сабы керек болот . Бул режимде, бардык керектүү көчүрүү жүргүзүлгөндөн кийин, тиркемени ишке киргизүү мүмкүн болот.
жыйынтыктоо
Чындыгында, маалымат базасынын миграциясы менен иштөөдө дагы көптөгөн мүчүлүштүктөр болушу мүмкүн жана алардын көбү чыгармачылык мамилени талап кылат. Эгер куралды туура колдонсоңуз, бул тузактардын көбүн болтурбай коюуга болорун түшүнүү маанилүү. Тактап айтканда, мен саналган көйгөйлөрдүн баарын ар кандай формада чечүүгө туура келди, алардын айрымдары менин каталарымдын натыйжасы болду. Көбүнчө, бул, албетте, көңүл бурбоодон улам болот, бирок кээде куралды колдонууга криминалдык жөндөмсүздүктөн улам болот.
Source: www.habr.com