Ինչպես չկրակել ձեր ոտքին Liquibase-ի միջոցով

Դա երբեք տեղի չի ունեցել, և ահա նորից:

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

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

Liquibase-ը և Flyway-ը Java աշխարհում հարաբերական կառույցների տարբերակների վերահսկման խնդիրների լուծման հիմնական մրցակցող տեխնոլոգիաներն են: Առաջինը լիովին անվճար է, գործնականում այն ​​ավելի հաճախ ընտրվում է օգտագործման համար, ինչի պատճառով էլ հրապարակման հերոս է ընտրվել 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. Եթե սկսել եք օգտագործել միգրացիոն գործիքներ, թույլ մի տվեք ձեռքով ուղղումներ կատարել տվյալների բազայի կառուցվածքում

Ինչպես ասում են՝ «Մի անգամ Պերսիլ, միշտ Պերսիլ»: Եթե ​​ձեր հավելվածի բազան սկսել է կառավարվել Liquibase գործիքների կողմից, ցանկացած ձեռքի փոփոխություն անմիջապես հանգեցնում է անհամապատասխան վիճակի, և փոփոխվողների նկատմամբ վստահության մակարդակը դառնում է զրոյական: Պոտենցիալ ռիսկեր՝ տվյալների բազայի վերականգնման վրա ծախսված մի քանի ժամ, վատագույն դեպքում՝ մեռած սերվեր: Եթե ​​ձեր թիմն ունի «հին դպրոցի» DBA ճարտարապետ, համբերատար և մտածված բացատրեք նրան, թե որքան վատ կլինի, եթե նա պարզապես խմբագրի տվյալների բազան իր ձևով պայմանական SQL Developer-ից:

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

Եթե ​​մեկ այլ ծրագրավորող քաշեց և կիրառեց փոփոխություններ, որը կխմբագրվի ավելի ուշ, նա անպայման կհիշի ձեզ բարի խոսքով, երբ դիմումը մեկնարկելու ժամանակ սխալ ստանա: Եթե ​​փոփոխությունները խմբագրելը ինչ-որ կերպ դուրս է գալիս մշակման մեջ, դուք ստիպված կլինեք իջնել թեժ շտկումների սայթաքուն լանջի վրայով: Խնդիրի էությունը հիմնված է փոփոխությունների վավերացման վրա հաշ գումարով` Liquibase-ի հիմնական մեխանիզմը: Փոփոխությունների հավաքածուի կոդը խմբագրելիս հեշ գումարը փոխվում է: Փոփոխությունների հավաքածուների խմբագրումը հնարավոր է միայն այն դեպքում, երբ հնարավոր է ամբողջ տվյալների բազան զրոյից տեղակայել՝ առանց տվյալների կորստի: Այս դեպքում SQL կամ XML կոդի վերամշակումը, ընդհակառակը, կարող է հեշտացնել կյանքը, ավելի ընթեռնելի դարձնել միգրացիաները։ Օրինակ կարող է լինել մի իրավիճակ, երբ հավելվածի սկզբում աղբյուրի տվյալների բազայի սխեման համակարգվում էր թիմի ներսում:

4. Հնարավորության դեպքում ստուգեք տվյալների բազայի կրկնօրինակները

Այստեղ, կարծում եմ, ամեն ինչ պարզ է։ Եթե ​​հանկարծ միգրացիան անհաջող լինի, ամեն ինչ կարելի է հետ վերադարձնել։ Liquibase-ն ունի rollback գործիք, բայց հետադարձ սկրիպտները նույնպես գրվում են հենց մշակողի կողմից, և դրանք կարող են խնդիրներ ունենալ նույն հավանականությամբ, ինչ հիմնական փոփոխականների սկրիպտներում։ Սա նշանակում է, որ այն անվտանգ խաղալը կրկնօրինակումներով ամեն դեպքում օգտակար է:

5. Հնարավորության դեպքում օգտագործեք տվյալների բազայի ստուգված կրկնօրինակները

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

6. Զրուցեք թիմի այլ մշակողների հետ

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

7. Մտածիր, թե ինչ ես անում։

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

Ծուղակ

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

Իրավիճակ 1. Երկու մշակողներ միաժամանակ փորձում են ավելացնել նոր փոփոխություններ

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

Ինչպես որոշել

1. Ինչ-որ կերպ, գործընկերները պետք է պայմանավորվեն, թե ինչ հաջորդականությամբ պետք է ընթանան իրենց փոփոխությունները, ասենք, նախ պետք է կիրառվի Պետինը:
2. Մեկը պետք է լցնի մյուսին և նշի Vasya-ի փոփոխությունները 5-րդ տարբերակով: Դա կարելի է անել Cherry Pick-ի կամ կոկիկ միաձուլման միջոցով:
3. Փոփոխություններից հետո անպայման ստուգեք կատարված գործողությունների վավերականությունը։
   Փաստորեն, Liquibase մեխանիզմները թույլ կտան պահեստում ունենալ 4 տարբերակի երկու փոփոխություններ, որպեսզի կարողանաք ամեն ինչ թողնել այնպես, ինչպես կա: Այսինքն՝ դուք պարզապես կունենաք 4-րդ տարբերակի երկու տարբերակ՝ տարբեր անուններով։ Այս մոտեցմամբ տվյալների բազայի տարբերակները հետագայում նավարկելը շատ դժվար է դառնում:

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

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

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

Դեպք 2. Տվյալների վրա հիմնված միգրացիա

Ենթադրենք, դուք չեք կարող օգտագործել տվյալների բազայի կրկնօրինակները կենդանի սերվերներից: Պետյան ստեղծեց փոփոխություններ, փորձարկեց այն տեղական մակարդակում և լիովին վստահ լինելով, որ նա իրավացի էր, ծրագրավորողին խնդրանք ներկայացրեց: Համենայն դեպս, նախագծի ղեկավարը պարզաբանեց՝ արդյոք Պետյան ստուգե՞լ է այն, ապա լցրել այն։ Սակայն զարգացման սերվերի վրա տեղակայումն ընկել է:

Իրականում դա հնարավոր է, և ոչ ոք զերծ չէ դրանից։ Դա տեղի է ունենում, եթե աղյուսակի կառուցվածքի փոփոխությունները ինչ-որ կերպ կապված են տվյալների բազայի հատուկ տվյալների հետ: Ակնհայտ է, որ եթե Petya-ի տվյալների բազան լցված է միայն թեստային տվյալներով, ապա այն չի կարող ընդգրկել բոլոր խնդրահարույց դեպքերը: Օրինակ, աղյուսակը ջնջելիս պարզվում է, որ այլ աղյուսակներում կան գրառումներ արտաքին բանալիով` կապված ջնջվողի գրառումների հետ: Կամ սյունակի տեսակը փոխելիս պարզվում է, որ տվյալների 100%-ը չի կարող փոխակերպվել նոր տեսակի։

Ինչպես որոշել

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

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

Իրավիճակ 3. Liquibase-ը սկսում է օգտագործվել արտադրության մեջ մտնելուց հետո

Ենթադրենք, թիմի ղեկավարը խնդրել է Petya-ին ներառել Liquibase-ը նախագծում, սակայն նախագիծն արդեն արտադրվում է, և կա տվյալների բազայի արդեն գոյություն ունեցող կառուցվածք։

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

Ինչպես որոշել

Կան նաև մի քանի եղանակներ.

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

Սցենար 4. Միգրացիան դառնում է հսկայական և չի կարող շարունակվել

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

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

Ինչպես որոշել

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

Անցանց, դուք կարող եք միգրացիաների կիրառումը թողնել ձեր CI/CD միջավայրին կամ ձեր sysadmins/deployers-ի ուժեղ ուսերին: Դա անելու համար ձեզ հարկավոր է Liquibase հրամանի տողը https://www.liquibase.org/documentation/command_line.html. Այս ռեժիմում հնարավոր է դառնում գործարկել հավելվածը բոլոր անհրաժեշտ միգրացիաների ավարտից հետո:

Արտադրողականություն

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

Source: www.habr.com