Մաս 1. Վեբ/Android
Նշում: այս հոդվածը բնօրինակ հոդվածի ռուսերեն թարգմանությունն է Այնուամենայնիվ, բոլոր նկարազարդումները, հղումները, մեջբերումները և տերմինները պահպանվում են բնօրինակ լեզվով, ռուսերեն թարգմանելիս իմաստի աղավաղումից խուսափելու համար: Մաղթում եմ ձեզ երջանիկ ուսում:
Ներկայումս DevOps մասնագիտությունը ՏՏ ոլորտում ամենապահանջվածներից մեկն է: Եթե բացեք աշխատանքի որոնման հանրաճանաչ կայքեր և զտեք ըստ աշխատավարձի, կտեսնեք, որ DevOps-ի հետ կապված աշխատանքները ցուցակի վերևում են։ Այնուամենայնիվ, կարևոր է հասկանալ, որ դա հիմնականում վերաբերում է «Ավագ» պաշտոնին, ինչը ենթադրում է, որ թեկնածուն ունի հմտությունների, տեխնոլոգիայի և գործիքների իմացության բարձր մակարդակ: Սա նաև պայմանավորված է արտադրության անխափան աշխատանքի հետ կապված պատասխանատվության բարձր աստիճանով: Այնուամենայնիվ, մենք սկսեցինք մոռանալ, թե ինչ է DevOps-ը: Ի սկզբանե դա որևէ կոնկրետ անձ կամ գերատեսչություն չէր։ Եթե փնտրենք այս տերմինի սահմանումները, ապա կգտնենք շատ գեղեցիկ և ճիշտ գոյականներ, ինչպիսիք են մեթոդաբանությունը, պրակտիկան, մշակութային փիլիսոփայությունը, հասկացությունների խումբը և այլն:
Իմ մասնագիտացումը թեստային ավտոմատացման ինժեներ է (QA automation engineer), բայց ես կարծում եմ, որ այն չպետք է կապված լինի միայն ավտոմատ թեստեր գրելու կամ թեստային շրջանակի ճարտարապետության մշակման հետ: 2020 թվականին անհրաժեշտ է նաև ավտոմատացման ենթակառուցվածքի իմացությունը։ Սա թույլ է տալիս ինքներդ կազմակերպել ավտոմատացման գործընթացը՝ սկսած թեստերից մինչև բոլոր շահագրգիռ կողմերին ձեր նպատակներին համապատասխան արդյունքներ տրամադրելը: Արդյունքում, DevOps-ի հմտությունները պարտադիր են աշխատանքն ավարտելու համար: Եվ այս ամենը լավ է, բայց, ցավոք, խնդիր կա (spoiler. այս հոդվածը փորձում է պարզեցնել այս խնդիրը) Բանն այն է, որ DevOps-ը դժվար է: Եվ դա ակնհայտ է, քանի որ ընկերությունները շատ չեն վճարի մի բանի համար, որը հեշտ է անել... DevOps աշխարհում կան մեծ թվով գործիքներ, տերմիններ և պրակտիկաներ, որոնք պետք է տիրապետել: Սա հատկապես դժվար է կարիերայի սկզբում և կախված է կուտակված տեխնիկական փորձից։
Source:
Այստեղ մենք հավանաբար կավարտենք ներածական մասով և կկենտրոնանանք այս հոդվածի նպատակի վրա:
Ինչի՞ մասին է այս հոդվածը։
Այս հոդվածում ես պատրաստվում եմ կիսվել փորձնական ավտոմատացման ենթակառուցվածք կառուցելու իմ փորձով: Ինտերնետում տեղեկատվության բազմաթիվ աղբյուրներ կան տարբեր գործիքների և դրանց կիրառման մասին, բայց ես կցանկանայի դրանք դիտարկել զուտ ավտոմատացման համատեքստում: Կարծում եմ, որ շատ ավտոմատացման ինժեներներ ծանոթ են իրավիճակին, երբ ոչ ոք, բացի ձեզնից, չի կատարում մշակված թեստերը կամ հոգ է տանում դրանց պահպանման մասին: Արդյունքում թեստերը դառնում են հնացած, և դուք պետք է ժամանակ ծախսեք դրանք թարմացնելու վրա: Կրկին, կարիերայի սկզբում սա կարող է բավականին բարդ խնդիր լինել. խելամտորեն որոշել, թե որ գործիքները պետք է օգնեն վերացնել տվյալ խնդիրը, ինչպես ընտրել, կարգավորել և պահպանել դրանք: Որոշ թեստավորողներ դիմում են DevOps-ին (մարդկանց) օգնության համար և, եկեք անկեղծ լինենք, այս մոտեցումն աշխատում է: Շատ դեպքերում դա կարող է լինել միակ տարբերակը, քանի որ մենք տեսանելիություն չունենք բոլոր կախվածությունների մեջ: Բայց ինչպես գիտենք, DevOps-ը շատ զբաղված տղաներ են, քանի որ նրանք պետք է մտածեն ամբողջ ընկերության ենթակառուցվածքի, տեղակայման, մոնիտորինգի, միկրոսերվիսների և այլ նմանատիպ խնդիրների մասին՝ կախված կազմակերպությունից/թիմից: Ինչպես սովորաբար լինում է, ավտոմատացումը առաջնահերթություն չէ: Նման պարագայում մենք պետք է փորձենք սկզբից մինչև վերջ անել հնարավորը մեր կողմից։ Սա կնվազեցնի կախվածությունները, կարագացնի աշխատանքի ընթացքը, կբարելավի մեր հմտությունները և թույլ կտա մեզ տեսնել տեղի ունեցողի ավելի մեծ պատկերը:
Հոդվածում ներկայացված են ամենատարածված և հանրաճանաչ գործիքները և ցույց է տրվում, թե ինչպես կարելի է դրանք օգտագործել ավտոմատացման ենթակառուցվածք կառուցելու համար քայլ առ քայլ: Յուրաքանչյուր խումբ ներկայացված է գործիքներով, որոնք փորձարկվել են անձնական փորձով: Բայց դա չի նշանակում, որ դուք պետք է օգտագործեք նույնը: Գործիքներն իրենք կարևոր չեն, դրանք հայտնվում և հնանում են։ Մեր ինժեներական խնդիրն է հասկանալ հիմնական սկզբունքները՝ ինչու է մեզ անհրաժեշտ գործիքների այս խումբը և ինչ աշխատանքային խնդիրներ կարող ենք լուծել դրանց օգնությամբ: Ահա թե ինչու յուրաքանչյուր բաժնի վերջում ես թողնում եմ նմանատիպ գործիքների հղումներ, որոնք կարող են օգտագործվել ձեր կազմակերպությունում:
Ինչ չկա այս հոդվածում
Եվս մեկ անգամ կրկնում եմ, որ հոդվածը կոնկրետ գործիքների մասին չէ, ուստի փաստաթղթերից և կոնկրետ հրամանների նկարագրություններից կոդի ներդիրներ չեն լինի։ Բայց յուրաքանչյուր բաժնի վերջում ես հղումներ եմ թողնում մանրամասն ուսումնասիրության համար:
Սա արվում է, քանի որ.
- այս նյութը շատ հեշտ է գտնել տարբեր աղբյուրներում (փաստաթղթեր, գրքեր, վիդեո դասընթացներ);
- եթե սկսենք խորանալ, ապա ստիպված կլինենք գրել այս հոդվածի 10, 20, 30 մասերը (մինչդեռ պլանները 2-3 են);
- Ես պարզապես չեմ ուզում վատնել ձեր ժամանակը, քանի որ դուք կարող եք օգտագործել այլ գործիքներ նույն նպատակներին հասնելու համար:
Պրակտիկա
Շատ կուզենայի, որ այս նյութը օգտակար լինի յուրաքանչյուր ընթերցողի համար, այլ ոչ թե պարզապես կարդացվի ու մոռացվի: Ցանկացած ուսումնասիրության մեջ պրակտիկան շատ կարևոր բաղադրիչ է: Դրա համար ես պատրաստել եմ. Կա նաև տնային աշխատանք, որը սպասում է ձեզ, որպեսզի համոզվեք, որ դուք անմիտ կերպով չեք պատճենում ձեր կատարած հրամանների տողերը:
Պլան
Քայլ
տեխնոլոգիա
Գործիքներ
1
Տեղական վազք (պատրաստեք վեբ / android-ի ցուցադրական թեստեր և գործարկեք այն տեղական)
Node.js, Selenium, Appium
2
Տարբերակի կառավարման համակարգեր
գնալ
3
Կոնտեյներացում
Docker, Selenium grid, Selenoid (Web, Android)
4
CI/CD
Gitlab CI
5
Cloud պլատֆորմները
Google Cloud պլատֆորմը
6
Նվագախումբ
Կուբերնետես
7
Ենթակառուցվածքը որպես կոդ (IaC)
Terraform, Ansible
Յուրաքանչյուր հատվածի կառուցվածքը
Պատմությունը պարզ պահելու համար յուրաքանչյուր բաժին նկարագրված է հետևյալ ուրվագծի համաձայն.
- տեխնոլոգիայի համառոտ նկարագրությունը,
- արժեքը ավտոմատացման ենթակառուցվածքի համար,
- ենթակառուցվածքի ներկա վիճակի նկարազարդում,
- ուսումնասիրության հղումներ,
- նմանատիպ գործիքներ:
1. Կատարեք թեստեր տեղական մակարդակում
Տեխնոլոգիայի համառոտ նկարագրությունը
Սա պարզապես նախապատրաստական քայլ է ցուցադրական թեստերը տեղում գործարկելու և դրանց անցումը հաստատելու համար: Գործնական մասում օգտագործվում է Node.js-ը, սակայն ծրագրավորման լեզուն և հարթակը նույնպես կարևոր չեն, և դուք կարող եք օգտագործել ձեր ընկերությունում օգտագործվողները։
Այնուամենայնիվ, որպես ավտոմատացման գործիքներ, ես խորհուրդ եմ տալիս օգտագործել Selenium WebDriver-ը վեբ հարթակների համար և Appium-ը Android պլատֆորմի համար, քանի որ հաջորդ քայլերում մենք կօգտագործենք Docker պատկերները, որոնք հարմարեցված են հատուկ այս գործիքների հետ աշխատելու համար: Ավելին, անդրադառնալով աշխատանքի պահանջներին, այս գործիքներն ամենապահանջվածն են շուկայում։
Ինչպես նկատել եք, մենք դիտարկում ենք միայն վեբ և Android թեստերը: Ցավոք սրտի, iOS-ը բոլորովին այլ պատմություն է (շնորհակալություն Apple-ին): Ես նախատեսում եմ ցուցադրել IOS-ի հետ կապված լուծումներն ու պրակտիկան առաջիկա մասերում:
Արժեքը ավտոմատացման ենթակառուցվածքի համար
Ենթակառուցվածքի տեսանկյունից, տեղական վազքը որևէ արժեք չի տալիս: Դուք միայն ստուգում եք, որ թեստերն աշխատում են տեղական մեքենայի վրա՝ տեղական բրաուզերներում և սիմուլյատորներում: Բայց ամեն դեպքում սա անհրաժեշտ ելակետ է։
Ենթակառուցվածքների ներկա վիճակի նկարազարդում
Հղումներ ուսումնասիրելու համար
Նմանատիպ գործիքներ
- ցանկացած ծրագրավորման լեզու, որը ձեզ դուր է գալիս, Selenium/Appium թեստերի հետ համատեղ;
- ցանկացած թեստեր;
- ցանկացած փորձնական վազորդ:
2. Տարբերակների կառավարման համակարգեր (Git)
Տեխնոլոգիայի համառոտ նկարագրությունը
Որևէ մեկի համար մեծ բացահայտում չի լինի, եթե ասեմ, որ տարբերակի վերահսկումը զարգացման չափազանց կարևոր մասն է, ինչպես թիմում, այնպես էլ անհատապես: Տարբեր աղբյուրների հիման վրա կարելի է վստահորեն ասել, որ Git-ը ամենահայտնի ներկայացուցիչն է։ Տարբերակների վերահսկման համակարգը տալիս է բազմաթիվ առավելություններ, ինչպիսիք են կոդերի փոխանակումը, տարբերակների պահպանումը, նախկին մասնաճյուղերի վերականգնումը, նախագծի պատմության մոնիտորինգը և կրկնօրինակումները: Յուրաքանչյուր կետ մանրամասն չենք քննարկելու, քանի որ վստահ եմ, որ դուք շատ ծանոթ եք դրան և օգտագործում եք ձեր ամենօրյա աշխատանքում։ Բայց եթե հանկարծ ոչ, ապա խորհուրդ եմ տալիս դադարեցնել այս հոդվածի ընթերցումը և որքան հնարավոր է շուտ լրացնել այս բացը:
Արժեքը ավտոմատացման ենթակառուցվածքի համար
Եվ այստեղ դուք կարող եք ողջամիտ հարց տալ. «Ինչու է նա մեզ պատմում Git-ի մասին: Սա բոլորը գիտեն և օգտագործում են ինչպես մշակման կոդի, այնպես էլ ավտոմատ փորձարկման կոդի համար»: Դուք բացարձակապես ճիշտ կլինեք, բայց այս հոդվածում մենք խոսում ենք ենթակառուցվածքների մասին, և այս բաժինը գործում է որպես 7-րդ բաժնի նախադիտում. «Ենթակառուցվածքը որպես կոդ (IaC)»: Մեզ համար սա նշանակում է, որ ամբողջ ենթակառուցվածքը, ներառյալ թեստավորումը, նկարագրված է կոդի տեսքով, այնպես որ մենք կարող ենք նաև կիրառել տարբերակների համակարգեր և ստանալ նմանատիպ առավելություններ, ինչ մշակման և ավտոմատացման կոդի համար:
Մենք ավելի մանրամասն կանդրադառնանք IaC-ին Քայլ 7-ում, բայց նույնիսկ հիմա կարող եք սկսել օգտագործել Git-ը լոկալ՝ ստեղծելով տեղական պահեստ: Մեծ պատկերը կընդլայնվի, երբ ենթակառուցվածքին ավելացնենք հեռավոր պահեստ:
Ենթակառուցվածքների ներկա վիճակի նկարազարդում
Հղումներ ուսումնասիրելու համար
Նմանատիպ գործիքներ
3. Կոնտեյներացում (Docker)
Տեխնոլոգիայի համառոտ նկարագրությունը
Ցույց տալու համար, թե ինչպես է կոնտեյներացումը փոխել խաղի կանոնները, եկեք մի քանի տասնամյակ հետ գնանք ժամանակը: Այն ժամանակ մարդիկ գնում և օգտագործում էին սերվերային մեքենաներ՝ հավելվածներ գործարկելու համար: Բայց շատ դեպքերում անհրաժեշտ ստարտափ ռեսուրսները նախապես հայտնի չեն եղել։ Արդյունքում, ընկերությունները գումարներ ծախսեցին թանկարժեք, հզոր սերվերներ գնելու վրա, սակայն այդ կարողությունների մի մասը ամբողջությամբ չօգտագործվեց:
Էվոլյուցիայի հաջորդ փուլը վիրտուալ մեքենաներն էին (VMs), որոնք լուծեցին չօգտագործված ռեսուրսների վրա գումար վատնելու խնդիրը։ Այս տեխնոլոգիան հնարավորություն տվեց գործարկել հավելվածները միմյանցից անկախ նույն սերվերում՝ հատկացնելով ամբողջովին մեկուսացված տարածք։ Բայց, ցավոք, ցանկացած տեխնոլոգիա ունի իր թերությունները. VM-ի գործարկումը պահանջում է լիարժեք օպերացիոն համակարգ, որը սպառում է պրոցեսոր, օպերատիվ հիշողություն, պահեստավորում և, կախված ՕՀ-ից, պետք է հաշվի առնել լիցենզիայի ծախսերը: Այս գործոնները ազդում են բեռնման արագության վրա և դժվարացնում տեղափոխելիությունը:
Եվ հիմա մենք հասնում ենք կոնտեյներացմանը: Եվս մեկ անգամ այս տեխնոլոգիան լուծում է նախկին խնդիրը, քանի որ կոնտեյներները չեն օգտագործում ամբողջական ՕՀ, ինչը մեծ քանակությամբ ռեսուրսներ է ազատում և արագ և ճկուն լուծում է տալիս շարժականության համար:
Իհարկե, կոնտեյներացման տեխնոլոգիան նորություն չէ և առաջին անգամ ներդրվել է 70-ականների վերջին: Այդ օրերին բազմաթիվ հետազոտություններ, մշակումներ, փորձեր արվեցին։ Բայց դա Docker-ն էր, որ հարմարեցրեց այս տեխնոլոգիան և այն հեշտությամբ հասանելի դարձրեց լայն զանգվածներին: Մեր օրերում, երբ խոսում ենք բեռնարկղերի մասին, շատ դեպքերում նկատի ունենք Docker-ը։ Երբ մենք խոսում ենք Docker կոնտեյներների մասին, մենք նկատի ունենք Linux կոնտեյներները: Մենք կարող ենք օգտագործել Windows և macOS համակարգերը կոնտեյներներ գործարկելու համար, բայց կարևոր է հասկանալ, որ այս դեպքում լրացուցիչ շերտ է հայտնվում։ Օրինակ, Docker-ը Mac-ում լուռ գործարկում է կոնտեյներներ թեթև Linux VM-ի ներսում: Մենք կվերադառնանք այս թեմային, երբ քննարկենք Android-ի էմուլյատորների գործարկումը կոնտեյներների ներսում, ուստի այստեղ կա մի շատ կարևոր նրբերանգ, որը պետք է ավելի մանրամասն քննարկվի:
Արժեքը ավտոմատացման ենթակառուցվածքի համար
Մենք պարզեցինք, որ կոնտեյներացումը և Docker-ը հիանալի են: Եկեք սա դիտարկենք ավտոմատացման համատեքստում, քանի որ յուրաքանչյուր գործիք կամ տեխնոլոգիա պետք է լուծի խնդիր: Եկեք ուրվագծենք թեստային ավտոմատացման ակնհայտ խնդիրները UI թեստերի համատեքստում.
- Սելենի և հատկապես Appium-ի տեղադրման ժամանակ մեծ թվով կախվածություններ.
- բրաուզերների, սիմուլյատորների և վարորդների տարբերակների համատեղելիության խնդիրներ.
- բրաուզերների/սիմուլյատորների համար մեկուսացված տարածքի բացակայություն, ինչը հատկապես կարևոր է զուգահեռ աշխատանքի համար.
- դժվար է կառավարել և պահպանել, եթե ձեզ անհրաժեշտ է միաժամանակ գործարկել 10, 50, 100 կամ նույնիսկ 1000 բրաուզեր:
Բայց քանի որ Selenium-ը ավտոմատացման ամենահայտնի գործիքն է, իսկ Docker-ը՝ կոնտեյներացման ամենահայտնի գործիքը, զարմանալի չէ, որ ինչ-որ մեկը փորձել է դրանք համատեղել՝ ստեղծելու հզոր գործիք՝ վերը նշված խնդիրները լուծելու համար: Դիտարկենք նման լուծումները ավելի մանրամասն:
Սելենի ցանցը դոկերում
Այս գործիքն ամենահայտնին է Selenium աշխարհում՝ բազմաթիվ բրաուզերներ մի քանի մեքենաների վրա գործարկելու և դրանք կենտրոնական հանգույցից կառավարելու համար: Սկսելու համար հարկավոր է գրանցել առնվազն 2 մաս՝ հանգույց և հանգույց(ներ): Հաբը կենտրոնական հանգույց է, որը ստանում է բոլոր հարցումները թեստերից և դրանք բաշխում համապատասխան հանգույցներին: Յուրաքանչյուր հանգույցի համար մենք կարող ենք կարգավորել որոշակի կոնֆիգուրացիա, օրինակ՝ նշելով ցանկալի բրաուզերը և դրա տարբերակը։ Այնուամենայնիվ, մենք դեռ պետք է ինքներս հոգ տանենք բրաուզերի համատեղելի դրայվերների մասին և տեղադրենք դրանք ցանկալի հանգույցների վրա: Այս պատճառով, Selenium grid-ը չի օգտագործվում իր մաքուր տեսքով, բացառությամբ այն դեպքերի, երբ մենք պետք է աշխատենք բրաուզերների հետ, որոնք չեն կարող տեղադրվել Linux OS-ում: Բոլոր մյուս դեպքերի համար զգալիորեն ճկուն և ճիշտ լուծում կլինի Docker պատկերների օգտագործումը Selenium grid Hub-ը և Nodes-ը գործարկելու համար: Այս մոտեցումը զգալիորեն հեշտացնում է հանգույցների կառավարումը, քանի որ մենք կարող ենք ընտրել մեզ անհրաժեշտ պատկերը բրաուզերների և արդեն տեղադրված դրայվերների համատեղելի տարբերակներով:
Չնայած կայունության վերաբերյալ բացասական ակնարկներին, հատկապես մեծ թվով հանգույցներ զուգահեռ աշխատելիս, Selenium grid-ը դեռևս ամենատարածված գործիքն է զուգահեռաբար սելենի թեստերի համար: Կարևոր է նշել, որ այս գործիքի տարբեր բարելավումներ և փոփոխություններ անընդհատ հայտնվում են բաց կոդով, որոնք պայքարում են տարբեր խոչընդոտների դեմ:
Selenoid ցանցի համար
Այս գործիքը բեկումնային է սելենի աշխարհում, քանի որ այն աշխատում է անմիջապես տուփից և շատ ավելի հեշտացրել է շատ ավտոմատացման ինժեներների կյանքը: Նախ, սա Selenium grid-ի հերթական փոփոխությունը չէ: Փոխարենը, ծրագրավորողները Գոլանգում ստեղծեցին Selenium Hub-ի բոլորովին նոր տարբերակը, որը զուգակցված տարբեր բրաուզերների համար թեթև Docker պատկերների հետ խթան հաղորդեց թեստային ավտոմատացման զարգացմանը: Ավելին, Selenium Grid-ի դեպքում մենք պետք է նախօրոք որոշենք բոլոր անհրաժեշտ բրաուզերները և դրանց տարբերակները, ինչը խնդիր չէ միայն մեկ բրաուզերի հետ աշխատելիս։ Բայց երբ խոսքը վերաբերում է բազմաթիվ աջակցվող բրաուզերներին, Selenoid-ը թիվ մեկ լուծումն է իր «զննարկիչ ըստ պահանջի» հատկության շնորհիվ: Մեզնից միայն պահանջվում է նախօրոք ներբեռնել անհրաժեշտ պատկերները բրաուզերներով և թարմացնել կազմաձևման ֆայլը, որի հետ Սելենոիդը համագործակցում է։ Այն բանից հետո, երբ Selenoid-ը թեստերից հարցում է ստանում, այն ավտոմատ կերպով կգործարկի ցանկալի բեռնարկղը ցանկալի բրաուզերով: Երբ փորձարկումն ավարտվի, Selenoid-ը կթողարկի կոնտեյները՝ դրանով իսկ ազատելով ռեսուրսները ապագա հարցումների համար: Այս մոտեցումը լիովին վերացնում է «հանգույցի դեգրադացիայի» հայտնի խնդիրը, որը մենք հաճախ հանդիպում ենք սելենի ցանցում:
Բայց, ավաղ, Սելենոիդը դեռ արծաթե փամփուշտ չէ։ Մենք ստացել ենք «զննարկիչ ըստ պահանջի» գործառույթը, սակայն «պահանջով ռեսուրսներ» գործառույթը դեռ հասանելի չէ: Selenoid-ն օգտագործելու համար մենք պետք է այն տեղակայենք ֆիզիկական սարքաշարի կամ VM-ի վրա, ինչը նշանակում է, որ մենք պետք է նախապես իմանանք, թե որքան ռեսուրսներ պետք է հատկացվեն: Կարծում եմ, որ սա խնդիր չէ փոքր նախագծերի համար, որոնք զուգահեռ աշխատում են 10, 20 կամ նույնիսկ 30 բրաուզերների համար: Բայց ի՞նչ, եթե մեզ անհրաժեշտ լինի 100, 500, 1000 կամ ավելի: Անիմաստ է անընդհատ պահպանել և վճարել այդքան ռեսուրսների համար: Այս հոդվածի 5-րդ և 6-րդ բաժիններում մենք կքննարկենք լուծումներ, որոնք թույլ են տալիս մասշտաբավորել՝ դրանով իսկ զգալիորեն նվազեցնելով ընկերության ծախսերը:
Selenoid Android-ի համար
Selenoid-ի՝ որպես վեբ ավտոմատացման գործիքի հաջողությունից հետո մարդիկ ցանկանում էին նման բան Android-ի համար: Եվ դա տեղի ունեցավ - Selenoid-ը թողարկվեց Android-ի աջակցությամբ: Բարձր մակարդակի օգտագործողների տեսանկյունից գործարկման սկզբունքը նման է վեբ ավտոմատացմանը: Միակ տարբերությունն այն է, որ զննարկիչի կոնտեյներների փոխարեն, Selenoid-ն աշխատում է Android emulator կոնտեյներներով: Ըստ իս, սա ներկայումս ամենահզոր անվճար գործիքն է Android-ի թեստերը զուգահեռ գործարկելու համար։
Ես իսկապես չէի ցանկանա խոսել այս գործիքի բացասական կողմերի մասին, քանի որ այն ինձ իսկապես դուր է գալիս: Բայց այնուամենայնիվ, կան նույն թերությունները, որոնք վերաբերում են վեբ ավտոմատացմանը և կապված են մասշտաբի հետ: Ի հավելումն սրան, մենք պետք է խոսենք ևս մեկ սահմանափակման մասին, որը կարող է անակնկալ լինել, եթե մենք առաջին անգամ ստեղծենք գործիքը: Android-ի պատկերները գործարկելու համար մեզ անհրաժեշտ է ֆիզիկական մեքենա կամ VM՝ վիրտուալացման աջակցությամբ: Ինչպես-ի ուղեցույցում ես ցույց եմ տալիս, թե ինչպես դա միացնել Linux VM-ում: Այնուամենայնիվ, եթե դուք macOS-ի օգտատեր եք և ցանկանում եք տեղակայել Selenoid-ը, ապա դա հնարավոր չի լինի իրականացնել Android-ի թեստերը: Բայց դուք միշտ կարող եք գործարկել Linux VM-ը տեղում՝ կազմաձևված «ներդիր վիրտուալիզացիայով» և տեղադրել Selenoid-ը ներսում:
Ենթակառուցվածքների ներկա վիճակի նկարազարդում
Այս հոդվածի համատեքստում մենք կավելացնենք 2 գործիք ենթակառուցվածքը պատկերացնելու համար: Սրանք են Selenium grid-ը վեբ թեստերի համար և Selenoid-ը Android-ի թեստերի համար: GitHub-ի ձեռնարկում ես նաև ձեզ ցույց կտամ, թե ինչպես օգտագործել Selenoid-ը՝ վեբ թեստերն իրականացնելու համար:
Հղումներ ուսումնասիրելու համար
Նմանատիպ գործիքներ
- Կան կոնտեյներացման այլ գործիքներ, բայց Docker-ը ամենատարածվածն է: Եթե ցանկանում եք որևէ այլ բան փորձել, հիշեք, որ այն գործիքները, որոնք մենք ներկայացրել ենք սելենի թեստերը զուգահեռ անցկացնելու համար, չեն աշխատի:
- Ինչպես արդեն ասվեց, սելենի ցանցի բազմաթիվ փոփոխություններ կան, օրինակ..
4.CI/CD
Տեխնոլոգիայի համառոտ նկարագրությունը
Շարունակական ինտեգրման պրակտիկան բավականին տարածված է զարգացման մեջ և համընկնում է տարբերակների կառավարման համակարգերի հետ: Չնայած դրան, ես զգում եմ, որ տերմինաբանության մեջ շփոթություն կա։ Այս պարբերությունում ես կցանկանայի նկարագրել այս տեխնոլոգիայի 3 փոփոխություն իմ տեսանկյունից: Համացանցում դուք կգտնեք բազմաթիվ հոդվածներ տարբեր մեկնաբանություններով, և բացարձակապես նորմալ է, եթե ձեր կարծիքը տարբերվում է: Ամենակարևորն այն է, որ դու քո գործընկերների հետ նույն կողմում ես։
Այսպիսով, կա 3 տերմին՝ CI - Continuous Integration, CD - Continuous Delivery և կրկին CD - Continuous Deployment: (Ստորև ես կօգտագործեմ այս տերմինները անգլերենում) Յուրաքանչյուր փոփոխություն ավելացնում է մի քանի լրացուցիչ քայլեր ձեր զարգացման խողովակաշարին: Բայց խոսքը շարունակական (շարունակական) ամենակարեւորն է։ Այս համատեքստում մենք նկատի ունենք մի բան, որը տեղի է ունենում սկզբից մինչև վերջ, առանց ընդհատումների կամ ձեռքի միջամտության: Եկեք նայենք CI & CD-ին և CD-ին այս համատեքստում:
- Շարունակական ինտեգրում սա էվոլյուցիայի սկզբնական քայլն է: Նոր կոդը սերվեր ուղարկելուց հետո մենք ակնկալում ենք արագ արձագանք ստանալ, որ մեր փոփոխությունները լավ են: Սովորաբար, CI-ն ներառում է ստատիկ կոդի վերլուծության գործիքների և միավորի/ներքին API-ի թեստերի գործարկում: Սա թույլ է տալիս մեզ տեղեկություններ ստանալ մեր կոդի մասին մի քանի վայրկյան/րոպեում:
- Շարունակական Առաքում ավելի առաջադեմ քայլ է, որտեղ մենք կատարում ենք ինտեգրման/UI թեստեր: Այնուամենայնիվ, այս փուլում մենք արդյունք չենք ստանում այնքան արագ, որքան CI-ով: Նախ, այս տեսակի թեստերն ավելի երկար են տևում ավարտելու համար: Երկրորդ, գործարկումից առաջ մենք պետք է մեր փոփոխությունները տեղակայենք թեստային/փուլային միջավայրում: Ավելին, եթե մենք խոսում ենք բջջային ծրագրավորման մասին, ապա լրացուցիչ քայլ է հայտնվում՝ ստեղծելու մեր հավելվածի բիլդը։
- Շարունակ տեղակայում ենթադրում է, որ մենք ավտոմատ կերպով թողարկում ենք արտադրության մեր փոփոխությունները, եթե ընդունման բոլոր թեստերն անցել են նախորդ փուլերում: Ի հավելումն դրան, թողարկման փուլից հետո կարող եք կարգավորել տարբեր փուլեր, օրինակ՝ ծխի թեստերի անցկացումը արտադրության վրա և հավաքագրել հետաքրքրության չափանիշները: Շարունակական տեղակայումը հնարավոր է միայն լավ ծածկույթով ավտոմատացված թեստերով: Եթե ձեռքով որևէ միջամտություն է պահանջվում, ներառյալ թեստավորումը, ապա դա այլևս չէ Շարունակական (շարունակական): Այնուհետև կարող ենք ասել, որ մեր խողովակաշարը համապատասխանում է միայն շարունակական առաքման պրակտիկային:
Արժեքը ավտոմատացման ենթակառուցվածքի համար
Այս բաժնում ես պետք է հստակեցնեմ, որ երբ մենք խոսում ենք վերջից մինչև վերջ UI թեստերի մասին, դա նշանակում է, որ մենք պետք է տեղակայենք մեր փոփոխությունները և հարակից ծառայությունները փորձարկման միջավայրերում: Շարունակական ինտեգրում. գործընթացը կիրառելի չէ այս առաջադրանքի համար, և մենք պետք է հոգ տանենք առնվազն շարունակական առաքման պրակտիկաների իրականացման մասին: Continuous Deployment-ը նաև իմաստ ունի UI թեստերի համատեքստում, եթե մենք պատրաստվում ենք դրանք գործարկել արտադրության մեջ:
Եվ մինչ մենք կանդրադառնանք ճարտարապետության փոփոխության նկարազարդմանը, ես ուզում եմ մի քանի խոսք ասել GitLab CI-ի մասին: Ի տարբերություն այլ CI/CD գործիքների՝ GitLab-ը տրամադրում է հեռավոր պահեստ և շատ այլ լրացուցիչ հնարավորություններ: Այսպիսով, GitLab-ը ավելին է, քան CI-ն: Այն ներառում է ելակետային կոդի կառավարում, արագաշարժ կառավարում, CI/CD խողովակաշարեր, անտառահատումների գործիքներ և չափումների հավաքագրում: GitLab ճարտարապետությունը բաղկացած է Gitlab CI/CD-ից և GitLab Runner-ից: Ահա կարճ նկարագրությունը պաշտոնական կայքից.
Gitlab CI/CD-ն API-ով վեբ հավելված է, որը պահում է իր վիճակը տվյալների բազայում, կառավարում է նախագծերը/կառուցում և տրամադրում է օգտատիրոջ միջերես: GitLab Runner-ը ծրագիր է, որը մշակում է կառուցումները: Այն կարող է տեղակայվել առանձին և աշխատում է GitLab CI/CD-ի հետ API-ի միջոցով: Գործարկվող թեստերի համար ձեզ հարկավոր է և՛ Gitlab օրինակ, և՛ Runner:
Ենթակառուցվածքների ներկա վիճակի նկարազարդում
Հղումներ ուսումնասիրելու համար
Նմանատիպ գործիքներ
- Եվ շատ ուրիշներ
5. Ամպային հարթակներ
Տեխնոլոգիայի համառոտ նկարագրությունը
Այս բաժնում մենք կխոսենք հայտնի միտումի մասին, որը կոչվում է «հանրային ամպեր»: Չնայած վերը նկարագրված վիրտուալացման և կոնտեյներացման տեխնոլոգիաների ահռելի առավելություններին, մենք դեռևս հաշվողական ռեսուրսների կարիք ունենք: Ընկերությունները գնում են թանկարժեք սերվերներ կամ վարձակալում տվյալների կենտրոններ, սակայն այս դեպքում անհրաժեշտ է հաշվարկներ կատարել (երբեմն անիրատեսական), թե որքան ռեսուրսներ մեզ անհրաժեշտ կլինեն, արդյոք դրանք կօգտագործենք 24/7 և ինչ նպատակով։ Օրինակ, արտադրության համար պահանջվում է սերվեր, որն աշխատում է XNUMX/XNUMX, բայց արդյոք մեզ անհրաժեշտ են նմանատիպ ռեսուրսներ աշխատանքային ժամերից դուրս փորձարկման համար: Դա կախված է նաև կատարվող փորձարկման տեսակից: Օրինակ կարող են լինել ծանրաբեռնվածության/սթրես թեստերը, որոնք մենք նախատեսում ենք անցկացնել ոչ աշխատանքային ժամերին՝ հաջորդ օրը արդյունք ստանալու համար: Բայց հաստատ XNUMX/XNUMX սերվերի առկայությունը չի պահանջվում ծայրից ծայր ավտոմատացված թեստերի և հատկապես ձեռքով փորձարկման միջավայրերի համար: Նման իրավիճակների համար լավ կլինի պահանջով ձեռք բերել այնքան ռեսուրսներ, որքան անհրաժեշտ է, օգտագործել դրանք և դադարեցնել վճարումները, երբ դրանք այլևս կարիք չունեն: Ավելին, հիանալի կլիներ դրանք ստանալ ակնթարթորեն՝ մկնիկի մի քանի կտտոց անելով կամ մի քանի սցենար գործարկելով։ Ահա թե ինչի համար են օգտագործվում հանրային ամպերը: Եկեք նայենք սահմանմանը.
«Հանրային ամպը սահմանվում է որպես հաշվողական ծառայություններ, որոնք առաջարկվում են երրորդ կողմի մատակարարների կողմից հանրային ինտերնետի միջոցով՝ դրանք հասանելի դարձնելով բոլորին, ովքեր ցանկանում են օգտագործել կամ գնել դրանք: Նրանք կարող են լինել անվճար կամ վաճառվել ըստ պահանջի, ինչը թույլ է տալիս հաճախորդներին վճարել միայն մեկ օգտագործման համար CPU-ի ցիկլերի, պահեստավորման կամ թողունակության համար, որը նրանք սպառում են»:
Կարծիք կա, որ հանրային ամպերը թանկ են։ Բայց նրանց հիմնական գաղափարը ընկերության ծախսերի կրճատումն է: Ինչպես նշվեց ավելի վաղ, հանրային ամպերը թույլ են տալիս ստանալ ռեսուրսներ ըստ պահանջի և վճարել միայն դրանք օգտագործելու ժամանակի համար: Նաև երբեմն մոռանում ենք, որ աշխատողները աշխատավարձ են ստանում, իսկ մասնագետները նույնպես թանկ ռեսուրս են։ Պետք է հաշվի առնել, որ հանրային ամպերը զգալիորեն հեշտացնում են ենթակառուցվածքների աջակցությունը, ինչը թույլ է տալիս ինժեներներին կենտրոնանալ ավելի կարևոր խնդիրների վրա։
Արժեքը ավտոմատացման ենթակառուցվածքի համար
Ի՞նչ հատուկ ռեսուրսներ են մեզ անհրաժեշտ վերջից մինչև վերջ UI թեստերի համար: Հիմնականում դրանք վիրտուալ մեքենաներ կամ կլաստերներ են (մենք կխոսենք Kubernetes-ի մասին հաջորդ բաժնում) բրաուզերների և էմուլյատորների գործարկման համար: Որքան շատ բրաուզերներ և էմուլյատորներ ենք ուզում աշխատել միաժամանակ, այնքան ավելի շատ պրոցեսոր և հիշողություն է պահանջվում, և այնքան ավելի շատ գումար պետք է վճարենք դրա համար: Այսպիսով, հանրային ամպերը թեստային ավտոմատացման համատեքստում մեզ թույլ են տալիս գործարկել մեծ թվով (100, 200, 1000...) բրաուզերներ/էմուլյատորներ ըստ պահանջի, հնարավորինս արագ ստանալ թեստի արդյունքները և դադարել վճարել նման խելահեղ ռեսուրսների համար: ուժ.
Ամպային ամենահայտնի մատակարարներն են Amazon Web Services (AWS), Microsoft Azure, Google Cloud Platform (GCP): Ինչպես-ի ուղեցույցը տալիս է օրինակներ, թե ինչպես օգտագործել GCP-ն, բայց ընդհանուր առմամբ կարևոր չէ, թե ինչ եք օգտագործում ավտոմատացման առաջադրանքների համար: Նրանք բոլորն ապահովում են մոտավորապես նույն գործառույթը: Սովորաբար, մատակարար ընտրելու համար ղեկավարությունը կենտրոնանում է ընկերության ամբողջ ենթակառուցվածքի և բիզնեսի պահանջների վրա, ինչը դուրս է այս հոդվածի շրջանակներից: Ավտոմատացման ինժեներների համար ավելի հետաքրքիր կլինի համեմատել ամպային պրովայդերների օգտագործումը հատուկ թեստավորման նպատակով ամպային հարթակների օգտագործման հետ, ինչպիսիք են Sauce Labs, BrowserStack, BitBar և այլն: Այնպես որ, եկեք դա նույնպես անենք: Իմ կարծիքով, Sauce Labs-ը ամպի փորձարկման ամենահայտնի ֆերմա է, այդ իսկ պատճառով ես այն օգտագործել եմ համեմատության համար։
GCP vs Sauce Labs ավտոմատացման նպատակներով.
Եկեք պատկերացնենք, որ մենք պետք է միաժամանակ գործարկենք 8 վեբ թեստ և 8 Android թեստ: Դրա համար մենք կօգտագործենք GCP և կաշխատենք 2 վիրտուալ մեքենա Selenoid-ով: Առաջինի վրա մենք կբարձրացնենք 8 կոնտեյներ բրաուզերներով։ Երկրորդի վրա կա էմուլյատորներով 8 կոնտեյներ։ Եկեք նայենք գներին.
Chrome-ով մեկ կոնտեյներ գործարկելու համար մեզ անհրաժեշտ է n1-ստանդարտ-1 մեքենա. Android-ի դեպքում դա կլինի n1-ստանդարտ-4 մեկ էմուլյատորի համար: Իրականում, ավելի ճկուն և էժան միջոց է CPU/Memory-ի համար օգտագործողի հատուկ արժեքներ սահմանելն է, բայց այս պահին դա կարևոր չէ Sauce Labs-ի հետ համեմատելու համար:
Եվ ահա Sauce Labs-ի օգտագործման սակագները.
Կարծում եմ, դուք արդեն նկատել եք տարբերությունը, բայց ես դեռ կներկայացնեմ աղյուսակ մեր առաջադրանքի համար հաշվարկներով.
Պահանջվող ռեսուրսներ
Ամսական
Աշխատանքային ժամեր `(8:8 - XNUMX:XNUMX)
Աշխատանքային ժամեր `+ Կանխավճար
GCP ցանցի համար
n1-ստանդարտ-1 x 8 = n1-ստանդարտ-8
$194.18
23 օր * 12ժ * 0.38 = 104.88 դոլար
23 օր * 12ժ * 0.08 = 22.08 դոլար
Սոուսի լաբորատորիաներ համացանցի համար
Վիրտուալ Cloud8-ի զուգահեռ թեստեր
$1.559
-
-
GCP Android-ի համար
n1-ստանդարտ-4 x 8: n1-ստանդարտ-16
$776.72
23 օր * 12ժ * 1.52 = 419.52 դոլար
23 օր * 12ժ * 0.32 = 88.32 դոլար
Sauce Labs Android-ի համար
Real Device Cloud 8 զուգահեռ թեստեր
$1.999
-
-
Ինչպես տեսնում եք, ծախսերի տարբերությունը հսկայական է, հատկապես, եթե դուք փորձարկումներ եք կատարում միայն տասներկու ժամ աշխատանքային ժամանակահատվածում: Բայց դուք կարող եք է՛լ ավելի կրճատել ծախսերը, եթե օգտագործում եք կանխարգելիչ մեքենաներ: Ի՞նչ է դա։
Նախնական VM-ն այն օրինակն է, որը դուք կարող եք ստեղծել և գործարկել շատ ավելի թանկ գնով, քան սովորական օրինակները: Այնուամենայնիվ, Compute Engine-ը կարող է դադարեցնել (կանխարգելել) այս դեպքերը, եթե այն պահանջում է մուտք գործել այդ ռեսուրսներին այլ առաջադրանքների համար: Կանխարգելման դեպքերը Հաշվողական շարժիչի ավելցուկային հզորությունն են, ուստի դրանց հասանելիությունը տարբերվում է օգտագործման հետ:
Եթե ձեր հավելվածները սխալների նկատմամբ հանդուրժող են և կարող են դիմակայել հնարավոր օրինակների կանխարգելմանը, ապա կանխարգելիչ օրինակները կարող են զգալիորեն նվազեցնել ձեր Հաշվողական շարժիչի ծախսերը: Օրինակ, խմբաքանակի մշակման աշխատանքները կարող են գործարկվել կանխարգելիչ օրինակների վրա: Եթե այդ դեպքերից մի քանիսը ավարտվում են մշակման ընթացքում, աշխատանքը դանդաղում է, բայց ամբողջությամբ չի դադարում: Կանխավճարային օրինակներն ավարտում են ձեր խմբաքանակի մշակման առաջադրանքները՝ առանց լրացուցիչ ծանրաբեռնվածության ձեր առկա օրինակների վրա և առանց ձեզանից պահանջելու վճարել ամբողջ գինը լրացուցիչ սովորական օրինակների համար:
Եվ դա դեռ չի ավարտվել: Իրականում, վստահ եմ, ոչ ոք առանց ընդմիջման 12 ժամ թեստեր չի անում: Եվ եթե այո, ապա դուք կարող եք ավտոմատ կերպով գործարկել և դադարեցնել վիրտուալ մեքենաները, երբ դրանք անհրաժեշտ չեն: Օգտագործման փաստացի ժամանակը կարող է կրճատվել մինչև օրական 6 ժամ: Այնուհետև վճարումը մեր առաջադրանքի համատեքստում կնվազի մինչև ամսական $11 8 բրաուզերի համար։ Սա հրաշալի չէ՞: Բայց կանխարգելվող մեքենաների դեպքում մենք պետք է զգույշ լինենք և պատրաստ լինենք ընդհատումների և անկայունության, թեև այս իրավիճակները կարող են ապահովվել և կարգավորվել ծրագրային ապահովման մեջ: Դա արժե այն!
Բայց ես ոչ մի կերպ չեմ ասում «երբեք մի օգտագործեք ամպային փորձարկման ֆերմաներ»: Նրանք ունեն մի շարք առավելություններ. Նախ, սա ոչ միայն վիրտուալ մեքենա է, այլ լիարժեք փորձարկման ավտոմատացման լուծում, որն ունի մի շարք ֆունկցիոնալ հնարավորություններ՝ հեռակա մուտք, տեղեկամատյաններ, սքրինշոթներ, տեսագրում, տարբեր բրաուզերներ և ֆիզիկական շարժական սարքեր: Շատ իրավիճակներում սա կարող է էական շքեղ այլընտրանք լինել: Փորձարկման հարթակները հատկապես օգտակար են IOS-ի ավտոմատացման համար, երբ հանրային ամպերը կարող են առաջարկել միայն Linux/Windows համակարգեր: Բայց iOS-ի մասին կխոսենք հաջորդ հոդվածներում։ Ես խորհուրդ եմ տալիս միշտ նայել իրավիճակին և սկսել առաջադրանքներից. որոշ դեպքերում ավելի էժան և արդյունավետ է օգտագործել հանրային ամպերը, իսկ որոշ դեպքերում թեստային հարթակներն անկասկած արժեն ծախսված գումարը:
Ենթակառուցվածքների ներկա վիճակի նկարազարդում
Հղումներ ուսումնասիրելու համար
Նմանատիպ գործիքներ.
6. Նվագախումբ
Տեխնոլոգիայի համառոտ նկարագրությունը
Ես լավ նորություն ունեմ. մենք գրեթե հոդվածի վերջում ենք: Այս պահին մեր ավտոմատացման ենթակառուցվածքը բաղկացած է վեբ և Android թեստերից, որոնք մենք զուգահեռաբար անցկացնում ենք GitLab CI-ի միջոցով՝ օգտագործելով Docker-ի միացված գործիքները՝ Selenium grid և Selenoid: Ավելին, մենք օգտագործում ենք վիրտուալ մեքենաներ, որոնք ստեղծված են GCP-ի միջոցով՝ զննարկիչներով և էմուլյատորներով կոնտեյներներ տեղադրելու համար: Ծախսերը նվազեցնելու համար մենք գործարկում ենք այս վիրտուալ մեքենաները միայն ըստ պահանջի և դադարեցնում ենք դրանք, երբ փորձարկումը չի իրականացվում: Կա՞ որևէ այլ բան, որը կարող է բարելավել մեր ենթակառուցվածքը: Պատասխանը այո է։ Հանդիպեք Kubernetes-ին (K8s):
Նախ, եկեք տեսնենք, թե ինչպես են միմյանց հետ կապված նվագախումբ, կլաստեր և Կուբերնետես բառերը: Բարձր մակարդակի վրա նվագախումբը այն համակարգն է, որը տեղակայում և կառավարում է հավելվածները: Փորձարկման ավտոմատացման համար նման կոնտեյներային հավելվածներն են Selenium grid-ը և Selenoid-ը: Docker-ը և K8-ները լրացնում են միմյանց: Առաջինն օգտագործվում է հավելվածների տեղակայման համար, երկրորդը՝ նվագախմբման համար։ Իր հերթին, K8-ը կլաստեր է: Կլաստերի խնդիրն է օգտագործել VM-ները որպես հանգույցներ, ինչը թույլ է տալիս մեկ սերվերի (կլաստերի) ներսում տեղադրել տարբեր գործառույթներ, ծրագրեր և ծառայություններ։ Եթե հանգույցներից որևէ մեկը ձախողվի, այլ հանգույցներ կվերցնեն, ինչը ապահովում է մեր հավելվածի անխափան աշխատանքը: Բացի սրանից, K8-ն ունի մասշտաբի հետ կապված կարևոր ֆունկցիոնալություն, որի շնորհիվ մենք ավտոմատ կերպով ստանում ենք ռեսուրսների օպտիմալ քանակը՝ հիմնվելով բեռի վրա և սահմանում ենք սահմաններ։
Իրականում, Kubernetes-ի ձեռքով զրոյից տեղակայելը ամենևին էլ չնչին խնդիր չէ: Ես կթողնեմ «Kubernetes The Hard Way» հայտնի ուղեցույցի հղումը, և եթե հետաքրքրված եք, կարող եք կիրառել այն: Բայց, բարեբախտաբար, կան այլընտրանքային մեթոդներ և գործիքներ։ Ամենահեշտ ճանապարհը GCP-ում Google Kubernetes Engine-ի (GKE) օգտագործումն է, որը թույլ կտա մի քանի կտտոցով ստանալ պատրաստի կլաստեր։ Ես խորհուրդ եմ տալիս օգտագործել այս մոտեցումը սովորել սկսելու համար, քանի որ այն թույլ կտա ձեզ կենտրոնանալ սովորելու վրա, թե ինչպես օգտագործել K8-ները ձեր առաջադրանքների համար՝ սովորելու փոխարեն, թե ինչպես պետք է ներքին բաղադրիչները ինտեգրվեն միմյանց հետ:
Արժեքը ավտոմատացման ենթակառուցվածքի համար
Եկեք դիտարկենք մի քանի կարևոր առանձնահատկություններ, որոնք ապահովում են K8s-ը.
- հավելվածի տեղակայում. VM-ների փոխարեն բազմահանգույցների կլաստերի օգտագործումը;
- դինամիկ մասշտաբավորում. նվազեցնում է ռեսուրսների արժեքը, որոնք օգտագործվում են միայն ըստ պահանջի.
- ինքնաբուժում. պատիճների ավտոմատ վերականգնում (որի արդյունքում վերականգնվում են նաև տարաները);
- Թարմացումների տարածում և փոփոխությունների հետադարձում առանց ընդհատումների. գործիքների, բրաուզերների և էմուլյատորների թարմացումը չի ընդհատում ներկայիս օգտատերերի աշխատանքը
Բայց K8-ը դեռևս արծաթե փամփուշտ չէ: Մեր դիտարկած գործիքների համատեքստում բոլոր առավելություններն ու սահմանափակումները հասկանալու համար (Selenium grid, Selenoid), մենք համառոտ կքննարկենք K8-ների կառուցվածքը: Կլաստերը պարունակում է երկու տեսակի հանգույցներ՝ Master Nodes և Workers Nodes: Master Nodes-ը պատասխանատու է կառավարման, տեղակայման և պլանավորման որոշումների համար: Աշխատողների հանգույցները այնտեղ են, որտեղ գործարկվում են հավելվածները: Հանգույցները պարունակում են նաև կոնտեյների գործարկման միջավայր: Մեր դեպքում դա Docker-ն է, որը պատասխանատու է կոնտեյների հետ կապված գործառնությունների համար: Բայց կան նաև այլընտրանքային լուծումներ, օրինակ. Կարևոր է հասկանալ, որ թեփոտումը կամ ինքնաբուժումը ուղղակիորեն չի վերաբերում տարաներին: Սա իրականացվում է՝ ավելացնելով/նվազեցնելով պատյանների քանակը, որոնք իրենց հերթին պարունակում են բեռնարկղեր (սովորաբար մեկ կոնտեյներ յուրաքանչյուր պատիճ, բայց կախված առաջադրանքից կարող են լինել ավելին): Բարձր մակարդակի հիերարխիան բաղկացած է աշխատող հանգույցներից, որոնց ներսում կան պատյաններ, որոնց ներսում բեռնարկղերը բարձրացված են։
Սանդղակավորման հատկանիշը առանցքային է և կարող է կիրառվել ինչպես կլաստերի հանգույցների լողավազանի, այնպես էլ հանգույցների վրա՝ հանգույցների մեջ: Գոյություն ունեն սանդղակի 2 տեսակ, որոնք կիրառվում են ինչպես հանգույցների, այնպես էլ պատիճների համար: Առաջին տեսակը հորիզոնական է՝ մասշտաբը տեղի է ունենում հանգույցների/փոդերի քանակի ավելացմամբ: Այս տեսակն ավելի նախընտրելի է։ Երկրորդ տեսակը, համապատասխանաբար, ուղղահայաց է: Մասշտաբավորումն իրականացվում է հանգույցների/փոկերի չափի մեծացմամբ, այլ ոչ թե դրանց քանակով։
Այժմ եկեք նայենք մեր գործիքներին վերը նշված տերմինների համատեքստում:
Սելենի ցանց
Ինչպես նշվեց ավելի վաղ, Selenium grid-ը շատ տարածված գործիք է, և զարմանալի չէ, որ այն բեռնարկղային է: Հետևաբար, զարմանալի չէ, որ Selenium ցանցը կարող է տեղակայվել K8-ներում: Օրինակ, թե ինչպես դա անել, կարելի է գտնել պաշտոնական K8s պահոցում: Ինչպես միշտ, ես հղումներ եմ կցում բաժնի վերջում: Բացի այդ, ինչպես անել ուղեցույցը ցույց է տալիս, թե ինչպես դա անել Terraform-ում: Կան նաև հրահանգներ այն մասին, թե ինչպես կարելի է չափել բրաուզերի կոնտեյներներ պարունակող պատյանների քանակը: Բայց K8-ների համատեքստում ավտոմատ մասշտաբավորման գործառույթը դեռևս լիովին ակնհայտ խնդիր չէ: Երբ սկսեցի սովորել, ոչ մի գործնական ուղեցույց կամ առաջարկություն չգտա: DevOps թիմի աջակցությամբ մի քանի ուսումնասիրություններից և փորձերից հետո մենք ընտրեցինք անհրաժեշտ բրաուզերներով կոնտեյներներ բարձրացնելու մոտեցումը մեկ պատիճում, որը գտնվում է մեկ աշխատող հանգույցի ներսում: Այս մեթոդը թույլ է տալիս կիրառել հանգույցների հորիզոնական մասշտաբի ռազմավարությունը՝ ավելացնելով դրանց թիվը։ Հուսով եմ, որ դա կփոխվի ապագայում, և մենք կտեսնենք ավելի ու ավելի շատ ավելի լավ մոտեցումների և պատրաստի լուծումների նկարագրություններ, հատկապես փոփոխված ներքին ճարտարապետությամբ Selenium grid 4-ի թողարկումից հետո:
Սելենոիդ:
Selenoid-ի տեղակայումը K8-ում ներկայումս ամենամեծ հիասթափությունն է: Նրանք համատեղելի չեն: Տեսականորեն մենք կարող ենք Selenoid կոնտեյներ բարձրացնել պատիճ ներսում, բայց երբ Selenoid-ը սկսում է բրաուզերներով բեռնարկղեր գործարկել, դրանք դեռ կլինեն նույն պատի ներսում: Սա անհնարին է դարձնում մասշտաբը, և արդյունքում Selenoid-ի աշխատանքը կլաստերի ներսում չի տարբերվի վիրտուալ մեքենայի ներսում աշխատանքից: Պատմության ավարտը.
լուսին:
Իմանալով այս խոչընդոտը Selenoid-ի հետ աշխատելիս՝ մշակողները թողարկել են ավելի հզոր գործիք, որը կոչվում է Moon: Այս գործիքը ի սկզբանե նախատեսված էր Kubernetes-ի հետ աշխատելու համար, և արդյունքում կարող է և պետք է օգտագործվի autoscaling ֆունկցիան: Ավելին, ես կասեի, որ այս պահին այդպես է միայնակ գործիք Selenium աշխարհում, որն ունի բնիկ K8s կլաստերային աջակցություն տուփից դուրս (այլևս հասանելի չէ, տես հաջորդ գործիքը ) Լուսնի հիմնական հատկանիշները, որոնք ապահովում են այս աջակցությունը, հետևյալն են.
Լիովին քաղաքացիություն չունեցող. Սելենոիդը հիշողության մեջ պահում է տեղեկատվությունը բրաուզերի ընթացիկ աշխատաշրջանների մասին: Եթե ինչ-ինչ պատճառներով դրա գործընթացը խափանվում է, ապա բոլոր գործող նիստերը կորչում են: Լուսինը, ընդհակառակը, չունի ներքին վիճակ և կարող է կրկնօրինակվել տվյալների կենտրոններում: Բրաուզերի աշխատաշրջանները մնում են կենդանի, նույնիսկ եթե մեկ կամ մի քանի կրկնօրինակներ անհետանան:
Այսպիսով, Լուսինը հիանալի լուծում է, բայց կա մեկ խնդիր՝ այն անվճար չէ։ Գինը կախված է նիստերի քանակից։ Դուք կարող եք անվճար վարել միայն 0-4 սեանս, որն առանձնապես օգտակար չէ: Բայց հինգերորդ նիստից սկսած՝ յուրաքանչյուրի համար պետք է վճարեք 5 դոլար։ Իրավիճակը կարող է տարբեր լինել ընկերությունից ընկերություն, բայց մեր դեպքում Moon-ի օգտագործումն անիմաստ է։ Ինչպես նկարագրեցի վերևում, մենք կարող ենք աշխատեցնել VM-ները Selenium Grid-ով ըստ պահանջի կամ ավելացնել հանգույցների թիվը կլաստերում: Մոտավորապես մեկ խողովակաշարի համար մենք գործարկում ենք 500 բրաուզեր և դադարեցնում ենք բոլոր ռեսուրսները փորձարկումների ավարտից հետո: Եթե մենք օգտագործեինք Moon-ը, մենք ստիպված կլինեինք ամսական լրացուցիչ վճարել 500 x 5 = 2500 դոլար, անկախ նրանից, թե որքան հաճախ ենք փորձարկումներ կատարում: Կրկին, ես չեմ ասում, որ մի օգտագործեք Moon-ը: Ձեր առաջադրանքների համար սա կարող է լինել անփոխարինելի լուծում, օրինակ, եթե ձեր կազմակերպությունում ունեք բազմաթիվ նախագծեր/թիմեր և ձեզ անհրաժեշտ է հսկայական ընդհանուր կլաստեր բոլորի համար: Ինչպես միշտ, ես վերջում թողնում եմ հղում և խորհուրդ եմ տալիս կատարել բոլոր անհրաժեշտ հաշվարկները ձեր առաջադրանքի համատեքստում:
Callisto: (Ուշադրություն. Սա բնօրինակ հոդվածում չէ և պարունակվում է միայն ռուսերեն թարգմանության մեջ)
Ինչպես ասացի, սելենը շատ տարածված գործիք է, և ՏՏ ոլորտը շատ արագ է զարգանում։ Մինչ ես աշխատում էի թարգմանության վրա, համացանցում հայտնվեց նոր խոստումնալից գործիք, որը կոչվում է Callisto (բարև Cypress և այլ սելենի մարդասպաններ): Այն աշխատում է բնիկորեն K8-ների հետ և թույլ է տալիս գործարկել Selenoid կոնտեյներները պատիճներով, որոնք բաշխված են հանգույցների վրա: Ամեն ինչ աշխատում է անմիջապես տուփից, ներառյալ ավտոմատ մասշտաբը: Ֆանտաստիկ է, բայց պետք է փորձարկել: Ես արդեն հասցրել եմ տեղակայել այս գործիքը և մի քանի փորձեր կատարել: Բայց դեռ վաղ է եզրակացություններ անելու համար, երկար հեռավորության վրա արդյունքներ ստանալուց հետո, երևի հետագա հոդվածներում ակնարկ անեմ: Առայժմ ես թողնում եմ միայն հղումներ անկախ հետազոտության համար:
Ենթակառուցվածքների ներկա վիճակի նկարազարդում
Հղումներ ուսումնասիրելու համար
Նմանատիպ գործիքներ
7. Ենթակառուցվածքը որպես կոդ (IaC)
Տեխնոլոգիայի համառոտ նկարագրությունը
Եվ հիմա մենք հասնում ենք վերջին բաժնին: Սովորաբար, այս տեխնոլոգիան և հարակից առաջադրանքները ավտոմատացման ինժեներների պատասխանատվությունը չեն: Եվ դրա համար կան պատճառներ. Նախ, շատ կազմակերպություններում ենթակառուցվածքի հարցերը գտնվում են DevOps բաժնի հսկողության տակ, և մշակող թիմերին իրականում չի հետաքրքրում, թե ինչն է ստիպում խողովակաշարն աշխատել և ինչպես պետք է աջակցել դրա հետ կապված ամեն ինչ: Երկրորդ, եկեք անկեղծ լինենք, Ենթակառուցվածքը որպես կոդ (IaC) պրակտիկան դեռևս ընդունված չէ շատ ընկերություններում։ Բայց դա միանշանակ դարձել է հանրաճանաչ միտում, և կարևոր է փորձել ներգրավվել դրա հետ կապված գործընթացներում, մոտեցումներում և գործիքներում։ Կամ գոնե տեղեկացված մնացեք:
Սկսենք այս մոտեցումն օգտագործելու մոտիվացիայից: Մենք արդեն քննարկել ենք, որ GitlabCI-ում թեստեր գործարկելու համար մեզ անհրաժեշտ կլինեն առնվազն ռեսուրսներ Gitlab Runner-ը գործարկելու համար: Իսկ բրաուզերներով/էմուլյատորներով կոնտեյներներ գործարկելու համար մենք պետք է VM կամ կլաստեր վերապահենք: Ի հավելումն ռեսուրսների փորձարկման, մեզ անհրաժեշտ է զգալի հզորություն՝ աջակցելու զարգացմանը, բեմադրությանը, արտադրական միջավայրերին, որոնք ներառում են նաև տվյալների շտեմարաններ, ավտոմատ ժամանակացույցեր, ցանցի կոնֆիգուրացիաներ, բեռի հավասարակշռողներ, օգտվողների իրավունքները և այլն: Հիմնական խնդիրը այդ ամենին աջակցելու համար պահանջվող ջանքերն են: Կան մի քանի եղանակներ, որոնց միջոցով մենք կարող ենք փոփոխություններ կատարել և թարմացումներ տարածել: Օրինակ, GCP-ի համատեքստում մենք կարող ենք օգտագործել UI կոնսոլը բրաուզերում և կատարել բոլոր գործողությունները՝ սեղմելով կոճակները: Այլընտրանք կարող է լինել API-ի զանգերի օգտագործումը ամպային սուբյեկտների հետ փոխազդելու համար կամ օգտագործել gcloud հրամանի տողի օգտակար ծրագիրը՝ ցանկալի մանիպուլյացիաները կատարելու համար: Բայց իսկապես մեծ թվով տարբեր միավորների և ենթակառուցվածքի տարրերի առկայության դեպքում բոլոր գործողությունները ձեռքով կատարելը դառնում է դժվար կամ նույնիսկ անհնար: Ավելին, այս բոլոր ձեռքով գործողությունները անվերահսկելի են: Մենք չենք կարող դրանք վերանայման ներկայացնել նախքան կատարումը, օգտագործել տարբերակների վերահսկման համակարգ և արագ հետ վերադարձնել միջադեպի հանգեցրած փոփոխությունները: Նման խնդիրները լուծելու համար ինժեներները ստեղծել և ստեղծել են ավտոմատ bash/shell սկրիպտներ, որոնք շատ ավելի լավը չեն, քան նախորդ մեթոդները, քանի որ դրանք այնքան էլ հեշտ չէ արագ կարդալ, հասկանալ, պահպանել և փոփոխել ընթացակարգային ոճով:
Այս հոդվածում և ուղեցույցում ես օգտագործում եմ IaC պրակտիկայի հետ կապված 2 գործիք: Սրանք Terraform և Ansible են: Ոմանք կարծում են, որ անիմաստ է դրանք միաժամանակ օգտագործել, քանի որ դրանց ֆունկցիոնալությունը նման է և դրանք փոխարինելի են: Բայց փաստն այն է, որ սկզբում նրանց տրվում են բոլորովին այլ առաջադրանքներ։ Իսկ այն, որ այս գործիքները պետք է լրացնեն միմյանց, հաստատվել է HashiCorp-ը և RedHat-ը ներկայացնող մշակողների համատեղ շնորհանդեսի ժամանակ։ Հայեցակարգային տարբերությունն այն է, որ Terraform-ը տրամադրող գործիք է հենց սերվերները կառավարելու համար: Մինչդեռ Ansible-ը կազմաձևման կառավարման գործիք է, որի խնդիրն է տեղադրել, կարգավորել և կառավարել ծրագրակազմը այս սերվերների վրա:
Այս գործիքների մեկ այլ հիմնական տարբերակիչ հատկանիշը կոդավորման ոճն է: Ի տարբերություն bash-ի և Ansible-ի՝ Terraform-ն օգտագործում է դեկլարատիվ ոճ՝ հիմնված կատարման արդյունքում ձեռք բերվող ցանկալի վերջնական վիճակի նկարագրության վրա: Օրինակ, եթե մենք ստեղծենք 10 VM և կիրառենք փոփոխությունները Terraform-ի միջոցով, ապա կստանանք 10 VM։ Եթե մենք նորից գործարկենք սցենարը, ոչինչ չի պատահի, քանի որ մենք արդեն ունենք 10 VM, և Terraform-ը գիտի այս մասին, քանի որ այն պահպանում է ենթակառուցվածքի ներկայիս վիճակը պետական ֆայլում: Բայց Ansible-ն օգտագործում է ընթացակարգային մոտեցում, և եթե նրան խնդրեք ստեղծել 10 VM, ապա առաջին գործարկման ժամանակ մենք կստանանք 10 VM՝ նման Terraform-ին: Բայց վերագործարկումից հետո մենք արդեն կունենանք 20 VM: Սա է կարևոր տարբերությունը։ Ընթացակարգային ոճով մենք չենք պահում ներկա վիճակը և պարզապես նկարագրում ենք քայլերի հաջորդականությունը, որոնք պետք է կատարվեն: Իհարկե, մենք կարող ենք հաղթահարել տարբեր իրավիճակներ, ավելացնել մի քանի ստուգումներ ռեսուրսների առկայության և ներկա վիճակի համար, բայց իմաստ չունի ժամանակ վատնել և ջանք թափել այս տրամաբանությունը վերահսկելու համար: Բացի այդ, սա մեծացնում է սխալվելու վտանգը:
Ամփոփելով վերը նշված բոլորը, մենք կարող ենք եզրակացնել, որ Terraform-ը և դեկլարատիվ նշումը ավելի հարմար գործիք են սերվերների տրամադրման համար: Բայց ավելի լավ է կազմաձևման կառավարման աշխատանքը փոխանցել Ansible-ին: Քանի որ դա բացակայում է, եկեք նայենք օգտագործման դեպքերին ավտոմատացման համատեքստում:
Արժեքը ավտոմատացման ենթակառուցվածքի համար
Այստեղ հասկանալի միակ կարևոր բանն այն է, որ փորձարկման ավտոմատացման ենթակառուցվածքը պետք է դիտարկվի որպես ընկերության ամբողջ ենթակառուցվածքի մաս: Սա նշանակում է, որ IaC-ի բոլոր պրակտիկաները պետք է կիրառվեն գլոբալ մակարդակով՝ ամբողջ կազմակերպության ռեսուրսների համար: Ով է պատասխանատու դրա համար, կախված է ձեր գործընթացներից: DevOps-ի թիմն ավելի փորձառու է այս հարցերում, նրանք տեսնում են տեղի ունեցողի ամբողջ պատկերը։ Այնուամենայնիվ, QA ինժեներները ավելի շատ ներգրավված են շենքերի ավտոմատացման և խողովակաշարի կառուցվածքի գործընթացում, ինչը թույլ է տալիս նրանց ավելի լավ տեսնել բոլոր անհրաժեշտ փոփոխություններն ու բարելավման հնարավորությունները: Լավագույն տարբերակը միասին աշխատելն է, գիտելիքների ու գաղափարների փոխանակումը սպասվող արդյունքին հասնելու համար։
Ահա Terraform-ի և Ansible-ի օգտագործման մի քանի օրինակներ թեստային ավտոմատացման համատեքստում և այն գործիքները, որոնք մենք նախկինում քննարկել ենք.
1. Նկարագրեք VM-ների և կլաստերների անհրաժեշտ բնութագրերն ու պարամետրերը Terraform-ի միջոցով:
2. Ansible-ի միջոցով տեղադրեք փորձարկման համար անհրաժեշտ գործիքները՝ docker, Selenoid, Selenium Grid և ներբեռնեք բրաուզերների/էմուլյատորների անհրաժեշտ տարբերակները:
3. Օգտագործելով Terraform-ը, նկարագրեք VM-ի բնութագրերը, որում կգործարկվի GitLab Runner-ը:
4. Տեղադրեք GitLab Runner-ը և անհրաժեշտ ուղեկցող գործիքները՝ օգտագործելով Ansible, սահմանեք կարգավորումներ և կոնֆիգուրացիաներ:
Ենթակառուցվածքների ներկա վիճակի նկարազարդում
Հղումներ ուսումնասիրելու համար.
Նմանատիպ գործիքներ
Եկեք ամփոփենք այն:
Քայլ
տեխնոլոգիա
Գործիքներ
Արժեքը ավտոմատացման ենթակառուցվածքի համար
1
Տեղական վազք
Node.js, Selenium, Appium
- Ամենատարածված գործիքները վեբ-ի և բջջայինի համար
- Աջակցում է բազմաթիվ լեզուների և հարթակների (ներառյալ Node.js-ը)
2
Տարբերակի կառավարման համակարգեր
գնալ
- Նմանատիպ առավելություններ զարգացման կոդով
3
Կոնտեյներացում
Docker, Selenium grid, Selenoid (Web, Android)
- Զուգահեռաբար թեստեր անցկացնելը
- Մեկուսացված միջավայրեր
- Պարզ, ճկուն տարբերակի արդիականացում
- Չօգտագործված ռեսուրսների դինամիկ դադարեցում
- Հեշտ է կարգավորել
4
CI/CD
Gitlab CI
- Փորձարկում է խողովակաշարի մի մասը
- Արագ արձագանք
- Տեսանելիություն ամբողջ ընկերության/թիմի համար
5
Cloud պլատֆորմները
Google Cloud պլատֆորմը
- Ռեսուրսներ ըստ պահանջի (մենք վճարում ենք միայն անհրաժեշտության դեպքում)
- Հեշտ է կառավարել և թարմացնել
- Բոլոր ռեսուրսների տեսանելիությունը և վերահսկողությունը
6
Նվագախումբ
Կուբերնետես
Բրաուզերներով/էմուլյատորներով բեռնարկղերի համատեքստում՝ պատիճների ներսում.
- Scaling/auto scaling
- Ինքնաբուժում
- Թարմացումներ և հետադարձումներ առանց ընդհատումների
7
Ենթակառուցվածքը որպես կոդ (IaC)
Terraform, Ansible
- Նմանատիպ առավելություններ զարգացման ենթակառուցվածքների հետ կապված
- Կոդերի տարբերակման բոլոր առավելությունները
- Հեշտ է փոփոխություններ կատարել և պահպանել
- Լիովին ավտոմատացված
Մտքի քարտեզի դիագրամներ. ենթակառուցվածքի էվոլյուցիան
Քայլ 1. Տեղական
Քայլ 2. VCS
Քայլ 3. Կոնտեյներացում
Քայլ 4. CI/CD
Քայլ 5. Ամպային հարթակներ
Քայլ 6. Նվագախումբ
քայլ 7. IaC
Ինչ հաջորդ?
Այսպիսով, սա հոդվածի ավարտն է: Բայց ամփոփելով՝ ես կցանկանայի ձեզ հետ որոշ պայմանավորվածություններ հաստատել։
Ձեր կողմից
Ինչպես սկզբում ասվեց, ես կցանկանայի, որ հոդվածը գործնական կիրառություն ունենա և օգներ ձեռք բերված գիտելիքները կիրառել իրական աշխատանքում: Նորից ավելացնում եմ.
Բայց նույնիսկ դրանից հետո մի կանգնեք, պարապեք, ուսումնասիրեք համապատասխան հղումներ և գրքեր, պարզեք, թե ինչպես է այն աշխատում ձեր ընկերությունում, գտեք վայրեր, որոնք կարելի է բարելավել և մասնակցեք դրան: Հաջողություն!
Իմ կողմից
Վերնագրից երևում է, որ սա միայն առաջին մասն էր։ Չնայած այն հանգամանքին, որ այն բավականին ծավալուն է ստացվել, այնուամենայնիվ կարևոր թեմաներն այստեղ չեն լուսաբանվում։ Երկրորդ մասում ես նախատեսում եմ դիտարկել ավտոմատացման ենթակառուցվածքը IOS-ի համատեքստում: Apple-ի սահմանափակումների պատճառով iOS-ի սիմուլյատորները միայն macOS համակարգերում գործարկելու հարցում, մեր լուծումների շրջանակը նեղացել է: Օրինակ, մենք չենք կարող օգտագործել Docker-ը՝ սիմուլյատորը գործարկելու համար, կամ հանրային ամպեր՝ վիրտուալ մեքենաներ գործարկելու համար: Բայց դա չի նշանակում, որ այլ այլընտրանքներ չկան։ Ես կփորձեմ ձեզ թարմացնել առաջադեմ լուծումներով և ժամանակակից գործիքներով:
Նաև մոնիտորինգի հետ կապված բավականին մեծ թեմաներ չեմ նշել։ 3-րդ մասում ես պատրաստվում եմ դիտարկել ենթակառուցվածքի մոնիտորինգի ամենահայտնի գործիքները և ինչ տվյալներ և չափումներ պետք է հաշվի առնել:
Եւ, վերջապես. Ապագայում ես նախատեսում եմ թողարկել տեսադասընթաց թեստային ենթակառուցվածքների և հանրաճանաչ գործիքների կառուցման վերաբերյալ: Ներկայումս ինտերնետում DevOps-ի վերաբերյալ բավականին շատ դասընթացներ և դասախոսություններ կան, բայց բոլոր նյութերը ներկայացված են մշակման, այլ ոչ թե թեստային ավտոմատացման համատեքստում։ Այս հարցում ես իսկապես կարիք ունեմ արձագանքների, թե արդյոք նման դասընթացը հետաքրքիր և արժեքավոր կլինի թեստավորողների և ավտոմատացման ինժեներների համայնքի համար: Կանխավ շնորհակալություն!
Source: www.habr.com