Զեկույցում կխոսվի DevOps-ի որոշ պրակտիկայի մասին, բայց մշակողի տեսանկյունից: Սովորաբար, բոլոր ինժեներները, ովքեր միանում են DevOps-ին, արդեն ունեն մի քանի տարվա վարչական փորձ: Բայց դա չի նշանակում, որ այստեղ մշակողի համար տեղ չկա։ Ավելի հաճախ, քան ոչ, մշակողները զբաղված են շտկելով «օրվա հաջորդ հրատապ կարևոր վրիպակը», և նրանք ժամանակ չունեն նույնիսկ արագ նայելու DevOps դաշտը: Հեղինակի ընկալմամբ, DevOps-ը, առաջին հերթին, ողջախոհություն է: Երկրորդ՝ դա ավելի արդյունավետ լինելու հնարավորություն է։ Եթե դուք մշակող եք, ունեք ողջամտություն և ցանկանում եք ավելի արդյունավետ լինել որպես թիմային խաղացող, այս զեկույցը ձեզ համար է:
Թույլ տվեք ներկայանալ, ես լիովին ընդունում եմ, որ սենյակում կան մարդիկ, ովքեր ինձ չեն ճանաչում։ Ես Անտոն Բոյկոն եմ, ես Microsoft Azure MVP-ն եմ: Ի՞նչ է MVP-ն: Սա Model-View-Presenter-ն է: Model-View-Presenter-ը հենց ես եմ:
Բացի այդ, ես ներկայումս զբաղեցնում եմ «Ciklum»-ում լուծումների ճարտարապետի պաշտոնը: Եվ հենց վերջերս ես ինքս ինձ նման գեղեցիկ տիրույթ գնեցի և թարմացրի իմ էլփոստը, որը սովորաբար ցուցադրում եմ շնորհանդեսների ժամանակ: Դուք կարող եք գրել ինձ հետևյալ հասցեով՝ me [dog] byokoant.pro: Հարցերի դեպքում կարող եք էլ. Ես սովորաբար պատասխանում եմ նրանց. Միակ բանն այն է, որ ես չէի ցանկանա էլեկտրոնային փոստով հարցեր ստանալ, որոնք վերաբերում են երկու թեմայի՝ քաղաքականության և կրոնի: Մնացած ամեն ինչի մասին կարող եք գրել ինձ էլեկտրոնային փոստով: Որոշ ժամանակ կանցնի, կպատասխանեմ.
Մի քանի խոսք իմ մասին.
- Ես այս ոլորտում եմ արդեն 10 տարի։
- Ես աշխատել եմ Microsoft-ում։
- Ես ուկրաինական Azure համայնքի հիմնադիր հայրն եմ, որը մենք հիմնադրել ենք ինչ-որ տեղ 2014 թվականին: Իսկ մենք դեռ ունենք ու զարգացնում ենք։
- Ես նաև Azure համաժողովի հիմնադրի հայրն եմ, որը մենք հյուրընկալում ենք Ուկրաինայում։
- Ես նաև օգնում եմ կազմակերպել Global Azure Bootcamp-ը Կիևում:
- Ինչպես ասացի, ես Microsoft Azure MVP-ն եմ:
- Ես բավականին հաճախ եմ ելույթ ունենում կոնֆերանսների ժամանակ: Ես իսկապես սիրում եմ խոսել կոնֆերանսների ժամանակ: Անցած տարվա ընթացքում ես կարողացա մոտ 40 ելույթ ունենալ։ Եթե դուք անցնում եք Ուկրաինայի, Բելառուսի, Լեհաստանի, Բուլղարիայի, Շվեդիայի, Դանիայի, Նիդեռլանդների, Իսպանիայի կողքով կամ տալիս կամ վերցնում եք Եվրոպայի մեկ այլ երկիր, ապա միանգամայն հնարավոր է, որ երբ գնում եք համաժողովի, որն իր հոսքում ունի ամպային թեմա, դուք կարող եք տեսնել ինձ բանախոսների ցանկում:
- Ես նաև Star Trek-ի երկրպագու եմ:
Մի փոքր խոսենք օրակարգի մասին։ Մեր օրակարգը շատ պարզ է.
- Մենք կխոսենք այն մասին, թե ինչ է DevOps-ը: Եկեք խոսենք, թե ինչու է սա կարևոր: Նախկինում DevOps-ը բանալի բառ էր, որը դուք գրել էիք ձեր ռեզյումեում և անմիջապես ստացաք +500 դոլար աշխատավարձ: Այժմ դուք պետք է գրեք, օրինակ, բլոկչեյն ձեր ռեզյումեում, որպեսզի ստանաք +500 դոլար ձեր աշխատավարձին։
- Եվ հետո, երբ մենք մի փոքր հասկանանք, թե ինչ է սա, մենք կխոսենք այն մասին, թե ինչ է DevOps պրակտիկան: Բայց ոչ այնքան DevOps-ի համատեքստում ընդհանրապես, որքան այն DevOps պրակտիկայի մասին, որոնք կարող են հետաքրքրել մշակողներին: Ես ձեզ կասեմ, թե ինչու նրանք կարող են ձեզ հետաքրքրել: Ես ձեզ կասեմ, թե ինչու պետք է դա անեք ընդհանրապես և ինչպես դա կարող է օգնել ձեզ ավելի քիչ ցավ զգալ:
Ավանդական պատկեր, որը շատերն են ցույց տալիս։ Սա այն է, ինչ տեղի է ունենում շատ նախագծերում: Սա այն դեպքում, երբ մենք ունենք զարգացման և գործառնությունների բաժիններ, որոնք աջակցում են մեր ծրագրաշարը: Իսկ այս գերատեսչությունները միմյանց հետ չեն շփվում։
Թերևս, եթե դուք չկարողացաք դա այդքան պարզ զգալ DevOps-ի և գործառնությունների բաժիններում, կարող եք անալոգիա անել Dev և QA բաժինների հետ: Կան մարդիկ, ովքեր ծրագրային ապահովում են մշակում, և կան QA մարդիկ, ովքեր վատն են մշակողների տեսանկյունից: Օրինակ, ես իմ հրաշալի ծածկագիրը հանձնում եմ պահեստին, և այնտեղ նստած է ինչ-որ սրիկա, ով ինձ վերադարձնում է այս կոդը և ասում, որ քո կոդը վատն է։
Այս ամենը տեղի է ունենում այն պատճառով, որ մարդիկ չեն շփվում միմյանց հետ: Եվ ինչ-որ փաթեթներ, ինչ-որ դիմում իրար են նետում թյուրիմացության ինչ-որ պատի միջով ու փորձում ինչ-որ բան անել դրանցով։
Հենց այս պատն է, որ DevOps մշակույթը նախատեսված է քանդելու, այսինքն. ստիպեք մարդկանց շփվել միմյանց հետ և գոնե հասկանալ, թե ինչ են անում նախագծի տարբեր մարդիկ և ինչու է նրանց աշխատանքը կարևոր:
Եվ երբ մենք խոսում ենք DevOps-ի մասին, ինչ-որ մեկը ձեզ կասի, որ DevOps-ն այն է, երբ նախագիծն ունի շարունակական ինտեգրում; ինչ-որ մեկը կասի, որ DevOps-ն այն է, եթե նախագիծն իրականացնում է «ենթակառուցվածքը որպես կոդ» պրակտիկան. ինչ-որ մեկը կասի, որ DevOps-ի առաջին քայլը հնարավորությունների ճյուղավորումն է, հատկանիշի դրոշները:
Ըստ էության, այս ամենը ճիշտ է իր ձևով: Բայց սրանք ընդամենը վերջնական պրակտիկա են, որոնք մենք ունենք: Նախքան այս պրակտիկաներին անցնելը, ես առաջարկում եմ դիտել այս սլայդը, որը ցույց է տալիս Dev-Ops մեթոդաբանության ներդրման 3 փուլերը ձեր նախագծում՝ ձեր ընկերությունում։
Այս սլայդն ունի նաև երկրորդ ոչ պաշտոնական անվանումը։ Դուք կարող եք որոնել առցանց՝ պարզելու համար, թե որոնք են DevOps-ի 3 հրացանակիրները: Հնարավոր է, որ դուք կգտնեք այս հոդվածը: Ինչու՞ 3 հրացանակիրներ: Ներքևում ասվում է՝ մարդիկ, գործընթացները և ապրանքները, այսինքն. PPP – Պորտոս, Պորտոս և Պորտոս: Ահա DevOps-ի 3 հրացանակիրները։ Այս հոդվածը ավելի մանրամասն նկարագրում է, թե ինչու է դա կարևոր և ինչ է ենթադրում:
Երբ սկսում եք իրականացնել DevOps մշակույթը, շատ կարևոր է, որ այն իրականացվի հետևյալ հաջորդականությամբ.
Սկզբում պետք է խոսել մարդկանց հետ: Եվ դուք պետք է մարդկանց բացատրեք, թե ինչ է դա և ինչպես նրանք կարող են որոշակի օգուտներ ստանալ դրանից:
Մեր համաժողովը կոչվում է DotNet Fest: Եվ ինչպես ինձ ասացին կազմակերպիչները, մենք հիմնականում ծրագրավորողների լսարան ենք հրավիրել այստեղ, ուստի հուսով եմ, որ դահլիճի մարդկանց մեծ մասը ներգրավված է զարգացման գործում:
Մենք կխոսենք մարդկանց մասին, մենք կխոսենք այն մասին, թե ինչ են ուզում անել մշակողները ամեն օր: Ի՞նչ են նրանք ամենից շատ ուզում: Նրանք ցանկանում են ինչ-որ նոր կոդ գրել, օգտագործել նորաստեղծ շրջանակներ, ստեղծել նոր հնարավորություններ: Ի՞նչ են ամենաքիչը ցանկանում մշակողները: Ուղղել հին սխալները: Հուսով եմ՝ համաձայն եք ինձ հետ։ Սա այն է, ինչ ցանկանում են մշակողները: Նրանք ցանկանում են գրել նոր գործառույթներ, չեն ցանկանում շտկել սխալները:
Որոշակի մշակողի կողմից արտադրվող սխալների քանակը կախված է նրանից, թե որքան ուղիղ են նրա ձեռքերը և որքան են դրանք աճում նրա ուսերից, և ոչ թե հետույքի գրպաններից: Բայց այնուամենայնիվ, երբ մենք ունենք մեծ նախագիծ, երբեմն պատահում է, որ անհնար է հետևել ամեն ինչին, ուստի լավ կլինի, որ մենք օգտագործենք որոշ մոտեցումներ, որոնք կօգնեն մեզ ավելի կայուն և որակյալ կոդ գրել։
Ի՞նչ են ամենաշատը ցանկանում QA-ները: Դահլիճում են՝ չգիտեմ։ Ինձ համար դժվար է ասել, որ ես ուզում եմ ՈԱ, քանի որ ես երբեք այդպիսին չեմ եղել: Եվ ոչ մի վիրավորանք տղերքին, կասեն, որ հուսով եմ՝ երբեք չեմ անի։ Բայց ոչ այն պատճառով, որ ես անիմաստ ու անպետք եմ համարում նրանց աշխատանքը, այլ որովհետև ես ինձ չեմ համարում մարդ, ով կկարողանար արդյունավետ կերպով կատարել այս աշխատանքը, ուստի չեմ էլ փորձի դա անել։ Բայց, ինչ ես հասկանում եմ, այն, ինչ QA-ին ամենից շատ դուր չի գալիս, դա առավոտյան աշխատելն է, անընդհատ ինչ-որ ռեգրեսիոն թեստեր անցկացնելը, նույն սխալները, որոնք նրանք հայտնել էին ծրագրավորողներին 3 սպրինտ առաջ և ասելով. Պարոն Դ «Արտանյան, ուղղեք այս սխալը։ Եվ պարոն Դ'Արտանյանը պատասխանում է նրան. «Այո, այո, այո, ես արդեն ուղղել եմ»: Եվ ինչպես է պատահում, որ ես ուղղեցի մեկ սխալ և ճանապարհին դարձրի 5:
Մարդիկ, ովքեր աջակցում են այս լուծմանը արտադրության մեջ, ցանկանում են, որ այս լուծումը աշխատի առանց սխալների, որպեսզի նրանք ստիպված չլինեն վերագործարկել սերվերը ամեն ուրբաթ, երբ բոլոր նորմալ մարդիկ գնում են բար: Մշակողները տեղակայվել են ուրբաթ օրը, ադմինները նստում են մինչև շաբաթ՝ փորձելով վերացնել այս տեղակայումը և ուղղել:
Իսկ երբ մարդկանց բացատրում ես, որ նրանք ուղղված են նույն խնդիրների լուծմանը, կարող ես անցնել գործընթացների պաշտոնականացմանը։ Դա շատ կարեւոր է. Ինչո՞ւ։ Որովհետև, երբ ասում ենք «ֆորմալացում», ձեզ համար կարևոր է նկարագրել, թե ինչպես են ձեր գործընթացները տեղի ունենում գոնե ինչ-որ տեղ անձեռոցիկի վրա: Դուք պետք է հասկանաք, որ եթե դուք, օրինակ, տեղակայվում եք QA միջավայրում կամ արտադրական միջավայրում, ապա դա միշտ տեղի է ունենում այս կարգով. այս փուլերում մենք գործարկում ենք, օրինակ, ավտոմատ միավորի թեստեր և UI թեստեր: Տեղակայումից հետո մենք ստուգում ենք՝ տեղակայումը լավ է անցել, թե վատ: Բայց դուք արդեն ունեք գործողությունների հստակ ցուցակ, որոնք պետք է կրկնվեն նորից ու նորից, երբ գործարկեք արտադրություն:
Եվ միայն այն ժամանակ, երբ ձեր գործընթացները պաշտոնականացվում են, դուք սկսում եք ընտրել ապրանքներ, որոնք կօգնեն ձեզ ավտոմատացնել այդ գործընթացները:
Ցավոք սրտի, ես շատ հաճախ տեսնում եմ, որ դա տեղի է ունենում հակառակ ուղղությամբ: Հենց ինչ-որ մեկը լսում է «DevOps» բառը, անմիջապես առաջարկում են տեղադրել Jenkins, քանի որ կարծում են, որ հենց որ տեղադրեն Jenkins, կունենան DevOps։ Նրանք տեղադրեցին Jenkins-ը, կարդացին «Ինչպես անել» հոդվածները Ջենքինսի կայքում, փորձեցին գործընթացները լցնել «How to» հոդվածների մեջ, այնուհետև եկան մարդկանց մոտ և կռացան՝ ասելով, որ գրքում ասվում է, որ պետք է դա անել այսպես. այնպես որ մենք դա անում ենք այսպես.
Այնպես չէ, որ Ջենքինսը վատ գործիք է: Ես դա չեմ ուզում ասել որևէ կերպ։ Բայց սա միայն ապրանքներից մեկն է: Իսկ թե որ ապրանքն եք օգտագործում, պետք է լինի ձեր վերջին որոշումը, և ոչ մի դեպքում առաջինը: Ձեր արտադրանքը չպետք է առաջնորդվի մշակույթի և մոտեցումների ներդրմամբ: Սա շատ կարևոր է հասկանալու համար, ինչի պատճառով ես այդքան ժամանակ եմ ծախսում այս սլայդի վրա և այսքան երկար բացատրում եմ այս ամենը:
Եկեք ընդհանուր առմամբ խոսենք DevOps-ի պրակտիկայի մասին: Ինչ են նրանք? Որն է տարբերությունը? Ինչպե՞ս փորձել դրանք: Ինչու են դրանք կարևոր:
Առաջին պրակտիկան, որի մասին դուք կարող եք լսել, կոչվում է Continuous Integration: Հավանաբար նախագծում ինչ-որ մեկը ունի շարունակական ինտեգրում (CI):
Ամենամեծ խնդիրն այն է, որ ամենից հաճախ, երբ ես հարցնում եմ մարդուն. «Դուք ունե՞ք CI նախագծում»: և նա ասում է. «Այո», հետո երբ ես հարցնում եմ, թե ինչ է անում, նա ինձ նկարագրում է բացարձակապես ամբողջ ավտոմատացման գործընթացը: Սա լիովին ճիշտ չէ:
Իրականում, CI-ի պրակտիկան պարզապես ուղղված է այն ծածկագրի ինտեգրմանը, որը տարբեր մարդիկ գրում են ինչ-որ մեկ կոդի բազայի մեջ: Այսքանը:
CI-ի հետ մեկտեղ ճանապարհին սովորաբար լինում են նաև այլ պրակտիկաներ, ինչպիսիք են՝ շարունակական տեղակայումը, թողարկման կառավարումը, բայց մենք այդ մասին կխոսենք ավելի ուշ:
CI-ն ինքնին մեզ ասում է, որ տարբեր մարդիկ գրում են կոդ, և այս կոդը պետք է շարունակաբար ինտեգրվի մեկ ծածկագրի բազայի մեջ:
Ի՞նչ է սա մեզ տալիս և ինչու է դա կարևոր: Եթե մենք ունենք DotNet, ապա դա լավ է, դա կոմպիլացված լեզու է, մենք կարող ենք կազմել մեր հավելվածը: Եթե այն կազմում է, ապա սա արդեն լավ նշան է։ Սա դեռ ոչինչ չի նշանակում, բայց դա առաջին լավ նշանն է, որ մենք կարող ենք գոնե կազմել:
Հետո մենք կարող ենք մի քանի թեստեր անցկացնել, ինչը նույնպես առանձին պրակտիկա է։ Թեստերն ամբողջությամբ կանաչ են. սա երկրորդ լավ նշանն է: Բայց կրկին, սա ոչինչ չի նշանակում:
Բայց ինչո՞ւ եք դա անում: Բոլոր այն պրակտիկաները, որոնց մասին ես կխոսեմ այսօր, ունեն մոտավորապես նույն արժեքը, այսինքն մոտավորապես նույն օգուտները և նույնպես չափվում են մոտավորապես նույն կերպ:
Նախ, դա թույլ է տալիս արագացնել առաքումը: Ինչպե՞ս է դա թույլ տալիս արագացնել առաքումը: Երբ մենք որոշ նոր փոփոխություններ ենք կատարում մեր կոդի բազայում, մենք կարող ենք անմիջապես փորձել ինչ-որ բան անել այս կոդով: Մենք չենք սպասում մինչև հինգշաբթի գա, քանի որ հինգշաբթի մենք այն թողարկում ենք QA Environment-ին, մենք դա անում ենք հենց այստեղ և հենց այստեղ:
Մի տխուր պատմություն կպատմեմ իմ կյանքից. Դա շատ վաղուց էր, երբ ես դեռ երիտասարդ էի ու գեղեցիկ։ Հիմա ես արդեն երիտասարդ եմ, գեղեցիկ ու խելացի, համեստ։ Որոշ ժամանակ առաջ ես նախագծում էի. Մենք ունեինք մոտ 30 ծրագրավորողներից բաղկացած մեծ թիմ: Եվ մենք ունեինք մի մեծ, մեծ Enterprise նախագիծ, որը զարգացավ մոտ 10 տարի: Եվ մենք ունեինք տարբեր մասնաճյուղեր։ Պահեստում մենք ունեինք մասնաճյուղ, որտեղ ծրագրավորողները քայլում էին: Եվ կար մի մասնաճյուղ, որը ցուցադրում էր կոդի տարբերակը, որը արտադրության մեջ է։
Արտադրական ճյուղը 3 ամիս հետ էր մնացել այն ճյուղից, որը հասանելի էր ծրագրավորողներին: Ինչ է սա նշանակում? Սա նշանակում է, որ հենց որ ես ինչ-որ տեղ ունեմ սխալ, որը գնում է արտադրություն մշակողների մեղքով, քանի որ նրանք դա թույլ են տվել, և QA-ի մեղքով, քանի որ նրանք նայել են դրան, ապա սա նշանակում է, որ եթե ես ստանամ առաջադրանք արտադրության համար թեժ շտկման համար, ապա ես պետք է հետ գլորեմ իմ կոդի փոփոխությունները 3 ամիս առաջ: Ես պետք է հիշեմ այն, ինչ ունեի 3 ամիս առաջ և փորձեմ շտկել այն:
Եթե դեռ չեք ունեցել այս փորձը, կարող եք փորձել այն ձեր տան նախագծի վրա: Հիմնական բանը, մի փորձեք այն կոմերցիոնի վրա: Գրեք մի քանի տող կոդ, մոռացեք դրանց մասին վեց ամսով, այնուհետև վերադարձեք և փորձեք արագ բացատրել, թե ինչի մասին են այդ կոդի տողերը և ինչպես կարող եք դրանք ուղղել կամ օպտիմալացնել: Դա շատ, շատ հուզիչ փորձ է:
Եթե մենք ունենք շարունակական ինտեգրման պրակտիկա, ապա դա մեզ թույլ է տալիս ստուգել այն մի շարք ավտոմատացված գործիքների միջոցով հենց այստեղ և հենց հիմա, հենց որ ես գրեմ իմ կոդը: Սա կարող է ինձ ամբողջական պատկերացում չտալ, բայց, այնուամենայնիվ, այն կվերացնի առնվազն որոշ ռիսկեր: Իսկ եթե ինչ-որ պոտենցիալ վրիպակ լինի, ես դրա մասին կիմանամ հենց հիմա, այսինքն բառացիորեն մի երկու րոպեից։ Ես 3 ամսով հետ գլորվելու կարիք չեմ ունենա։ Ինձ կպահանջվի ընդամենը 2 րոպե հետ գլորվել: Լավ սուրճի մեքենան անգամ չի հասցնի սուրճ եփել 2 րոպեում, այնպես որ դա շատ լավ է:
Սա ունի այն արժեքը, որ այն կարող է կրկնվել ժամանակ առ ժամանակ յուրաքանչյուր նախագծի վրա, այսինքն. ոչ միայն այն մեկը, որի վրա այն կարգավորել եք: Դուք կարող եք կրկնել և՛ պրակտիկան, և՛ ինքնին CI-ն կկրկնվի նախագծում ձեր կատարած յուրաքանչյուր նոր փոփոխության համար: Սա թույլ է տալիս օպտիմալացնել ռեսուրսները, քանի որ ձեր թիմն ավելի արդյունավետ է աշխատում: Դուք այլևս չեք ունենա այնպիսի իրավիճակ, երբ ձեզ մոտ վրիպակ գա այն կոդից, որի հետ աշխատել եք 3 ամիս առաջ: Դուք այլևս չեք ունենա կոնտեքստի փոխում, երբ նստեք և անցկացնեք առաջին երկու ժամը՝ փորձելով հասկանալ, թե ինչ է տեղի ունեցել այն ժամանակ, և նախքան ինչ-որ բան ուղղել սկսելը մտնել ենթատեքստի էության մեջ:
Ինչպե՞ս կարող ենք չափել այս պրակտիկայի հաջողությունը կամ ձախողումը: Եթե մեծ պետին զեկուցեք, թե ինչ ենք մենք իրականացրել CI նախագծի վրա, նա լսում է բլա բլա բլա: Իրականացրել ենք, լավ, բայց ինչո՞ւ, ի՞նչ բերեց մեզ, ինչպե՞ս ենք չափում, որքանո՞վ ենք ճիշտ կամ սխալ իրականացնում։
Առաջինն այն է, որ CI-ի շնորհիվ մենք կարող ենք ավելի ու ավելի հաճախ տեղակայել, և ավելի հաճախ հենց այն պատճառով, որ մեր կոդը պոտենցիալ ավելի կայուն է: Նույն կերպ կրճատվում է սխալ գտնելու մեր ժամանակը և կրճատվում է այս սխալը շտկելու ժամանակը հենց այն պատճառով, որ մենք համակարգից ստանում ենք պատասխան հենց այստեղ և հենց հիմա, թե ինչն է սխալ մեր կոդի հետ։
Մեկ այլ պրակտիկա, որը մենք ունենք, ավտոմատացման փորձարկման պրակտիկան է, որն ամենից հաճախ գալիս է CI պրակտիկայի հետ: Նրանք գնում են ձեռք ձեռքի տված:
Ի՞նչն է կարևոր հասկանալ այստեղ: Կարևոր է հասկանալ, որ մեր թեստերը տարբեր են: Եվ յուրաքանչյուր ավտոմատացված թեստ ուղղված է սեփական խնդիրների լուծմանը։ Մենք ունենք, օրինակ, միավորի թեստեր, որոնք թույլ են տալիս առանձին թեստավորել մոդուլը, այսինքն. Ինչպե՞ս է այն աշխատում վակուումում: Սա լավ է.
Մենք ունենք նաև ինտեգրման թեստեր, որոնք թույլ են տալիս հասկանալ, թե ինչպես են տարբեր մոդուլներ ինտեգրվում միմյանց հետ: Դա նույնպես լավ է։
Մենք կարող ենք ունենալ UI-ի ավտոմատացման թեստեր, որոնք թույլ են տալիս ստուգել, թե որքանով է UI-ի հետ աշխատանքը համապատասխանում հաճախորդի կողմից սահմանված որոշակի պահանջներին և այլն:
Ձեր կատարած հատուկ թեստերը կարող են ազդել, թե որքան հաճախ եք դրանք կատարում: Միավոր թեստերը սովորաբար գրվում են կարճ և փոքր: Եվ դրանք կարող են պարբերաբար գործարկվել:
Եթե մենք խոսում ենք UI-ի ավտոմատացման թեստերի մասին, ապա լավ է, եթե ձեր նախագիծը փոքր է: Ձեր UI-ի ավտոմատացման թեստերը կարող են որոշակի ժամանակ պահանջել: Բայց սովորաբար UI ավտոմատացման թեստը մի բան է, որը մի քանի ժամ տևում է մեծ նախագծի վրա: Եվ լավ է, եթե դա մի քանի ժամ է: Միակ բանն այն է, որ իմաստ չկա դրանք գործարկել յուրաքանչյուր կառուցման համար: Իմաստ է դրանք վարել գիշերը: Եվ երբ առավոտյան բոլորը գալիս էին աշխատանքի՝ և՛ փորձարկողները, և՛ ծրագրավորողները, նրանք ստացան մի տեսակ հաշվետվություն, որ մենք գիշերն անցկացրինք UI-ի ավտոմատ թեստը և ստացանք այս արդյունքները: Եվ ահա, սերվերի աշխատանքի մեկ ժամը, ով կստուգի, որ ձեր ապրանքը համապատասխանում է որոշ պահանջների, շատ ավելի էժան կլինի, քան նույն QA ինժեների մեկ ժամ աշխատանքը, նույնիսկ եթե դա Junior QA ինժեներ է, ով աշխատում է սննդի և շնորհակալությունների համար: Միևնույն է, մեքենայի աշխատանքի մեկ ժամն ավելի էժան կլինի։ Ահա թե ինչու իմաստ ունի ներդրումներ կատարել դրա մեջ:
Ես ունեմ ևս մեկ նախագիծ, որի վրա աշխատել եմ: Այս նախագծով մենք երկուշաբաթյա սպրինտներ ունեինք: Նախագիծը մեծ էր, ֆինանսական հատվածի համար կարեւոր, եւ սխալ թույլ տալ չէր կարելի։ Իսկ երկշաբաթյա սպրինտից հետո զարգացման ցիկլին հաջորդեց թեստավորման գործընթացը, որը տեւեց եւս 4 շաբաթ։ Փորձեք պատկերացնել ողբերգության մասշտաբները։ Մենք գրում ենք կոդը երկու շաբաթ, այնուհետև դա անում ենք ala CodeFreeze, փաթեթավորում ենք հավելվածի նոր տարբերակում և ներկայացնում ենք փորձարկողներին: Փորձարկողները փորձարկում են այն ևս 4 շաբաթ, այսինքն. Մինչ նրանք փորձարկում են այն, մենք ժամանակ ունենք նրանց համար պատրաստելու ևս երկու տարբերակ։ Սա իսկապես տխուր դեպք է։
Եվ մենք նրանց ասացինք, որ եթե դուք ցանկանում եք ավելի արդյունավետ լինել, իմաստ ունի ձեզ համար կիրառել Ավտոմատացված թեստավորման պրակտիկա, քանի որ սա այն է, ինչը ձեզ ցավ է պատճառում հենց այստեղ, հենց հիմա:
Կիրառեք շարունակական տեղակայում: Հիանալի է, դուք ավարտել եք շինարարությունը: Սա արդեն լավ է։ Ձեր կոդը կազմվել է: Հիմա լավ կլիներ այս կառուցումը տեղակայել ինչ-որ միջավայրի վրա: Ասենք ծրագրավորողների միջավայրում.
Ինչու՞ է դա կարևոր: Նախ, դուք կարող եք տեսնել, թե որքան հաջողակ եք դուք տեղակայման գործընթացում: Ես հանդիպել եմ նման նախագծերի, երբ հարցնում եմ. «Ինչպե՞ս ես տեղադրում հավելվածի նոր տարբերակը», տղաներն ինձ ասում են. «Մենք այն հավաքում ենք և փաթեթավորում ենք zip արխիվում: Փոստով ուղարկում ենք ադմինիստրատորին։ Ադմինիստրատորը ներբեռնում և ընդլայնում է այս արխիվը: Եվ ամբողջ գրասենյակը սկսում է աղոթել, որ սերվերը վերցնի նոր տարբերակը»։
Սկսենք մի պարզ բանից. Օրինակ, նրանք մոռացել են CSS-ը տեղադրել արխիվում կամ մոռացել են փոխել java-script ֆայլի անվանման հեշթեգը։ Եվ երբ մենք հարցում ենք անում սերվերին, բրաուզերը մտածում է, որ արդեն ունի այս java-script ֆայլը և որոշում է չներբեռնել այն։ Եվ կար մի հին տարբերակ, ինչ-որ բան պակասում էր. Ընդհանուր առմամբ, կարող են լինել բազմաթիվ խնդիրներ։ Հետևաբար, Continuous Deployment-ի պրակտիկան թույլ է տալիս գոնե ստուգել, թե ինչ տեղի կունենա, եթե վերցնեք մաքուր հղումային պատկեր և վերբեռնեք այն ամբողջովին մաքուր նոր միջավայր: Դուք կարող եք տեսնել, թե դա ուր է տանում:
Բացի այդ, երբ դուք ինտեգրում եք կոդը միմյանց միջև, այսինքն. հրամանի միջև, սա թույլ է տալիս նաև տեսնել, թե ինչպես է այն երևում UI-ում:
Խնդիրներից մեկը, որն առաջանում է շատ վանիլային java-script-ի օգտագործման դեպքում, այն է, որ երկու ծրագրավորողներ պատուհանի օբյեկտում չմտածված հայտարարագրել են նույն անունով փոփոխական: Եվ հետո, կախված ձեր բախտից: Ում java-script ֆայլը հանվում է երկրորդը, կվերագրի մյուսի փոփոխությունները: Դա նույնպես շատ հուզիչ է: Դու մտնում ես. մի բան աշխատում է մի մարդու մոտ, մյուսը՝ մյուսի համար: Եվ դա «հրաշալի» է, երբ այդ ամենը հայտնվում է արտադրության մեջ:
Հաջորդ պրակտիկան, որը մենք ունենք, ավտոմատ վերականգնման պրակտիկան է, այն է, որ վերադառնանք հավելվածի նախորդ տարբերակին:
Ինչու՞ է սա կարևոր մշակողների համար: Դեռ կան մարդիկ, ովքեր հիշում են հեռավոր, հեռավոր 90-ականները, երբ համակարգիչները մեծ էին, իսկ ծրագրերը՝ փոքր։ Իսկ վեբ մշակման միակ ճանապարհը PHP-ն էր: Այնպես չէ, որ PHP-ն վատ լեզու է, չնայած դա այդպես է:
Բայց խնդիրն այլ էր. Երբ մենք տեղակայեցինք մեր php կայքի նոր տարբերակը, ինչպե՞ս այն տեղակայեցինք: Ամենից հաճախ մենք բացում էինք Far Manager կամ այլ բան: Եվ վերբեռնեց այս ֆայլերը FTP-ում: Եվ մենք հանկարծ հասկացանք, որ մենք ունենք մի փոքր, փոքր սխալ, օրինակ, մենք մոռացել ենք ստորակետ դնել կամ մոռացել ենք փոխել տվյալների բազայի գաղտնաբառը, և կա տվյալների բազայի գաղտնաբառ, որը գտնվում է լոկալ հոսթի վրա։ Եվ մենք որոշում ենք արագ միանալ FTP-ին և խմբագրել ֆայլերը հենց այնտեղ: Սա ուղղակի կրակ է: Սա այն է, ինչ հայտնի էր 90-ականներին։
Բայց եթե օրացույցը չեք նայել, ապա 90-ականները գրեթե 30 տարի առաջ էին։ Հիմա ամեն ինչ մի փոքր այլ կերպ է կատարվում։ Եվ փորձեք պատկերացնել ողբերգության մասշտաբները, երբ ձեզ ասում են. Ահա ձեր FTP մուտքն ու գաղտնաբառը, միացեք արտադրությանը և արագ շտկեք այն այնտեղ»: Եթե դուք Չակ Նորիսն եք, սա կաշխատի: Եթե ոչ, ապա դուք ռիսկի եք դիմում, որ եթե շտկեք մեկ սխալ, կստեղծեք ևս 10-ը: Ահա թե ինչու նախկին տարբերակին վերադառնալու այս պրակտիկան թույլ է տալիս շատ բանի հասնել:
Նույնիսկ եթե ինչ-որ վատ բան ինչ-որ տեղ ինչ-որ տեղ խրախուսվում է, ապա դա վատ է, բայց ոչ ճակատագրական: Դուք կարող եք վերադառնալ ձեր նախկին տարբերակին: Անվանեք այն պահեստային, եթե ավելի հեշտ է դա ընկալել այդ տերմինաբանության մեջ: Դուք կարող եք վերադառնալ այս նախորդ տարբերակին, և օգտվողները դեռ կկարողանան աշխատել ձեր արտադրանքի հետ, և դուք կունենաք համապատասխան բուֆերային ժամանակ: Դուք կարող եք հանգիստ, առանց շտապելու վերցնել այս ամենը և լոկալ թեստավորել, շտկել, ապա ներբեռնել նոր տարբերակը։ Սա իսկապես իմաստ ունի անել:
Հիմա եկեք փորձենք ինչ-որ կերպ համատեղել նախորդ երկու պրակտիկան միասին: Մենք կստանանք երրորդը, որը կոչվում է Release Management:
Երբ մենք խոսում ենք Continuous Deployment-ի մասին իր դասական տեսքով, մենք ասում ենք, որ մենք պետք է պահեստից ինչ-որ ճյուղից կոդ հանենք, կազմենք և տեղակայենք այն: Լավ է, եթե մենք ունենք նույն միջավայրը։ Եթե մենք ունենք մի քանի միջավայր, դա նշանակում է, որ մենք պետք է ամեն անգամ քաշենք կոդը, նույնիսկ նույն commit-ից: Մենք ամեն անգամ կհանենք այն, ամեն անգամ կկառուցենք և կտեղակայենք նոր միջավայրում: Նախ, սա ժամանակն է, քանի որ նախագիծ կառուցելու համար, եթե դուք ունեք մեծ նախագիծ և եկել եք 90-ականներից, ապա դա կարող է տևել մի քանի ժամ:
Բացի այդ, կա ևս մեկ տխրություն. Երբ դուք կառուցում եք, նույնիսկ նույն մեքենայի վրա, դուք կկառուցեք նույն աղբյուրները, դուք դեռ երաշխիք չունեք, որ այս մեքենան գտնվում է նույն վիճակում, ինչ վերջին կառուցման ժամանակ:
Ենթադրենք, ինչ-որ մեկը մտել է և թարմացրել է DotNet-ը ձեզ համար կամ, ընդհակառակը, ինչ-որ մեկը որոշել է ինչ-որ բան ջնջել: Եվ հետո դուք ունեք կոգնիտիվ դիսոնանս, որ երկու շաբաթ առաջ մենք կառուցում էինք շինարարություն, և ամեն ինչ լավ էր, բայց հիմա թվում է, թե նույն մեքենան, նույն հանձնառությունը, նույն կոդը, որը մենք փորձում ենք կառուցել, բայց այն չի աշխատում: . Դուք երկար ժամանակ կզբաղվեք դրա հետ, և դա փաստ չէ, որ դուք դա կհասկանաք: Գոնե նյարդերդ շատ կփչացնես։
Հետևաբար, Release Management պրակտիկան առաջարկում է ներդնել լրացուցիչ աբստրակցիա, որը կոչվում է artifact repository կամ պատկերասրահ կամ գրադարան: Դուք կարող եք անվանել այն, ինչպես ուզում եք:
Հիմնական գաղափարն այն է, որ հենց որ մենք այնտեղ ինչ-որ պարտավորություն ունենանք, ասենք, մի ճյուղում, որը մենք պատրաստ ենք տեղակայել մեր տարբեր միջավայրերում, մենք հավաքում ենք հավելվածներ այս կոմիտից և այն ամենը, ինչ մեզ անհրաժեշտ է այս հավելվածի համար, մենք փաթեթավորում ենք այն: zip արխիվում և պահեք այն որոշակի հուսալի պահեստում: Եվ այս պահեստից մենք կարող ենք ցանկացած պահի ստանալ այս zip արխիվը:
Այնուհետև մենք վերցնում ենք այն և ավտոմատ կերպով տեղակայում այն մշակողի միջավայրում: Մենք մրցում ենք այնտեղ, և եթե ամեն ինչ լավ է, ապա տեղակայվում ենք բեմ: Եթե ամեն ինչ լավ է, ապա մենք տեղադրում ենք նույն արխիվը արտադրության մեջ, նույն երկուականները, որոնք կազմվել են ուղիղ մեկ անգամ:
Բացի այդ, երբ մենք ունենք այսպիսի պատկերասրահ, այն նաև օգնում է մեզ լուծել այն ռիսկերը, որոնք մենք անդրադարձել ենք վերջին սլայդում, երբ խոսում էինք նախորդ տարբերակին հետ վերադարձի մասին: Եթե դուք պատահաբար ինչ-որ բան սխալ եք տեղակայել, միշտ կարող եք վերցնել այս պատկերասրահից ցանկացած այլ նախորդ տարբերակ և նույն կերպ չտեղակայել այն այս միջավայրերում: Սա թույլ է տալիս հեշտությամբ վերադառնալ նախորդ տարբերակին, եթե ինչ-որ բան սխալ է:
Կա ևս մեկ հիանալի պրակտիկա. Դուք և ես բոլորս հասկանում ենք, որ երբ մենք վերադարձնում ենք մեր հավելվածները նախորդ տարբերակին, դա կարող է նշանակել, որ մեզ անհրաժեշտ է նաև նախորդ տարբերակի ենթակառուցվածքը:
Երբ մենք խոսում ենք վիրտուալ ենթակառուցվածքի մասին, շատերը կարծում են, որ սա ադմինիստրատորների կողմից ստեղծված մի բան է: Իսկ եթե Ձեզ անհրաժեշտ է, ասենք, ստանալ նոր սերվեր, որի վրա ցանկանում եք փորձարկել Ձեր հավելվածի նոր տարբերակը, ապա դուք պետք է տոմս գրեք ադմիններին կամ devops-ին։ Devops-ին դրա համար կպահանջվի 3 շաբաթ: Իսկ 3 շաբաթ հետո ձեզ կասեն, որ մենք ձեզ համար վիրտուալ մեքենա ենք տեղադրել՝ մեկ միջուկով, երկու գիգաբայթ օպերատիվ հիշողությամբ և առանց DotNet Windows սերվերի։ Դուք ասում եք. «Բայց ես ուզում էի DotNet»: Նրանք. «Լավ, վերադարձիր 3 շաբաթից»:
Գաղափարն այն է, որ օգտագործելով Ենթակառուցվածքը որպես օրենսգրքի պրակտիկա, դուք կարող եք վերաբերվել ձեր վիրտուալ ենթակառուցվածքին որպես այլ ռեսուրսի:
Հավանաբար, եթե ձեզանից որևէ մեկը հավելվածներ է մշակում DotNet-ում, դուք կարող եք լսել Entity Framework կոչվող գրադարանի մասին: Եվ գուցե դուք նույնիսկ լսել եք, որ Entity Framework-ը այն մոտեցումներից մեկն է, որը Microsoft-ը ակտիվորեն առաջ է մղում: Տվյալների բազայի հետ աշխատելու համար սա մոտեցում է, որը կոչվում է Code First: Սա այն դեպքում, երբ դուք կոդով նկարագրում եք, թե ինչպես եք ուզում ունենալ ձեր տվյալների բազան: Եվ հետո դուք տեղակայում եք հավելվածը: Այն միանում է տվյալների շտեմարանին, ինքն է որոշում, թե որ աղյուսակները կան, որոնք՝ ոչ, և ստեղծում է այն ամենը, ինչ ձեզ հարկավոր է:
Դուք կարող եք նույնը անել ձեր ենթակառուցվածքի հետ: Տարբերություն չկա այն բանի միջև, թե արդյոք Ձեզ անհրաժեշտ է տվյալների բազա նախագծի համար, թե արդյոք Ձեզ անհրաժեշտ է Windows սերվեր ծրագրի համար: Դա պարզապես ռեսուրս է: Եվ դուք կարող եք ավտոմատացնել այս ռեսուրսի ստեղծումը, կարող եք ավտոմատացնել այս ռեսուրսի կոնֆիգուրացիան: Համապատասխանաբար, ամեն անգամ, երբ ցանկանում եք փորձարկել ինչ-որ նոր հայեցակարգ, ինչ-որ նոր մոտեցում, ձեզ հարկավոր չի լինի տոմս գրել դեպի devops, դուք պարզապես կարող եք ինքներդ ձեզ համար մեկուսացված ենթակառուցվածք տեղադրել պատրաստի կաղապարներից, պատրաստի սցենարներից և իրականացնել այն: այնտեղ ձեր բոլոր փորձերը: Դուք կարող եք ջնջել սա, ստանալ որոշ արդյունքներ և լրացուցիչ հաղորդել դրա մասին:
Հաջորդ պրակտիկան, որը նույնպես գոյություն ունի և նույնպես կարևոր է, բայց որից քչերն են օգտագործում, հավելվածի կատարողականի մոնիտորինգն է:
Ես ուզում էի միայն մեկ բան ասել Application Performance Monitoring-ի մասին: Ի՞նչն է ամենակարևորը այս պրակտիկայի մեջ: Սա այն է, ինչ Application Performance Monitoring-ը մոտավորապես նույնն է, ինչ բնակարանի վերանորոգումը: Սա վերջնական վիճակ չէ, գործընթաց է։ Դուք պետք է պարբերաբար դա անեք:
Լավ իմաստով, լավ կլիներ իրականացնել Application Performance Monitoring-ը գրեթե յուրաքանչյուր նախագծում, չնայած, ինչպես հասկանում եք, դա միշտ չէ, որ հնարավոր է: Բայց, առնվազն, այն պետք է իրականացվի յուրաքանչյուր թողարկման համար:
Ինչու՞ է դա կարևոր: Որովհետև եթե դուք հանկարծակի կատարողականության անկում ապրեք, ապա պետք է հստակ հասկանաք, թե ինչու: Եթե ձեր թիմն ունի, ասենք, երկշաբաթյա սպրինտ, ապա առնվազն երկու շաբաթը մեկ անգամ դուք պետք է տեղադրեք ձեր հավելվածը որևէ առանձին սերվերի վրա, որտեղ դուք ունեք հստակ ֆիքսված պրոցեսոր, օպերատիվ հիշողություն, սկավառակներ և այլն: Եվ կատարեք այդ նույն աշխատանքի թեստերը: . Դուք ստանում եք արդյունքը: Տեսեք, թե ինչպես է այն փոխվել նախորդ սպրինտի համեմատ:
Եվ եթե իմանաք, որ ինչ-որ տեղ կտրուկ նվազել է, կնշանակի, որ դա եղել է ընդամենը վերջին երկու շաբաթվա ընթացքում տեղի ունեցած փոփոխությունների պատճառով։ Սա թույլ կտա ձեզ բացահայտել և շտկել խնդիրը շատ ավելի արագ: Եվ կրկին, սրանք մոտավորապես նույն ցուցանիշներն են, որոնցով դուք կարող եք չափել, թե որքան հաջողությամբ եք դա արել:
Հաջորդ պրակտիկան, որը մենք ունենք, կոնֆիգուրացիայի կառավարման պրակտիկան է: Շատ քչերն են, ովքեր լուրջ են վերաբերվում դրան: Բայց հավատացեք, սա իրականում շատ լուրջ բան է։
Վերջերս մի զվարճալի պատմություն եղավ. Տղաները եկան ինձ մոտ և ասացին. «Օգնիր մեզ մեր հավելվածի անվտանգության աուդիտ անցկացնել»: Մենք երկար ժամանակ միասին նայեցինք կոդը, նրանք ինձ ասացին հավելվածի մասին, գծագրեր գծեցին։ Եվ գումարած կամ մինուս ամեն ինչ տրամաբանական էր, հասկանալի, անվտանգ, բայց կար մեկ ԲԱՅՑ! Նրանք ունեին կազմաձևման ֆայլեր իրենց աղբյուրի հսկողության մեջ, ներառյալ IP տվյալների բազայի արտադրությունից ստացված ֆայլերը, մուտքերի և գաղտնաբառերով այս տվյալների բազաներին միանալու համար և այլն:
Եվ ես ասում եմ. «Տղաներ, լավ, դուք փակել եք ձեր արտադրական միջավայրը firewall-ով, բայց այն փաստը, որ դուք ունեք մուտքի և գաղտնաբառ արտադրության տվյալների բազայի հենց սկզբնաղբյուրի հսկողության մեջ, և ցանկացած մշակող կարող է կարդալ դա, արդեն իսկ անվտանգության ահռելի վտանգ է։ . Եվ անկախ նրանից, թե որքանով է գերապահով ձեր հավելվածը կոդի տեսանկյունից, եթե այն թողնեք աղբյուրի հսկողության տակ, ապա երբեք որևէ աուդիտ չեք անցկացնի որևէ տեղ»: Դա այն է, ինչի մասին ես խոսում եմ.
Կազմաձևման կառավարում. Մենք կարող ենք ունենալ տարբեր կոնֆիգուրացիաներ տարբեր միջավայրերում: Օրինակ, մենք կարող ենք ունենալ տարբեր մուտքեր և գաղտնաբառեր տվյալների բազաների համար QA-ի, ցուցադրման, արտադրական միջավայրի և այլնի համար:
Այս կոնֆիգուրացիան կարող է նաև ավտոմատացվել: Այն միշտ պետք է առանձին լինի բուն հավելվածից: Ինչո՞ւ։ Քանի որ դուք ստեղծել եք հավելվածը մեկ անգամ, իսկ հետո հավելվածին չի հետաքրքրում, թե արդյոք դուք միանում եք SQL սերվերին այսինչ IP-ի կամ այսինչ IP-ի միջոցով, այն պետք է աշխատի նույնը: Հետևաբար, եթե հանկարծ ձեզանից մեկը դեռ կոշտ կոդավորում է կապի տողը կոդի մեջ, ապա հիշեք, որ ես կգտնեմ ձեզ և կպատժեմ, եթե հայտնվեք ինձ հետ նույն նախագծում: Սա միշտ տեղադրվում է առանձին կոնֆիգուրացիայի մեջ, օրինակ՝ web.config-ում:
Եվ այս կոնֆիգուրացիան արդեն կառավարվում է առանձին, այսինքն՝ սա հենց այն պահն է, երբ ծրագրավորողը և ադմինիստրատորը կարող են գալ և նստել նույն սենյակում։ Իսկ մշակողը կարող է ասել. «Տեսեք, ահա իմ հավելվածի երկուականները։ Նրանք աշխատում են. Հավելվածին անհրաժեշտ է տվյալների բազա՝ աշխատելու համար: Այստեղ երկուականների կողքին կա ֆայլ։ Այս ֆայլում այս դաշտը պատասխանատու է մուտքի համար, սա գաղտնաբառի համար է, սա IP-ի համար է: Տեղադրեք այն ամենուր»: Եվ դա պարզ և պարզ է ադմինիստրատորի համար: Նա կարող է տեղակայել այն իսկապես ցանկացած վայրում՝ կառավարելով այս կոնֆիգուրացիան:
Եվ վերջին պրակտիկան, որի մասին ես կցանկանայի խոսել, պրակտիկա է, որը շատ, շատ կապված է ամպերի հետ: Եվ դա բերում է առավելագույն ազդեցություն, եթե աշխատում եք ամպի մեջ: Սա ձեր միջավայրի ավտոմատ հեռացումն է:
Ես գիտեմ, որ այս համաժողովին մի քանի հոգի կան այն թիմերից, որոնց հետ ես աշխատում եմ: Եվ բոլոր թիմերի հետ, որոնց հետ ես աշխատում եմ, մենք օգտագործում ենք այս պրակտիկան:
Ինչո՞ւ։ Իհարկե, հիանալի կլիներ, եթե յուրաքանչյուր մշակող ունենար վիրտուալ մեքենա, որը կաշխատի 24/7: Բայց միգուցե սա ձեզ համար նորություն է, միգուցե դուք ուշադրություն չեք դարձրել, բայց ծրագրավորողն ինքը չի աշխատում 24/7: Մշակողը սովորաբար աշխատում է օրական 8 ժամ: Նույնիսկ եթե նա շուտ է գալիս աշխատանքի, նա մեծ ճաշ է ունենում, որի ընթացքում գնում է մարզասրահ։ Թող լինի օրական 12 ժամ, երբ մշակողը իրականում օգտագործում է այս ռեսուրսները: Մեր օրենսդրությամբ մենք շաբաթական 5 օրից 7-ն ունենք, որոնք համարվում են աշխատանքային։
Համապատասխանաբար, աշխատանքային օրերին այս մեքենան չպետք է աշխատի 24 ժամ, այլ միայն 12, իսկ հանգստյան օրերին այս մեքենան ընդհանրապես չպետք է աշխատի։ Թվում է, թե ամեն ինչ շատ պարզ է, բայց ի՞նչն է կարևոր ասել այստեղ։ Իրականացնելով այս պարզ պրակտիկան այս հիմնական ժամանակացույցում, այն թույլ է տալիս նվազեցնել այս միջավայրերի պահպանման ծախսերը 70%-ով, այսինքն՝ վերցրել եք ձեր մշակողի, QA-ի, ցուցադրության, միջավայրի գինը և այն բաժանել 3-ի:
Հարց է առաջանում՝ ի՞նչ անել մնացած գումարի հետ։ Օրինակ, մշակողները պետք է գնեն ReSharper, եթե դեռ չեն գնել: Կամ կազմակերպեք կոկտեյլ երեկույթ: Եթե նախկինում ունեիք մեկ միջավայր, որտեղ և՛ dev-ը, և՛ QA-ն արածում էին, և վերջ, այժմ կարող եք ստեղծել 3 տարբեր, որոնք կմեկուսացվեն, և մարդիկ չեն խանգարի միմյանց:
Անընդհատ կատարողականի չափման սլայդի հետ կապված, ինչպե՞ս կարող ենք համեմատել կատարողականը, եթե նախագծում տվյալների բազայում ունեինք 1 գրառում, երկու ամիս հետո կա միլիոն: Ինչպե՞ս հասկանալ, թե ինչու և որն է արդյունավետությունը չափելու իմաստը:
Սա լավ հարց է, քանի որ դուք միշտ պետք է չափեք կատարողականը նույն ռեսուրսների վրա: Այսինքն, դուք թողարկում եք նոր ծածկագիր, դուք չափում եք կատարումը նոր կոդի վրա: Օրինակ, դուք պետք է փորձարկեք կատարման տարբեր սցենարներ, ասենք, ուզում եք ստուգել, թե ինչպես է հավելվածը աշխատում թեթև ծանրաբեռնվածության վրա, որտեղ կա 1 օգտվող, և տվյալների բազայի չափը 000 գիգաբայթ է: Դուք չափեցիք այն և ստացաք թվերը: Հաջորդը մենք վերցնում ենք մեկ այլ սցենար. Օրինակ՝ 5 օգտատեր, տվյալների բազայի չափը՝ 5 տերաբայթ։ Մենք ստացանք արդյունքները և հիշեցինք դրանք։
Ի՞նչն է այստեղ կարևոր: Այստեղ կարևորն այն է, որ կախված սցենարից, տվյալների ծավալից, միաժամանակ օգտագործողների քանակից և այլն, կարող եք որոշակի սահմանների մեջ ընկնել։ Օրինակ՝ մինչև ցանցային քարտի սահմանը, կամ կոշտ սկավառակի սահմանը կամ պրոցեսորի հնարավորությունների սահմանը։ Սա այն է, ինչ ձեզ համար կարևոր է հասկանալ: Տարբեր սցենարներում դուք բախվում եք որոշակի սահմանների: Եվ դուք պետք է հասկանաք թվերը, երբ հարվածում եք դրանց:
Արդյո՞ք մենք խոսում ենք հատուկ թեստային միջավայրում կատարողականությունը չափելու մասին: Այսինքն՝ սա արտադրություն չէ՞։
Այո, սա արտադրություն չէ, սա թեստային միջավայր է, որը միշտ նույնն է, որպեսզի կարողանաք համեմատել այն նախորդ չափումների հետ։
Հասկացա, շնորհակալություն!
Եթե հարցեր չլինեն, կարծում եմ՝ կարող ենք ավարտել։ Շնորհակալություն!
Source: www.habr.com