Համեղ 1: Web / Android
Նշում: այս հոդվածը ռուսերեն լեզվով թարգմանություն է ի սկզբանե հոդվածից Այսպիսով, բոլոր պատկերները, հղումները, հարցումները և հասկացությունները պահպանվում են սկզբնական լեզվով՝ փախչելու համար երթուղիների կատաղությունից, երբ թարգմանվում է դեպի ռուսերեն։ Ներդրում եմ հաճելի ուսուցում!
Այս պահին DevOps մասնագիտությունը ամենաբարձր պահանջարկ ունեցողներից մեկն է IT արդյունաբերությունում։ Եթե դուք բացեք հայտնի աշխատավարձային որոնման կայքերը և կիրառեք աշխատավարձի ֆիլտր, կտեսնեք, որ DevOps-ի հետ կապված աշխատատեղերը գտնվում են ցուցակի սկզբում։ Չնայած դրան, կարևոր է հասկանալ, որ սա मुख्यապես վերաբերում է ‘Senior’ դիրքին, որն ենթադրում է, որ թեկնածուն ունի բարձր մակարդակի հմտություններ, տեխնոլոգիաների և գործիքների գիտելիքներ։ Դրանով կապված է բարձր պատասխանատվության աստիճան, որը կապված է production-ի անխափան աշխատանքի հետ։ Սակայն մենք սկսել ենք մոռանալ, ինչը է DevOps-ը։ Ի սկզբանե դա չէինք դիտարկում որպես որևէ կոնկրետ անձ կամ բաժին։ Եթե մենք փնտրենք այս տերմինի սահմանումները, ապա կգտնենք շատ գեղեցիկ ու ճիշտ անուններ, ինչպիսիք են մեթոդաբանություն, պրակտիկա, մշակութային փիլիսոփայություն, գաղափարների խումբ և այլն։
Իմ մասնագիտությունը՝ QA ավտոմատացման ինժեներ (QA automation engineer), սակայն կարծում եմ, որ այն պետք է կապված լինի միայն ավտո-tեզերի գրելուն կամ թեստային կառուցվածքի մշակմանը։ 2020 թվականին ավտոմատացման ենթակառուցվածքի գիտելիքներն նույնպես անհրաժեշտ են։ Սա թույլ է տալիս կազմակերպել ավտոմատացման գործընթացը ինքնուրույն, սկսած թեստերի մեկնարկից մինչև արդյունքների տրամադրումը բոլոր հետաքրքրված կողմերին՝ ըստ առկա նպատակների։ Հետևաբար, DevOps հմտությունները պարտադիր գործոն են այս աշխատանքի կատարման համար։ Եվ բոլորը շատ լավ է, բայց, ցավոք, կա խնդիր (spoiler: այս հոդվածը փորձում է պարզեցնել այդ խնդիրը). Ամբողջությունն այն է, որ DevOps ունակություններն արվում են բարդ։ Եվ սա ակնհայտ է, քանի որ ընկերությունները չեն վճարի շատ գումար այն բանի համար, ինչը հեշտ է անել… DevOps աշխարհում մեծ թվով գործիքներ, տերմիններ, պրակտիկներ կան, որոնց պետք է տիրապետել։ Այս ամենը հատկապես դժվար է նոր կարիերայի սկզբում և կախված է կուտակված տեխնիկական փորձից։
Ընտանիք:
Այստեղ, կարծես, ավարտենք ծանոթության մասը և կենտրոնանանք այս հոդվածի նպատակին։
Այս հոդվածը ինչի մասին է
Այս հոդվածում ես կիսվում եմ իմ փորձով թեստավորման ավտոմատացման ենթակառուցվածքի կառուցման գործում: Ցանցում կարելի է գտնել բազմաթիվ տեղեկություններ տարբեր գործիքների մասին և թե ինչպես օգտագործել դրանք, սակայն ես կցանկանայի քննարկել դրանք բացառապես ավտոմատացման համատեքստում: Հավատում եմ, որ շատ ավտոմատացման ինժեներներին ծանոթ է այն իրավիճակը, երբ մշակված թեստերը, բացի ձեզնից, ոչ ոք չի կիրառում և չի հոգում դրանց պահպանման մասին: Արդյունքում, թեստերը դառնում են հնացած, և անհրաժեշտ է ծախսել ժամանակ դրանց актуализация-ի համար: Կրկին, կարիերայի սկզբում դա կարող է լինել բավականին բարդ խնդիր. ճիշտ որոշել, թե որ գործիքները պետք է օգնեն լուծելու այս խնդիրը, ինչպես ընտրել, կարգավորել և պահպանել դրանք: Մի քանի թեստավորողներ դիմում են DevOps (հեռանկարային) մասնագետներին, և, խոստովանենք, այս մոտեցումը գործում է: Շատ դեպքերում դա կարող է լինել միակ տարբերակը, քանի որ չունենք բոլոր կախվածությունների տեսանելիություն: Սակայն, ինչպես գիտենք, DevOps-ն շատ զբաղված տղաներ են, քանի որ նրանք պետք է մտածեն ողջ ընկերության ենթակառուցվածքի, ներդրման, մոնիթորինգի, միկրոծառայությունների և նմանատիպ այլ խնդիրների մասին: Ինչպես միշտ, ավտոմատացումը նախապատրաստական չէ: Այս դեպքում մենք պետք է փորձենք անել հնարավոր ամեն ինչ մեր կողմից սկզբից մինչև վերջ: Սա կնվազեցնի կախվածությունները, կարագացնի աշխատանքային գործընթացը, կբարելավի մեր հմտությունները և թույլ կտա մեզ տեսնել գործընթացի լայն picture-ը:
Հոդվածում ներկայացված են առավել պահանջված և հայտնի գործիքները և թե ինչպես օգտագործել դրանք ավտոմատացման ենթակառուցվածքի կառուցման քայլ առ քայլ: Յուրաքանչյուր խումբ ներկայացված է գործիքներով, որոնք փորձարկվել են անձնական փորձով: Սակայն դա չի նշանակում, որ դուք պետք է օգտագործեք նույնը: Գործիքները կարևոր չեն, դրանք ի հայտնվում և հնանում: Մեր ինժեներական խնդիրը՝ հասկանալ հիմնարար սկզբունքները. ինչու է մեզ անհրաժեշտ այս գործիքների խումբ և ինչ աշխատանքային խնդիրներ կարող ենք լուծել դրանց միջոցով: Այդ պատճառով, յուրաքանչյուր բաժնի վերջում ես թողնում եմ հղումներ այլ նմանատիպ գործիքների, որոնք, հնարավոր է, օգտագործված են ձեր կազմակերպությունում:
Այս հոդվածում չկա այնպիսի իրեր
Ա nochmals կրկնում եմ, որ հոդվածը կոնկրետ գործիքների մասին չէ, այդ պատճառով այստեղ չեն լինի կոդի հատվածներ документация-ի և կոնկրետ հրամանների նկարագրություններ: Սակայն յուրաքանչյուր բաժնի վերջում ես թողնում եմ հղումներ մանրամասն ուսումնասիրության համար:
Դա արվել է հետևյալ պատճառով:
- այս նյութը շատ հեշտությամբ կարելի է գտնել տարբեր աղբյուրներում (հրապարակումներ, գրքեր, տեսանյութերի դասընթացներ);
- եթե մենք սկսենք խորանալ, ապա ստիպված կլինենք գրել 10, 20, 30 մաս այս հոդվածից (երբ որ ծրագրեր նախատեսված են 2-3);
- ես պարզապես չէի ուզում ծախսել ձեր ժամանակը, որովհետև հնարավոր է, որ դուք ցանկանում եք օգտվել այլ գործիքներից նույն նպատակներին հասնելու համար։
Փորձ
Ես շատ կցանկանայի, որպեսզի այս նյութը օգտակար լիներ յուրաքանչյուր ընթերցողի համար, ոչ թե պարզապես կարդացած ու մոռացված: Ուսումը միշտ պետք է ուղեկցվի պրակտիկայով: Դրա համար ես պատրաստել եմ։ Ձեզ սպասում է նաև տնային աշխատանք, որպեսզի վստահ լինեք, որ դուք անիմաստ ձեզ մուրզել հրամանների շարքերը
Պլան
Քայլ
Տեխնոլոգիա
Գործիքներ
1
Այն տարածքը, որտեղ դուք կաշխատեք (պատրաստեք կայք/անդրադարձի դեմո հուզում՝ և աշխատեք այն տեղայնապես)
Node.js, Selenium, Appium
2
Տ/version հրամանների կառավարման համակարգեր
Git
3
Կոնտեյներսում
Docker, Selenium grid, Selenoid (Web, Android)
4
CI/CD
Gitlab CI
5
Cloud platforms
Google Cloud Platform
6
Օրակարգ
Kubernetes
7
Տեղն են հանդիսանում որպես կոդ (IaC)
Terraform, Ansible
Յուրաքանչյուր բաժնի կառուցվածքը
Գործ ընթացը պարզ ու գտնվելու համար, յուրաքանչյուր բաժին նկարագիրը ունի հետևյալ պլանով՝
- տեխնոլոգիայի համառոտ նկարագրություն,
- ավտոմատացման ենթաակարկչի արժեքը,
- տարածքի ներկայիս վիճակի նկարագրությունը,
- ուսումնասիրելու հղումներ,
- նման գործիքներ։
1. Տեղային վարկածների թողարկում
Տեխնոլոգիայի համառոտ նկարագրություն
Սա պարզապես նախապատրաստիչ քայլ է տեղային դեմո թեստերն իրականացնելու համար և համոզվելու համար, որ նրանք విజయад են անցնում: Պրակտիկ կիսին օգտագործում ենք Node.js, բայց ծրագրավորման լեզուն և պլատֆորմը չէին կարևոր, կարող եք օգտագործել այն, ինչ օգտագործել իրենց ընկերության մեջ։
Բայց ավտոմատացման գործիքներով ես խորհուրդ եմ տալիս օգտագործել Selenium WebDriver web պլատֆորմների և Appium Android պլատֆորմի համար, քանի որ հաջորդ քայլերից մենք օգտագործելու ենք Docker պատուհանի, որոնք նախատեսված են ըստ այս գործիքների աշխատանքի: Բացի այդ, աշխատատեղերի պահանջներում նշելով, այս գործիքները ամենահարուստ են շուկայում։
Այնպես, ինչպես դուք նկատում եք, մենք քննարկում ենք միայն web և Android թեստերը: Ցավոք. IOS-ը՝ լրիվ այլ պատմություն (շնորհակալություն Apple-ին): Ես պլանավորում եմ ցույց տալ լուծումներ և ամփոփումներ, որոնք վերաբերում են IOS-ին, հաջորդ բաժիններում։
Ավտոմատացման ենթակառուցվածքների արժեքը
Ավտոմատացման ենթակառուցվածքի տեսանկյունից տեղայն նշարձումը որևէ արժեք չունի։ Դուք պարզապես օժանդակային եք տեսնում, որ թեստները գործում են տեղային համակարգում տեղային բրաուզերներում և սիմուլյատորներում։ Բայց այնուամենայնիվ, սա անհրաժեշտ մեկնարկային կետ է:
Տարածքի ներկա պայմանների նկարագրությունը
Ուսումնասիրելու հղումներ
Նման գործիքներ
- ոչ մի ծրագրավորման լեզու, որը ձեզ հաճելի է, կապված Selenium/Appium թեստերով;
- ոչ մի թեստ;
- ոչ մի թեստ-քցիչ։
2. Վարկածների կառավարման համակարգեր (Git)
Տեխնոլոգիայի համառոտ նկարագրություն
Բոլորին հայտնի է, որ վարկային վերահսկման համակարգը համարվում է շատ կարևոր բաղադրիչ ինչպես թիմային, այնպես էլ անհատական ծրագրավորման գործընթացում: Այդ մասին տարբեր աղբյուրների հիման վրա կարելի է վստահորեն ասել, որ Git-ը ամենատարածված ներկայացումն է: Վարկային վերահսկման համակարգը տալիս է բազմաթիվ առավելություններ, ինչպիսիք են կոդի փոխանակումը, տարբեր տարբերակների պահպանումը, նախորդ ճյուղեր վերականգնելու հնարավորությունը, նախագծային պատմության մոնիթորինգը, բեքափները: Մենք չի քննարկելու յուրաքանչյուր կետ մանրամասն, քանի որ վստահ եմ, որ դուք լավ տիրապետում եք և օգտագործում եք այս ամենը ձեր առօրյա աշխատանքում: Բայց եթե հանկարծ դա ձեր համար դեռևս չի պարզ է, խորհուրդ եմ տալիս暂停ել այս հոդվածի ընթերցումը և հնարավորինս արագ լրացնել այս բացը:
Ավտոմատացման ենթակառուցվածքների արժեքը
Այս պահին կարող եք հարցնել. « pourquoi nous raconte-t-il sur Git? Tout le monde sait cela et utilise pour le développement de code ainsi que pour le code de test automatique». Vous avez tout à fait raison, mais dans cet article, nous parlons d'infrastructure et cette section sert de préambule à la section 7 : « infrastructure en tant que code (IaC) ». Pour nous, cela signifie que toute l'infrastructure, y compris celle de test, est décrite sous forme de code, ce qui signifie que nous pouvons également appliquer des systèmes de versionnage et obtenir des avantages similaires pour le développement de code et l'automatisation.
Nous examinerons l'IaC plus en détail à l'étape 7, mais même maintenant, vous pouvez commencer à utiliser Git localement en créant un dépôt local. L'image générale sera élargie lorsque nous ajouterons un dépôt distant à l'infrastructure.
Տարածքի ներկա պայմանների նկարագրությունը
Ուսումնասիրելու հղումներ
Նման գործիքներ
3. Կոնտեյներизация (Docker)
Տեխնոլոգիայի համառոտ նկարագրություն
Կոնտեյներիզացիայի խաղի կանոնները փոխելու ցուցադրման համար, եկեք գնանք մի քանի տասնամյակ առաջ: Այն ժամանակ մարդիկ ձեռք էին բերում և օգտագործում էին սերվերային մեքենաներ aplicativos գործարկելու համար: Բայց մեծ մասամբ անհրաժեշտ ռեսուրսները, որոնց անհրաժեշտ էր գործարկելու համար, չեն եղել նախօրոք հայտնի: Դրա արդյունքում ընկերությունները գումար էին ծախսում թանկ, խոշոր սերվերներ ձեռք բերելու վրա, բայց այդ հնարավորություններից մի մասը լիովին օգտագործված չէր:
Էվոլյուցիայի հաջորդ փուլը վիրտուալ մեքենաներն էին (VM), որոնք լուծեցին չօգտագործվող ռեսուրսների համար գումար ծախսելու խնդիրը: Այս տեխնոլոգիան թույլ տվեց գործարկել ծրագրեր միմյանցից անկախ մեկ սերվերում, ուսուցանելով լրիվ մեկուսացված տարածք: Բայց, ցավոք, ցանկացած տեխնոլոգիա ունի իր թերությունները: VM-ների գործարկումը պահանջում է ամբողջական օպերացիոն համակարգ, որը սպառում է CPU, RAM, պահեստավորում, և կախված նույնիսկ OS-ից, հաշվի առնել լիցենզիոն ծախսերը. այս գործոնները ազդում են բեռնման արագության և բարդացնում տեղափոխելիությունը:
Եվ ահա մենք հասել ենք կոնտեյնեգրման դաշտին: Ապա այս տեխնոլոգիան մեկ անգամ ևս լուծեց նախորդ պրոբլեմն, քանի որ կոնտեյներները չեն օգտագործում լիարժեք օպերացիոն համակարգ, ինչը թույլ է տալիս ազատել մեծ քանակությամբ ռեսուրսներ և տրամադրել արագ և ճկուն լուծում շարժունակության համար:
Իհարկե, կոնտեյնեգրման տեխնոլոգիան ոչ թե նոր զարգացում է, և առաջին անգամ ներկայացվել է 70-ականների վերջին: Այդ ժամանակներում տրվել են բազմաթիվ հետազոտություններ, աշխատանքներ և փորձեր: Սակայն հենց Docker-ն է հարմարեցրել այս տեխնոլոգիան և դարձրել այն հասանելի հանրության համար: Մեր ժամանակներում, երբ խոսում ենք կոնտեյներների մասին, մեծամասամբ խոսում ենք Docker-ի մասին: Երբ խոսում ենք Docker կոնտեյներների մասին, ենթադրում ենք Linux կոնտեյներներ: Մենք կարող ենք օգտագործել Windows և macOS համակարգեր կոնտեյներներ սկսելու համար, սակայն կարևոր է հասկանալ, որ այդ դեպքում առաջանում է լրացուցիչ շերտ: Օրինակ, Docker-ը Mac-ում աննկատորեն սկսեցնում է կոնտեյներները թեթև Linux VM-ի ներսում: Մենք դեռ կվերադառնանք այս թեմային, երբ քննարկենք Android էմուլյատորների աշխատանքի փոխարեն կոնտեյներների ներսում, քանի որ այստեղ լուրջ մի нюանս կա, որը մանրամասն քննարկման կարիք ունի:
Ավտոմատացման ենթակառուցվածքների արժեքը
Մենք պարզեցինք, որ կոնտեյնեգրում և Docker-ը շատ օգտակար են: Եկեք այդ հարցը դիտարկենք ավտոմատացման համատեքստում, որովհետև յուրաքանչյուր գործիքն կամ տեխնոլոգիան պետք է լուծի որևէ խնդիր: Ցանկանանք պարզել ավտոմատացված թեստավորման ակնառու խնդիրները UI թեստերի համատեքստում:
- Շատ կախվածությունների առկայություն Selenium-ի և հատկապես Appium-ի इंस्टալման ժամանակ;
- Բռաուզերների, սիմուլատորների և վարորդների տարբերակների միջև համատեղելիության խնդիրներ;
- Բռաուզերների/սիմուլատորների համար առանձնացված տարածության բացակայություն, ինչը կարևոր է զուգահեռ գործունեության համար;
- Դժվար է կառավարել և աջակցել, եթե պետք է միաժամանակ աշխատեցնել 10, 50, 100 կամ նույնիսկ 1000 բրաուզեր:
Այնուամենայնիվ, քանի որ Selenium ամենաերբևէ հանրահայտ ավտոմատացման գործիքն է, իսկ Docker-ն ամենաերբևէ հանրահայտ կոնտեյնեգրման գործիքն է, ապա ոչ ոք պետք է զարմանա, որ որ alguien փորձել է դրանք միացնել` ստանալով հզոր գործիք վերոնշյալ խնդիրները լուծելու համար: Դիտարկենք այդպիսի լուծումներն ավելի մանրամասն:
Selenium grid in docker
Այս գործիքը最受欢迎的 Selenium 工具ն է，允许多个浏览器运行多个机器上，并从中央节点进行管理。启用时必须注册至少两个部分：Hub 和 Node(s)。Hub 是一个中央节点，它接收来自测试的所有请求，并将它们分配到相应的 Nodes。对于每个 Node，我们可以设置特定的配置，例如指定所需的浏览器及其版本。然而，我们仍然需要自行处理浏览器兼容的驱动程序并将其安装到所需的 Nodes 上。因此，除非我们必须处理无法在 Linux OS 上安装的浏览器，否则 Selenium grid 并不以纯粹的形式使用。在所有其他情况下，使用 Docker 图像来运行 Selenium grid Hub 和 Nodes 是一个更加灵活和正确的解决方案。这种方法极大地简化了节点管理，因为我们可以选择已经安装了兼容版本的浏览器和驱动程序的所需图像。
尽管对其稳定性，尤其是在同时启动大量 Nodes 时的负面反馈，Selenium grid 仍然是并行启动 Selenium 测试的最受欢迎的工具。值得注意的是，开源社区不断推出该工具的各种改进和修改，以解决各种瓶颈问题。
Selenoid for Web
这个工具是 Selenium 世界的一个突破，因为它开箱即用，使许多自动化工程师的生活变得更加简单。首先，这不是 Selenium grid 的另一个修改版。相反，开发人员使用 Golang 创建了一个全新的 Selenium Hub 版本，加上轻量级的 Docker 镜像，为各个浏览器的发展提供了动力。此外，在 Selenium Grid 的情况下，我们必须提前定义所有所需的浏览器及其版本，这在仅与某一浏览器合作时并不是问题。但是当涉及到多个受支持的浏览器时，Selenoid 是首选解决方案，得益于“按需浏览器”的功能。我们需要做的就是提前下载所需的浏览器图像，并更新与 Selenoid 交互的配置文件。当 Selenoid 收到来自测试的请求时，它会自动启动所需浏览器的容器。测试完成后，Selenoid 会停止容器，从而释放资源以供后续请求使用。这种方法完全消除了我们经常在 Selenium grid 中遇到的“节点降级”问题。
Բայց, ցավոք, Selenoid-ը դեռևսSilver Bullet չէ։ Մենք ստացանք 'բրաուզեր պահանջի' ֆունկցիա, բայց 'ռեսուրսների պահանջի' ֆունկցիան դեռևս հասանելի չէ։ Selenoid օգտագործելու համար մենք պետք է այն տեղադրենք ֆիզիկական մետաղի կամ VM վրա, ինչը նշանակում է, որ մենք պետք է նախապես իմանանք, թե քանի ռեսուրս է անհրաժեշտ հատկացնել։ Իմ կարծիքով, դա խնդիր չէ փոքր նախագծերի համար, որոնք запускают 10, 20 կամ նույնիսկ 30 բրաուզերներ զուգահեռ։ Սակայն ինչպե՞ս անել, եթե մեզ հարկավոր են 100, 500, 1000 և ավելի։ Դա իմաստ չունի աջակցել և վճարել այդքան ռեսուրսների համար մշտապես։ Այս հոդվածի 5-րդ և 6-րդ բաժիններում մենք կքննարկենք լուծումներ, որոնք թույլ են տալիս մասշտաբվել, այդպիսով զգալիորեն նվազեցնելով公司的 ծախսերը։
Selenoid for Android
Web ավտոմատացմանTools-ի հաջողությունից հետո մարդիկ ցանկանում էին ստանալ նման բան Android-ի համար։ Եվ սա տեղի ունեցավ՝ Selenoid-ը թողարկվեց Android-ի աջակցությամբ։ Բարձր մակարդակի օգտվողի տեսանկյունից աշխատանքի սկզբունքը նման է web-ավտոմատացմանը։ Միակ տարբերությունը այն է, որ Selenoid-ը запускает контейներ Android эмуляторов։ Իմ կարծիքով, սա ներկայիս պահին ամենաուժեղ անվճար գործիքն է Android թեստերը զուգահեռ գործարկելուն։
Ես շատ չեմ ուզում խոսել այս գործիքի բացասական կողմերի մասին, քանի որ այն իսկապես շատ եմ սիրում։ Բայց արդյոք այստեղ նույն խնդիրներն են, որոնք վերաբերում են web-ավտոմատացման մասշտաբմանը։ Ավելին, անհրաժեշտ է խոսել մեկ այլ սահմանափակման մասին, որը կարող է անակնկալ լինել, եթե մենք այս գործիքը սահմանում ենք առաջին անգամ։ Android-ի պատկերները գործարկելու համար մեզ անհրաժեշտ է ֆիզիկական մեքենա կամ VM, որը ունի nested virtualisation — աջակցում։ Օգտագործելով պրակտիկ ուղեցույցը, ես ցույց եմ տալիս, թե ինչպես ակտիվացնել դա Linux VM-ում։ Բայց եթե դուք macOS օգտագործող եք և ցանկանում եք տեղադրել Selenoid-ը տեղականորեն, ապա Android թեստերը գործարկելն հնարավոր չի լինելու։ Բայց դուք միշտ կարող եք տեղականորեն գործարկել Linux VM, որտեղ տեղակայված է 'nested virtualisation' և տեղադրել Selenoid-ը ներսում։
Տարածքի ներկա պայմանների նկարագրությունը
Այս հոդվածի համատեքստում մենք կավելացնենք 2 գործիքներ, որպեսզի ներկայացնենք ենթակառուցվածքը։ Սա Selenium grid-ն է web թեստերի համար և Selenoid-ը Android թեստերի համար։ GitHub-ում ուղեցույցում ես նաև կցուցադրեմ, թե ինչպես օգտագործել Selenoid-ը web թեստերի գործարկման համար։
Ուսումնասիրելու հղումներ
Նման գործիքներ
- Հ exista այլ контейներավորման գործիքներ, բայց Docker-ը հանդիսանում է ամենատարածվածը։ Եթե ցանկանում եք փորձել ինչ-որ բան այլ, ապա հաշվի առեք, որ այն գործիքները, որոնք մենք դիտարկել ենք բաշխված Selenium թեստերի գործարկման համար, չեն աշխատի անմիջապես։
- Որպեսզի արդեն ասվեց, կա շատ տարբերակներ Selenium grid-ի, օրինակ՝.
4. CI / CD
Տեխնոլոգիայի համառոտ նկարագրություն
Անընդհատ ինտեգրման պրակտիկան դրսևորվում է մշակման մեջ և համեմատության մեջ է տարբերակի վերահսկման համակարգերի հետ: Այնուամենայնիվ, ես զգում եմ, որ այդ տերմինաբանության մեջ խնդիրներ կան: Այս պարբերությունում ես ցանկանում եմ նկարագրել այս տեխնոլոգիայի 3 փոփոխություն իմ իմանց համար: Արտահայտություններ և տարբերակներ կան, որոնք դուք կարող եք գտնել ինտերնետում, և դա լիովին նորմալ է, եթե ձեր կարծիքը տարբերվում է: Ամենակարևորը, որ դուք ձեր գործընկերների հետ նույն ալիքում լինել պետք է:
Ուրեմն, կան 3 տերմին՝ CI — Continuous Integration (անընդհատ ինտեգրում), CD — Continuous Delivery (անընդհատ մատակարարում) և կրկին CD — Continuous Deployment (անընդհատ մշակման): (Եղեք շատ ուշադրություն այս տերմինների ըմբռնելիս, քանի որ դրանք օգտագործելիս ես անգլյերեն լավագույն ձևն եմ օգտագործելու:). Յուրաքանչյուր փոփոխություն ավելացնում է մի քանի լրացուցիչ քայլեր ձեր զարգացման խողովակին: Սակայն բառը continuous (անընդհատ) ամենակարևորն է: Այս համատեքստում մենք ենթադրում ենք այն, ինչը տեղի է ունենում սկզբից մինչև վերջ, առանց դադարների կամ ձեռքի միջամտության: Եկեք դիտարկենք CI & CD և CD այս համատեքստում:
- Continuous Integration - это начальный шаг эволюции. После отправки нового кода на сервер, мы ожидаем получить быструю обратную связь, что с нашими изменениями все в порядке. Обычно CI включает запуск инструментов статического анализа кода и модульные/внутренние API тесты Это позволяет получать информацию о нашем коде уже несколько секунд/минут спустя.
- Հայտերի շարունակական մատակարարում является более продвинутым шагом, на котором мы запускаем интеграционные/UI-тесты. Однако на данном этапе мы не получаем результаты так же быстро, как в случае с CI. Во-первых, эти типы тестов требует больше времени для прохождения. Во-вторых, перед запуском мы должны развернуть наши изменения на test/staging — среде. Более того, если мы говорим о мобильной разработке, то появляется дополнительный этап для создания сборки нашего приложения.
- Continuous Deployment предполагает, что мы автоматически выпускаем (release) наши изменения на production, если все приемочные тесты были пройдены на предыдущих этапах. В дополнение к этому после этапа release можно настроить различные этапы, такие как запуск smoke — тестов на production и сбор интересующих метрик. Continuous Deployment возможно только при хорошем покрытии автоматизированными тестами. Если требуются какие-то ручные вмешательства, в том числе и тестирование, то это больше не Continuous (անընդհատ). Այդ դեպքում, մենք կարող ենք ասել, որ մեր խողովակը համապատասխանում է միայն Continuous Delivery պրակտիկային:
Ավտոմատացման ենթակառուցվածքների արժեքը
Այս բաժնում ես պետք է հստակեցնեմ, որ երբ մենք խոսում ենք եզրից եզր UI-թեստերի մասին, դա ենթադրում է, որ մենք պետք է տեղադենք մեր փոփոխությունները եւ առնչվող ծառայությունները թեստավորման միջավայրերում։ Հաճախակի միացման գործընթացը չի կիրառվում այս խնդրի համար, եւ մենք պետք է հոգանք շարունակական առաքման (Continuous Delivery) պակառույցների ներդրման մասին։ Շարունակական տեղադրման (Continuous Deployment) գործընթացը նույնպես իմաստ ունի UI-թեստերի համատեքստում, եթե մենք նախատեսում ենք դրանք գործարկել արտադրությունում։
Եվ առաջ, քան մենք նայենք ճարտարապետության փոփոխությունների պատկերին, ես ուզում եմ ասել մի քանի խոսք GitLab CI-ի մասին։ Մյուս CI/CD գործիքներից տարբեր, GitLab-ը տրամադրում է հեռավոր ռեպոզիտար ու շատ այլ լրացուցիչ ֆունկցիաներ։ Այսպիսով, GitLab-ը՝ դա CI-ից ավելի շատ բան է։ Այն ներառում է կոդի կառավարման, Agile կառավարում, CI/CD pipelines, լոգավորման գործիքներ եւ մետրիկաների հավաքում։ GitLab-ի ճարտարապետությունը բաղկացած է Gitlab CI/CD եւ GitLab Runner-ից։ Ներկայացնում եմ փափուկ նկարագրություն պաշտոնական կայքից：
Gitlab CI/CD-ը վեբ հավելված է API-ով, որը պահպանում է իր վիճակը տվյալների բազայում, կառավարում նախագծերը/կառուցումները եւ տրամադրում է օգտագործողի ինտերֆեյս։ GitLab Runner-ը ծրագիր է, որն մշակել նախագծերը։ Այն կարելի է տեղադրել առանձին եւ աշխատում է GitLab CI/CD-ի հետ API-ով։ Թեստեր վարելու համար ձեզ անհրաժեշտ են ինչպես GitLab instance-ը, այնպես էլ Runner-ը։
Տարածքի ներկա պայմանների նկարագրությունը
Ուսումնասիրելու հղումներ
Նման գործիքներ
- Եվ շատ այլ
5. Բարձրորակ cloud հարթակներ
Տեխնոլոգիայի համառոտ նկարագրություն
Այս բաժնում մենք խոսելու ենք հանրաճանաչ մի միտման մասին, որը կոչվում է 'հանրային ամպեր'։ Չնայած վերոնշյալ վիրտուալացման եւ կերակրման տեխնոլոգիաներից ստացվող մեծ օգուտներին, մեզ դեռ անհրաժեշտ են հաշվարկային ռեսուրսներ։ Ընկերություններն ձեռք են բերում թանկ սերվերներ կամ վարձում տվյալների կենտրոններ, սակայն այս դեպքում անհրաժեշտ է կատարել հաշվարկներ (บาง դեպքերում անհնարին), թե որքան ռեսուրսներ ենք անհրաժեշտ, թե արդյոք դրանք կօգտագործենք 24/7 և ինչ նպատակներով։ Օրինակ, արտադրության համար պահանջվում են 24/7 աշխատող սերվեր, բայց արդյոք նմանատիպ ռեսուրսներ անհրաժեշտ են թեստավորման համար աշխատանքային ժամերի ընթացքում։ Դա նույնպես կախված է կատարվող թեստավորման տեսակից։ Օրինակ կարելի է անվանել ծանրաբեռնման/սթրեսային թեստեր, որոնք մենք նախատեսում ենք անցկացնել աշխատանքի ավարտին՝ հաջորդ օրը արդյունքներ ստանալու համար։ Բայց, գոնե 24/7 հասանելիությունը սերվերների համար չի պահանջվում end-to-end ավտոթեստերի համար, եւ հատկապես ձեռնարկային թեստավորման միջավայրերի համար։ Այսպիսի իրավիճակներում լավ կլիներ ունենալ այնքան ռեսուրսներ, որքան անհրաժեշտ է ըստ պահանջի, օգտագործել դրանք եւ դադարեցնել վճարումն, երբ դրանք այլևս պետք չեն։ Բացի այդ, հրաշալի կլիներ ստանալ դրանք անմիջապես, միայն մի քանի կլիկով կամ մի քանի սկրիպտներ գործարկելով։ Դրա համար էլ օգտագործվում են հանրային ամպեր։ Այդպիսով, եկեք նայենք որոշման թարգմանությանը：
«Հանրային ամպը սահմանվում է որպես հաշվարկային ծառայություններ, որոնք մատուցվում են երրորդ կողմերի կողմից հանրային ինտերնետի միջոցով, դրանք հասանելի դարձնելով բոլոր նրանց համար, ովքեր ցանկանում են օգտագործել կամ գնել դրանք։ Նրանք կարող են լինել անվճար կամ վաճառվել պահանջով՝ թույլ տալով հաճախորդներին վճարել միայն օգտագործման համար CPU շրջանառություն, պահեստավորում կամ լայնաձիգություն, որը նրանք օգտագործում են»։
Այսօր հանրային CLOUD-ների մասին կարծիք կա, որ դրանք թանկ են: Սակայն դրանց գլխավոր գաղափարը՝ ընկերությունների ծախսերն իջեցննելն է: Ինչպես նշվել է ավելի վաղ, հանրային CLOUD-ները թույլ են տալիս ստանալ ռեսուրսներ պահանջով և վճարել միայն սպառման ժամանակահատվածի համար: Երբեմն մենք մոռանում ենք, որ աշխատակիցները ստանում են աշխատավարձ, և մասնագետները նույնպես թանկ ռեսուրս են: Պետք է հաշվի առնել, որ հանրային CLOUD-ները զգալիորեն հեշտացնում են ինֆրաստրուկտուրայի սպասարկումը, ինչը թույլ է տալիս ինժեներներին կենտրոնանալ ավելի կարևոր խնդիրների վրա.
Ավտոմատացման ենթակառուցվածքների արժեքը
Որոնք են կոնկրետ ռեսուրսները, որոնք անհրաժեշտ են end-to-end UI թեստերի համար? Հիմնականում դրանք վիրտուալ մեքենաներ կամ կլաստերներ են (հաջորդ հատվածում կխոսենք Kubernetes-ի մասին) բրաուզերների և էմուլատորների գործարկման համար: Ո kolքան ծավալել բրաուզերներ և էմուլատորներ միասին, այնքան ավելի շատ CPU և հիշողություն է անհրաժեշտ, և այդքան ավելի շատ գումար ենք վատնելու: Այսպիսով, հանրային CLOUD-ները հասկանում են, որ թեստավորման ավտոմատացման տեսանկյունից մեզ թույլ են տալիս պահանջով մեծ թվով (100, 200, 1000 ...) բրաուզերներ/էմուլատորներ գործարկել, ստանալ արագ թեստավորման բոլոր արդյունքները և դադարել վճարել այնպիսի չափազանց ռեսուրսատար կարողությունների համար.
Առավել հայտնի CLOUD մատակարարները են Amazon Web Services (AWS), Microsoft Azure, Google Cloud Platform (GCP): Ուժեղ ձեռնարկումներում ներկայացված են GCP օգտակարության օրինակները, սակայն ընդհանուր առմամբ կարևոր չէ, թե ինչ եք օգտագործելու ավտոմատացման խնդիրների համար: Դրանք բոլորը տրամադրում են մոտավորապես նույն գործառույթները: Մատակարար ընտրելու համար ուղեցույցը սովորաբար կենտրոնանում է ընկերության ամբողջ ինֆրաստրուկտուրայի և բիզնես պահանջների վրա, ինչը դուրս է այս հոդվածի շրջանակներից: Ավտոմատացված ինժեներների համար ավելի հետաքրքիր կլինի համեմատել CLOUD մատակարարների օգտագործումը կոնկրետ թեստավորման նպատակների CLOUD հարթակների օգտագործման հետ, ինչպիսիք են Sauce Labs, BrowserStack, BitBar և այլն: Այժմ դա անենք! Իմ կարծիքով, Sauce Labs-ն ամենահայտնի CLOUD թեստավորման ֆերման է, այդ պատճառով ես ընտրեցի այն համեմատության համար.
GCP Sauce Labs-ի դեմ ավտոմատացման նպատակներով:
Ներկայացնենք, որ մեզ անհրաժեշտ է միաժամանակ 8 web թեստ և 8 Android թեստ անցկացնել: Այս նպատակով մենք օգտագործելու ենք GCP և գործարկելու ենք 2 վիրտուալ մեքենա Selenoid-ի հետ: Առաջինում մենք կբարձրացնենք 8 կոնտեյներ բրաուզերներով: Երկրորդում՝ 8 կոնտեյներ էմուլատորներով: Եկեք նայենք գներին:
Յուրաքանչյուր Chrome կոնտեյների գործարկման համար մենք կպահանջենք n1-standard-1 մեքենա: Android-ի դեպքում դա կլինի n1-standard-4 մեկ էմուլատորի համար: Իրականում ավելի ճկուն և էժան տարբերակը՝ CPU/Memory-ի համար կոնկրետ օգտակար արժեքներ սահմանելն է, սակայն այս պահին Sauce Labs-ի համեմատության համար դա սկզբունքային չէ.
Sauce Labs-ի օգտագործման արժեքները.
Ես համոզված եմ, որ դուք արդեն նկատել եք տարբերությունը, բայց այնուամենայնիվ ներկայացնեմ մեր խնդրի հաշվարկների աղյուսակը:
Պահանջվող ռեսուրսներ
Ամսական
Աշխատակազմի ժամեր(08:00 – 20:00)
Աշխատակազմի ժամեր+ Նախորդական
GCP Համացանցի համար
n1-standard-1 x 8 = n1-standard-8
$194.18
23 օր * 12ժ * 0.38 = 104.88$
23 օր * 12ժ * 0.08 = 22.08$
Sauce Labs Համացանցի համար
Virtual Cloud 8 զուգահեռ թեստեր
$1.559
—
—
GCP Android-ի համար
n1-standard-4 x 8: n1-standard-16
$776.72
23 օր * 12ժ * 1.52 = 419.52$
23 օր * 12ժ * 0.32 = 88.32$
Sauce Labs Android-ի համար
Իրական սարքերի կես 8 զուգահեռ թեստեր
$1.999
—
—
Ինչպես տեսնում եք, արժեքի տարբերությունը մեծ է, հատկապես երբ թեստերը են կատարվում միայն աշխատանքային 12-ժամյա ընթացքում: Բայց կարելի է ևս ավելի շատ կրճատել ծախսերը, եթե օգտագործեք նախորդական մեքենաներ։ Ի՞նչ է դա։
Նախորդական VM-ն այն ինստանցիան է, որը կարող եք ստեղծել և գործարկել շատ ավելի ցածր գնով, քան սովորական ինստանցիաները: Սակայն, Compute Engine-ն կարող է վերացնել (նախորդել) այդ ինստանցիաները, եթե անհրաժեշտություն ունենա այդ աղբյուրներին այլ գործառույթների համար: Նախորդական ինստանցիաները Compute Engine-ի ավելցուկային պաշար են, ուստի դրանց հասանելիությունը տարբերվում է օգտագործման ընթացքում:
Եթե ձեր ծրագրերը սխալառաժանր են և կարող են դիմադրել հնարավոր նախորդական ինստանցիաների վերացմանը, ապա նախորդական ինսկանցիաները կարող են էապես կրճատել ձեր Compute Engine-ի ծախսերը: Օրինակ, խմբային պրոցեսավորման աշխատանքները կարող են կատարվել նախորդական ինստանցիաներով: Եթե այդ ինստանցիաներից ոմանք դադարեցվեն պրոցեսավորման ընթացքում, աշխատանքը դանդաղում է, բայց չի երբեմնի կանգնում: Նախորդական ինստանցիաները լրացնում են ձեր խմբային պրոցեսավորման առաջադրանքները առանց լրացուցիչ բեռի ավելացնելու ձեր գոյություն ունեցող ինստանցիաների վրա և առանց ձեզ լրացուցիչ սովորական ինստանցիաների համար ամբողջ գին վճարելու:
Եվ դեռ սա չի ավարտվում! Իրականում ես վստահ եմ, որ ոչ ոք չի աշխատացնում թեստերը 12 ժամ շարունակաբար: Եվ եթե այդպես է, ապա դուք կարող եք ավտոմատ կերպով շահարկել և կանգնեցնել վիրտուալ մեքենաները, երբ դրանք անհրաժեշտ չեն: Իրական օգտագործման ժամանակը կարող է կրճատվել 6 ժամվա: Այդ դեպքում վճարը մեր խնդրի համատեքստում կնվազի аж до 11$ ամսական 8 բրաուզերների համար: Չէ որ դա հրաշալի չէ? Բայց նախորդական մեքենաներով պետք է զգույշ լինել և պատրաստ լինել ընդհատումներին և ոչ կայուն աշխատանքին, թեև այս իրավիճակները կարող են կանխատեսվել և մշակվել ծրագրային կերպով: Դա արժանի է:
Բայց ոչ մի դեպքում ես չեմ ասում ‘ք jamás օգտագործեք ամպային թեստային ֆերմաներ’: Դրանք ունեն մի շարք առավելություններ: Նախ ամենքից դա ոչ միայն վիրտուալ մեքենա է, այլ նաև ամբողջական լուծում ավտոմատացվող թեստավորմանը, որը ունի ֆունկցիոնալություն տուփից:.remote access, logs, screenshots, video recording, տարբեր բրաուզերներ և ֆիզիկական շարժական սարքեր: Շատ իրավիճակներում դա կարող է լինել անփոխարինելի շքեղ այլընտրանք: Բավականին օգտակար են IOS-ավտոմատացման համար, երբ հանրային ամպերը կարող են առաջարկել միայն Linux/Windows համակարգեր: Սակայն IOS-ի մասին խոսքը կստանա հաջորդ հոդվածներում: Ես խորհուրդ եմ տալիս միշտ դիտել իրավիճակի ըստ, ու հիմնվել խնդիրներից. որևէ մի իրավիճակում ավելի մատչելի ու արդյունավետ է օգտագործել հանրային ամպեր, իսկ ուրիշներում թեստային պլատֆորմները հաստատ արժեն իրենց ծախսի:
Տարածքի ներկա պայմանների նկարագրությունը
Ուսումնասիրելու հղումներ
Անալոգիաները
6. Օրկեստրացիա
Տեխնոլոգիայի համառոտ նկարագրություն
Ամենայն լավ nieuws – մենք գրեթե ավարտել ենք հոդվածի վերջը: Այս պահին մեր ավտոմատացման ենթակառուցվածքը բաղկացած է web և Android թեստերից, որոնք մենք запускаем через GitLab CI параллельно, используя инструменты с поддержкой Docker: Selenium grid и Selenoid. Более того, мы используем созданные через GCP виртуальные машины для поднятия в них контейнеров с браузерами и эмуляторами. Для уменьшения расходов мы запускаем этим виртуальные машины только по требованию и останавливаем, когда тестирование не проводится. Существует ли что-то еще, что может улучшить нашу инфраструктуру? Ответ – да! Встречаем Kubernetes (K8s)!
Արդեն սկսենք рассмотреть, как слова оркестрация, кластер и Kubernetes связаны между собой. На высоком уровне оркестрация – это система, которая разворачивает и управляет приложениями. Для автоматизации тестирования такими контейнеризируемыми (containerised) приложениями являются Selenium grid и Selenoid. Docker и K8s дополняют друг друга. Первый используется для развертывания приложений, второй – для оркестрации. В свою очередь K8s является кластером. Задача кластера использовать VMs в качестве Nodes, что позволяет устанавливать различный функционал, программы и сервисы в рамках одного сервера (кластера). Если какой либо из Node упадет, то подхватятся другие Nodes, что обеспечивает нашему приложению бесперебойную работу. В дополнение к этому K8s имеет важную функциональность, связанную с масштабированием (scaling), благодаря чему мы автоматически получаем оптимальное количество ресурсов, основываясь на нагрузке и установленных ограничениях.
Սա ոչ այլ ինչ է, քան ручное разворачивание Kubernetes с нуля является совсем нетривиальной задачей. Я оставлю ссылку на известное практическое руководство «Kubernetes The Hard Way», и, если вам интересно, вы можете попрактиковаться. Но, к счастью, существуют альтернативные способы и инструменты. Самым легкий из них – использовать Google Kubernetes Engine (GKE) в GCP, что позволит получить готовый кластер после нескольких кликов. Для начала изучения я рекомендую использовать именно этот подход, так как он позволит вам сфокусироваться на изучении того, как использовать K8s для своих задач вместо исследования того, как внутренние компоненты должны быть между собой интегрированы.
Ավտոմատացման ենթակառուցվածքների արժեքը
Рассмотрим несколько значимых функций, которые предоставляет K8s:
- развертывании приложения: использование multi-nodes кластера, вместо VMs;
- динамическое масштабирование: уменьшает расходы на ресурсы, которые используются только по требованию;
- самовосстановление (Self-healing): автоматическое восстановление pods (в результате чего восстанавливаются и контейнеры);
- թարմացումների և վերադարձերի կատարման առանց դադարների. Նյութատեքստային գործիքների, զննարկիչների և էմուլյատորների թարմացումները չեն խափանում ընթացիկ օգտվողների աշխատանքը
Սակայն K8s – դեռևս չի հանդիսանում կախարդական դաշտի լուծում: Կարստոնք բոլոր առավելությունների և սահմանափակումների համար, որոնք մենք քննարկում ենք (Selenium grid, Selenoid), կարճ կխոսենք K8s կառուցվածքի մասին: Clusters-ն ունի երկու տեսակի Nodes: Master Nodes և Workers Nodes: Master Nodes-ը պատասխանատու են կառավարելու, տեղակայելու և պլանավորման որոշումների համար: Workers Nodes-ը տեղադրում է ծրագրերը: Nodes-ը նաև պարունակում է կոնտեյների գործառնական միջավայր: Մեր դեպքում սա Docker-ն է, որը պատասխանատու է կոնտեյների հետ կապված գործողությունների համար: Սակայն կան նաև այլ լուծումներ, օրինակ. Կարևոր է հասկանալ, որ սանդղակի կամ ինքնակատարման գործընթացները չեն վերաբերում կոնտեյներներին անուղղակիորեն: Սա իրականացվում է pods-ի թվի ավելացմամբ / նվազեցմամբ, որոնք գրվում են, եւ որոնք, իրենց հերթին, պարունակում են կոնտեյներներ ( սովորաբար մեկ կոնտեյներ յուրաքանչյուր pod-ում, սակայն կախված խնդրից կարող է լինել նաև ավելի): Շուկայական մակարդակը ներկայացնում է աշխատող nodes-ը, որի ներսում կան pods, որոնց ներսում տեղադրված են կոնտեյներներ:
Սանդղակի ֆունկցիան հիմնականն է և կարող է դառնալ ինչպես nodes-ի, այնպես էլ pods-ի նկատմամբ: Սуществують 2 տեսակ սандղակում, որ վերաբերվում են ինչպես nodes-ին, այնպես էլ pods-ին: Առաջին տեսակը – հորիզոնական – սանդղակում է տեղի ունենում nodes/pods-ի թվի ավելացման արդյունքում: Այս տեսակը հանդիսանում է ավելի նախընտրելի: Երկրորդ տեսակ, համապատասխանաբար, ուղղահայաց: Մասշտաբը իրականացվում է nodes/pods-ի չափերի մեծացման հաշվին, և ոչ թե նրանց քանակի:
Հիմա դիտենք մեր գործիքները վերոհիշյալ պայմանների համատեքստում:
Selenium grid
Ինչպես արդեն նշվեց, Selenium grid-ը շատ հայտնի инструмент է, և ոչ մի անակնկալ չէ, որ այն կոնտեյներացված է: Հետևաբար, զարմանալի չէ, որ Selenium grid-ը կարելի է կիրառել K8s-ում: Ինչպես դա անել՝ տեսեք պաշտոնական K8s-ռեպոզիտորում: Ինչպես միշտ, վերջում կցուցադրվեն հղումներ: Բացի դրանից, պրակտիկական ուղեցույցում ասվում է, թե ինչպես դա անել Terraform-ի միջոցով: Նույնպես կա հրահանգ, թե ինչպես լայնացնել կոնտեյներներ պարունակող pods-ի թիվը: Բայց K8s-ի համապատասխանությամբ ավտոմատ ընդլայնման գործառույթը դեռևս լիովին պարզ չէ: Երբ ես սկսեցի ուսումնասիրություն կատարել, ես որևէ պրակտիկ ուղեցույց կամ խորհուրդ չգտա: Որոշ հետազոտությունների և փորձարկումների արդյունքում, որոնք աջակցում էին DevOps թիմը, մենք ընտրեցինք մոտեցումը՝ կոնտեյներները բրդել մեկ pod-ում՝ մեկ աշխատանքային հանգույցի ներսում: Այս մեթոդը մեզ հնարավորություն է տալիս կիրառել հորիզոնական ընդլայնման ռազմավարություն հանգույցների թիվն ավելացնելով: Ես հուսով եմ, որ ապագայում իրավիճակը կփոխվի, և մենք ավելի ու ավելի շատ կտեսնենք լավագույն մոտեցումների և պատրաստի լուծումների նկարագրություններ, հատկապես Selenium grid 4-ի թողարկումից հետո՝ փոփոխված ներքին ճարտարապետությամբ:
Selenoid:
Այսօր Selenoid-ի իրականացումը K8s-ում ամենամեծ ձախողումն է: Նրանք անհամատեղելի են: Теоретически мы можем поднять Selenoid-контейнер внутри pod, но когда Selenoid начнет запускать контейнеры с браузерами, они все еще будут находиться внутри этого pod: Это делает масштабирование невозможным и, как результат, работа Selenoid внутри кластера не будет отличаться от работы внутри виртуальной машины. Конец истории.
Moon:
Վիմանալով Selenoid-ի հետ գործողության այս նեղ տեղը, մշակողները թողարկել են ավելի мощный инструмент, который назвали Moon. Этот инструмент был изначально задуман для работы с Kubernetes и, как результат, можно и нужно использовать функцию автомасштабирования: Более того, я бы сказал, что в настоящий момент это միայն инструмент в мире Selenium, который из коробки имеет native K8s cluster-поддержку (уже нет, см. следующий инструмент ). Moon-ի հիմնական առանձնահատկությունը, որը ապահովում է այս աջակցությունը, հետևյալն է:
Completely stateless. Selenoid-ը հիշողության մեջ պահում է ընթացիկ աշխատող վեբ կայքերի միջպատասխանները: Եթե որեւէ պատճառով դրա գործընթացը փրկված է, ապա բոլոր աշխատող միջպատասխանները կկորցվեն: Moon-ը, հակառակը, չունի ներքին վիճակ և կարող է կրկնօրինակվել տվյալների կենտրոններում: Վեբ կայքի միջպատասխանները մնում են գոյություն, նույնիսկ եթե մեկ կամ մի քանի կրկնօրինակ պակասեն:
Այդպես, Moon-ը լավագույն լուծում է, բայց ունի մեկ խնդիր՝ այն անվճար չէ։ Արժեքը կախված է սեսիաների թվից։ 0-4 սեսիաներ գործարկելը անվճար է, բայց դա առանձնապես օգտակար չէ։ Բայց արդեն հինգերորդ սեսիայից սկսած, ստիպված կլինեք վճարել 5$ յուրաքանչյուրի համար։ Տեսակը կարող է տարբերվել ընկերությունից ընկերություն, սակայն մեր դեպքում Moon-ի օգտագործումը իմաստ չունի։ Ինչպես արդեն նշեցի, մենք կարող ենք VMs ներդնել Selenium Grid-ի միջոցով ըստ պահանջի կամ ավելացնել Nodes կլաստերում։ Միանշանակ մեկ pipeline-ի համար մենք գործարկում ենք 500 բրաուզեր և կանգնեցնում բոլոր ռեսուրսները թեստերից հետո։ Եթե մենք օգտագործեինք Moon, ստիպված կլինեինք վճարել հավելյալ 500 x 5 = 2500 $ ամսվա համար և ոչ կարեւոր, թե որքան հաճախ ենք գործարկում թեսթերը։ Եվ կրկին, ես չեմ ասում «չօգտագործեք Moon»։ Ձեր խնդիրների համար դա կարող է անփոխարինելի լուծում լինել, օրինակ, եթե ձեր կազմակերպությունում շատ նախագծեր/թիմեր են և ձեզ անհրաժեշտ է մեծ համատեղ կլաստեր բոլորի համար։ Ինչպես միշտ, վերջում թողնում եմ հոլովակ և խորհուրդ տալիս անել բոլոր անհրաժեշտ հաշվարկները ձեր խնդիրների համատեքստում։
Callisto: (Ուշադրություն! Սա չկա գրված բնօրինակ հոդվածում և առկա է միայն ռուսերեն թարգմանությունում)
Ինչպես արդեն նշեցի, Selenium-ը շատ տարածված գործիք է, իսկ IT ոլորտը արագ զարգանում է։ Քանի դեռ աշխատում էի թարգմանության վրա, ցանցում հայտնվեց նոր խոստումնալից գործիք՝ Callisto (բարև Cypress-ին ու մյուս Selenium-ի սպանողներին): Այն աշխատում է Ծերեքում (K8s) և թույլ է տալիս գործարկել Selenoid կոնտեյներներ pods-ում, տարածված Nodes-երի վրա։ Ամեն բան աշխատում է անմիջապես և նրանով ավտոմատ առաջացնելում է։ Հիանալի է, բայց պետք է փորձարկվի։ Ինձ հաջողվեց տեղադրել այս գործիքը և մի քանի փորձարկումներ կատարել։ Աλλά վաղ է եզրակացություն անել, երկարաժամկետ արդյունքների ստացումից հետո, հնարավոր է, ես կ zrobi այս մասին մոտալուտ հոդվածներում։ Մինչ այդ թողնում եմ միայն հղումներ ինքնուրույն ուսումնասիրությունների համար։
Տարածքի ներկա պայմանների նկարագրությունը
Ուսումնասիրելու հղումներ
Ուսումնասիրելու հղումներ
Նման գործիքներ
7. Ինֆրաստրուկտուրա որպես կոդ (IaC)
Տեխնոլոգիայի համառոտ նկարագրություն
Եվ ահա մենք մոտեցանք վերջին բաժնին։ Օбычно, այս տեխնոլոգիան և հետագա խնդիրները չեն մտնում ավտոմատացման ինժեների պատասխանատվության շրջանակներում։ Իրականում դրա համար կան որոշ պատճառներ։ Նախ, շատ կազմակերպություններում ինֆրաստրուկտուրայի խնդիրները գտնվում են DevOps բաժնի վերահսկողության տակ, և զարգացման թիմերը հատուկ չեն հարևանվում, թե ինչով է աշխատում pipeline-ը և ինչպես պետք է պահպանել դրան առնչվող ամեն բան։ Երկրորդ, անկեղծ լինենք, ասելով, "Ինֆրաստրուկտուրա որպես կոդ (IaC)" պրակտիկան դեռևս շատ ընկերություններում չի կիրառվում։ Սակայն դա անպայման դարձել է հանրահայտ միտումներ և կարևոր է փորձել ներգրավվել նման գործընթացների, մոտեցումների և գործիքների։ Հնարավոր է, թե գոնե լինեք իրադարձությունների մասին տեղեկացված։
Մոտեցման օգտագործման մոտիվացիայից սկսենք: Մենք արդեն քննարկել ենք, որ GitlabCI-ում թեստերի արձակման համար անհրաժեշտ են ամենաքիչը ռեսուրսներ Gitlab Runner-ի գործարկման համար: Իսկ բրաուզերների/ էմուլյատորների հետ կոնտեյներների գործարկման համար մենք պետք է վերապահենք VM կամ կլաստեր: Թեստավորման ռեսուրսներից բացին, մեզ հարկավոր է զգալի թվով հզորություններ նյութական միջավայրերի, staging-ի, production-ի պահպանումն ապահովելու համար, ինչն էլ ներառում է տվյալների բազաներ, ավտոմատ ծրագրագիրներ, ցանցի կոնֆիգուրացիաներ, բեռնաթափման սարքեր, օգտվողների իրավունքներ և այլն: Մարմին: Դիրքավորման հիմնական խնդիրը կապված է այդ ամենի պահպանման պահանջվող ջանքերի հետ: Մենք կարող ենք փոփոխություններ կատարել և թարմացումներ թողարկել մի քանի եղանակներով: Օրինակ, GCP համատեքստում մենք կարող ենք օգտագործել UI-կոնսոլը բրաուզերում և կատարել բոլոր գործողությունները, սեղմելով կոճակներ: Ալտերնատիվ եղանակը կարող է լինել API կանչերի օգտագործումը ամպային օբյեկտների հետ փոխազդելու համար կամ gcloud հրամանային տողի գործիքի կիրառումը անհրաժեշտ գործողություններ կատարելու համար: Իսկ եթե իսկապես տարբեր օբյեկտների և ենթակառուցվածքային տարրերի քանակը շատ մեծ է, ձեռքով ամեն գործողություն կատարել դժվար կամ նույնիսկ անհնար է: Բացի այդ, բոլոր այս ձեռքով կատարած գործողությունները՝ վերահսկողությունից դուրս են: Մենք չենք կարող դրանք ենթարկել վերանայման կատարելուց առաջ, օգտագործել տարբերակի վերահսկման համակարգ և արագ հետ բերել այն փոփոխությունները, որոնք հանգեցրին պատահարի: Այս խնդիրները լուծելու նպատակով المهندիրները ստեղծել են և իրականացնում են ավտոմատ bash/shell-սկրիպտեր, ինչը առաջ-mentioned եղանակներից այնքան էլ լավ չէ, քանի որ դրանք այնքան էլ հեշտ չեն արագ կարդալ, հասկանալ, պահեստավորել ու փոխել ընթացակարգային ոճով:
Այս հոդվածում և պրակտիկ ուղեցույցում ես օգտագործում եմ երկու գործիք, որոնք կապված են IaC պրակտիկայի հետ: Այսինքն՝ Terraform և Ansible: Ոմանք կարծում են, որ դրանց մեկը միաժամանակ օգտագործելը իմաստ չունի, քանի որ նրանց ֆունկցիաները նման են, և նրանք փոխարինելի են: Սակայն այնտեղ հարցն այն է, որ սկզբունքորեն նրանց առջև ամբողջովին տարբեր խնդիրներ են դրվում: Եվ այն փաստը, որ այս գործիքները պետք է մեկը մյուսին լրացնեն, հաստատվել է HashiCorp և RedHat ընկերությունների մշակողների համատեղ ներկայացման ընթացքում: Կոնցեպտուալ տարբերությունը կայանում է նրանում, որ Terraform-ը շարժիչի գործիք է, որը ծառայում էServer-ների կառավարմանը: մինչդեռ Ansible-ն էConfiguration-ների կառավարման գործիք: դրա խնդիրն է՝ ծրագր的软件 վերապատրաստում, կարգավորում և կառավարման մարմիններ այդ Server-ներում:
Այդ գործիքների մեկ այլ հիմնական առանձնահատկությունն է՝ կոդի գրելու ոճը: Bash-ի և Ansible-ի տարբերությամբ, Terraform-ը օգտագործում է դեկլարատիվ ոճ, որը հիմնված է իրականացման արդյունքում հասանելի վերջնական վիճակի նկարագրության վրա: Օրինակ, եթե մենք պատրաստվում ենք ստեղծել 10 VM-ներ և փոփոխություններ կիրառել Terraform-ի միջոցով, ապա մենք ստանում ենք 10 VM: եթե կրկնակի անգամ կիրառենք սկրիպտը, ոչինչ չի պատահի, քանի որ մենք արդեն ունենք 10 VM, և Terraform-ը գիտի դրա մասին, քանի որ պահպանում է ենթակառուցվածքի ներկայիս վիճակը state-ֆայլում: Անսիբլը օգտագործում է գործընթացային մոտեցում, և եթե խնդրենք նրան ստեղծել 10 VM, ապա առաջին գործարկման ժամանակ մենք ստանում ենք 10 VM, ինչքանով դա ավելի նման է Terraform-ին: Սակայն կրկնակի գործարկման դեպքում մեզ մոտ արդեն կլինի 20 VM: Այստեղ հիմնական տարբերությունն է: Ստեղծված ոճում մենք չի պահի ներկայիս վիճակը և պարզապես նկարագրում ենք կատարման հաջորդականությունը: Իհարկե, մենք կարող ենք մշակել տարբեր իրավիճակներ, ավելացնել մի քանի ստուգումներ ռեսուրսների և ներկայիս վիճակի առկայության վրա, սակայն մեր ժամանակն ու ջանքերը չարժի ծախսել այս տրամաբանության վերահսկմանը: Այս իրավիճակը նաև increases ռիսկը սխալներ գործելու համար.
Համադրելով վերոնշյալը, կարելի է եզրակացնել, որ սերվերների provisioning-ի համար առավել համապատասխան գործիք է Terraform-ը և դեկլարատիվ նոտացիան: Իսկ վարկածի կառավարման աշխատանքը ավելի լավ է վստահել Ansible-ին: Դրանից հետո դիտարկենք օգտագործման օրինակները ավտոմատացման համատեքստում.
Ավտոմատացման ենթակառուցվածքների արժեքը
Այս դեպքում կարևոր է հասկանալ, որ թեստավորման ավտոմատացման ենթակառուցվածքը պետք է դիտարկվի որպես ողջ կազմակերպության ենթակառուցվածքի մաս: Դա նշանակում է, որ բոլոր IaC-ի պրակտիկաները պետք է εφαρμοվեն համընդհանուր բոլոր կազմակերպության ռեսուրսների վրա: Ով պատասխանատու է դրա համար, կախված է ձեր գործընթացներից: DevOps թիմը ավելի փորձառու է այս հարցերում, նրանք տեսնում են տեղի ունեցող ամբողջ картին: Սակայն QA ինժեներները ավելի ուժեղ ներգրավված են ավտոմատացման կառուցվածքի և pipeline-ի գործընթացում, ինչը նրանց ավելի լավ հնարավորություն է տալիս տեսնելու բոլոր անհրաժեշտ փոփոխությունները և բարելավման հնարավորությունները: Հնարավորության լավագույն տարբերակը՝ աշխատել միասին, փոխանակել գիտելիքներ և գաղափարներ ակնկալվող արդյունքներին հասնելու համար.
Ներկայացնեմ մի քանի օրինակ Terraform-ի և Ansible-ի օգտագործման վերաբերյալ թեստավորման ավտոմատացման համատեքստում և այն գործիքների մասին, որոնցDiscussիվում էինք նախկինում:
1. Թողնել Terraform-ի միջոցով անհրաժեշտ VMs և կլաստերների հատկությունները և պարամետրերը.
2. Անսիբլի օգնությամբ տեղադրել թեստավորման համար անհրաժեշտ գործիքները՝ docker, Selenoid, Selenium Grid, և ներբեռնել անհրաժեշտ բրաուզերների/էմուլյատորների տարբերակները.
3. Լուծել Terraform-ի միջոցով VM-ի հատկությունները, որտեղ GitLab Runner-ն է գործարկվելու.
4. GitLab Runner-ի և անհրաժեշտ լրացուցիչ գործիքների տեղադրում Ansible-ի միջոցով, կարգավորումների և կոնֆիգուրացիաների սահմանում:
Տարածքի ներկա պայմանների նկարագրությունը
Ուսումնասիրության հղումները:
Նման գործիքներ
Ամփոփենք!
Քայլ
Տեխնոլոգիա
Գործիքներ
Ավտոմատացման ենթակառուցվածքների արժեքը
1
Yerokh dzhans
Node.js, Selenium, Appium
- Ամենատարածված գործիքները web և mobile-ի համար
- Հաշվի առնելով բազմաթիվ լեզուներ և պլատֆորմներ (ներառյալ Node.js)
2
Տ/version հրամանների կառավարման համակարգեր
Git
- Նմանապես ծրագրավորողի կոդի առավելություններ
3
Կոնտեյներսում
Docker, Selenium grid, Selenoid (Web, Android)
- Օպտիմալ դիտարկմամբ հսկողության ընթացակարգ
- Ազատ շրջակա միջավայրեր
- Հեշտ ու ճFlexibleible փոփոխել տարբերակները
- Դինամիկ կանգառներ չօգտագործվող ռեսուրսների համար
- Անսահման անհատական
4
CI/CD
Gitlab CI
- Թեստեր ընթացակարգի մասն
- Արագ հետադարձ կապ
- Տեսանելիություն ամբողջ ընկերության / թիմի համար
5
Cloud platforms
Google Cloud Platform
- Հաշվարկով ռեսուրսները (վճարում ենք միայն երբ անհրաժեշտ է)
- Անհեշտ կառավարելի և թարմացվող
- Տեսանելիություն և վերահսկում բոլոր ռեսուրսների համար
6
Օրակարգ
Kubernetes
Դրվել են կոնտեյներների մեջ բրաուզերների / էմուլյատորների հետ մեջ pods:
- Մեծացում / ավտոմատ մեծացում
- Ինքներկանող
- Թարմացումները և վերադարձը առանց ընդհատվելու
7
Տեղն են հանդիսանում որպես կոդ (IaC)
Terraform, Ansible
- Նմանապես ծրագրի ենթակառուցվածքի առավելություններ
- Որպեսզի ռեսուրսները կարողանան կրկնօրինակվել
- Հեշտ է փոփոխություններ անել և պահպանել
- Լրովին ավտոմատացված
Միտք քարտի գծային գծերով: ենթակառուցվածքի իրադարձային դինամիկ
քայլ 1: Yerokh
քայլ 2: VCS
քայլ 3: Контейнерացում
քայլ 4: CI/CD
քայլ 5: Կլաուդային Պլատֆորմներ
քայլ 6: Օպերացիոն համակարգ
քայլ 7: IaC
Ի՞նչ կլինի հաջորդը:
Այսպիսով, հոդվածը ավարտվելու է։ Բայց վերջում ես ցանկանում եմ մի քանի պայմաններից հրաժարվելու մասին խոսել:
Ձեր կողմից
Ինչպես նշվեց սկզբում, ես ուզում էի, որպեսզի հոդվածը օգտակար լինի և օգնի ձեզ կիրառել ձեռք բերված գիտելիքները իրական աշխատանքի մեջ։ Թողնում եմ լրացուցիչ.
Բայց նույնիսկ դրանից հետո մի կանգ առեք, պրակտիկայում, ուսումնասիրեք համապատասխան հղումները և գրքեր, դասացուցակ բերեք, ինչպես դա աշխատում է ձեր ընկերության մեջ, գտեք վայրեր, որոնք կարող եք բարելավել և մասնակցեք դրան։ Բարև!
Իմ կողմից
Վերնագրից երևում է, որ սա միայն առաջին մասն էր։ Չնայած այն բավական մեծ է, այդուհանդերձ այստեղ դեռևս չհանդիպված են կարևոր թեմաներ։ Երկրորդ մասում ես ծրագրում եմ քննարկել ավտոմատացման ենթակառուցվածքը IOS-ի տեսանկյունից։ Apple-ի սահմանափակումների պատճառով, որոնք կապված են IOS սիմուլյատորների գործարկման միայն macOS համակարգերի վրա, մեր լուծման ձևաչափն համեմատաբար նեղ է: Օրինակ, մենք զրկված ենք Docker-ի միջոցով սիմուլյատոր ուղարկելու կամ հանրային ամպերի նման վիրտուալ մեքենաներ: Բայց դա չի նշանակում, որ այլ այլընտրանքներ գոյություն չունեն: Ես փորձելու եմ պահել ձեզ մինչև առաջնակարգ լուծումների և ժամանակակից գործիքների:
բացի այդ, ես չեմ հիշատակել բավական մեծ թեմաներ, որոնք կապված են մոնիտորինգի հետ։ 3-րդ մասում ես ծրագրում եմ քննարկել ենթակառուցվածքի մոնիտորինգի ամենատարածված գործիքները, ինչպես նաև որոնք տվյալներ և մետրիկա պետք է նկատի ունենալ:
Եւ վերջինը. בעתיד ես ծրագրում եմ թողարկել տեսածրագիր թեստային ենթակառուցվածքի կառուցման և հանրաճանաչ գործիքների մասին: Այս պահին համացանցում բավականին շատ դասընթացներ և лекցիաներ կան DevOps-ի վերաբերյալ, բայց բոլոր նյութերը ներկայացված են ծրագրավորման համատեքստում, ոչ թե թեստավորման ավտոմատացման: Այս հարցում ինձ չափազանց անհրաժեշտ է հակադարձություն, արդյո՞ք նման դասընթացը հետաքրքիր ու արժեքավոր կլինի թեստավորողների և ավտոմատացողների համ społeczության համար: Շնորհակալություն։
Ընտանիք: habr.com
