Част 1: Уеб/Android
Внимание: тази статия е превод на руски език на оригиналната статия Всички илюстрации, връзки, цитати и термини обаче се запазват на оригиналния език, за да се избегне изкривяване на смисъла при превод на руски. Желая ви приятно учене!
В момента специалността DevOps е една от най-търсените в ИТ индустрията. Ако отворите популярни сайтове за търсене на работа и филтрирате по заплата, ще видите, че работните места, свързани с DevOps, са в горната част на списъка. Важно е обаче да се разбере, че това се отнася главно за позиция „старши“, което предполага, че кандидатът има високо ниво на умения, познания за технологии и инструменти. Това е свързано и с висока степен на отговорност, свързана с непрекъснатата работа на производството. Въпреки това започнахме да забравяме какво е DevOps. Първоначално не беше конкретно лице или отдел. Ако потърсим дефиниции на този термин, ще намерим много красиви и правилни съществителни, като методология, практики, културна философия, група от концепции и т.н.
Специализацията ми е инженер по автоматизация на тестове (QA автоматизиран инженер), но смятам, че не трябва да се свързва само с писане на автоматични тестове или разработване на архитектура на тестова рамка. През 2020 г. познаването на инфраструктурата за автоматизация също е от съществено значение. Това ви позволява сами да организирате процеса на автоматизация, от провеждането на тестове до предоставянето на резултати на всички заинтересовани страни в съответствие с вашите цели. В резултат на това уменията за DevOps са задължителни, за да се свърши работата. И всичко това е добре, но за съжаление има проблем (спойлер: тази статия се опитва да опрости този проблем). Въпросът е, че DevOps е труден. И това е очевидно, защото компаниите няма да плащат много за нещо, което е лесно за изпълнение... В света на DevOps има голям брой инструменти, термини и практики, които трябва да бъдат усвоени. Това е особено трудно в началото на кариерата и зависи от натрупания технически опит.
Източник:
Тук вероятно ще завършим с уводната част и ще се съсредоточим върху целта на тази статия.
За какво е тази статия?
В тази статия ще споделя моя опит в изграждането на инфраструктура за автоматизация на тестове. В интернет има много източници на информация за различни инструменти и как да ги използвате, но бих искал да ги разгледам чисто в контекста на автоматизацията. Вярвам, че много инженери по автоматизация са запознати със ситуацията, когато никой освен вас не изпълнява разработените тестове или не се грижи да ги поддържа. В резултат на това тестовете стават остарели и трябва да отделите време за актуализирането им. Отново, в началото на кариерата, това може да бъде доста трудна задача: мъдро да решите кои инструменти трябва да помогнат за отстраняването на даден проблем, как да ги изберете, конфигурирате и поддържате. Някои тестери се обръщат към DevOps (хора) за помощ и, нека бъдем честни, този подход работи. В много случаи това може да е единствената опция, тъй като нямаме видимост за всички зависимости. Но както знаем, DevOps са много заети хора, защото трябва да мислят за цялата инфраструктура на компанията, внедряване, мониторинг, микроуслуги и други подобни задачи в зависимост от организацията/екипа. Както обикновено се случва, автоматизацията не е приоритет. В такъв случай трябва да се опитаме да направим всичко възможно от наша страна от началото до края. Това ще намали зависимостите, ще ускори работния процес, ще подобри уменията ни и ще ни позволи да видим по-голямата картина на случващото се.
Статията представя най-популярните и популярни инструменти и показва как да ги използвате за изграждане на инфраструктура за автоматизация стъпка по стъпка. Всяка група е представена от инструменти, които са тествани чрез личен опит. Но това не означава, че трябва да използвате едно и също нещо. Самите инструменти не са важни, те се появяват и остаряват. Нашата инженерна задача е да разберем основните принципи: защо имаме нужда от тази група инструменти и какви работни проблеми можем да решим с тяхна помощ. Ето защо в края на всеки раздел оставям връзки към подобни инструменти, които може да се използват във вашата организация.
Какво не е в тази статия
Още веднъж повтарям, че статията не е за конкретни инструменти, така че няма да има вмъквания на код от документацията и описания на конкретни команди. Но в края на всеки раздел оставям връзки за подробно проучване.
Това се прави, защото:
- този материал е много лесен за намиране в различни източници (документация, книги, видео курсове);
- ако започнем да се задълбочаваме, ще трябва да напишем 10, 20, 30 части от тази статия (докато плановете са 2-3);
- Просто не искам да ви губя времето, тъй като може да искате да използвате други инструменти, за да постигнете същите цели.
Практика
Много бих искал този материал да бъде полезен за всеки читател, а не просто прочетен и забравен. Във всяко обучение практиката е много важен компонент. За това съм се подготвил. Има и домашна работа, която ви чака, за да сте сигурни, че не копирате безсмислено редовете на командите, които изпълнявате.
план
Стъпка
Технологии
Инструменти
1
Локално изпълнение (подгответе уеб / android демо тестове и го стартирайте локално)
Node.js, Selenium, Appium
2
Системи за контрол на версиите
отивам
3
Контейнеризация
Docker, Selenium grid, Selenoid (уеб, Android)
4
CI/CD
Gitlab CI
5
Облачни платформи
Платформата Google Cloud
6
Оркестровка
Kubernetes
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), които решиха проблема с пиленето на пари за неизползвани ресурси. Тази технология направи възможно стартирането на приложения независимо едно от друго в рамките на един и същи сървър, разпределяйки напълно изолирано пространство. Но, за съжаление, всяка технология има своите недостатъци. Изпълнението на виртуална машина изисква пълна операционна система, която консумира CPU, RAM, памет и, в зависимост от операционната система, трябва да се вземат предвид разходите за лиценз. Тези фактори влияят върху скоростта на зареждане и затрудняват преносимостта.
И сега стигаме до контейнеризацията. Още веднъж тази технология решава предишния проблем, тъй като контейнерите не използват пълна операционна система, което освобождава голямо количество ресурси и осигурява бързо и гъвкаво решение за преносимост.
Разбира се, технологията за контейнеризиране не е нищо ново и е въведена за първи път в края на 70-те години. В онези дни бяха извършени много изследвания, разработки и опити. Но именно Docker адаптира тази технология и я направи лесно достъпна за масите. В днешно време, когато говорим за контейнери, в повечето случаи имаме предвид Docker. Когато говорим за Docker контейнери, имаме предвид Linux контейнери. Можем да използваме Windows и macOS системи за стартиране на контейнери, но е важно да разберем, че в този случай се появява допълнителен слой. Например Docker на Mac безшумно изпълнява контейнери в лека Linux VM. Ще се върнем към тази тема, когато обсъдим стартирането на Android емулатори в контейнери, така че тук има много важен нюанс, който трябва да бъде обсъден по-подробно.
Стойност за инфраструктурата за автоматизация
Открихме, че контейнеризацията и Docker са готини. Нека да разгледаме това в контекста на автоматизацията, защото всеки инструмент или технология трябва да реши проблем. Нека очертаем очевидните проблеми на автоматизацията на тестовете в контекста на UI тестовете:
- огромен брой зависимости при инсталиране на Selenium и особено Appium;
- проблеми със съвместимостта между версии на браузъри, симулатори и драйвери;
- липса на изолирано пространство за браузъри/симулатори, което е особено критично за паралелно изпълнение;
- трудно се управлява и поддържа, ако трябва да стартирате 10, 50, 100 или дори 1000 браузъра едновременно.
Но тъй като Selenium е най-популярният инструмент за автоматизация, а Docker е най-популярният инструмент за контейнеризиране, не трябва да е изненада, че някой се е опитал да ги комбинира, за да създаде мощен инструмент за решаване на гореспоменатите проблеми. Нека разгледаме по-подробно такива решения.
Селенова мрежа в докер
Този инструмент е най-популярният в света на Selenium за стартиране на множество браузъри на множество машини и управлението им от централен център. За да започнете, трябва да регистрирате поне 2 части: Хъб и Възел(и). Хъбът е централен възел, който получава всички заявки от тестове и ги разпределя към съответните възли. За всеки възел можем да конфигурираме специфична конфигурация, например като посочим желания браузър и неговата версия. Все пак трябва сами да се погрижим за съвместимите драйвери на браузъра и да ги инсталираме на желаните възли. Поради тази причина Selenium grid не се използва в чист вид, освен когато трябва да работим с браузъри, които не могат да бъдат инсталирани на Linux OS. За всички останали случаи значително гъвкаво и правилно решение би било използването на Docker изображения за стартиране на Selenium grid Hub и Nodes. Този подход значително опростява управлението на възлите, тъй като можем да изберем изображението, от което се нуждаем, с вече инсталирани съвместими версии на браузъри и драйвери.
Въпреки отрицателните отзиви за стабилността, особено при паралелно изпълнение на голям брой възли, Selenium grid все още е най-популярният инструмент за паралелно изпълнение на Selenium тестове. Важно е да се отбележи, че различни подобрения и модификации на този инструмент постоянно се появяват в отворения код, които се борят с различни тесни места.
Селеноид за уеб
Този инструмент е пробив в света на Selenium, тъй като работи направо от кутията и направи живота на много инженери по автоматизация много по-лесен. Първо, това не е поредната модификация на мрежата Selenium. Вместо това разработчиците създадоха напълно нова версия на Selenium Hub в Golang, която, комбинирана с олекотени изображения на Docker за различни браузъри, даде тласък на развитието на автоматизацията на тестовете. Освен това, в случая на Selenium Grid, трябва предварително да определим всички необходими браузъри и техните версии, което не е проблем при работа само с един браузър. Но когато става дума за множество поддържани браузъри, Selenoid е решение номер едно благодарение на функцията си „браузър при поискване“. Всичко, което се изисква от нас, е предварително да изтеглим необходимите изображения с браузъри и да актуализираме конфигурационния файл, с който Selenoid взаимодейства. След като Selenoid получи заявка от тестовете, той автоматично ще стартира желания контейнер с желания браузър. Когато тестът приключи, Selenoid ще оттегли контейнера, като по този начин ще освободи ресурси за бъдещи заявки. Този подход напълно елиминира добре известния проблем с „деградацията на възела“, който често срещаме в Selenium grid.
Но, уви, Selenoid все още не е сребърен куршум. Имаме функцията „браузър при поискване“, но функцията „ресурси при поискване“ все още не е налична. За да използваме Selenoid, трябва да го разположим на физически хардуер или на VM, което означава, че трябва да знаем предварително колко ресурси трябва да бъдат разпределени. Предполагам, че това не е проблем за малки проекти, които работят с 10, 20 или дори 30 браузъра паралелно. Но какво ще стане, ако имаме нужда от 100, 500, 1000 и повече? Няма смисъл да поддържате и плащате за толкова много ресурси през цялото време. В раздели 5 и 6 на тази статия ще обсъдим решения, които ви позволяват да мащабирате, като по този начин значително намалявате разходите на компанията.
Селеноид за Android
След успеха на Selenoid като инструмент за уеб автоматизация, хората искаха нещо подобно за Android. И това се случи - Selenoid беше пуснат с поддръжка на Android. От гледна точка на потребител на високо ниво, принципът на работа е подобен на уеб автоматизацията. Единствената разлика е, че вместо контейнери на браузъра, Selenoid изпълнява контейнери на Android емулатор. Според мен в момента това е най-мощният безплатен инструмент за паралелно провеждане на Android тестове.
Наистина не бих искал да говоря за отрицателните страни на този инструмент, тъй като наистина го харесвам. Но все пак има същите недостатъци, които се отнасят за уеб автоматизацията и са свързани с мащабирането. В допълнение към това, трябва да говорим за още едно ограничение, което може да ни изненада, ако настройваме инструмента за първи път. За да изпълняваме изображения на Android, имаме нужда от физическа машина или виртуална машина с поддръжка на вложена виртуализация. В ръководството как да демонстрирам как да активирате това на Linux VM. Ако обаче сте потребител на macOS и искате да внедрите Selenoid локално, това няма да е възможно за стартиране на Android тестове. Но винаги можете да стартирате Linux VM локално с конфигурирана „вложена виртуализация“ и да разположите Selenoid вътре.
Илюстрация на текущото състояние на инфраструктурата
В контекста на тази статия ще добавим 2 инструмента, за да илюстрираме инфраструктурата. Това са Selenium grid за уеб тестове и Selenoid за Android тестове. В урока за GitHub ще ви покажа също как да използвате Selenoid за провеждане на уеб тестове.
Връзки за изследване
Подобни инструменти
- Има и други инструменти за контейнеризиране, но Docker е най-популярният. Ако искате да опитате нещо друго, имайте предвид, че инструментите, които разгледахме за паралелно провеждане на тестове на Selenium, няма да работят веднага.
- Както вече казахме, има много модификации на Selenium grid, напр..
4.CI/CD
Кратко описание на технологията
Практиката на непрекъсната интеграция е доста популярна в разработката и е наравно със системите за контрол на версиите. Въпреки това смятам, че има объркване в терминологията. В този параграф бих искал да опиша 3 модификации на тази технология от моя гледна точка. В интернет ще намерите много статии с различни тълкувания и е абсолютно нормално мнението ви да е различно. Най-важното е да сте на една вълна с колегите си.
И така, има 3 термина: CI - непрекъсната интеграция, CD - непрекъсната доставка и отново CD - непрекъснато внедряване. (По-долу ще използвам тези термини на английски). Всяка модификация добавя няколко допълнителни стъпки към вашата линия за разработка. Но думата непрекъснат (непрекъснато) е най-важното нещо. В този контекст имаме предвид нещо, което се случва от началото до края, без прекъсване или ръчна намеса. Нека да разгледаме CI & CD и CD в този контекст.
- Непрекъсната интеграция това е началната стъпка на еволюцията. След като изпратим нов код на сървъра, очакваме да получим бърза обратна връзка, че промените са добри. Обикновено CI включва стартиране на инструменти за статичен анализ на код и единици/вътрешни API тестове.Това ни позволява да получим информация за нашия код в рамките на няколко секунди/минути.
- Continuous Delivery е по-напреднала стъпка, при която провеждаме тестове за интеграция/ПИ. На този етап обаче не получаваме резултати толкова бързо, колкото при CI. Първо, завършването на тези видове тестове отнема повече време. Второ, преди да стартираме, трябва да внедрим нашите промени в средата за тестване/постановка. Освен това, ако говорим за мобилна разработка, тогава се появява допълнителна стъпка за създаване на компилация на нашето приложение.
- Непрекъснато внедряване предполага, че ние автоматично пускаме нашите промени в производството, ако всички тестове за приемане са преминали в предишните етапи. В допълнение към това, след етапа на пускане можете да конфигурирате различни етапи, като например провеждане на димни тестове за производство и събиране на показатели, които представляват интерес. Непрекъснатото внедряване е възможно само при добро покритие от автоматизирани тестове. Ако са необходими някакви ръчни намеси, включително тестване, това вече не е така Непрекъснат (непрекъснато). Тогава можем да кажем, че нашият тръбопровод отговаря само на практиката за непрекъсната доставка.
Стойност за инфраструктурата за автоматизация
В този раздел трябва да изясня, че когато говорим за UI тестове от край до край, това означава, че трябва да внедрим нашите промени и свързаните с тях услуги за тестови среди. Непрекъсната интеграция – процесът не е приложим за тази задача и трябва да се погрижим да внедрим поне практиките за непрекъсната доставка. Непрекъснатото внедряване също има смисъл в контекста на UI тестове, ако ще ги изпълняваме в производство.
И преди да разгледаме илюстрацията на промяната на архитектурата, искам да кажа няколко думи за GitLab CI. За разлика от други CI/CD инструменти, GitLab предоставя отдалечено хранилище и много други допълнителни функции. По този начин GitLab е повече от CI. Той включва управление на изходния код, Agile управление, 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 срещу Sauce Labs за целите на автоматизацията:
Нека си представим, че трябва да изпълним 8 уеб теста и 8 Android теста едновременно. За целта ще използваме GCP и ще стартираме 2 виртуални машини със Selenoid. На първия ще съберем 8 контейнера с браузъри. На втория има 8 контейнера с емулатори. Нека да разгледаме цените:
За да стартираме един контейнер с Chrome, имаме нужда n1-стандарт-1 кола. В случая с Android ще бъде така n1-стандарт-4 за един емулатор. Всъщност по-гъвкав и по-евтин начин е да зададете специфични потребителски стойности за CPU/Memory, но в момента това не е важно за сравнение с Sauce Labs.
А ето и тарифите за използване на Sauce Labs:
Вярвам, че вече сте забелязали разликата, но все пак ще предоставя таблица с изчисления за нашата задача:
Необходими ресурси
Месечно
Работни часове(8 сутринта - 8 часа)
Работни часове+ Предварително изместваем
GCP за уеб
n1-стандарт-1 x 8 = n1-стандарт-8
$194.18
23 дни * 12 часа * 0.38 = $104.88
23 дни * 12 часа * 0.08 = $22.08
Sauce Labs за уеб
Virtual Cloud8 паралелни тестове
$1.559
-
-
GCP за Android
n1-стандарт-4 x 8: n1-стандарт-16
$776.72
23 дни * 12 часа * 1.52 = $419.52
23 дни * 12 часа * 0.32 = $88.32
Sauce Labs за Android
Real Device Cloud 8 паралелни тестове
$1.999
-
-
Както можете да видите, разликата в цената е огромна, особено ако провеждате тестове само по време на дванадесетчасов работен период. Но можете да намалите още повече разходите, ако използвате машини с възможност за изключване. Какво е?
Виртуална машина с възможност за изместване е екземпляр, който можете да създадете и стартирате на много по-ниска цена от нормалните екземпляри. Въпреки това Compute Engine може да прекрати (изпреварва) тези екземпляри, ако изисква достъп до тези ресурси за други задачи. Изпреварваемите екземпляри са излишък от капацитет на Compute Engine, така че тяхната наличност варира в зависимост от употребата.
Ако приложенията ви са устойчиви на грешки и могат да издържат на евентуални изпреварващи инстанции, тогава изпреварваните инстанции могат значително да намалят разходите ви за Compute Engine. Например заданията за групова обработка могат да се изпълняват на екземпляри с предимство. Ако някои от тези екземпляри прекратят по време на обработка, заданието се забавя, но не спира напълно. Изпреварваемите екземпляри изпълняват задачите ви за групова обработка, без да натоварват допълнително вашите съществуващи екземпляри и без да изискват да плащате пълната цена за допълнителни нормални екземпляри.
И все още не е свършило! В действителност съм сигурен, че никой не прави тестове по 12 часа без почивка. И ако е така, тогава можете автоматично да стартирате и спирате виртуални машини, когато не са необходими. Реалното време за използване може да бъде намалено до 6 часа на ден. Тогава плащането в контекста на нашата задача ще намалее до $11 на месец за 8 браузъра. Не е ли това прекрасно? Но с изпреварващите машини трябва да сме внимателни и подготвени за прекъсвания и нестабилност, въпреки че тези ситуации могат да бъдат предвидени и обработени в софтуера. Заслужава си!
Но в никакъв случай не казвам „никога не използвайте облачни тестови ферми“. Те имат редица предимства. На първо място, това не е просто виртуална машина, а пълноценно решение за автоматизация на тестове с набор от функционалности от кутията: отдалечен достъп, регистрационни файлове, екранни снимки, видеозапис, различни браузъри и физически мобилни устройства. В много ситуации това може да бъде съществена шикозна алтернатива. Платформите за тестване са особено полезни за автоматизация на IOS, когато публичните облаци могат да предлагат само Linux/Windows системи. Но ние ще говорим за iOS в следващите статии. Препоръчвам винаги да разглеждате ситуацията и да започнете от задачите: в някои случаи е по-евтино и по-ефективно да използвате публични облаци, а в други тестовите платформи определено си заслужават похарчените пари.
Илюстрация на текущото състояние на инфраструктурата
Връзки за изследване
Подобни инструменти:
6. Оркестрация
Кратко описание на технологията
Имам добри новини – почти сме в края на статията! В момента нашата инфраструктура за автоматизация се състои от уеб и Android тестове, които провеждаме през GitLab CI паралелно, използвайки инструменти с активиран Docker: Selenium grid и Selenoid. Освен това ние използваме виртуални машини, създадени чрез GCP, за да хостваме контейнери с браузъри и емулатори. За да намалим разходите, ние стартираме тези виртуални машини само при поискване и ги спираме, когато не се извършва тестване. Има ли нещо друго, което може да подобри нашата инфраструктура? Отговорът е да! Запознайте се с Kubernetes (K8s)!
Първо, нека да разгледаме как думите оркестрация, клъстер и Kubernetes са свързани помежду си. На високо ниво оркестрацията е системата, която внедрява и управлява приложения. За автоматизация на тестовете, такива контейнеризирани приложения са Selenium grid и Selenoid. Docker и K8 се допълват взаимно. Първият се използва за внедряване на приложения, вторият за оркестрация. От своя страна K8s е клъстер. Задачата на клъстера е да използва виртуални машини като възли, което ви позволява да инсталирате различни функционалности, програми и услуги в рамките на един сървър (клъстер). Ако някой от възлите се повреди, други възли ще се задействат, което гарантира непрекъсната работа на нашето приложение. В допълнение към това, K8s има важна функционалност, свързана с мащабиране, благодарение на която автоматично получаваме оптималното количество ресурси въз основа на натоварването и зададените лимити.
Всъщност ръчното внедряване на Kubernetes от нулата изобщо не е тривиална задача. Ще оставя линк към известното ръководство с инструкции „Kubernetes The Hard Way“ и ако се интересувате, можете да го практикувате. Но, за щастие, има алтернативни методи и инструменти. Най-лесният начин е да използвате Google Kubernetes Engine (GKE) в GCP, което ще ви позволи да получите готов клъстер с няколко кликвания. Препоръчвам да използвате този подход, за да започнете да учите, тъй като ще ви позволи да се съсредоточите върху научаването как да използвате K8s за вашите задачи, вместо да учите как вътрешните компоненти трябва да бъдат интегрирани един с друг.
Стойност за инфраструктурата за автоматизация
Нека да разгледаме няколко важни функции, които K8s предоставя:
- внедряване на приложение: използване на клъстер с множество възли вместо виртуални машини;
- динамично мащабиране: намалява разходите за ресурси, които се използват само при поискване;
- самовъзстановяване: автоматично възстановяване на шушулките (в резултат на което контейнерите също се възстановяват);
- внедряване на актуализации и връщане назад на промени без прекъсване: актуализирането на инструменти, браузъри и емулатори не прекъсва работата на текущите потребители
Но K8s все още не е сребърен куршум. За да разберем всички предимства и ограничения в контекста на инструментите, които разглеждаме (Selenium grid, Selenoid), ще обсъдим накратко структурата на K8s. Клъстерът съдържа два типа възли: главни възли и работни възли. Главните възли отговарят за решенията за управление, внедряване и планиране. Работните възли са мястото, където се стартират приложенията. Възлите също съдържат среда за изпълнение на контейнер. В нашия случай това е Docker, който отговаря за операциите, свързани с контейнера. Но има и алтернативни решения, напр. Важно е да се разбере, че образуването на котлен камък или самовъзстановяването не се отнася директно за контейнерите. Това се осъществява чрез добавяне/намаляване на броя на контейнерите, които от своя страна съдържат контейнери (обикновено един контейнер на пакет, но в зависимост от задачата може да има повече). Йерархията на високо ниво се състои от работни възли, вътре в които има подове, вътре в които се повдигат контейнери.
Функцията за мащабиране е ключова и може да се приложи както към възли в клъстерен възел-пул, така и към подове в рамките на възел. Има 2 вида мащабиране, които се прилагат както за възли, така и за групи. Първият тип е хоризонтален - мащабирането става чрез увеличаване на броя на възлите/подовете. Този тип е по-предпочитан. Вторият тип е съответно вертикален. Мащабирането се извършва чрез увеличаване на размера на възлите/подовете, а не на техния брой.
Сега нека разгледаме нашите инструменти в контекста на горните термини.
Селенова решетка
Както споменахме по-рано, Selenium grid е много популярен инструмент и не е изненада, че е контейнеризиран. Следователно не е изненадващо, че мрежата Selenium може да бъде внедрена в K8s. Пример за това как да направите това може да бъде намерен в официалното хранилище на K8s. Както обикновено, прикачвам връзки в края на раздела. В допълнение ръководството с инструкции показва как да направите това в Terraform. Има също инструкции как да мащабирате броя на подовете, които съдържат контейнери на браузъра. Но функцията за автоматично мащабиране в контекста на K8s все още не е напълно очевидна задача. Когато започнах да уча, не намерих практически насоки или препоръки. След няколко проучвания и експерименти с подкрепата на екипа на DevOps, ние избрахме подхода за издигане на контейнери с необходимите браузъри в един под, който се намира в един работен възел. Този метод ни позволява да приложим стратегията за хоризонтално мащабиране на възлите чрез увеличаване на броя им. Надявам се, че това ще се промени в бъдеще и ще виждаме все повече описания на по-добри подходи и готови решения, особено след пускането на Selenium grid 4 с променена вътрешна архитектура.
Селеноид:
Внедряването на Selenoid в K8s в момента е най-голямото разочарование. Те не са съвместими. На теория можем да създадем Selenoid контейнер вътре в pod, но когато Selenoid започне да стартира контейнери с браузъри, те все още ще бъдат в същия pod. Това прави мащабирането невъзможно и в резултат на това работата на Selenoid вътре в клъстер няма да се различава от работата вътре във виртуална машина. Край на историята.
Луна:
Знаейки това тясно място при работа със Selenoid, разработчиците пуснаха по-мощен инструмент, наречен Moon. Този инструмент първоначално е проектиран да работи с Kubernetes и в резултат на това функцията за автоматично мащабиране може и трябва да се използва. Освен това бих казал, че в момента е така единственото инструмент в света на Selenium, който има вградена поддръжка на клъстер K8s от кутията (вече не е наличен, вижте следващия инструмент ). Основните характеристики на Moon, които осигуряват тази поддръжка, са:
Напълно без гражданство. Selenoid съхранява в паметта информация за текущите сесии на браузъра. Ако по някаква причина неговият процес се срине — всички работещи сесии се губят. Обратно, Moon няма вътрешно състояние и може да се копира в центрове за данни. Сесиите на браузъра остават живи, дори ако една или повече реплики отпаднат.
И така, Moon е чудесно решение, но има един проблем: не е безплатно. Цената зависи от броя сесии. Можете да провеждате само 0-4 сесии безплатно, което не е особено полезно. Но, започвайки от петата сесия, ще трябва да платите $5 за всяка. Ситуацията може да се различава в различните компании, но в нашия случай използването на Moon е безсмислено. Както описах по-горе, можем да стартираме виртуални машини със Selenium Grid при поискване или да увеличим броя на възлите в клъстера. За приблизително един тръбопровод стартираме 500 браузъра и спираме всички ресурси след приключване на тестовете. Ако използвахме Moon, ще трябва да плащаме допълнително 500 x 5 = $2500 на месец, без значение колко често провеждаме тестове. Отново, не казвам да не използвате Moon. За вашите задачи това може да бъде незаменимо решение, например, ако имате много проекти/екипи във вашата организация и имате нужда от огромен общ клъстер за всички. Както винаги, оставям връзка в края и препоръчвам да направите всички необходими изчисления в контекста на вашата задача.
Callisto: (внимание! Това не е в оригиналната статия и се съдържа само в руския превод)
Както казах, Selenium е много популярен инструмент и ИТ сферата се развива много бързо. Докато работех върху превода, в мрежата се появи нов обещаващ инструмент, наречен Callisto (здравей Cypress и други убийци на Selenium). Той работи естествено с K8s и ви позволява да стартирате Selenoid контейнери в подове, разпределени между възли. Всичко работи веднага след изваждането от кутията, включително автоматичното мащабиране. Фантастично, но трябва да се тества. Вече успях да разположа този инструмент и да проведа няколко експеримента. Но е твърде рано да се правят заключения, след получаване на резултати от голямо разстояние, може би ще направя преглед в бъдещи статии. Засега оставям само връзки за независими изследвания.
Илюстрация на текущото състояние на инфраструктурата
Връзки за изследване
Подобни инструменти
7. Инфраструктурата като код (IaC)
Кратко описание на технологията
И сега стигаме до последния раздел. Обикновено тази технология и свързаните с нея задачи не са отговорност на инженерите по автоматизация. И има причини за това. Първо, в много организации проблемите с инфраструктурата са под контрола на отдела DevOps и екипите за разработка всъщност не се интересуват от това какво кара тръбопровода да работи и как трябва да се поддържа всичко, свързано с него. Второ, нека бъдем честни, практиката на инфраструктурата като кодекс (IaC) все още не е възприета в много компании. Но определено се превърна в популярна тенденция и е важно да се опитаме да участваме в процесите, подходите и инструментите, свързани с нея. Или поне бъдете в течение.
Нека започнем с мотивацията за използването на този подход. Вече обсъдихме, че за да изпълняваме тестове в GitlabCI, ще ни трябват минимум ресурси за стартиране на Gitlab Runner. И за да стартираме контейнери с браузъри/емулатори, трябва да резервираме VM или клъстер. В допълнение към ресурсите за тестване, ние се нуждаем от значително количество капацитет за поддръжка на среди за разработка, етапи, производствени среди, което също включва бази данни, автоматични графици, мрежови конфигурации, балансьори на натоварването, потребителски права и т.н. Ключовият въпрос е необходимото усилие, за да се поддържа всичко това. Има няколко начина, по които можем да правим промени и да пускаме актуализации. Например, в контекста на GCP, можем да използваме UI конзолата в браузъра и да извършваме всички действия, като щракваме върху бутони. Алтернатива би била използването на API извиквания за взаимодействие с облачни обекти или използване на помощната програма за команден ред gcloud за извършване на желаните манипулации. Но с наистина голям брой различни обекти и инфраструктурни елементи става трудно или дори невъзможно да се извършват всички операции ръчно. Освен това всички тези ръчни действия са неконтролируеми. Не можем да ги изпратим за преглед преди изпълнение, да използваме система за контрол на версиите и бързо да върнем назад промените, довели до инцидента. За да решат подобни проблеми, инженерите създадоха и създават автоматични bash/shell скриптове, които не са много по-добри от предишните методи, тъй като не са толкова лесни за бързо четене, разбиране, поддържане и модифициране в процедурен стил.
В тази статия и ръководството как да използвам 2 инструмента, свързани с практиката на IaC. Това са Terraform и Ansible. Някои смятат, че няма смисъл да се използват едновременно, тъй като функционалността им е сходна и са взаимозаменяеми. Но факт е, че първоначално им се дават съвсем различни задачи. И фактът, че тези инструменти трябва да се допълват взаимно, беше потвърден на съвместна презентация от разработчици, представляващи HashiCorp и RedHat. Концептуалната разлика е, че Terraform е инструмент за осигуряване за управление на самите сървъри. Докато Ansible е инструмент за управление на конфигурацията, чиято задача е да инсталира, конфигурира и управлява софтуер на тези сървъри.
Друга ключова отличителна черта на тези инструменти е стилът на кодиране. За разлика от bash и Ansible, Terraform използва декларативен стил, базиран на описание на желаното крайно състояние, което трябва да бъде постигнато в резултат на изпълнение. Например, ако ще създадем 10 VM и приложим промените чрез Terraform, тогава ще получим 10 VM. Ако стартираме скрипта отново, нищо няма да се случи, тъй като вече имаме 10 виртуални машини и Terraform знае за това, защото съхранява текущото състояние на инфраструктурата във файл със състояние. Но Ansible използва процедурен подход и ако го помолите да създаде 10 VM, тогава при първото стартиране ще получим 10 VM, подобно на Terraform. Но след рестартиране вече ще имаме 20 VM. Това е важната разлика. В процедурен стил ние не съхраняваме текущото състояние и просто описваме последователност от стъпки, които трябва да бъдат изпълнени. Разбира се, можем да се справим с различни ситуации, да добавим няколко проверки за наличие на ресурси и текущо състояние, но няма смисъл да си губим времето и да влагаме усилия, за да контролираме тази логика. Освен това това увеличава риска от допускане на грешки.
Обобщавайки всичко по-горе, можем да заключим, че Terraform и декларативната нотация са по-подходящ инструмент за осигуряване на сървъри. Но е по-добре да делегирате работата по управление на конфигурацията на Ansible. Като приключим с това, нека да разгледаме случаите на употреба в контекста на автоматизацията.
Стойност за инфраструктурата за автоматизация
Единственото важно нещо, което трябва да разберете тук е, че инфраструктурата за автоматизация на тестовете трябва да се разглежда като част от цялата инфраструктура на компанията. Това означава, че всички IaC практики трябва да се прилагат глобално към ресурсите на цялата организация. Кой е отговорен за това зависи от вашите процеси. Екипът на DevOps е по-опитен в тези проблеми, те виждат цялата картина на случващото се. QA инженерите обаче са по-ангажирани в процеса на автоматизация на сградата и структурата на тръбопровода, което им позволява да видят по-добре всички необходими промени и възможности за подобрение. Най-добрият вариант е да работим заедно, да обменяме знания и идеи, за да постигнем очаквания резултат.
Ето няколко примера за използване на Terraform и Ansible в контекста на автоматизацията на тестовете и инструментите, които обсъдихме преди:
1. Опишете необходимите характеристики и параметри на виртуални машини и клъстери, използващи Terraform.
2. Използвайки Ansible, инсталирайте необходимите инструменти за тестване: docker, Selenoid, Selenium Grid и изтеглете необходимите версии на браузъри/емулатори.
3. Използвайки Terraform, опишете характеристиките на виртуалната машина, в която ще се стартира GitLab Runner.
4. Инсталирайте GitLab Runner и необходимите съпътстващи инструменти с помощта на Ansible, задайте настройки и конфигурации.
Илюстрация на текущото състояние на инфраструктурата
Връзки за изследване:
Подобни инструменти
Нека обобщим!
Стъпка
Технологии
Инструменти
Стойност за инфраструктурата за автоматизация
1
Локално бягане
Node.js, Selenium, Appium
- Най-популярните инструменти за уеб и мобилни устройства
- Поддържа много езици и платформи (включително Node.js)
2
Системи за контрол на версиите
отивам
- Подобни предимства с код за разработка
3
Контейнеризация
Docker, Selenium grid, Selenoid (уеб, Android)
- Паралелно провеждане на тестове
- Изолирани среди
- Прости, гъвкави надстройки на версията
- Динамично спиране на неизползваните ресурси
- Лесна за настройка
4
CI/CD
Gitlab CI
- Тества част от тръбопровода
- Бърза обратна връзка
- Видимост за цялата фирма/екип
5
Облачни платформи
Платформата Google Cloud
- Ресурси при поискване (плащаме само когато е необходимо)
- Лесен за управление и актуализиране
- Видимост и контрол на всички ресурси
6
Оркестровка
Kubernetes
В контекста на контейнери с браузъри/емулатори вътре в подове:
- Мащабиране/автоматично мащабиране
- Самолечение
- Актуализации и връщания назад без прекъсване
7
Инфраструктурата като код (IaC)
Terraform, Ansible
- Подобни ползи с инфраструктура за развитие
- Всички предимства на версията на кода
- Лесен за промени и поддръжка
- Напълно автоматизиран
Диаграми на мисловни карти: еволюция на инфраструктурата
стъпка 1: Локален
стъпка 2: VCS
стъпка 3: Контейнеризация
стъпка 4: CI/CD
стъпка 5: Облачни платформи
стъпка 6: Оркестрация
стъпка 7: IaC
Каква е следващата?
И така, това е краят на статията. Но в заключение бих искал да установя някои споразумения с вас.
От твоя страна
Както казах в началото, бих искал статията да има практическа полза и да ви помогне да приложите получените знания в реална работа. добавям отново.
Но дори и след това не спирайте, практикувайте, изучавайте подходящи връзки и книги, разберете как работи във вашата компания, намерете места, които могат да бъдат подобрени и участвайте в това. Късмет!
От моя страна
От заглавието се вижда, че това е само първата част. Въпреки факта, че се оказа доста голям, важни теми все още не са засегнати тук. Във втората част планирам да разгледам инфраструктурата за автоматизация в контекста на IOS. Поради ограниченията на Apple за стартиране на iOS симулатори само на macOS системи, нашата гама от решения е стеснена. Например не можем да използваме Docker за стартиране на симулатора или публични облаци за стартиране на виртуални машини. Но това не означава, че няма други алтернативи. Ще се опитам да ви държа в течение с модерни решения и модерни инструменти!
Освен това не съм споменавал доста големи теми, свързани с мониторинга. В част 3 ще разгледам най-популярните инструменти за наблюдение на инфраструктурата и какви данни и показатели да вземете предвид.
И накрая. В бъдеще планирам да пусна видео курс за изграждане на тестова инфраструктура и популярни инструменти. В момента има доста курсове и лекции за DevOps в Интернет, но всички материали са представени в контекста на разработката, а не на автоматизацията на тестовете. По този въпрос наистина се нуждая от обратна връзка дали такъв курс ще бъде интересен и полезен за общността от тестери и инженери по автоматизация. Благодаря ви предварително!
Източник: www.habr.com