Дел 1: Веб/Андроид
Имајте на ум: овој напис е превод на руски на оригиналниот напис Сепак, сите илустрации, врски, цитати и термини се зачувани на оригиналниот јазик за да се избегне нарушување на значењето кога се преведуваат на руски. Ви посакувам среќно учење!
Во моментов, специјалитетот DevOps е еден од најбараните во ИТ индустријата. Ако отворите популарни сајтови за барање работа и филтрирате по плата, ќе видите дека работните места поврзани со DevOps се на врвот на листата. Сепак, важно е да се разбере дека ова главно се однесува на позицијата 'Виша', што подразбира дека кандидатот има високо ниво на вештини, познавање на технологија и алатки. Ова, исто така, доаѓа со висок степен на одговорност поврзана со непреченото функционирање на производството. Сепак, почнавме да забораваме што е DevOps. Првично, тоа не беше одредено лице или оддел. Ако бараме дефиниции за овој поим, ќе најдеме многу убави и правилни именки, како што се методологија, практики, културна филозофија, група поими итн.
Мојата специјализација е инженер за автоматизација за тестирање (QA automation engineer), но верувам дека не треба да се поврзува само со пишување авто-тестови или развивање на архитектура на рамка за тестови. Во 2020 година, знаењето за инфраструктурата за автоматизација е исто така од суштинско значење. Ова ви овозможува сами да го организирате процесот на автоматизација, од извршување на тестови до обезбедување резултати на сите засегнати страни во согласност со вашите цели. Како резултат на тоа, вештините на DevOps се неопходни за да се заврши работата. И сето ова е добро, но, за жал, има проблем (спојлер: оваа статија се обидува да го поедностави овој проблем). Поентата е дека DevOps е тежок. И ова е очигледно, бидејќи компаниите нема да платат многу за нешто што е лесно да се направи... Во светот на DevOps, постојат голем број алатки, термини и практики кои треба да се совладаат. Ова е особено тешко на почетокот на кариерата и зависи од акумулираното техничко искуство.
Извор:
Овде веројатно ќе завршиме со воведниот дел и ќе се фокусираме на целта на оваа статија.
За што е оваа статија?
Во оваа статија, ќе го споделам моето искуство за изградба на инфраструктура за тестирање автоматизација. Постојат многу извори на информации на Интернет за различни алатки и како да се користат, но би сакал да ги разгледам чисто во контекст на автоматизација. Верувам дека многу инженери за автоматизација се запознаени со ситуацијата кога никој освен вас не ги извршува развиените тестови или не се грижи за нивно одржување. Како резултат на тоа, тестовите стануваат застарени и мора да потрошите време за да ги ажурирате. Повторно, на почетокот на кариерата, ова може да биде доста тешка задача: мудро одлучување кои алатки треба да помогнат да се елиминира даден проблем, како да се изберат, конфигурираат и одржуваат. Некои тестери се обраќаат до DevOps (луѓе) за помош и, да бидеме искрени, овој пристап функционира. Во многу случаи ова може да биде единствената опција бидејќи немаме видливост на сите зависности. Но, како што знаеме, DevOps се многу зафатени момци, затоа што треба да размислуваат за инфраструктурата на целата компанија, распоредувањето, мониторингот, микросервисите и други слични задачи во зависност од организацијата/тимот. Како што обично се случува, автоматизацијата не е приоритет. Во таков случај, мора да се обидеме да направиме се што е можно од наша страна од почеток до крај. Ова ќе ги намали зависностите, ќе го забрза работниот тек, ќе ги подобри нашите вештини и ќе ни овозможи да ја видиме поголемата слика за она што се случува.
Статијата ги претставува најпопуларните и најпопуларните алатки и покажува како да ги користите за изградба на инфраструктура за автоматизација чекор по чекор. Секоја група е претставена со алатки кои се тестирани преку лично искуство. Но, тоа не значи дека треба да го користите истото. Самите алатки не се важни, тие се појавуваат и застаруваат. Нашата инженерска задача е да ги разбереме основните принципи: зошто ни е потребна оваа група алатки и кои работни проблеми можеме да ги решиме со нивна помош. Затоа на крајот од секој дел оставам линкови до слични алатки кои може да се користат во вашата организација.
Што не е во оваа статија
Повторувам уште еднаш дека статијата не е за специфични алатки, така што нема да има вметнувања на код од документацијата и описи на конкретни команди. Но, на крајот од секој дел оставам линкови за детално проучување.
Ова е направено затоа што:
- овој материјал е многу лесно да се најде во различни извори (документација, книги, видео курсеви);
- ако почнеме да навлегуваме подлабоко, ќе треба да напишеме 10, 20, 30 делови од оваа статија (додека плановите се 2-3);
- Едноставно не сакам да го трошам вашето време бидејќи можеби ќе сакате да користите други алатки за да ги постигнете истите цели.
Пракса
Навистина би сакал овој материјал да биде корисен за секој читател, а не само да се чита и заборава. Во секоја студија, практиката е многу важна компонента. За ова се подготвив. Ве чекаат и домашна задача за да се уверите дека нема безумно да ги копирате линиите од командите што ги извршувате.
План
Чекор
технологија
алатки
1
Локално извршување (подгответе веб/андроид демо тестови и стартувајте ги локално)
Node.js, Selenium, Appium
2
Системи за контрола на верзии
оди
3
Контејнеризација
Докер, селенска мрежа, селеноид (Веб, Андроид)
4
CI/CD
Гитлаб CI
5
Облачни платформи
Облачна платформа на Google
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)
Краток опис на технологијата
За да покажеме како контејнеризацијата ги промени правилата на игра, да се вратиме во времето неколку децении. Тогаш, луѓето купуваа и користеа серверски машини за да стартуваат апликации. Но, во повеќето случаи, потребните ресурси за стартување не беа однапред познати. Како резултат на тоа, компаниите потрошија пари за купување на скапи, моќни сервери, но дел од овој капацитет не беше целосно искористен.
Следната фаза на еволуцијата беа виртуелните машини (ВМ), кои го решија проблемот со трошење пари на неискористени ресурси. Оваа технологија овозможи да се извршуваат апликациите независно една од друга во рамките на истиот сервер, распределувајќи целосно изолиран простор. Но, за жал, секоја технологија има свои недостатоци. Водење на VM бара целосен оперативен систем, кој троши процесор, RAM меморија, складирање и, во зависност од ОС, треба да се земат предвид трошоците за лиценца. Овие фактори влијаат на брзината на вчитување и ја отежнуваат преносливоста.
И сега доаѓаме до контејнеризација. Уште еднаш, оваа технологија го решава претходниот проблем, бидејќи контејнерите не користат целосен оперативен систем, што ослободува голема количина ресурси и обезбедува брзо и флексибилно решение за преносливост.
Се разбира, технологијата за контејнеризација не е ништо ново и првпат беше воведена во доцните 70-ти. Во тие денови беа направени многу истражувања, случувања и обиди. Но, Докер беше тој што ја адаптираше оваа технологија и ја направи лесно достапна за масите. Во денешно време, кога зборуваме за контејнери, во повеќето случаи мислиме на Docker. Кога зборуваме за Docker контејнери, мислиме на Linux контејнери. Можеме да користиме Windows и macOS системите за извршување на контејнери, но важно е да се разбере дека во овој случај се појавува дополнителен слој. На пример, Docker на Mac тивко работи контејнери во лесен Linux VM. Ќе се вратиме на оваа тема кога ќе разговараме за извршување на Android емулатори во контејнерите, така што тука има една многу важна нијанса што треба да се дискутира подетално.
Вредност за инфраструктура за автоматизација
Дознавме дека контејнеризацијата и Docker се кул. Да го погледнеме ова во контекст на автоматизација, бидејќи секоја алатка или технологија треба да реши проблем. Дозволете ни да ги наведеме очигледните проблеми на автоматизацијата на тестовите во контекст на тестовите за UI:
- огромен број на зависности при инсталирање на Selenium и особено Appium;
- проблеми со компатибилноста помеѓу верзии на прелистувачи, симулатори и драјвери;
- недостаток на изолиран простор за прелистувачи/симулатори, што е особено критично за паралелно трчање;
- тешко е да се управува и одржува ако треба да работиш 10, 50, 100 или дури 1000 прелистувачи во исто време.
Но, бидејќи Selenium е најпопуларната алатка за автоматизација, а Docker е најпопуларната алатка за контејнеризација, не треба да изненадува што некој се обидел да ги комбинира за да создаде моќна алатка за решавање на горенаведените проблеми. Да ги разгледаме таквите решенија подетално.
Решетка од селен во докерот
Оваа алатка е најпопуларна во светот на Selenium за водење на повеќе прелистувачи на повеќе машини и управување со нив од централен центар. За да започнете, треба да регистрирате најмалку 2 дела: Hub и Node(и). Hub е централен јазол кој ги прима сите барања од тестовите и ги дистрибуира до соодветните Јазли. За секој Јазол можеме да конфигурираме одредена конфигурација, на пример, со наведување на саканиот прелистувач и неговата верзија. Сепак, сè уште треба сами да се грижиме за компатибилните драјвери за прелистувачи и да ги инсталираме на саканите Јазли. Поради оваа причина, Selenium grid не се користи во својата чиста форма, освен кога треба да работиме со прелистувачи кои не можат да се инсталираат на Linux OS. За сите други случаи, значително флексибилно и правилно решение би било да се користат сликите на Docker за да се стартуваат Selenium grid Hub и Nodes. Овој пристап во голема мера го поедноставува управувањето со јазлите, бидејќи можеме да ја избереме сликата што ни треба со веќе инсталирани компатибилни верзии на прелистувачи и драјвери.
И покрај негативните критики за стабилноста, особено кога се извршуваат голем број јазли паралелно, селенската мрежа сè уште е најпопуларната алатка за паралелно извршување на тестови за селен. Важно е да се напомене дека различни подобрувања и модификации на оваа алатка постојано се појавуваат во отворен код, кои се борат со различни тесни грла.
Селеноид за веб
Оваа алатка е пробив во светот на селенот бидејќи работи веднаш надвор од кутијата и многу го олесни животот на многу инженери за автоматизација. Како прво, ова не е уште една модификација на селенската мрежа. Наместо тоа, програмерите создадоа сосема нова верзија на Selenium Hub во Голанг, која, во комбинација со лесните Docker слики за различни прелистувачи, даде поттик за развој на автоматизација на тестовите. Згора на тоа, во случајот со Selenium Grid, мора однапред да ги одредиме сите потребни прелистувачи и нивните верзии, што не е проблем кога работиме само со еден прелистувач. Но, кога станува збор за повеќе поддржани прелистувачи, Selenoid е решение број еден благодарение на неговата функција „прелистувач на барање“. Сè што се бара од нас е однапред да ги преземеме потребните слики со прелистувачи и да ја ажурираме конфигурациската датотека со која комуницира Selenoid. Откако Selenoid ќе добие барање од тестовите, автоматски ќе го стартува саканиот контејнер со саканиот прелистувач. Кога ќе заврши тестот, Selenoid ќе го повлече контејнерот, а со тоа ќе ослободи ресурси за идните барања. Овој пристап целосно го елиминира добро познатиот проблем на „деградација на јазлите“ што често го среќаваме во мрежата на селен.
Но, за жал, Селеноид сè уште не е сребрен куршум. Ја добивме функцијата „прелистувач на барање“, но функцијата „ресурси на барање“ сè уште не е достапна. За да го користиме Selenoid, мора да го распоредиме на физички хардвер или на VM, што значи дека мора однапред да знаеме колку ресурси треба да се распределат. Претпоставувам дека ова не е проблем за мали проекти кои работат 10, 20 или дури 30 прелистувачи паралелно. Но, што ако ни требаат 100, 500, 1000 и повеќе? Нема смисла постојано да одржувате и плаќате толку многу ресурси. Во деловите 5 и 6 од овој напис, ќе разговараме за решенијата што ви дозволуваат да ги зголемите, а со тоа значително да ги намалите трошоците на компанијата.
Селеноид за Андроид
По успехот на Selenoid како алатка за веб-автоматизација, луѓето сакаа нешто слично за Android. И се случи - Selenoid беше објавен со поддршка за Android. Од корисничка гледна точка на високо ниво, принципот на работа е сличен на веб-автоматизацијата. Единствената разлика е во тоа што наместо контејнери на прелистувачот, Selenoid користи контејнери за емулатори на Android. Според мое мислење, ова е моментално најмоќната бесплатна алатка за паралелно извршување на тестови за 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 - Континуирана интеграција, ЦД - Континуирана испорака и повторно ЦД - Континуирано распоредување. (Подолу ќе ги користам овие термини на англиски јазик). Секоја модификација додава неколку дополнителни чекори на вашата развојна линија. Но, зборот континуирано (континуирано) е најважното нешто. Во овој контекст, мислиме на нешто што се случува од почеток до крај, без прекин или рачна интервенција. Ајде да ги погледнеме CI & CD и CD во овој контекст.
- Континуирана интеграција ова е почетниот чекор на еволуцијата. По поднесувањето на новиот код на серверот, очекуваме да добиеме брзи повратни информации дека нашите промени се во ред. Вообичаено, CI вклучува извршување на алатки за анализа на статички код и тестови на единица/внатрешна API. Ова ни овозможува да добиеме информации за нашиот код во рок од неколку секунди/минути.
- Континуирана испорака е понапреден чекор каде што извршуваме тестови за интеграција/UI. Меѓутоа, во оваа фаза не добиваме резултати толку брзо како со CI. Прво, овие типови на тестови треба подолго да се завршат. Второ, пред да започнеме, мораме да ги распоредиме нашите промени во околината за тестирање/сценирање. Згора на тоа, ако зборуваме за развој на мобилни телефони, тогаш се појавува дополнителен чекор за создавање на градба на нашата апликација.
- Континуирано распоредување претпоставува дека автоматски ги ослободуваме нашите промени во производството ако сите тестови за прифаќање се поминати во претходните фази. Дополнително на ова, по фазата на ослободување, можете да конфигурирате различни фази, како што се извршување тестови за чад за производство и собирање метрики од интерес. Континуираното распоредување е можно само со добра покриеност со автоматизирани тестови. Ако се потребни какви било рачни интервенции, вклучително и тестирање, тогаш ова повеќе не е Континуирано (континуирано). Тогаш можеме да кажеме дека нашиот гасовод е во согласност само со практиката на континуирана испорака.
Вредност за инфраструктура за автоматизација
Во овој дел, треба да објаснам дека кога зборуваме за тестови за интерфејс од крај до крај, тоа значи дека треба да ги распоредиме нашите промени и придружните услуги за тестирање околини. Континуирана интеграција - процесот не е применлив за оваа задача и ние мора да се грижиме за спроведување на барем практики за континуирано доставување. Континуираното распоредување, исто така, има смисла во контекст на тестовите за кориснички интерфејс ако сакаме да ги извршиме во производство.
И пред да ја погледнеме илустрацијата за промената на архитектурата, сакам да кажам неколку зборови за 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 за автоматизирани тестови од крај до крај, а особено не за средини за рачно тестирање. За такви ситуации, би било добро да се набават онолку ресурси колку што се потребни на барање, да се користат и да престанете да плаќате кога веќе не ви се потребни. Покрај тоа, би било одлично да ги примите веднаш со неколку кликнувања на глувчето или со извршување на неколку скрипти. За ова се користат јавните облаци. Ајде да ја разгледаме дефиницијата:
„Јавниот облак се дефинира како компјутерски услуги понудени од трети лица провајдери преку јавниот интернет, што ги прави достапни за секој што сака да ги користи или купи. Тие можат да бидат бесплатни или да се продаваат на барање, дозволувајќи им на клиентите да плаќаат само по користење за циклусите на процесорот, складирањето или пропусниот опсег што го трошат“.
Постои мислење дека јавните облаци се скапи. Но, нивната клучна идеја е да ги намалат трошоците на компанијата. Како што споменавме порано, јавните облаци ви дозволуваат да добивате ресурси на барање и да плаќате само за времето кога ги користите. Исто така, понекогаш забораваме дека вработените земаат плати, а специјалистите се исто така скап ресурс. Мора да се земе предвид дека јавните облаци многу ја олеснуваат инфраструктурната поддршка, што им овозможува на инженерите да се фокусираат на поважни задачи.
Вредност за инфраструктура за автоматизација
Кои специфични ресурси ни се потребни за тестови за интерфејс од крај до крај? Во основа, ова се виртуелни машини или кластери (ќе зборуваме за 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 автомобил. Во случајот со Андроид ќе биде n1-стандард-4 за еден емулатор. Всушност, пофлексибилен и поевтин начин е да се постават специфични кориснички вредности за процесорот/меморијата, но во моментов тоа не е важно за споредба со 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 за Андроид
Паралелни тестови на 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 за хостирање контејнери со прелистувачи и емулатори. За да ги намалиме трошоците, ги стартуваме овие виртуелни машини само на барање и ги запираме кога тестирањето не се спроведува. Дали има нешто друго што може да ја подобри нашата инфраструктура? Одговорот е да! Запознајте го Кубернетис (К8)!
Прво, да погледнеме како зборовите оркестрација, кластер и Кубернети се поврзани едни со други. На високо ниво, оркестрацијата е систем кој распоредува и управува со апликациите. За тест автоматизација, такви контејнеризирани апликации се Selenium grid и Selenoid. Docker и K8 се надополнуваат еден со друг. Првиот се користи за распоредување на апликации, вториот за оркестрација. За возврат, K8s е кластер. Задачата на кластерот е да користи VM како Јазли, што ви овозможува да инсталирате различни функционалности, програми и услуги во рамките на еден сервер (кластер). Ако некој од Јазлите не успее, ќе се појават други Јазли, што обезбедува непречено функционирање на нашата апликација. Дополнително на ова, K8s има важна функционалност поврзана со скалирање, благодарение на што автоматски ја добиваме оптималната количина на ресурси врз основа на оптоварувањето и поставените граници.
За волја на вистината, рачното распоредување на Kubernetes од нула не е воопшто тривијална задача. Ќе оставам линк до познатиот водич како да се „Kubernetes The Hard Way“ и доколку ве интересира, можете да го вежбате. Но, за среќа, постојат алтернативни методи и алатки. Најлесен начин е да користите Google Kubernetes Engine (GKE) во GCP, што ќе ви овозможи да добиете готов кластер со неколку кликања. Препорачувам да го користите овој пристап за да започнете со учење, бидејќи ќе ви овозможи да се фокусирате на учење како да ги користите K8 за вашите задачи наместо да научите како внатрешните компоненти треба да се интегрираат едни со други.
Вредност за инфраструктура за автоматизација
Ајде да погледнеме неколку значајни карактеристики што ги обезбедува K8s:
- распоредување на апликацијата: користење кластер со повеќе јазли наместо VMs;
- динамично скалирање: ги намалува трошоците за ресурсите што се користат само на барање;
- само-заздравување: автоматско обновување на мешунките (како резултат на што се обновуваат и контејнерите);
- објавување на ажурирања и враќање на промените без прекин: ажурирањето на алатките, прелистувачите и емулаторите не ја прекинува работата на тековните корисници
Но, K8s сè уште не е сребрен куршум. За да ги разбереме сите предности и ограничувања во контекст на алатките што ги разгледуваме (решетка од селен, селеноид), накратко ќе разговараме за структурата на K8. Кластерот содржи два вида јазли: Главни јазли и Работнички јазли. Главните јазли се одговорни за одлуките за управување, распоредување и распоред. Работничките јазли се местото каде што се извршуваат апликациите. Јазлите, исто така, содржат средина за извршување на контејнер. Во нашиот случај, ова е Docker, кој е одговорен за операции поврзани со контејнери. Но, има и алтернативни решенија, на пример. Важно е да се разбере дека скалирањето или само-заздравувањето не се однесува директно на контејнерите. Ова се спроведува со додавање/намалување на бројот на мешунки, кои пак содржат контејнери (обично по еден контејнер по pod, но во зависност од задачата може да има повеќе). Хиерархијата на високо ниво се состои од работнички јазли, внатре во кои има мешунки, внатре во кои се креваат контејнери.
Функцијата за скалирање е клучна и може да се примени на двата јазли во рамките на кластерскиот јазол-базен и на мешунките во јазолот. Постојат 2 типа на скалирање кои се однесуваат и на јазлите и на мешунките. Првиот тип е хоризонтален - скалирањето се случува со зголемување на бројот на јазли/подови. Овој тип е попожелен. Вториот тип е, соодветно, вертикален. Скалирањето се врши со зголемување на големината на јазлите/подовите, а не нивниот број.
Сега да ги погледнеме нашите алатки во контекст на горенаведените термини.
Решетка од селен
Како што споменавме порано, селенската мрежа е многу популарна алатка и не е изненадување што е контејнеризирана. Затоа, не е изненадување што селенската мрежа може да се распореди во K8. Пример за тоа како да го направите ова може да се најде во официјалното складиште на K8s. Како и обично, прикачувам врски на крајот од делот. Дополнително, водичот како да се покаже како да го направите ова во Terraform. Исто така, има инструкции за тоа како да се зголеми бројот на подлоги што содржат контејнери на прелистувачот. Но, функцијата за автоматско скалирање во контекст на K8 сè уште не е сосема очигледна задача. Кога почнав да учам, не најдов никакви практични упатства или препораки. По неколку студии и експерименти со поддршка на тимот на DevOps, го избравме пристапот за подигнување на контејнери со потребните прелистувачи во една подлога, која се наоѓа во еден работник јазол. Овој метод ни овозможува да ја примениме стратегијата на хоризонтално скалирање на јазлите со зголемување на нивниот број. Се надевам дека тоа ќе се промени во иднина и ќе гледаме се повеќе описи на подобри пристапи и готови решенија, особено по објавувањето на Selenium grid 4 со променета внатрешна архитектура.
Селеноид:
Распоредувањето на селеноид во K8 е моментално најголемото разочарување. Тие не се компатибилни. Теоретски, можеме да подигнеме селеноиден контејнер во подлога, но кога Selenoid ќе почне да лансира контејнери со прелистувачи, тие сè уште ќе бидат во истата подлога. Ова го прави скалирањето невозможно и, како резултат на тоа, работата на Selenoid во кластерот нема да се разликува од работата во виртуелната машина. Крај на приказната.
Месечината:
Знаејќи го ова тесно грло при работа со Selenoid, програмерите објавија помоќна алатка наречена Moon. Оваа алатка првично беше дизајнирана да работи со Kubernetes и, како резултат на тоа, функцијата за автоматско скалирање може и треба да се користи. Згора на тоа, би рекол дека во моментов е единствениот алатка во светот на селенот, која има домашна поддршка за кластерот K8 надвор од кутијата (повеќе не е достапно, видете ја следната алатка ). Клучните карактеристики на Moon кои ја обезбедуваат оваа поддршка се:
Целосно без државјанство. Селеноидот зачувува информации во меморијата за тековните сесии на прелистувачот. Ако поради некоја причина неговиот процес се урна - тогаш сите работи сесии се изгубени. Месечината, пак, нема внатрешна состојба и може да се реплицира низ центрите за податоци. Сесиите на прелистувачот остануваат живи дури и ако една или повеќе реплики се симнат.
Значи, Месечината е одлично решение, но има еден проблем: не е бесплатен. Цената зависи од бројот на сесии. Можете да извршите само 0-4 сесии бесплатно, што не е особено корисно. Но, почнувајќи од петтата сесија, ќе треба да платите 5 долари за секоја. Ситуацијата може да се разликува од компанија до компанија, но во нашиот случај, користењето на Moon е бесмислено. Како што опишав погоре, можеме да работиме VM со Selenium Grid на барање или да го зголемиме бројот на Јазли во кластерот. За приближно еден гасовод, стартуваме 500 прелистувачи и ги запираме сите ресурси по завршувањето на тестовите. Ако го користевме Moon, ќе треба да плаќаме дополнителни 500 x 5 = 2500 долари месечно, без разлика колку често правиме тестови. Повторно, не велам да не го користите Moon. За вашите задачи, ова може да биде незаменливо решение, на пример, ако имате многу проекти/тимови во вашата организација и ви треба огромен заеднички кластер за секого. Како и секогаш, оставам врска на крајот и препорачувам да ги направите сите потребни пресметки во контекст на вашата задача.
Калисто: (Внимание! Ова го нема во оригиналната статија и е содржано само во рускиот превод)
Како што реков, селенот е многу популарна алатка, а полето на ИТ се развива многу брзо. Додека работев на преводот, на интернет се појави нова ветувачка алатка наречена Callisto (здраво Cypress и други убијци на селенот). Работи природно со K8 и ви овозможува да пуштате селеноид контејнери во мешунки, дистрибуирани низ јазли. Сè работи веднаш, вклучително и автоматско скалирање. Фантастично, но треба да се тестира. Веќе успеав да ја распоредам оваа алатка и да извршам неколку експерименти. Но, рано е да се извлечат заклучоци, откако ќе добијам резултати на долга дистанца, можеби ќе направам преглед во идни написи. Засега оставам само врски за независно истражување.
Илустрација на моменталната состојба на инфраструктурата
Линкови за истражување
Слични алатки
7. Инфраструктура како код (IaC)
Краток опис на технологијата
И сега доаѓаме до последниот дел. Вообичаено, оваа технологија и сродните задачи не се одговорност на инженерите за автоматизација. И има причини за ова. Прво, во многу организации, инфраструктурните проблеми се под контрола на одделот DevOps и развојните тимови навистина не се грижат за тоа што го прави гасоводот да работи и како треба да се поддржи сè што е поврзано со него. Второ, да бидеме искрени, практиката на Infrastructure as Code (IaC) сè уште не е усвоена во многу компании. Но, дефинитивно стана популарен тренд и важно е да се обидеме да бидеме вклучени во процесите, пристапите и алатките поврзани со него. Или барем бидете во тек.
Да почнеме со мотивацијата за користење на овој пристап. Веќе разговаравме дека за да извршиме тестови во GitlabCI, ќе ни требаат минимум ресурси за да го извршиме Gitlab Runner. И за да работиме контејнери со прелистувачи/емулатори, треба да резервираме VM или кластер. Покрај тестирањето на ресурсите, потребна ни е значителна количина на капацитет за поддршка на развој, поставување, производствени средини, кои исто така вклучуваат бази на податоци, автоматски распореди, мрежни конфигурации, балансери на оптоварување, кориснички права итн. Клучното прашање е напорот потребен за сето тоа да се поддржи. Постојат неколку начини на кои можеме да направиме промени и да објавиме ажурирања. На пример, во контекст на GCP, можеме да ја користиме UI конзолата во прелистувачот и да ги извршиме сите дејства со кликнување на копчињата. Алтернатива би била да се користат повици на API за интеракција со ентитети на облак или да се користи алатката за командна линија gcloud за да се извршат саканите манипулации. Но, со навистина голем број различни ентитети и инфраструктурни елементи, станува тешко, па дури и невозможно рачно извршување на сите операции. Покрај тоа, сите овие рачни дејства се неконтролирани. Не можеме да ги испратиме на преглед пред извршувањето, да користиме систем за контрола на верзијата и брзо да ги вратиме промените што доведоа до инцидентот. За да ги решат ваквите проблеми, инженерите создадоа и креираа автоматски баш/школка скрипти, кои не се многу подобри од претходните методи, бидејќи не се толку лесни за брзо читање, разбирање, одржување и менување во процедурален стил.
Во оваа статија и како да се води, користам 2 алатки поврзани со практиката на IaC. Тоа се Terraform и Ansible. Некои луѓе веруваат дека нема смисла да се користат во исто време, бидејќи нивната функционалност е слична и тие се заменливи. Но, факт е дека на почетокот им се даваат сосема различни задачи. И фактот дека овие алатки треба да се надополнуваат беше потврдено на заедничка презентација од страна на програмерите кои ги претставуваат HashiCorp и RedHat. Концептуалната разлика е во тоа што Terraform е алатка за обезбедување за управување со самите сервери. Додека Ansible е алатка за управување со конфигурации чија задача е да инсталира, конфигурира и управува софтвер на овие сервери.
Друга клучна карактеристика на овие алатки е стилот на кодирање. За разлика од bash и Ansible, Terraform користи декларативен стил заснован на опис на посакуваната крајна состојба што треба да се постигне како резултат на извршување. На пример, ако сакаме да создадеме 10 VM и да ги примениме промените преку Terraform, тогаш ќе добиеме 10 VMs. Ако повторно ја извршиме скриптата, ништо нема да се случи бидејќи веќе имаме 10 VM, а Terraform знае за ова бидејќи ја складира моменталната состојба на инфраструктурата во државна датотека. Но, Ansible користи процедурален пристап и, ако побарате од него да создаде 10 VMs, тогаш при првото лансирање ќе добиеме 10 VMs, слични на 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
Контејнеризација
Докер, селенска мрежа, селеноид (Веб, Андроид)
- Паралелно водење на тестови
- Изолирани средини
- Едноставни, флексибилни надградби на верзијата
- Динамично запирање на неискористените ресурси
- Лесно се поставува
4
CI/CD
Гитлаб CI
- Тестира дел од гасоводот
- Брзи повратни информации
- Видливост за целата компанија/тим
5
Облачни платформи
Облачна платформа на Google
- Ресурси на барање (плаќаме само кога е потребно)
- Лесно за управување и ажурирање
- Видливост и контрола на сите ресурси
6
Оркестрација
Кубернети
Во контекст на контејнерите со прелистувачи/емулатори во подлоги:
- Скалирање/автоматско скалирање
- Само-лекување
- Ажурирања и враќања без прекин
7
Инфраструктурата како код (IaC)
Terraform, Ansible
- Слични придобивки со развојната инфраструктура
- Сите придобивки од верзијата на кодот
- Лесно се прават промени и одржуваат
- Целосно автоматизиран
Дијаграми на умствена карта: еволуција на инфраструктурата
чекор 1: Локално
чекор 2: VCS
чекор 3: Контејнеризација
чекор 4: CI/CD
чекор 5: Облак платформи
чекор 6: Оркестрација
чекор 7: IaC
Што е следно?
Значи, ова е крајот на статијата. Но, како заклучок, би сакал да воспоставам некои договори со вас.
Од ваша страна
Како што реков на почетокот, би сакал статијата да биде од практична употреба и да ви помогне да го примените стекнатото знаење во вистинска работа. Повторно додавам.
Но, дури и после тоа, не застанувајте, вежбајте, проучувајте релевантни врски и книги, дознајте како функционира во вашата компанија, најдете места што може да се подобрат и учествувајте во тоа. Со среќа!
Од моја страна
Од насловот е јасно дека ова беше само првиот дел. И покрај фактот што се покажа дека е доста голем, важните теми сè уште не се опфатени овде. Во вториот дел, планирам да ја разгледам инфраструктурата за автоматизација во контекст на IOS. Поради ограничувањата на Apple за користење на симулатори за iOS само на системи за macOS, нашиот опсег на решенија е стеснет. На пример, не можеме да користиме Docker за да го стартуваме симулаторот или јавни облаци за да работиме виртуелни машини. Но, тоа не значи дека нема други алтернативи. Ќе се обидам да ве информирам со напредни решенија и современи алатки!
Исто така, немам спомнато прилично големи теми поврзани со мониторингот. Во третиот дел, ќе ги разгледам најпопуларните алатки за следење на инфраструктурата и кои податоци и метрики треба да се земат предвид.
И, конечно. Во иднина планирам да објавам видео курс за градење на тест инфраструктура и популарни алатки. Во моментов, има доста курсеви и предавања за DevOps на Интернет, но сите материјали се претставени во контекст на развој, а не во тест автоматизација. За ова прашање, навистина ми треба повратна информација дали таков курс ќе биде интересен и вреден за заедницата на тестери и инженери за автоматизација. Благодарам однапред!
Извор: www.habr.com