DevOps-ի պրակտիկաներն աշխատում են: Մենք ինքներս համոզվեցինք դրանում, երբ 10 անգամ կրճատեցինք թողարկման տեղադրման ժամանակը: FIS Profile համակարգում, որը մենք օգտագործում ենք VTB-ում, տեղադրումն այժմ տևում է 90 րոպե, քան 10: Թողարկման ստեղծման ժամանակը նվազել է երկու շաբաթից մինչև երկու օր: Իրականացման մշտական արատների թիվը գրեթե նվազագույնի է հասել: «Ձեռքի աշխատանքից» հեռու մնալու և վաճառողից կախվածությունը վերացնելու համար մենք ստիպված էինք աշխատել հենակներով և գտնել անսպասելի լուծումներ: Ներքևում ներկայացված է մանրամասն պատմություն այն մասին, թե ինչպես ենք մենք կառուցել լիարժեք ներքին զարգացում:
Նախաբան. DevOps-ը փիլիսոփայություն է
Անցած տարվա ընթացքում մենք մեծ աշխատանք ենք կատարել VTB-ում DevOps պրակտիկայի ներքին մշակումն ու ներդրումը կազմակերպելու համար.
- Մենք կառուցել ենք ներքին զարգացման գործընթացներ 12 համակարգերի համար.
- Գործարկեցինք 15 խողովակաշար, որոնցից չորսը բերվեցին արտադրության.
- Ավտոմատացված 1445 թեստային սցենարներ;
- Մենք հաջողությամբ իրականացրեցինք մի շարք թողարկումներ, որոնք պատրաստված էին ներքին թիմերի կողմից:
Պարզվեց, որ DevSecOps-ի պրակտիկաների ներքին մշակումն ու ներդրումը կազմակերպելու ամենադժվարներից մեկը FIS Profile համակարգը է՝ մանրածախ արտադրանքի պրոցեսորը ոչ հարաբերական DBMS-ի վրա: Այնուամենայնիվ, մենք կարողացանք կառուցել մշակումը, գործարկել խողովակաշարը, տեղադրել առանձին չթողարկվող փաթեթներ արտադրանքի վրա և սովորեցինք, թե ինչպես հավաքել թողարկումները: Խնդիրը հեշտ չէր, բայց հետաքրքիր և առանց կիրառման ակնհայտ սահմանափակումների. ահա համակարգը. անհրաժեշտ է կառուցել ներքին զարգացում: Միակ պայմանը CD-ն օգտագործելն է արդյունավետ միջավայրից առաջ:
Սկզբում իրականացման ալգորիթմը թվում էր պարզ և պարզ.
- Մենք զարգացնում ենք զարգացման նախնական փորձաքննությունը և կոդերի թիմից հասնում ենք որակի ընդունելի մակարդակի՝ առանց կոպիտ թերությունների.
- Մենք հնարավորինս ինտեգրվում ենք առկա գործընթացներին.
- Կոդը ակնհայտ փուլերի միջև փոխանցելու համար մենք կտրում ենք խողովակաշարը և դրա ծայրերից մեկը մղում դեպի շարունակություն:
Այս ընթացքում անհրաժեշտ չափի մշակող թիմը պետք է հմտություններ զարգացնի և թողարկումներում իր ներդրման մասնաբաժինը հասնի ընդունելի մակարդակի: Եվ վերջ, մենք կարող ենք առաջադրանքն ավարտված համարել:
Թվում է, թե սա լիովին էներգաարդյունավետ ճանապարհ է դեպի անհրաժեշտ արդյունք. ահա DevOps-ը, ահա թիմի կատարողականի ցուցանիշները, ահա կուտակված փորձը... Բայց գործնականում մենք ևս մեկ հաստատում ստացանք, որ DevOps-ը դեռ փիլիսոփայության մասին է։ , և ոչ «կցված gitlab գործընթացին, ansible, nexus և ավելի ցածր ցուցակում»:
Եվս մեկ անգամ վերլուծելով գործողությունների ծրագիրը՝ մենք հասկացանք, որ մենք մեր ներսում կառուցում ենք մի տեսակ աութսորսինգ վաճառող: Հետևաբար, վերը նկարագրված ալգորիթմին ավելացվեց գործընթացի վերաճարտարագիտությունը, ինչպես նաև փորձաքննության զարգացումը զարգացման ողջ երթուղու երկայնքով՝ այս գործընթացում առաջատար դերի հասնելու համար: Ամենահեշտ տարբերակը չէ, բայց սա գաղափարապես ճիշտ զարգացման ճանապարհն է։
Որտեղ է սկսվում ներքին զարգացումը:
Դա ամենաբարյաց համակարգը չէր, որի հետ կարելի էր աշխատել: Ճարտարապետական առումով այն մեկ մեծ ոչ հարաբերական DBMS էր, որը բաղկացած էր բազմաթիվ առանձին գործարկվող օբյեկտներից (սկրիպտներ, ընթացակարգեր, խմբաքանակ և այլն), որոնք կանչվում էին ըստ անհրաժեշտության և աշխատում էին սև արկղի սկզբունքով. այն ստանում է հարցում և խնդիրներ։ պատասխան. Այլ դժվարությունները, որոնք արժե ուշադրություն դարձնել, ներառում են.
- Էկզոտիկ լեզու (MUMPS);
- Վահանակով ինտերֆեյս;
- Հանրաճանաչ ավտոմատացման գործիքների և շրջանակների հետ ինտեգրման բացակայություն;
- Տվյալների ծավալը տասնյակ տերաբայթներով;
- ժամում ավելի քան 2 միլիոն գործողություն;
- Նշանակություն - Բիզնես-կրիտիկական:
Միևնույն ժամանակ, մեր կողմից չկար սկզբնաղբյուրի շտեմարան: Ընդհանրապես. Փաստաթղթեր կար, բայց բոլոր հիմնական գիտելիքներն ու իրավասությունները արտաքին կազմակերպության կողմից էին:
Համակարգի մշակումը սկսել ենք յուրացնել գրեթե զրոյից՝ հաշվի առնելով դրա առանձնահատկությունները և ցածր տարածումը։ Սկսվել է 2018 թվականի հոկտեմբերին.
- Ուսումնասիրել է կոդերի ստեղծման փաստաթղթերը և հիմունքները;
- Մենք ուսումնասիրեցինք վաճառողից ստացված զարգացման կարճ դասընթացը.
- Նախնական զարգացման հմտությունների տիրապետում;
- Մենք թիմի նոր անդամների համար ուսումնական ձեռնարկ ենք կազմել.
- Մենք պայմանավորվեցինք թիմը ներառել «մարտական» ռեժիմում.
- Խնդիրը լուծվել է կոդի որակի հսկողության հետ;
- Մենք կազմակերպեցինք զարգացման ստենդ:
Մենք երեք ամիս ծախսեցինք փորձագիտություն մշակելու և համակարգում խորասուզվելու վրա, և 2019 թվականի սկզբից ներքին զարգացումը սկսեց իր շարժումը դեպի պայծառ ապագա, երբեմն դժվարությամբ, բայց վստահ և նպատակասլաց։
Պահեստի միգրացիա և ավտոմատ փորձարկումներ
DevOps-ի առաջին առաջադրանքը պահեստն է: Մենք արագ պայմանավորվեցինք հասանելիություն ապահովելու մասին, բայց անհրաժեշտ էր ներկայիս SVN-ից տեղափոխել մեկ միջքաղաքային ճյուղ դեպի մեր թիրախային Git՝ անցնելով մի քանի ճյուղերի մոդելի և Git Flow-ի մշակմամբ: Մենք նաև ունենք 2 թիմ՝ իրենց սեփական ենթակառուցվածքով, գումարած արտասահմանում վաճառողի թիմի մի մասը: Ես ստիպված էի ապրել երկու Gits-ով և ապահովել համաժամացման: Նման իրավիճակում դա երկու չարիքի փոքրագույնն էր։
Պահեստի արտագաղթը բազմիցս հետաձգվել է, այն ավարտվել է միայն ապրիլին՝ առաջնագծի գործընկերների օգնությամբ։ Git Flow-ի միջոցով մենք որոշեցինք սկզբի համար ամեն ինչ պարզ պահել և կարգավորվեցինք դասական սխեմայի վրա՝ թեժ շտկումով, մշակելով և թողարկելով: Նրանք որոշեցին լքել վարպետին (նման է՝ պրոդ): Ստորև մենք կբացատրենք, թե ինչու այս տարբերակը մեզ համար դարձավ օպտիմալ։ Որպես աշխատող օգտագործվել է վաճառողին պատկանող արտաքին պահոցը, որը սովորական է երկու թիմերի համար: Այն համաժամեցվում է ներքին պահոցի հետ՝ ըստ ժամանակացույցի: Այժմ Git-ի և Gitlab-ի միջոցով հնարավոր եղավ ավտոմատացնել գործընթացները։
Ավտոթեստերի հարցը զարմանալիորեն հեշտությամբ լուծվեց՝ մեզ տրամադրվել է պատրաստի շրջանակ։ Հաշվի առնելով համակարգի առանձնահատկությունները՝ առանձին գործողություն կոչելը բիզնես գործընթացի հասկանալի մաս էր և միևնույն ժամանակ ծառայում էր որպես միավորի թեստ։ Մնում էր միայն պատրաստել թեստի տվյալները և սահմանել սցենարները կանչելու և արդյունքները գնահատելու ցանկալի կարգը։ Գործառնական վիճակագրության, գործընթացների կրիտիկականության և գոյություն ունեցող ռեգրեսիայի մեթոդաբանության հիման վրա կազմված սցենարների ցանկը լրացվելուն պես սկսեցին հայտնվել ավտոմատ թեստեր: Այժմ մենք կարող ենք սկսել խողովակաշարի կառուցումը:
Ինչպես էր. մոդելը մինչև ավտոմատացումը
Առանձին պատմություն է իրականացման գործընթացի գոյություն ունեցող մոդելը։ Յուրաքանչյուր փոփոխություն ձեռքով փոխանցվել է որպես առանձին աճող տեղադրման փաթեթ: Հաջորդը ձեռքով գրանցումն էր Jira-ում և ձեռքով տեղադրումը միջավայրերում: Առանձին փաթեթների համար ամեն ինչ պարզ էր թվում, բայց թողարկման նախապատրաստմամբ ամեն ինչ ավելի բարդ էր:
Մոնտաժումն իրականացվել է անհատական առաքումների մակարդակով, որոնք անկախ օբյեկտներ էին։ Ցանկացած փոփոխություն նոր առաքում է։ Ի թիվս այլ բաների, հիմնական թողարկման կոմպոզիցիայի 60-70 փաթեթներին ավելացվել են 10-15 տեխնիկական տարբերակներ՝ տարբերակներ, որոնք ստացվել են թողարկումից որևէ բան ավելացնելիս կամ բացառելիս և արտացոլել վաճառքի փոփոխությունները թողարկումներից դուրս:
Առաքման մեջ գտնվող օբյեկտները համընկնում էին միմյանց հետ, հատկապես գործարկվող կոդում, որը կիսով չափ եզակի էր: Կային բազմաթիվ կախվածություններ ինչպես արդեն տեղադրված կոդի, այնպես էլ նրանից, որի տեղադրումը հենց նոր էր պլանավորվել։
Կոդի պահանջվող տարբերակը ստանալու համար անհրաժեշտ էր խստորեն պահպանել տեղադրման կարգը, որի ընթացքում օբյեկտները ֆիզիկապես վերաշարադրվել են բազմիցս՝ մոտ 10–12 անգամ։
Փաթեթների խմբաքանակ տեղադրելուց հետո ես ստիպված էի ձեռքով հետևել հրահանգներին՝ պարամետրերը սկզբնավորելու համար: Թողարկումը հավաքվել և տեղադրվել է վաճառողի կողմից: Թողարկման կազմը հստակեցվել է գրեթե մինչև իրականացման պահը, ինչը ենթադրում է «անջատող» փաթեթների ստեղծում։ Արդյունքում պաշարների մի զգալի մասը թողարկումից տեղափոխվեց թողարկում՝ «անջատումների» սեփական պոչով։
Այժմ պարզ է, որ այս մոտեցմամբ՝ փաթեթի մակարդակով ազատման գլուխկոտրուկը հավաքելով, մեկ գլխավոր մասնաճյուղը գործնական նշանակություն չուներ: Արտադրության վրա տեղադրումը տևեց մեկուկես-երկու ժամ ձեռքի աշխատանք: Լավ է, որ գոնե տեղադրողի մակարդակում նշվել է օբյեկտների մշակման կարգը. դաշտերն ու կառուցվածքները մուտքագրվել են նախքան դրանց տվյալները և ընթացակարգերը: Այնուամենայնիվ, սա միայն աշխատեց առանձին փաթեթի շրջանակներում:
Այս մոտեցման տրամաբանական արդյունքը եղան տեղադրման պարտադիր թերությունները՝ օբյեկտների ծուռ տարբերակների, անհարկի կոդի, բացակայող հրահանգների և օբյեկտների փոխադարձ ազդեցությունների տեսքով, որոնք տենդագին վերացվում էին թողարկումից հետո:
Առաջին թարմացումները. հավաքում և առաքում
Ավտոմատացումը սկսվեց այս երթուղու երկայնքով խողովակի միջոցով ծածկագիրը փոխանցելով.
- Վերցրեք պատրաստի առաքումը պահեստից;
- Տեղադրեք այն հատուկ միջավայրում;
- Գործարկել ավտոմատ փորձարկումներ;
- Գնահատեք տեղադրման արդյունքը;
- Զանգահարեք հետևյալ խողովակաշարը փորձարկման հրամանի կողքին:
Հաջորդ խողովակաշարը պետք է գրանցի առաջադրանքը Jira-ում և սպասի հրամանների բաշխմանը ընտրված փորձարկման օղակներին, որոնք կախված են առաջադրանքի իրականացման ժամանակից: Տիգեր - նամակ տվյալ հասցեով առաքման պատրաստակամության մասին: Սա, իհարկե, ակնհայտ հենակ էր, բայց ես պետք է ինչ-որ տեղից սկսեի։ 2019 թվականի մայիսին կոդի փոխանցումը սկսվեց մեր միջավայրի ստուգումներով: Գործընթացը սկսվել է, մնում է այն պատշաճ ձևի բերել.
- Յուրաքանչյուր փոփոխություն կատարվում է առանձին ճյուղով, որը համապատասխանում է տեղադրման փաթեթին և միաձուլվում է թիրախային գլխավոր ճյուղին.
- Խողովակաշարի գործարկման գործարկիչը նոր commit-ի հայտնվելն է հիմնական մասնաճյուղում միաձուլման հարցման միջոցով, որը փակվում է ներքին թիմի սպասարկողների կողմից.
- Պահեստները համաժամացվում են հինգ րոպեն մեկ անգամ.
- Տեղադրման փաթեթի հավաքումը սկսված է՝ օգտագործելով վաճառողից ստացված մոնտաժողը:
Դրանից հետո արդեն գոյություն ունեին ծածկագիրը ստուգելու և փոխանցելու, խողովակը գործարկելու և մեր կողմից հավաքելու քայլեր:
Այս տարբերակը գործարկվել է հուլիսին։ Անցման դժվարությունները հանգեցրին վաճառողի և առաջին գծի որոշակի դժգոհության, բայց հաջորդ ամսվա ընթացքում մեզ հաջողվեց հեռացնել բոլոր կոպիտ եզրերը և գործընթաց հաստատել թիմերի միջև: Մենք այժմ ունենք հավաքում ըստ պարտավորության և առաքման:
Օգոստոսին մեզ հաջողվեց ավարտել մեր խողովակաշարով արտադրության վրա առանձին փաթեթի առաջին տեղադրումը, և սեպտեմբերից, առանց բացառության, առանձին չթողարկվող փաթեթների բոլոր տեղադրումները կատարվում էին մեր CD գործիքի միջոցով: Բացի այդ, մեզ հաջողվեց հասնել ներքին առաջադրանքների մասնաբաժինը թողարկման կազմի 40%-ում ավելի փոքր թիմով, քան վաճառողը. սա միանշանակ հաջողություն է: Մնում էր ամենալուրջ խնդիրը՝ հավաքել և տեղադրել թողարկումը։
Վերջնական լուծում՝ կուտակային տեղադրման փաթեթներ
Մենք հիանալի հասկանում էինք, որ վաճառողի հրահանգների սկրիպտավորումը այդքան էլ ավտոմատացում էր, մենք պետք է վերանայեինք գործընթացը: Լուծումն ակնհայտ էր՝ թողարկման ճյուղից հավաքել կուտակային պաշար՝ պահանջվող տարբերակների բոլոր օբյեկտներով։
Մենք սկսեցինք հայեցակարգի ապացույցից. մենք ձեռքով հավաքեցինք թողարկման փաթեթը՝ համաձայն անցյալի իրականացման բովանդակության և տեղադրեցինք այն մեր միջավայրում: Ամեն ինչ ստացվեց, հայեցակարգը ստացվեց կենսունակ։ Այնուհետև մենք լուծեցինք սկզբնավորման կարգավորումների սկրիպտավորման խնդիրը և դրանք ներառելու commit-ում: Մենք պատրաստեցինք նոր փաթեթ և փորձարկեցինք այն թեստավորման միջավայրերում՝ որպես եզրագծի թարմացման մաս: Տեղադրումը հաջող էր, թեև իրականացվող թիմի մեկնաբանությունների լայն շրջանակով: Բայց գլխավորն այն է, որ մեզ տրվել է թույլտվություն՝ արտադրություն սկսելու նոյեմբերյան թողարկումում՝ մեր ժողովով:
Մեկ ամսից քիչ ժամանակ է մնացել, ձեռքով ընտրված պաշարները հստակ ակնարկում էին, որ ժամանակը սպառվում է: Նրանք որոշել են շինարարությունը պատրաստել արձակող ճյուղից, բայց ինչո՞ւ պետք է այն առանձնացվի։ Մենք չունենք Prod-ի նման, և գոյություն ունեցող մասնաճյուղերը լավ չեն. շատ ավելորդ կոդ կա: Մեզ շտապ պետք է կրճատել պրոդ-լայքերը, և սա ավելի քան երեք հազար պարտավորություն է: Ձեռքով հավաքելը ամենևին էլ տարբերակ չէ։ Մենք ուրվագծեցինք մի սցենար, որն անցնում է արտադրանքի տեղադրման մատյանում և հավաքում է մասնաճյուղի պարտավորությունները: Երրորդ անգամ այն ճիշտ աշխատեց, և «ֆայլով ավարտելուց» հետո մասնաճյուղը պատրաստ էր։
Տեղադրման փաթեթի համար մենք գրեցինք մեր սեփական շինարարը և ավարտեցինք այն մեկ շաբաթում: Այնուհետև մենք ստիպված էինք փոփոխել տեղադրիչը համակարգի հիմնական ֆունկցիոնալությունից, քանի որ այն բաց կոդով է: Մի շարք ստուգումներից և փոփոխություններից հետո արդյունքը հաջողված համարվեց։ Միևնույն ժամանակ ձևավորվեց թողարկման կազմը, որի ճիշտ տեղադրման համար անհրաժեշտ էր թեստային սխեման հավասարեցնել արտադրականին, և դրա համար գրվեց առանձին սցենար:
Բնականաբար, առաջին տեղադրման վերաբերյալ շատ մեկնաբանություններ եղան, բայց ընդհանուր առմամբ կոդը աշխատեց։ Եվ մոտավորապես երրորդ տեղադրումից հետո ամեն ինչ սկսեց լավ տեսք ունենալ։ Օբյեկտների կոմպոզիցիայի հսկողությունը և տարբերակի կառավարումը վերահսկվում էին առանձին՝ ձեռքով ռեժիմով, ինչն այս փուլում միանգամայն արդարացված էր։
Լրացուցիչ մարտահրավեր էր չթողարկվողների մեծ թիվը, որոնք պետք է հաշվի առնվեին: Բայց Prod-ի նման ճյուղի և Rebase-ի հետ առաջադրանքը դարձավ թափանցիկ:
Առաջին անգամ, արագ և առանց սխալների
Մենք թողարկմանը մոտեցանք լավատեսական վերաբերմունքով և մեկ տասնյակից ավելի հաջող տեղադրումներով տարբեր սխեմաների վրա: Բայց վերջնաժամկետից բառացիորեն մեկ օր առաջ պարզվեց, որ վաճառողը չի ավարտել աշխատանքը՝ թողարկումը տեղադրման համար ընդունված ձևով պատրաստելու համար։ Եթե ինչ-ինչ պատճառներով մեր կառուցումը չաշխատի, թողարկումը կխափանվի: Ավելին, մեր ջանքերով, ինչը հատկապես տհաճ է։ Նահանջի ճանապարհ չունեինք։ Հետևաբար, մենք մտածեցինք այլընտրանքային տարբերակների շուրջ, պատրաստեցինք գործողությունների պլաններ և սկսեցինք տեղադրումը:
Զարմանալի է, որ ամբողջ թողարկումը, որը բաղկացած է ավելի քան 800 օբյեկտից, ճիշտ է սկսվել առաջին անգամ և ընդամենը 10 րոպեում։ Մենք մեկ ժամ ծախսեցինք՝ ստուգելով տեղեկամատյանները՝ փնտրելով սխալներ, բայց չգտանք:
Ամբողջ հաջորդ օրը թողարկման չաթում լռություն տիրեց՝ իրականացման հետ կապված խնդիրներ չկան, խեղաթյուրված տարբերակներ կամ «անպատշաճ» կոդ: Նույնիսկ ինչ-որ կերպ անհարմար էր: Հետագայում որոշ մեկնաբանություններ ի հայտ եկան, բայց համեմատած այլ համակարգերի և նախկին փորձի հետ, դրանց թիվն ու առաջնահերթությունը նկատելիորեն ավելի քիչ էին։
Կուտակային էֆեկտի լրացուցիչ ազդեցությունը հավաքման և փորձարկման որակի բարձրացումն էր: Ամբողջական թողարկման բազմաթիվ տեղադրումների շնորհիվ ժամանակին հայտնաբերվեցին կառուցման թերությունները և տեղակայման սխալները: Ամբողջական թողարկման կոնֆիգուրացիաներով փորձարկումը հնարավորություն է տվել լրացուցիչ հայտնաբերել օբյեկտների փոխադարձ ազդեցության թերությունները, որոնք չեն երևացել աստիճանական տեղադրման ժամանակ: Դա միանշանակ հաջողություն էր, հատկապես հաշվի առնելով թողարկման մեջ մեր 57% ներդրումը:
Ամփոփում և եզրակացություններ
Մեկ տարուց պակաս ժամանակում մեզ հաջողվեց.
- Կառուցեք լիարժեք ներքին զարգացում, օգտագործելով էկզոտիկ համակարգ.
- Վերացնել կրիտիկական վաճառողից կախվածությունը;
- Գործարկել CI/CD-ն շատ անբարյացակամ ժառանգության համար.
- Բարձրացնել իրականացման գործընթացները նոր տեխնիկական մակարդակի.
- Զգալիորեն նվազեցնել տեղակայման ժամանակը;
- Զգալիորեն նվազեցնել կատարման սխալների քանակը.
- Վստահորեն հայտարարեք ձեզ որպես զարգացման առաջատար փորձագետ:
Իհարկե, նկարագրվածի մեծ մասը կարծես ուղղակի հիմարություն է, բայց սրանք համակարգի առանձնահատկություններն են և գործընթացի սահմանափակումները, որոնք առկա են դրանում: Այս պահին փոփոխությունները ազդել են IS Profile-ի արտադրանքների և ծառայությունների վրա (հիմնական հաշիվներ, պլաստիկ քարտեր, խնայողական հաշիվներ, էսքրո, կանխիկ վարկեր), սակայն հնարավոր է, որ մոտեցումը կարող է կիրառվել ցանկացած IS-ի նկատմամբ, որի համար դրված է DevOps պրակտիկաների ներդրման խնդիր: Կուտակային մոդելը կարող է ապահով կերպով կրկնօրինակվել բազմաթիվ առաքումների հետագա իրականացման համար (ներառյալ չթողարկվողները):
Source: www.habr.com