Մենք մշակեցինք DevOps-ը, որքան կարող էինք: Մենք 8 հոգի էինք, իսկ Վասյան ամենաթեժն էր Windows-ում։ Հանկարծ Վասյան հեռացավ, և ես խնդիր ունեի գործարկել նոր նախագիծ, որն ապահովված էր Windows-ի մշակմամբ։ Երբ ես սեղանի վրա գցեցի Windows-ի մշակման ողջ փաթեթը, հասկացա, որ իրավիճակը ցավալի է...
Այսպես է սկսվում պատմությունը Ալեքսանդրա Սինչինովա մասին . Երբ Windows-ի առաջատար մասնագետը հեռացավ ընկերությունից, Ալեքսանդրը մտածում էր՝ ինչ անել հիմա։ Անցեք Linux-ին, իհարկե: Ալեքսանդրը ձեզ կպատմի, թե ինչպես է իրեն հաջողվել ստեղծել նախադեպ և Windows-ի մշակման մի մասը փոխանցել Linux-ին՝ օգտագործելով ավարտված նախագծի օրինակը 100 վերջնական օգտագործողների համար:
Ինչպե՞ս հեշտությամբ և առանց ջանքերի նախագիծ հասցնել RPM-ին՝ օգտագործելով TFS, Puppet, Linux .NET միջուկը: Ինչպե՞ս աջակցել նախագծի տվյալների բազայի տարբերակմանը, եթե մշակող թիմն առաջին անգամ լսում է Postgres և Flyway բառերը, և վերջնաժամկետը վաղը հաջորդող օրն է: Ինչպե՞ս ինտեգրվել Docker-ի հետ: Ինչպե՞ս դրդել .NET ծրագրավորողներին հրաժարվել Windows-ից և սմուզիներից՝ հօգուտ Puppet-ի և Linux-ի: Ինչպե՞ս լուծել գաղափարական հակամարտությունները, եթե չկան Windows-ը արտադրության մեջ պահպանելու ոչ ուժ, ոչ ցանկություն, ոչ ռեսուրսներ: Այս մասին, ինչպես նաև Web Deploy-ի, փորձարկման, CI-ի, գոյություն ունեցող նախագծերում TFS-ի օգտագործման պրակտիկայի և, իհարկե, կոտրված հենակների և աշխատանքային լուծումների մասին՝ Ալեքսանդրի զեկույցի սղագրության մեջ։
Այսպիսով, Վասյան հեռացավ, խնդիրն իմ վրա է, մշակողները անհամբեր սպասում են պատառաքաղներով։ Երբ վերջապես հասկացա, որ Վասյային չեն կարող վերադարձնել, ես գործի անցա։ Սկզբից ես գնահատեցի Win VM-ների տոկոսը մեր նավատորմի մեջ: Հաշիվը Windows-ի օգտին չէր։
Քանի որ մենք ակտիվորեն զարգացնում ենք DevOps-ը, ես հասկացա, որ ինչ-որ բան պետք է փոխել նոր հավելվածի մատուցման մոտեցումներում։ Միայն մեկ լուծում կար՝ հնարավորության դեպքում ամեն ինչ փոխանցիր Linux-ին։ Google-ն ինձ օգնեց. այն ժամանակ .Net-ն արդեն տեղափոխված էր Linux-ում, և ես հասկացա, որ սա է լուծումը:
Ինչու՞ .NET միջուկը Linux-ի հետ համատեղ:
Դրա համար մի քանի պատճառ կար. «Փող վճարելու» և «չվճարելու» միջև մեծամասնությունը կընտրի երկրորդը՝ ինձ նման։ MSDB-ի լիցենզիան արժե մոտ $1, իսկ Windows վիրտուալ մեքենաների նավատորմի պահպանումն արժե հարյուրավոր դոլարներ: Խոշոր ընկերության համար սա մեծ ծախս է։ Ահա թե ինչու խնայողություն - առաջին պատճառը. Ոչ թե ամենակարեւորը, այլ նշանակալիցներից մեկը։
Windows վիրտուալ մեքենաները ավելի շատ ռեսուրսներ են վերցնում, քան իրենց Linux եղբայրները. դրանք ծանր են. Հաշվի առնելով խոշոր ընկերության մասշտաբները, մենք ընտրեցինք Linux-ը:
Համակարգը պարզապես ինտեգրված է գոյություն ունեցող CI-ում. Մենք մեզ համարում ենք առաջադեմ DevOps, մենք օգտագործում ենք Bamboo, Jenkins և GitLab CI, ուստի մեր աշխատանքի մեծ մասն աշխատում է Linux-ով:
Վերջին պատճառն այն է հարմար ուղեկցություն. Պետք էր իջեցնել «ուղեկցորդների» մուտքի արգելքը՝ այն տղաները, ովքեր հասկանում են տեխնիկական մասը, ապահովում են անխափան սպասարկում և սպասարկում են երկրորդ գծից: Նրանք արդեն ծանոթ էին Linux փաթեթին, ուստի նրանց համար շատ ավելի հեշտ է հասկանալ, աջակցել և պահպանել նոր արտադրանքը, քան լրացուցիչ ռեսուրսներ ծախսել Windows պլատֆորմի ծրագրային ապահովման նույն ֆունկցիոնալությունը հասկանալու համար:
Պահանջներ
Նախ եւ առաջ - նոր լուծման հարմարավետությունը մշակողների համար. Նրանցից ոչ բոլորն էին պատրաստ փոփոխությունների, հատկապես այն բանից հետո, երբ հնչեց Linux բառը: Մշակողները ցանկանում են իրենց սիրելի Visual Studio-ն՝ TFS-ը հավաքների և սմուզիների համար ավտոմատ թեստերով: Նրանց համար կարևոր չէ, թե ինչպես է տեղի ունենում արտադրություն առաքումը: Ուստի մենք որոշեցինք չփոխել սովորական գործընթացը և ամեն ինչ անփոփոխ թողնել Windows-ի մշակման համար։
Պահանջվում է նոր նախագիծ ինտեգրվել առկա CI-ին. Ռելսերն արդեն այնտեղ էին, և բոլոր աշխատանքները պետք է կատարվեին՝ հաշվի առնելով կոնֆիգուրացիայի կառավարման համակարգի պարամետրերը, ընդունված առաքման ստանդարտները և մոնիտորինգի համակարգերը։
Աջակցության և շահագործման հեշտությունը, որպես տարբեր ստորաբաժանումների և աջակցության բաժնի բոլոր նոր մասնակիցների համար նվազագույն մուտքի շեմի պայման:
Վերջնաժամկետ - երեկ.
Win Development Group
Ինչի՞ հետ էր աշխատում Windows-ի թիմն այն ժամանակ:
Հիմա դա կարող եմ վստահորեն ասել IdentityServer4 նման հնարավորություններով ADFS-ին անվճար այլընտրանք է կամ ինչ Entity Framework Core - դրախտ ծրագրավորողի համար, որտեղ պետք չէ անհանգստանալ SQL սկրիպտներ գրելով, այլ տվյալների բազայում հարցումները նկարագրել OOP տերմիններով: Բայց հետո, գործողությունների ծրագրի քննարկման ժամանակ, ես նայեցի այս կույտին, կարծես շումերական սեպագիր լիներ՝ ճանաչելով միայն PostgreSQL-ն և Git-ը:
Այն ժամանակ մենք ակտիվորեն օգտագործում էինք Տիկնիկ որպես կոնֆիգուրացիայի կառավարման համակարգ: Մեր նախագծերի մեծ մասում մենք օգտագործել ենք GitLab CI, Առաձգական, հավասարակշռված բարձր բեռնված ծառայությունների օգտագործումը HAProxy վերահսկում էր ամեն ինչ Zabbix- ը, կապաններ Գրաֆանա и Պրոմեթեւս, Jaeger, և այս ամենը պտտվում էր երկաթի կտորների վրա HP c ESXi մասին VMware. Բոլորը գիտեն դա՝ ժանրի դասական:
Եկեք նայենք և փորձենք հասկանալ, թե ինչ է տեղի ունեցել մինչ այս բոլոր միջամտությունները սկսելը։
Ինչ է պատահել
TFS-ը բավականին հզոր համակարգ է, որը ոչ միայն կոդ է հաղորդում մշակողից մինչև վերջնական արտադրության մեքենա, այլև ունի մի շարք տարբեր ծառայությունների հետ շատ ճկուն ինտեգրման համար.
Նախկինում դրանք ամուր պատուհաններ էին: TFS-ն օգտագործում էր մի քանի Build գործակալներ, որոնք օգտագործվում էին բազմաթիվ նախագծեր հավաքելու համար։ Յուրաքանչյուր գործակալ ունի 3-4 աշխատող՝ առաջադրանքները զուգահեռացնելու և գործընթացը օպտիմալացնելու համար: Այնուհետև, թողարկման պլանների համաձայն, TFS-ը թարմ թխված Build-ը հասցրեց Windows հավելվածի սերվերին:
Ինչի՞ էինք ուզում հասնել։
Մենք օգտագործում ենք TFS առաքման և զարգացման համար, և հավելվածը գործարկում ենք Linux Application սերվերի վրա, և նրանց միջև ինչ-որ կախարդանք կա: Սա Կախարդական տուփ և առջևում գործի աղն է: Նախքան այն առանձնացնելը, ես մի քայլ կանեմ մի կողմ և մի քանի խոսք կասեմ հավելվածի մասին:
Ծրագիր
Հավելվածն ապահովում է կանխավճարային քարտերի հետ աշխատելու գործառույթ:
հաճախորդ
Կային երկու տեսակի օգտատերեր. Առաջին մուտք է ստացել SSL SHA-2 վկայագրի միջոցով մուտք գործելով: U երկրորդը մուտք է եղել մուտքի և գաղտնաբառի միջոցով:
HAProxy
Այնուհետև հաճախորդի հարցումը գնաց HAProxy, որը լուծեց հետևյալ խնդիրները.
- առաջնային թույլտվություն;
- SSL դադարեցում;
- HTTP հարցումների կարգավորում;
- հեռարձակման հարցումներ.
Հաճախորդի վկայականը ստուգվել է շղթայի երկայնքով: Մենք - իշխանություն և մենք կարող ենք դա մեզ թույլ տալ, քանի որ մենք ինքներս սերտիֆիկատներ ենք տրամադրում սպասարկող հաճախորդներին:
Ուշադրություն դարձրեք երրորդ կետին, մի փոքր ուշ կանդրադառնանք դրան։
backend
Նրանք նախատեսում էին ստեղծել backend-ը Linux-ում: Backend-ը փոխազդում է տվյալների բազայի հետ, բեռնում է արտոնությունների անհրաժեշտ ցանկը և այնուհետև, կախված նրանից, թե ինչ արտոնություններ ունի լիազորված օգտվողը, հնարավորություն է տալիս ստորագրել ֆինանսական փաստաթղթերը և ուղարկել դրանք կատարման, կամ ստեղծել ինչ-որ տեսակի հաշվետվություն:
Խնայողություններ HAProxy-ով
Ի լրումն երկու համատեքստերի, որոնցով յուրաքանչյուր հաճախորդ նավարկեց, կար նաև ինքնության համատեքստ: IdentityServer4 պարզապես թույլ է տալիս մուտք գործել, սա անվճար և հզոր անալոգ է ADFS - Active Directory Ֆեդերացիայի ծառայություններ.
Ինքնության հարցումը մշակվել է մի քանի փուլով: Առաջին քայլ - հաճախորդ մտավ հետնամաս, որը շփվում էր այս սերվերի հետ և ստուգում հաճախորդի համար նշանի առկայությունը: Եթե այն չի գտնվել, հարցումը հետ է վերադարձվել այն համատեքստին, որտեղից այն եկել է, բայց վերահղումով, իսկ վերահղմամբ այն անցել է նույնականացման:
Երկրորդ քայլ - հարցումը ստացվել է դեպի IdentityServer-ի թույլտվության էջ, որտեղ հաճախորդը գրանցվեց, և այդ երկար սպասված նշանը հայտնվեց IdentityServer տվյալների բազայում:
Երրորդ քայլ - հաճախորդը վերահղվել է հետ այն համատեքստին, որտեղից այն եկել է:
IdentityServer4-ն ունի մի առանձնահատկություն. այն վերադարձնում է վերադարձի հարցման պատասխանը HTTP-ի միջոցով. Անկախ նրանից, թե որքան ենք մենք պայքարում սերվերի տեղադրման հետ, անկախ նրանից, թե որքանով ենք մենք ինքներս մեզ պարզաբանում փաստաթղթերով, ամեն անգամ մենք ստանում էինք հաճախորդի նախնական հարցում HTTPS-ի միջոցով ստացված URL-ով, և IdentityServer-ը վերադարձնում էր նույն համատեքստը, բայց HTTP-ով: Մենք ցնցված էինք։ Եվ այս ամենը ինքնության համատեքստի միջոցով փոխանցեցինք HAProxy-ին, իսկ վերնագրերում մենք պետք է փոփոխեինք HTTP արձանագրությունը HTTPS-ի։
Ո՞րն է բարելավումը և որտեղ եք խնայել:
Մենք գումար խնայեցինք՝ օգտագործելով օգտատերերի խմբի, ռեսուրսների թույլտվության անվճար լուծում, քանի որ մենք IdentityServer4-ը որպես առանձին հանգույց չենք տեղադրել առանձին հատվածում, այլ այն օգտագործել ենք այն նույն սերվերի հետին պլանի հետ միասին, որտեղ աշխատում է հավելվածի հետնամասը։ .
Ինչպես այն պետք է աշխատի
Այսպիսով, ինչպես խոստացել էի - Magic Box: Մենք արդեն հասկանում ենք, որ մենք երաշխավորված ենք շարժվել դեպի Linux։ Եկեք ձևակերպենք կոնկրետ խնդիրներ, որոնք լուծումներ էին պահանջում։
Տիկնիկային դրսևորումներ. Ծառայությունների և հավելվածների կազմաձևումը մատուցելու և կառավարելու համար պետք է գրվեին հիանալի բաղադրատոմսեր: Մատիտի գլան պերճախոս ցույց է տալիս, թե որքան արագ և արդյունավետ է դա արվել:
Առաքման եղանակ. Ստանդարտը RPM է: Բոլորը հասկանում են, որ Linux-ում դուք չեք կարող անել առանց դրա, բայց նախագիծն ինքնին, հավաքվելուց հետո, գործարկվող DLL ֆայլերի մի շարք էր: Նրանք մոտ 150-ն էին, նախագիծը բավականին բարդ էր։ Միակ ներդաշնակ լուծումը այս երկուականը RPM-ի մեջ փաթեթավորելն է և դրանից հավելվածը տեղակայելը:
Տարբերակում. Մենք ստիպված էինք շատ հաճախ թողարկել, և մենք պետք է որոշեինք, թե ինչպես ձևավորել փաթեթի անվանումը: Սա TFS-ի հետ ինտեգրման մակարդակի հարց է: Մենք ունեինք build գործակալ Linux-ում: Երբ TFS-ն առաջադրանք է ուղարկում մշակողին՝ աշխատողին, Build գործակալին, այն նաև փոխանցում է փոփոխականների մի խումբ, որոնք հայտնվում են մշակման գործընթացի միջավայրում: Այս միջավայրի փոփոխականները պարունակում են Build-ի անունը, տարբերակի անվանումը և այլ փոփոխականներ: Այս մասին ավելին կարդացեք «RPM փաթեթի կառուցում» բաժնում:
TFS-ի կարգավորում եկել է խողովակաշարի ստեղծմանը: Նախկինում մենք հավաքում էինք Windows-ի բոլոր նախագծերը Windows գործակալների վրա, բայց հիմա հայտնվում է Linux գործակալ՝ Build գործակալ, որը պետք է ներառվի build խմբի մեջ, հարստացվի որոշ արտեֆակտներով և ասի, թե ինչ տեսակի նախագծեր կկառուցվեն այս Build գործակալի վրա։ և ինչ-որ կերպ փոփոխել խողովակաշարը:
IdentityServer. ADFS-ը մեր ճանապարհը չէ, մենք գնում ենք բաց կոդով:
Եկեք անցնենք բաղադրիչների միջով:
Կախարդական տուփ
Բաղկացած է չորս մասից.
Linux Build գործակալ. Linux, քանի որ մենք դրա համար ենք կառուցում, դա տրամաբանական է: Այս հատվածը կատարվել է երեք քայլով.
- Կարգավորել աշխատողներին և ոչ միայնակ, քանի որ նախագծի վրա բաշխված աշխատանք էր սպասվում:
- Տեղադրեք .NET Core 1.x. Ինչու՞ 1.x, երբ 2.0-ն արդեն հասանելի է ստանդարտ պահեստում: Որովհետև երբ մենք սկսեցինք զարգացումը, կայուն տարբերակը 1.09 էր, և որոշվեց դրա տակ կառուցել նախագիծը։
- Git 2.x.
RPM-պահեստ. RPM փաթեթները պետք է ինչ-որ տեղ պահվեն: Ենթադրվում էր, որ մենք կօգտագործենք նույն կորպորատիվ RPM պահոցը, որը հասանելի է բոլոր Linux հոսթներին: Այդպես էլ արեցին։ Պահեստի սերվերը կազմաձևված է վեբհուք որը ներբեռնել է անհրաժեշտ RPM փաթեթը նշված վայրից: Փաթեթի տարբերակը զեկուցվել է webhook-ին Build գործակալի կողմից:
GitLab Ուշադրություն. GitLab-ն այստեղ օգտագործվում է ոչ թե մշակողների, այլ գործառնությունների բաժնի կողմից՝ վերահսկելու հավելվածների տարբերակները, փաթեթի տարբերակները, վերահսկելու բոլոր Linux մեքենաների կարգավիճակը, և այն պահում է բաղադրատոմսը՝ բոլոր Puppet-ի մանիֆեստները:
Տիկնիկ — լուծում է բոլոր վիճահարույց խնդիրները և մատուցում է հենց այն կոնֆիգուրացիան, որը ցանկանում ենք Gitlab-ից:
Մենք սկսում ենք սուզվել: Ինչպե՞ս է աշխատում DLL-ի առաքումը RPM-ին:
DDL-ի առաքում RPM-ին
Ենթադրենք, մենք ունենք .NET-ի զարգացման ռոք աստղ: Այն օգտագործում է Visual Studio-ն և ստեղծում է թողարկման մասնաճյուղ: Դրանից հետո այն վերբեռնում է Git-ում, իսկ Git-ն այստեղ TFS էություն է, այսինքն՝ այն հավելվածների պահոցն է, որի հետ աշխատում է մշակողը։
Որից հետո TFS-ը տեսնում է, որ նոր commit է եկել։ Ո՞ր հավելվածը: TFS-ի կարգավորումներում կա պիտակ, որը ցույց է տալիս, թե կոնկրետ ինչ ռեսուրսներ ունի Build գործակալը: Այս դեպքում նա տեսնում է, որ մենք կառուցում ենք .NET Core նախագիծ և լողավազանից ընտրում է Linux Build գործակալ։
Build գործակալը ստանում է աղբյուրները և ներբեռնում է անհրաժեշտը կախվածություններ .NET պահոցից, npm և այլն: և հենց հավելվածը կառուցելուց և հետագա փաթեթավորումից հետո RPM փաթեթն ուղարկում է RPM պահեստ:
Մյուս կողմից, տեղի է ունենում հետեւյալը. Գործառնությունների բաժնի ինժեներն անմիջականորեն մասնակցում է նախագծի իրականացմանը. նա փոխում է փաթեթների տարբերակները Հիերա պահեստում, որտեղ պահվում է հավելվածի բաղադրատոմսը, որից հետո Puppet-ը գործարկում է Yum, պահոցից վերցնում է նոր փաթեթը, և հավելվածի նոր տարբերակը պատրաստ է օգտագործման։
Ամեն ինչ բառերով պարզ է, բայց ի՞նչ է տեղի ունենում հենց Build գործակալի ներսում:
DLL RPM փաթեթավորում
Ստացել է նախագծի աղբյուրները և առաջադրանք կառուցել TFS-ից: Կառուցման գործակալ սկսում է ինքնուրույն կառուցել նախագիծը աղբյուրներից. Հավաքված նախագիծը հասանելի է որպես հավաքածու DLL ֆայլեր, որոնք փաթեթավորված են zip արխիվում՝ ֆայլային համակարգի բեռը նվազեցնելու համար։
ZIP արխիվը դեն է նետվում դեպի RPM փաթեթի կառուցման գրացուցակ: Հաջորդը, Bash սկրիպտը սկզբնավորում է շրջակա միջավայրի փոփոխականները, գտնում է Build տարբերակը, նախագծի տարբերակը, կառուցման գրացուցակի ուղին և գործարկում RPM-build: Կառուցումն ավարտվելուց հետո փաթեթը հրապարակվում է տեղական պահոց, որը գտնվում է Build գործակալի վրա։
Հաջորդը, Build գործակալից մինչև RPM պահեստի սերվեր JSON հարցումն ուղարկված է նշելով տարբերակի և կառուցման անվանումը: Webhook-ը, որի մասին ես ավելի վաղ խոսեցի, ներբեռնում է հենց այս փաթեթը Build գործակալի տեղական պահոցից և հասանելի է դարձնում նոր ժողովը տեղադրման համար:
Ինչու՞ փաթեթների առաքման այս կոնկրետ սխեման RPM պահեստ: Ինչու ես չեմ կարող անմիջապես հավաքված փաթեթը ուղարկել պահեստ: Փաստն այն է, որ դա անվտանգության ապահովման պայման է։ Այս սցենարը սահմանափակում է չարտոնված մարդկանց RPM փաթեթները վերբեռնելու հնարավորությունը սերվեր, որը հասանելի է բոլոր Linux մեքենաներին:
Տվյալների բազայի տարբերակավորում
Մշակողների թիմի հետ խորհրդակցության ժամանակ պարզվեց, որ տղաները ավելի մոտ էին MS SQL-ին, բայց ոչ Windows-ի նախագծերի մեծ մասում մենք արդեն օգտագործում էինք PostgreSQL-ն իրենց ողջ ուժով։ Քանի որ մենք արդեն որոշել էինք հրաժարվել վճարովի ամեն ինչից, այստեղ էլ սկսեցինք օգտագործել PostgreSQL:
Այս մասում ես ուզում եմ պատմել ձեզ, թե ինչպես ենք մենք տարբերակել տվյալների բազան և ինչպես ենք ընտրել Flyway-ի և Entity Framework Core-ի միջև: Եկեք նայենք դրանց դրական և բացասական կողմերին:
Դեմ
Flyway-ը գնում է միայն մեկ ճանապարհով, մենք մենք չենք կարող հետ գլորվել - սա էական թերություն է: Դուք կարող եք այն համեմատել Entity Framework Core-ի հետ այլ ձևերով՝ մշակողի հարմարության տեսանկյունից: Հիշում եք, որ մենք սա դրեցինք առաջին պլանում, և հիմնական չափանիշը Windows-ի զարգացման համար ոչինչ չփոխելն էր:
Flyway us-ի համար ինչ-որ փաթաթան էր պետքոր տղերքը չգրեն SQL հարցումներ. Նրանք շատ ավելի մոտ են OOP-ի առումով գործելուն: Մենք գրեցինք տվյալների բազայի օբյեկտների հետ աշխատելու հրահանգներ, ստեղծեցինք SQL հարցում և կատարեցինք այն: Տվյալների բազայի նոր տարբերակը պատրաստ է, փորձարկված՝ ամեն ինչ լավ է, ամեն ինչ աշխատում է:
Entity Framework Core-ն ունի մինուս՝ ծանր բեռների տակ ստեղծում է ոչ օպտիմալ SQL հարցումներ, և տվյալների բազայի կրճատումը կարող է նշանակալի լինել: Բայց քանի որ մենք չունենք բարձր բեռնվածության ծառայություն, մենք չենք հաշվարկում ծանրաբեռնվածությունը հարյուրավոր RPS-ներով, մենք ընդունեցինք այդ ռիսկերը և խնդիրը պատվիրակեցինք ապագա մեզ:
Կոալիցիայում
Entity Framework Core աշխատում է առանց տուփի և հեշտ է մշակվել, և Flyway Հեշտությամբ ինտեգրվում է գոյություն ունեցող CI-ին. Բայց մենք դա հարմար ենք դարձնում մշակողների համար :)
Գլորման կարգը
Puppet-ը տեսնում է, որ փաթեթային տարբերակի փոփոխություն է գալիս, ներառյալ այն, որը պատասխանատու է միգրացիայի համար: Նախ, այն տեղադրում է փաթեթ, որը պարունակում է միգրացիոն սկրիպտներ և տվյալների բազայի հետ կապված գործառույթներ: Դրանից հետո տվյալների բազայի հետ աշխատող հավելվածը վերագործարկվում է: Հաջորդը գալիս է մնացած բաղադրիչների տեղադրումը: Փաթեթների տեղադրման և հավելվածների գործարկման հերթականությունը նկարագրված է Տիկնիկային մանիֆեստում:
Հավելվածներն օգտագործում են զգայուն տվյալներ, ինչպիսիք են նշանները, տվյալների բազայի գաղտնաբառերը, այս ամենը մտցվում է Puppet Master-ի կոնֆիգուրացիայի մեջ, որտեղ դրանք պահվում են կոդավորված ձևով:
TFS խնդիրներ
Այն բանից հետո, երբ մենք որոշեցինք և հասկացանք, որ ամեն ինչ իսկապես աշխատում է մեզ համար, ես որոշեցի տեսնել, թե ինչ է կատարվում TFS-ում հավաքների հետ որպես ամբողջություն Win զարգացման բաժնի համար այլ նախագծերի վերաբերյալ՝ արդյոք մենք արագ ենք կառուցում/թողարկում, թե ոչ, և արագության հետ կապված զգալի խնդիրներ է հայտնաբերել:
Հիմնական նախագծերից մեկի հավաքումը տևում է 12-15 րոպե, դա երկար ժամանակ է, այդպես ապրել չես կարող: Արագ վերլուծությունը ցույց տվեց I/O-ի սարսափելի անկում, և սա զանգվածների վրա էր:
Այն բաղադրիչ առ բաղադրիչ վերլուծելուց հետո ես հայտնաբերեցի երեք օջախ: Առաջին - «Կասպերսկի հակավիրուսային», որը սկանավորում է Windows Build բոլոր գործակալների աղբյուրները: Երկրորդ - Windows Ինդեքսավորող. Այն անջատված չէր, և ամեն ինչ իրական ժամանակում ինդեքսավորվեց Build գործակալների վրա՝ տեղակայման գործընթացում:
Երրորդ - Npm տեղադրում: Պարզվեց, որ խողովակաշարերի մեծ մասում մենք օգտագործել ենք հենց այս սցենարը: Ինչու է նա վատը: Npm տեղադրման ընթացակարգը գործարկվում է, երբ ձևավորվում է կախվածության ծառը package-lock.json, որտեղ ձայնագրվում են փաթեթների տարբերակները, որոնք կօգտագործվեն նախագիծը կառուցելու համար։ Բացասական կողմն այն է, որ Npm-ի տեղադրումը ամեն անգամ ինտերնետից հանում է փաթեթների վերջին տարբերակները, և դա շատ ժամանակ է պահանջում մեծ նախագծի դեպքում:
Մշակողները երբեմն փորձարկում են տեղական մեքենայի վրա՝ ստուգելու, թե ինչպես է աշխատում որոշակի մասը կամ ամբողջ նախագիծը: Երբեմն պարզվում էր, որ տեղում ամեն ինչ թույն է, բայց հավաքում էին, գլորում, և ոչինչ չէր ստացվում: Մենք սկսում ենք պարզել, թե որն է խնդիրը. այո, կախվածություն ունեցող փաթեթների տարբեր տարբերակներ:
որոշում
- Աղբյուրներ AV բացառություններում:
- Անջատել ինդեքսավորումը:
- Գնալ npm ci.
npm ci-ի առավելություններն այն են, որ մենք Մենք մեկ անգամ հավաքում ենք կախվածության ծառը, և մենք հնարավորություն ենք ստանում տրամադրել մշակողին փաթեթների ընթացիկ ցանկը, որի հետ նա կարող է տեղական փորձարկումներ կատարել այնքան, որքան ցանկանում է։ Սա խնայում է ժամանակը ծրագրավորողներ, ովքեր գրում են կոդը:
Տեսիլ
Այժմ մի փոքր պահեստի կազմաձևման մասին: Պատմականորեն մենք օգտագործում ենք Կապանքներ պահոցների կառավարման համար, ներառյալ Ներքին ռեպո. Այս ներքին պահոցը պարունակում է բոլոր այն բաղադրիչները, որոնք մենք օգտագործում ենք ներքին նպատակների համար, օրինակ՝ ինքնուրույն գրավոր մոնիտորինգ:
Մենք նաև օգտագործում ենք NuGet- ը, так как он лучше кэширует по сравнению с другими пакетными менеджерами.
Արդյունք
Այն բանից հետո, երբ մենք օպտիմալացրինք Build Agents-ը, կառուցման միջին ժամանակը 12 րոպեից կրճատվեց մինչև 7:
Եթե հաշվենք բոլոր այն մեքենաները, որոնք մենք կարող էինք օգտագործել Windows-ի համար, բայց այս նախագծում անցանք Linux-ի, մենք խնայեցինք մոտ $10: Եվ դա միայն լիցենզիաների վրա, և ավելին, եթե հաշվի առնենք բովանդակությունը:
Plans
Հաջորդ եռամսյակի համար մենք նախատեսում էինք աշխատել կոդի առաքման օպտիմալացման վրա:
Անցում նախակառուցված Docker պատկերին. TFS-ը հիանալի բան է բազմաթիվ պլագիններով, որոնք թույլ են տալիս ինտեգրվել Pipeline-ին, ներառյալ, ասենք, Docker պատկերի ձգանման վրա հիմնված հավաքումը: Մենք ցանկանում ենք այս ձգան ստեղծել նույն մեկի համար package-lock.json. Եթե նախագծի կառուցման համար օգտագործվող բաղադրիչների կազմը ինչ-որ կերպ փոխվում է, մենք կառուցում ենք նոր Docker պատկեր: Այն հետագայում օգտագործվում է հավաքված հավելվածով բեռնարկղը տեղակայելու համար: Հիմա այդպես չէ, բայց մենք նախատեսում ենք անցնել միկրոսերվիսային ճարտարապետության Kubernetes-ում, որն ակտիվորեն զարգանում է մեր ընկերությունում և երկար ժամանակ սպասարկում է արտադրական լուծումներ։
Ամփոփում
Ես կոչ եմ անում բոլորին դեն նետել Windows-ը, բայց դա այն պատճառով չէ, որ ես չգիտեմ, թե ինչպես պատրաստել այն: Պատճառն այն է, որ Opensource լուծումների մեծամասնությունն են Linux բուրգ. լավ ես խնայել ռեսուրսների վրա. Իմ կարծիքով ապագան պատկանում է հզոր համայնք ունեցող Linux-ի բաց կոդով լուծումներին։
Ալեքսանդր Սինչինովի խոսնակի բնութագիրը .
Մասնագետների կողմից մասնագետների համար մշակման, փորձարկման և շահագործման գործընթացների ինտեգրման կոնֆերանս է: Ահա թե ինչու է այն նախագիծը, որի մասին խոսեց Ալեքսանդրը: իրականացվել և աշխատել է, իսկ ներկայացման օրը եղել է երկու հաջող թողարկում։ Վրա Մայիսի 27-ին և 28-ին էլ ավելի շատ նմանատիպ դեպքեր կլինեն պրակտիկանտներից։ Դուք դեռ կարող եք ցատկել վերջին կառքի մեջ և կամ վերցրեք ձեր ժամանակը տոմս. Հանդիպեք մեզ Սկոլկովոյում:
Source: www.habr.com