🥇Ինչպես խուսափել սեփական ոտքը կրակելուց, օգտագործելով Liquibase

Ո nunca , և ահա նորից!

Մեր հերթական նախագծում մենք որոշեցինք այդպես անել՝ սկսելով Liquibase-ից, որպեսզի ապագայում խնդիրներից խուսափենք։ Պարզվեց, որ թիմի բոլոր երիտասարդ անդամները չեն կարողանում ճիշտ գործածել այն։ Ես կազմակերպեցի ներքին վարպետության դաս, որը հետո որոշեցի դարձնել հոդվածի:

Այս հոդվածում ներառված են օգտակար խորհուրդներ և նկարագրություն երեք առավել ակնհայտ փանձնային դասի՝ որոնք կարելի է գտնել հարաբերական տվյալների բազաների միգրացիայի գործիքների հետ աշխատելու ժամանակ, մասնավորապես Liquibase-ի։ Այն նախատեսված է Java ծրագրավորողների համար՝ սկսնակ ու միջին մակարդակների, ավելի փորձառու ծրագրավորողների համար կարող է լինել հետաքրքիր օգտագործման կառուցվածման և կրկնության տեսանկյունից արդեն ծանոթների մասին:

Liquibase և Flyway — գլխավոր մրցակից տեխնոլոգիաներ, որոնք լուծում են հարաբերական կառուցվածքների վարկածների վերահսկման խնդիրները Java աշխարհում։ Առաջինը լիովին անվճար է, իսկ պրակտիկայում հաճախ է իրզի բավականին ընտրության օգտակար համար, այդ պատճառով էլ Liquibase-ը ընտրվել է հրապարակման հերոս։ Այնուամենայնիվ, նկարագրված որոշ մեթոդները կարող են լինել համընդհանուր, կախված ձեր application's կառուցվածքից:

Հարաբերական կառուցվածքների միգրացիաները պարտադրաբար ծնված միջոց են՝ պայքարելու համար հարաբերական տվյալների պահեստների թույլ ճկունության դեմ։ OOP դարի մոդայի ժամանակ տվյալների բազաներով աշխատանքը ենթադրում էր, որ մենք մի անգամ կնկարագրենք սխեման և այլևս չենք կուզելու։ Բայց իրականությունը միշտ կատարվում է այնպես, որ ամեն ինչ փոխվում է, և աղյուսակների կառուցվածքի փոփոխություններ պահանջվում են բավականին հաճախ։ Ակնհայտ է, որ գործընթացը ինքնին կարող է լինել ցավալի և անհանգիստ։

Դեռ վերևում չեմ անդրադարձնի տեխնոլոգիայի և գրադարանի ավելացման նշանման, այս թեմայի մասին շատ հոդվածներ են գրվել.

Բացի դրանից, արդեն եղել է հիանալի հոդված օգտակար խորհուրդների մասին:

Liquibase-ի օգտագործումը առանց գլխացավանքների։ 10 συμβոբներ իրական ծրագրավորմանից

Խորհուրդներ

Գասկացանք իմ խորհուրդներն ու մեկնաբանությունները, որոնք ծնվել են տ beinh վեր, արյուն, և ցավի միջոցով միգրացիայի խնդիրների լուծման ժամանակ։

1. Աշխատանքի նախքան անհրաժեշտ է ծանոթանալ լավագույն պրակտիկայի բաժնին на հասցեից Liquibase

Այնտեղ Նկարագրված են պարզ, բայց շատ կարևոր բաներ, որոնցից առանց շնորհակալությունը գրադարան օգտագործելու համար դժվար կլինի կյանքը: Օրինակ, ոչ կառուցվածքային մոտեցումը փոփոխության հավաքածուների կառավարմանը մի փոքր ուշ կամ վաղ կհանգեցնի խառնաշփոթի և հայտարարված միգրացիաների: Եթե խորհուրդները, որոնք կախված են իրարից, չեն ներկայացվում միաժամանակ, շատ մեծ հավանականություն կա, որ դա կհանգեցնի կարմիր թեստերի կամ փչացած միջավայրի: Եվ նաեւ Liquibase- ի պաշտոնական կայքում ոճի հատվածում առաջարկություններ կան, որոնք վերաբերում ենRollback սկրիպտերի մշակմանը և ստուգմանը հիմնական միգրացիոն սկրիպտերի հետ միասին: Եվ հոդվածում https://habr.com/ru/post/178665/ կան կոդի օրինակներ, որոնք վերաբերում են միգրացիաներին և rollback մեխանիզմին։

2. Եթե սկսել եք օգտագործել միգրացիոն օժանդակությունները, մի թույլ տվեք ձեռքով շտկումներ базы կառուցվածքում:

Ինչպես ասված է. «Մի անգամ Persil — միշտ Persil»: Եթե ձեր application's database-ն սկսել է կառավարվել Liquibase միջոցներով, ցանկացած ձեռքով փոփոխություններ հիմնականում հանգեցնում են ոչ համաչափ վիճակի և անփոխարինելի համաձայնության մակարդակը միանգամից զրոյանում է: Հնարավոր ռիսկերը` մի քանի ծախսված ժամերի համար базасын վերականգնելու վրա, վատագույն դեպքում՝ սպառնացող սերվեր: Եթե ձեր թիմում կա DBA ճարտարապետ «հին դպրոցից», համբերատար և մտածված բացատրել նրա, թե ինչպես ամեն բան վատ կլինի, եթե պարզապես խմբագրի տարածքը իր ցանկությամբ SQL Developer- ի մեջ։

3. Եթե փոփոխության հավաքածուն արդեն մղվել է ռեպոզիտորի, խուսափեք խմբագրելուց:

Եթե մի այլ մշակող ստացել է pull և կիրառել հավաքածուն, որը ապա կհավաքվի, նա, անպայման, ձեզ հիշելու է Հայաստանում, երբ ստանում է դիմումի սկիզբի սխալ: Եթե խմբագրումը որպես հետևանք կուսի հանդես-ում, ապա ստիպված կլինեք սլանալ հրամանով: Ռիսքը մնում է փոփոխությունների վաւերացման հեշ-մասնը - Liquibase-ի հիմնական մեխանիզմը: Հիվանդության դեպքում_patch-ը կհաջողվի, երբ անհրաժեշտ լինի ամբողջ բազայի զրոյացումը: Այդ դեպքում SQL կամ XML կոդի փոփոխությունը, հակառակ դեպքում, կարող է հեշտացնել կյանքը, դարձնելով միգրացիաները ավելիReadable: Օրինակ, կարող է լինել այն պահը, երբ ծրագրի մեկնարկի ժամանակ արտապատկերումը նախնական базы согласовано հանդիսանում է թիմի կազմում։

4. Ունեցեք проверенные бэкапы баз данных, если это возможно:

Այսինքն, կարծում եմ, ամեն բան պարզ է: Եթե միգրացիան դժբախտության դիմումում հայտնվի, ամեն ինչ կարող է վերադարձվել: Liquibase-ի մեջ կան փոփոխություններ տակի միջոցով, բայց տակի սկրիպտերը նույնպես գրում է ինքը ծրագրավորողը, և կարող են լինել նույնպիսի խնդիրներով, ինչպիսին՝ հիմնական փոփոխության հավաքածուն: Սա նշանակում է, որ սանդրակելու կարիք ունեք бэкап-ներին, ցանկացած դեպքում.

5. Օգտագործեք հայտնի տվյալների բազաների կրկնօրինակները զարգացումն ու բարելավումը, եթե դա հնարավոր է

Եթե դա չի հակասում համաձայնագրերին և գաղտնիության, տվյալների բազայում անձնական տվյալներ չկան, և այն չի ծանրանում ինչպես երկու արևներ, ապա ահա թե ինչ. Նախքան իրական սերվերներում իրականացնելու նախնական տվյալները, կարելի է ստուգել, թե ինչպես է դա աշխատում մշակողի մեքենայում և հաշվել գրեթե 100% պոտենցիալ խնդիրները միգրացիայի ժամանակ:

6. Հետևեք թիմի մյուս ծրագրավորողներին

Ստեղծման ճիշտ կազմակերպված գործընթացում թիմում բոլորը գիտեն, թե quién պատասխանատու է: Իրականում հակառակն է շատ դեպքերում, ուստի, եթե ձեր առաջադրանքներով բազայի կառուցվածքի փոփոխություններ եք պատրաստում, անհրաժեշտ է լրացուցիչ տեղեկացնել ողջ թիմին: Եթե ինչ-որ մեկը զուգահեռ փոփոխություններ կատարում է, դուք պետք է զգույշ կազմակերպվեք: Համագործակցեք գործընկերների հետ նաև աշխատանքի ավարտից հետո, ոչ միայն մեկնարկում: Փոփոխությունների հավաքածուներով կարող է բազմաթիվ պոտենցիալ խնդիրներ լուծվել կոդի վերանայման փուլում:

7. Վերլուծեք, ինչ եք անում!

Այն թվում, որ դա ակնհայտ խորհուրդ է, կիրառելի ամեն իրավիճակում: Սակայն շատ խնդիրներ կհաջողվեին խուսափել, եթե ծրագրավորողը կրկին վերլուծեր, թե ինչ անում է և ինչ կարող է դա ազդել: Միգրացիաներով աշխատելը միշտ պահանջում է լրացուցիչ ուշադրություն և զգուշություն:

Լովուսներ

Այժմ եկեք քննարկենք այն սովորական հնձավառները, որոնց մեջ կարող եք հայտնվել, եթե չհետևեք վերոնշյալ խորհուրդներին, և ինչ, ի վերջո, պետք է անել:

Իրադրություն 1. Երկու ծրագրավորողներ փորձում են միաժամանակ ավելացնել նոր փոփոխությունների հավաքածուներ

Վասյա և Վաչա ուզում են ստեղծել 4-րդ տարբերակի փոփոխությունների հավաքածու, չիմանալով միմյանց մասին: Նրանք կատարել են փոփոխություններ տվյալների բազայի կառուցվածքում և ծածկում են pull request-ներ տարբեր ֆայլերով: Այնուհետև առաջարկվում է հետևյալ գործողությունների մեխանիզմը:

Ինչպես լուծել

Նկատված է, որ գործընկերները պետք է պայմանավորվեն, թե ի՞նչ հերթականություն պետք է ունենան իրենց փոփոխությունների հավաքածուները, օրինակ, Վաչայի միտքը պետք է լինի առաջին:
Մեկը պետք է տարածի երկրորդը իրեն մոտ և մակնշի Վասյայի փոփոխության հավաքածուն 5-րդ տարբերակով: Սա կարող է արվել Cherry Pick-ով կամ հոգատար խառնիչով:
Փոփոխություններից հետո անպայման պետք է ստուգել կատարված գործողությունների վավերությունը:
Իրականում Liquibase-ի մեխանիզմները թույլատրելու են պահել ռեպոզիտորում երկու 4-րդ տարբերակի փոփոխություններից, ուստի կարող եք թողնել ամեն ինչ այնպես ինչպես կա: Դա նշանակում է, որ դուք պարզապես կունենաք երկու 4-րդ տարբերակներ տարբեր անուններով: Այդպիսի մոտեցման արդյունքում հետագայում տվյալների բազայի տարբերակներում շատ դժվար է դառնում կողմնորոշվել:

Բացի այդ, Liquibase-ը, ինչպես հոբբիթների տանը, պահում է բազմաթիվ գաղտնիքներ: Դրանցից մեկը validCheckSum հիշողության բանալին է, որը ծագել է 1.7 տարբերակում և թույլատրում է ցուցակավորել վավեր մոնրի արժեքներ հատուկ փոփոխության հավաքածուի համար՝ կախված տվյալների բազայում ինչ տեսակի տեղեկատվություն կա: վկայություն https://www.liquibase.org/documentation/changeset.html ասում է հետևյալը:

Անցնել ստիկան, որն ընդունելի է այս փոփոխված հավաքածուի համար, անկախ նրանից, թե ինչ է պահվում տվյալների բազայում: Primarily օգտագործվում է, երբ դուք պետք է փոխեք փոփոխված հավաքածուն և չեն ցանկանում, որ սխալներ առաջանան այն բազաներում, որոնց վրա դա արդեն իրականացվել է (չի առաջարկվում այս ընթացակարգը)

Այո-այո, նման ընթացակարգը չի առաջարկվում: Բայց sometimes ուժեղ արեգակնային մոգը տիրապետում է նաև մութ տեխնիկաներին

Հանդիպում 2: Միգրացիա, որը կախված է տվյալներից

Վոնեցնենք, որ դուք չունեք հնարավորություն օգտագործելու կենդանի սերվերներից պահեստային պատճենները: Պետյան ստեղծել է փոփոխված հավաքածու, ստուգել է այն տեղական տարբերակում և վստահորեն կատարել pull request զարգացման մեջ: Նախագծի ղեկավարը նախապես уточнил է, թե Պետյան ստուգե՞լ է այն, ապա ներգրավման է գնացել: Բայց զարգացումից հետո օրինակը աշխատել է սերվերի գետում:

Նույնիսկ դա հնարավոր է, և դրանից ոչ ոք ոչ հոգում է: Դա տեղի է ունենում, եթե աղյուսակների կառուցվածքի փոփոխությունները ինչ-որ կերպ կապված են տվյալների հետ տվյալների բազայում: Очевидно, որ եթե Պետյանի բազան զբաղված է միայն փորձնական տվյալներով, ապա այն կարող է չմատուցել բոլոր խնդիրները: Օրինակ, կորկի տակ լինելը պարզ է, որ այլ աղյուսակներում կան գրառումներ Foreign Key հետ կապված կատարվում են: Ուրեմն, երբ փոփոխվում է սյունակի տեսակը, պարզ է, որ 100% տվյալները կարող են փոփոխվել նոր տեսակի:

Ինչպես լուծել

Գրել հատուկ սկրიპտեր, որոնք կկատարեն մեկ անգամ միասին միգրացիայի և կհասցնեն տվյալները լուրջ տեսքի: Սա ընդհանուր միջոց առկա տվյալների տեղափոխման պրոբլեմի լուծման համար, արդեն միգրացիաներ իրականացնելուց հետո, բայց նման բան կարող է կիրառվել նաև նախօրոք, որոշ դեպքերում: Այս ճանապարհը, իհարկե, միշտ չի մատչելի, պարզ է, որ տվյալների խմբագրումը կենդանի սերվերների վրա կարող է վտանգավոր և վնասակար լինել:
Այդպես էլ բարդ ճանապարհ է `շտկել առկա փոփոխված հավաքածուն: Բարդությունը այն է, որ բոլոր տվյալների բազաները, որտեղ այն արդեն կիրառված է առկա վիճակում, պետք է վերականգնվեն: Թեև դա կարող է լինել, հավանական է, որ ամբողջ բակենդ թիմը ստիպված լինի տեղականորեն նորից վերախմբագնել տվյալների բազան:
Եվ ամենատարածված ճանապարհն է`. տվյալների պրոբլեմը տեղափոխել մշակողի միջավայր և վերակառուցել տվյալների բազան, ապա ավելացնել նոր փոփոխված հավաքածու, մինչ կոտրված, որը թույլ կտա обходить պրոբլեմը:

Ընդհանուր առմամբ, որքան ավելի շատ տվյալների բազայի բնութագրերը նման են պրոդուքշն սերվերի տվյալների բազային, այնքան քիչ շանս է, որ միգրացիաների հետ պրոբլեմները առաջանան: Եվ իհարկե, նախքան փոփոխված հավաքածուն ռեպոզիտորի մեջ ուղարկելիս, արժե մի քանի անգամ մտածել, որ այն չի խախտելու որևէ բան:

Հանդիպում 3: Liquibase սկսում է կիրառվել արդեն պրոդուքշն անցնելուց հետո

Վոնեցնենք, որ թիմի ղեկավարը Պետյանին խնդրել է լիցքավորել Liquibase նախագիծը, սակայն նախագիծը արդեն պրոդուքշնում է և արդեն գոյություն ունի տվյալների բազայի կառուցվածքը:

Հետևաբար, խնդիրն այն է, որ ցանկացած նոր սերվերների կամ ծրագրավորողների մեքենաներում այս աղյուսակների տվյալները պետք է վերափոխվեն նորից, իսկ արդեն գոյություն ունեցող միջավայրն պետք է մնա համարժեք վիճակում, պատրաստ ընդունելու նոր փոփոխություններ:

Ինչպես լուծել

Այստեղ նաև բազմաթիվ ճանապարհներ կան:

Ա Head-to-head scratch script, որը պետք է ձեռքով կիրառվի նոր միջավայրի սկզբնական փուլում:
Երկրորդը՝ նվազ ակնհայտ, ունենալ Liquibase միգրացիա, որը գտնվում է այլ Liquibase Context-ում, և կիրառել այն: Մանրամասն տեղեկություններ Liquibase Context-ի մասին կարելի է գտնել այստեղ: https://www.liquibase.org/documentation/contexts.html. Ընդհանուր առմամբ, սա հետաքրքիր մեխանիզմ է, որը կարող է հաջողությամբ կիրառվել, օրինակ, թեստավորման համար:
Երրորդ ճանապարհը բաղկացած է մի քանի քայլից: Նախ պետք է ստեղծվի միգրացիա արդեն գոյություն ունեցող աղյուսակների համար: Այնուհետեւ պետք է կիրառվի որոշ միջավայրում, և այդ կերպ կստեղծվի դրա hash-ստուգանիշը: Հաջորդ քայլն է մեր ոչ դատարկ սերվերում սկսել դատարկ Liquibase աղյուսակները, և պատմությունը փոփոխությունների կիրառման աղյուսակում կարելի է ձեռքով տեղադրել «ինչպես будто կիրառված» փոփոխության գրառում արդեն տվյալների բազայում առկա փոփոխություններով: Արդյունքում, արդեն գոյություն ունեցող սերվերում պատմության հաշիվը կսկսվի 2-րդ տարբերակից, իսկ բոլոր նոր միջավայրերը կվարեն իրենց վարքը նույն կերպ:

Համար 4. Միգրացիաները դառնում են հսկայական և չեն հասցնում կատարվել

Ծառայության նախնական մշակման փուլում, սովորաբար, Liquibase-ը օգտագործվում է որպես արտաքին կախվածություն, և բոլոր միգրացիաները մշակվում են հավելվածի մեկնարկի ժամանակ: Սակայն ժամանակի ընթացքով կարող եք հանդիպել հետևյալ դեպքերին:

Միգրացիաները դառնում են շատ մեծ և բավականին երկար են կատարելու համար:
Հայտնվում է անհրաժեշտություն միգրացիայի համար տարածքային միջավայրերում, ասենք, միանգամից մի քանի տվյալների բազայի սերվերներում:
Այս դեպքում չափազանց երկար կատարումը կմեղադրի հավելվածի մեկնարկի ժամանակ: Նաեւ, յուրաքանչյուր հավելվածի օրինակին միգրացիաների կիրառումը կարող է հանգեցնել այնպիսի իրավիճակի, երբ տարբեր սերվերները գտնվում են չհամընթաց վիճակում:

Ինչպես լուծել

Այսպիսի դեպքերում ձեր նախագիծն արդեն մեծ է, գուցե անգամ մեծահասակ, և Liquibase-ը սկսում է հանդես գալ որպես առանձին արտաքին գործիք: Խոսքն այն մասին է, որ Liquibase-ը որպես գրադարան հավաքվում է jar ֆայլում և կարող է աշխատել որպես կախվածություն ներքո նախագծի, կամ ինքնուրույն:

Ինքնուրույն ռեժիմում միգրացիաների կիրառումը կարող է վստահվել ձեր CI/CD միջավայրին կամ ձեր համակարգային ադմինիստրատորների կամ տարածման մասնագետների հզոր ուսերին: Bunun üçün lazımdır Liquibase komanda xətti https://www.liquibase.org/documentation/command_line.html. Այս ռեժիմում հնարավորություն է ստեղծվում ծրագրի մեկնարկը կատարել միայն այն բանից հետո, երբ բոլոր անհրաժեշտ միգրացիաները կատարվել են:

Ամփոփում

Դա իսկապես այնպես է, որ տվյալների բազաների միգրացիաների ժամանակ մահճակալների թիվը կարող է շատ ավելին լինել, և նրանցից շատերը պահանջում են ստեղծագործ մոտեցում: Կարևորն այն է, որ եթե գործիքն ճիշտ օգտագործել, ապա այս մահճակալների մեծ մասը կարող է խուսափվել: Քոնկրետ ինձ տարբեր տեսակի խնդիրների հանդիպել է և որոշները եղել են իմ սխալների արդյունքը: Զինված միայն անուշադրության պատճառով, բայց երբեմն էլ` գործիքի հանցավոր անթերի օգտագործման պատճառով:

Ընտանիք: habr.com