Част 1: Web / Android
Забележка: тази статия е превод на оригиналната статия Обаче, всички илюстрации, линкове, цитати и термини са запазени на оригиналния език, за да се избегне изкривяване на смисъла при превода на руски. Пожелавам ви приятно изучаване!
В момента специалността DevOps е една от най-търсените в IT индустрията. Ако отворите популярни сайтове за търсене на работа и зададете филтър по заплати, ще видите, че обявите, свързани с DevOps, са в началото на списъка. Важно е обаче да разберете, че това основно се отнася до позицията 'Senior', което означава, че кандидатът разполага с високо ниво на умения, знания за технологии и инструменти. Към това също се добавя висока степен на отговорност, свързана с безпроблемната работа на продукция. Но ние започваме да забравяме какво точно е DevOps. Първоначално не ставаше въпрос за конкретен човек или отдел. Ако потърсите определения на този термин, ще откриете много красиви и правилни съществителни, като методология, практики, културна философия, група концепти и така нататък.
Моята специализация е инженер по автоматизация на тестове (QA automation engineer), но смятам, че тя не трябва да бъде свързана само с написването на авто-тестове или разработването на архитектура на тестов framework. През 2020 година знанията за инфраструктура за автоматизация също са необходими. Това позволява да организирате процеса на автоматизация самостоятелно, започвайки от стартирането на тестовете и завършвайки с предоставянето на резултатите на всички заинтересовани лица в съответствие с поставените цели. В резултат на което уменията на DevOps са задължителен фактор за изпълнението на тази работа. И всичко това е добре, но за съжаление има проблем (спойлер: тази статия се опитва да опрости този проблем). Той се състои в това, че DevOps е сложно. И това е очевидно, защото компаниите няма да плащат много за нещо, което може да се направи лесно... В света на DevOps има множество инструменти, термини, практики, които трябва да усвоите. Особено е трудно в началото на кариерата и зависи от натрупания технически опит.
Източник:
Тук, предполагам, ще завършим с вводната част и ще се фокусираме върху целта на тази статия.
За какво става въпрос в тази статия
В тази статия ще споделя моя опит в изграждането на инфраструктура за автоматизирано тестване. В интернет може да се намери много информация относно различни инструменти и как да ги използваме, но бих искал да ги разгледам изцяло в контекста на автоматизацията. Смятам, че много инженери по автоматизация са запознати със ситуацията, в която разработените тестове не се стартират и не се поддържат от никого освен от вас. В резултат на това тестовете стават остарели и се налага да се похарчва време за тяхното актуализиране. В началото на кариерата си това може да бъде доста предизвикателна задача: да се определи какви инструменти трябва да помогнат за решаването на този проблем, как да ги изберем, настроим и поддържаме. Някои тестери търсят помощ от DevOps (хора), и да бъдем честни, този подход работи. В много случаи това може да бъде единственият вариант, тъй като нямаме представа за всички зависимости. Но, както знаем, DevOps са много заети, тъй като трябва да се грижат за инфраструктурата на цялата компания, разгръщането, мониторинга, микросервисите и други подобни задачи в зависимост от организацията/екипа. Както често се случва, автоматизацията не е приоритет. В такъв случай трябва да се опитаме да направим всичко възможно от наша страна, от начало до край. Това ще намали зависимостите, ще ускори работния процес, ще усъвършенства уменията ни и ще позволи да видим по-широката картина на случващото се.
В статията са представени най-търсените и популярни инструменти и как да ги използваме за стъпка по стъпка изграждане на инфраструктура за автоматизация. Всяка група е представена с инструменти, които са проверени на личен опит. Но това не означава, че трябва да използвате същото. Самите инструменти не са важни, те се появяват и остаряват. Наша инженерна задача е да разберем основните принципи: защо ни е нужна тази група инструменти и какви работни задачи можем да решим с тяхна помощ. Затова в края на всяка секция оставям връзки към подобни инструменти, които евентуално се използват във вашата организация.
Какво липсва в тази статия
Отново ще повторя, че статията не е за конкретни инструменти, затова тук няма да има кодови вставки от документацията и описание на конкретни команди. Но в края на всяка секция оставям линкове за дълбочинно изучаване.
Това е направено по причина, че:
- този материал е много лесен за намиране в различни източници (документация, книги, видео курсове);
- ако започнем да се задълбочаваме, ще трябва да напишем 10, 20, 30 части от тази статия (докато плановете са 2-3);
- просто не искам да губя времето ви, тъй като, възможно е, да искате да използвате други инструменти за постигане на същите цели.
Практика
Бих искал много, този материал да бъде полезен за всеки читател, а не просто да бъде прочетен и забравен. В всяко изучаване практиката е много важен компонент. Затова подготвих. Също така ви очаква домашна работа, за да бъдете сигурни, че не сте копирали наизуст редовете с изпълнявани команди.
План
Стъпка
Технология
Инструменти
1
Локален запуск (подготовка на уеб / андроид демонстрационни тестове и тяхното локално изпълнение)
Node.js, Selenium, Appium
2
Системи за контрол на версиите
Git
3
Контейнеризация
Docker, Selenium grid, Selenoid (Web, Android)
4
CI / CD
Gitlab CI
5
Облачни платформи
Google Cloud Platform
6
Оркестрация
Kubernetes
7
Инфраструктура като код (IaC)
Terraform, Ansible
Структура на всяка секция
За поддържане на повествованието в ясна форма, всяка секция е описана по следния план:
- кратко описание на технологията,
- стойността за автоматизация на инфраструктурата,
- илюстрация на текущото състояние на инфраструктурата,
- линкове за изучаване,
- аналогични инструменти.
1. Локален запуск на тестове
Кратко описание на технологията
Това е просто подготвителна стъпка за локално запускане на демонстрационни тестове и проверка, че те преминават успешно. В практическата част се използва Node.js, но езикът за програмиране и платформата също не са важни и може да използвате тези, които се използват във вашата компания.
Обаче, както инструменти за автоматизация, препоръчвам да използвате Selenium WebDriver за уеб платформи и Appium за Android платформи, тъй като в следващите стъпки ще използваме Docker образи, които са специално оптимизирани за работа с тези инструменти. Освен това, като се опираме на изискванията в обявите за работа, тези инструменти са най-търсени на пазара.
Както може да забележите, разглеждаме само web и Android тестовете. За съжаление, iOS е съвсем различна история (благодарение на Apple). Планирам да демонстрирам решения и практики, свързани с iOS, в следващите части.
Стойност за инфраструктурата на автоматизация
От гледна точка на инфраструктурата, локалното стартиране не носи никаква стойност. Просто проверявате дали тестовете работят на локалната машина в локалните браузъри и емулатори. Но каквото и да е, това е необходима отправна точка.
Илюстрация на текущото състояние на инфраструктурата
Линкове за проучване
Подобни инструменти
- всеки език за програмиране, който предпочитате, в комбинация с Selenium/Appium – тестовете;
- всички тестове;
- всякакъв тестов изпълнител.
2. Системи за контрол на версии (Git)
Кратко описание на технологията
За никого няма да е голямо откритие, ако кажа, че системата за контрол на версии е изключително важна част от разработката както в екип, така и индивидуално. Основавайки се на различни източници, можем с увереност да кажем, че Git е най-популярният представител. Системата за контрол на версии предлага много предимства, като обмен на код, съхранение на версии, възстановяване на предишни клонове, проследяване на историята на проекта, резервни копия. Няма да обсъждаме всеки аспект в детайли, тъй като съм сигурен, че сте добре запознати и я използвате в ежедневната си работа. Но ако случайно не сте, препоръчвам да спрете четенето на тази статия и да наваксате този пропуск възможно най-скоро.
Стойност за инфраструктурата на автоматизация
И тук можете да зададете резонен въпрос: «Защо той ни разказва за Git? Всички знаят и използват, както за разработката на код, така и за кодовете за автоматични тестове». Ще сте абсолютно прави, но в тази статия говорим за инфраструктура и тази секция играе роля на предварителен преглед за секция 7: «Инфраструктура като код (IaC)». За нас, това означава, че цялата инфраструктура, включително тестовата, се описва под формата на код, съответно можем да приложим системи за версии и да получим подобни предимства, както за кода за разработка, така и за автоматизация.
Ще разгледаме IaC по-подробно на стъпка 7, но дори сега можете да започнете да използвате Git локално, като създадете локално хранилище. Общата картина ще се разшири, когато добавим към инфраструктурата отдалечено хранилище.
Илюстрация на текущото състояние на инфраструктурата
Линкове за проучване
Подобни инструменти
3. Контейнеризация (Docker)
Кратко описание на технологията
За да демонстрираме как контейнизацията промени играта, нека се върнем няколко десетилетия назад. По онова време хората закупуваха и използваха сървърни машини за стартиране на приложения. Но в повечето случаи необходимите ресурси за стартиране не бяха известни предварително. В резултат на което компаниите харчеха пари за закупуване на скъпи мощни сървъри, но част от тези мощности не се използваха напълно.
Следващият етап в еволюцията бяха виртуалните машини (VM), които решиха проблема с харченето на средства за неизползвани ресурси. Тази технология позволи стартирането на приложения независимо едно от друго в рамките на един сървър, предоставяйки напълно изолирано пространство. Но, за съжаление, всяка технология има своите недостатъци. Стартирането на VM изисква полноценна операционна система, която консумира CPU, RAM, хранилище и, в зависимост от OS, трябва да се вземат предвид разходите за лиценз. Тези фактори влияят на скоростта на зареждане и усложняват преносимостта.
И така, стигнахме до контейнеризацията. Отново тази технология реши предишния проблем, тъй като контейнерите не използват полноценна операционна система, което позволява освобождаването на голямо количество ресурси и предоставя бързо и гъвкаво решение за преносимост.
Разбира се, технологията за контейнеризация не е нещо ново и бе представена за първи път в края на 70-те години. В тези времена бяха проведени много изследвания, разработки и опити. Но именно Docker адаптира тази технология и я направи леснодостъпна за масите. В наши дни, когато говорим за контейнери, в повечето случаи имаме предвид Docker. Когато говорим за Docker контейнери, ние подразбираме Linux контейнери. Можем да използваме Windows и macOS системи за стартиране на контейнери, но е важно да разберем, че в такъв случай се появява допълнителен слой. Например, Docker на Mac незабелязано стартира контейнери в рамките на лековесна Linux VM. Ще се върнем на тази тема, когато обсъждаме стартирането на Android емулатори в контейнери, тъй като тук се появява много важен нюанс, който трябва да разгледаме по-подробно.
Стойност за инфраструктурата на автоматизация
Разбрахме, че контейнеризацията и Docker – са страхотни. Нека да го разгледаме в контекста на автоматизацията, тъй като всеки инструмент или технология трябва да решава някакъв проблем. Да обозначим очевидните проблеми на автоматизацията на тестовете в контекста на UI тестовете:
- огромно количество зависимости при инсталирането на Selenium и по-специално на Appium;
- проблеми с съвместимостта между версиите на браузърите, симулаторите и драйверите;
- липса на изолирано пространство за браузъри/симулатори, което е особено критично за паралелно стартиране;
- трудно е да се управлява и поддържа, ако трябва да стартирате 10, 50, 100 или дори 1000 браузъра едновременно.
Но тъй като Selenium е най-популярният инструмент за автоматизация, а Docker – е най-популярният инструмент за контейнеризация, не трябва да учудва никого, че някой е опитал да ги съчетае, за да получи мощен инструмент за решаване на по-горе споменатите проблеми. Нека разгледаме тези решения по-подробно.
Selenium grid в docker
Този инструмент е най-популярният в света Selenium за стартиране на множество браузъри на множество машини и управление на тях от централен възел. За стартиране е необходимо да регистрирате поне 2 части: Hub и Node(s). Hub е централният възел, който получава всички заявки от тестовете и ги разпределя по съответните Nodes. За всеки Node можем да настроим конкретна конфигурация, например, като зададем нужния браузър и неговата версия. Въпреки това все пак трябва сами да се погрижим за съвместимите драйвери за браузърите и да ги инсталираме на нужните Nodes. Поради тази причина Selenium grid не се използва в своята чиста форма, освен в случаите, когато трябва да работим с браузъри, които не могат да се инсталират на Linux OS. За всички останали случаи значително гъвкаво и правилно решение ще бъде използването на Docker образи за стартиране на Selenium grid Hub и Nodes. Този подход улеснява управлението на възлите, тъй като можем да изберем желания от нас образ с вече инсталирани съвместими версии на браузърите и драйверите.
Въпреки негативните отзиви относно стабилността на работа, особено при стартиране на голям брой Nodes паралелно, Selenium grid все още остава най-популярният инструмент за паралелно стартиране на Selenium тестове. Важно е да се отбележи, че в open-source постоянно излизат различни доработки и модификации на този инструмент, които се борят с различните тясни места.
Selenoid за Web
Този инструмент е пробив в света на Selenium, тъй като работи директно от кутията и улесни значително живота на много автоматизационни инженери. Първо и най-важно, това не е просто модификация на Selenium grid. Вместо това, разработчиците създадоха изцяло нова версия на Selenium Hub на езика Go, което в комбинация с леките Docker образи за различни браузъри дало тласък в развитието на автоматизацията на тестовете. Освен това, при Selenium Grid трябва да определим предварително всички необходими браузъри и техните версии, което не е проблем, когато работим само с един браузър. Но когато става въпрос за множество поддържани браузъри, Selenoid е номер едно решение, благодарение на функцията „браузър по заявка“. Всичко, което трябва да направим, е предварително да изтеглим необходимите образи с браузъри и да актуализираме конфигурационния файл, с който взаимодейства Selenoid. След като Selenoid получи запитване от тестовете, той автоматично стартира необходимия контейнер с желания браузър. Когато тестът приключи, Selenoid спира контейнера, освобождавайки ресурси за следващите запитвания. Такъв подход напълно елиминира известната проблема с „деградация на възлите“, която често срещаме в Selenium grid.
Но, за съжаление, Selenoid все още не е сребърна куршуми. Получихме функцията „браузър по заявка“, но функцията „ресурси по заявка“ все още не е налична. За да използваме Selenoid, трябва да го разположим на физическо устройство или на VM, което означава, че трябва предварително да знаем колко ресурси трябва да бъдат разпределени. Смятам, че това не е проблем за малки проекти, които стартират 10, 20 или дори 30 браузъра паралелно. Но какво, ако трябва 100, 500, 1000 и повече? Няма смисъл да поддържаме и плащаме за толкова много ресурси постоянно. В секции 5 и 6 от тази статия ще обсъдим решения, които позволяват мащабиране, значително намалявайки разходите на компанията.
Selenoid за 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 — Continuous Integration (непрекъсната интеграция), CD — Continuous Delivery (непрекъсната доставка) и отново CD — Continuous Deployment (непрекъснато разгръщане). (По-нататък ще използвам тези термини на английски език). Всяка модификация добавя няколко допълнителни етапа към вашия конвейер за разработка. Но думата continuous (непрекъснато) е най-важната. В този контекст имаме предвид нещо, което се случва от начало до край, без прекъсвания или ръчно влияние. Нека да разгледаме CI & CD и CD в този контекст.
- Непрекъсната интеграция – е началната стъпка на еволюцията. След като новият код бъде изпратен на сървъра, очакваме бърза обратна връзка, че с нашите промени всичко е наред. Обикновено CI включва стартиране на инструменти за статичен анализ на кода и модулни/вътрешни API тестове. Това позволява получаване на информация за нашия код вече след няколко секунди/минути.
- Continuous Delivery е по-усъвършенстван етап, при който стартираме интеграционни/UI тестове. Въпреки това, в този етап не получаваме резултати толкова бързо, колкото в случая с CI. Първо, тези типове тестове изискват повече време за преминаване. Второ, преди да стартираме, трябва да разгръщаме нашите промени в тестова/стейджинг среда. Освен това, ако говорим за мобилна разработка, се добавя допълнителен етап за създаване на версия на нашето приложение.
- Непрекъснато разгръщане предполагае, че ние автоматично издаваме (release) нашите изменения на производствена среда, ако всички приемни тестове са преминали на предходните етапи. В допълнение, след етапа на издаване можем да настроим различни етапи, като стартиране на smoke тестове на производствена среда и събиране на интересуващи метрики. Continuous Deployment е възможен само при добро покритие с автоматизирани тестове. Ако са необходими ръчни намеси, включително и тестове, то това вече не е Непрекъснато (непрекъснато). Тогава можем да кажем, че нашият конвейер отговаря само на практиката на Continuous Delivery.
Стойност за инфраструктурата на автоматизация
В този раздел трябва да уточня, че когато говорим за end-to-end UI тестове, това означава, че трябва да разгръщаме нашите изменения и свързаните услуги в тестови среди. Continuous Integration е процес, който не е приложим за тази задача и трябва да се погрижим да внедрим поне практиките на Continuous Delivery. Continuous Deployment също има смисъл в контекста на 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 и за какви цели. Например, за производствени нужди е необходим работещ 24/7 сървър, но нуждаем ли се от подобни ресурси за тестове извън работно време? Това зависи и от типа изпълнявани тестове. Пример за такова може да бъде натоварващото/стрес тестове, които планираме да проведем извън работното време, за да получим резултатите на следващия ден. Но, определено, не е необходима 24/7 наличност на сървъри за end-to-end автоматизирани тестове и особено за среда за ръчно тестване. За такива ситуации би било добре да получим толкова ресурси, колкото е нужно на поискване, да ги използваме и да спрем плащанията, когато вече не са нужни. Още повече, би било чудесно да ги получаваме моментално, с няколко клика на мишката или като стартираме няколко скрипта. Именно за това се използват публичните облаци. Нека погледнем определението:
«Публичният облак е определен като изчислителни услуги, предлагани от доставчици на трети страни през публичния интернет, като ги правят достъпни за всеки, който желае да ги използва или закупи. Те могат да бъдат безплатни или продавани при поискване, позволявайки на клиентите да плащат само за извършената употреба на CPU цикли, съхранение или честотна лента, които консумират».
Съществува мнение, че публичните облаци са скъпи. Но основната им идея е намаляване на разходите за компанията. Както беше споменато по-рано, публичните облаци позволяват да получим ресурси при поискване и да платим само за времето на тяхното използване. Също така, понякога забравяме, че служителите получават заплати, а специалистите също са скъп ресурс. Необходимо е да се има предвид, че публичните облаци значително облекчават поддръжката на инфраструктурата, което позволява на инженерите да се фокусират върху по-важни задачи.
Стойност за инфраструктурата на автоматизация
Какви точно ресурси са ни необходими за end-to-end UI тестове? Основно, това са виртуални машини или клъстери (ще говорим за Kubernetes в следващия раздел) за стартиране на браузъри и емулатори. Колкото повече браузъри и емулатори искаме да стартираме едновременно, толкова повече CPU и памет са необходими и толкова повече средства ще трябва да платим. По този начин, публичните облаци в контекста на автоматизацията на тестове ни позволяват да стартираме голям брой (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-standard-1 машина. В случая с Android, това ще бъде n1-standard-4 за един емулатор. Всъщност, по-гъвкав и по-евтин начин – е да зададем конкретни потребителски стойности за CPU/Памет, но в момента за сравнение с Sauce Labs това не е принципно.
А ето тарифите за използване на Sauce Labs:
Предполагам, вече сте забелязали разликата, но все пак ще представя таблица с изчисления за нашата задача:
Необходими ресурси
Месечно
Работни часове(8 ч. - 20 ч.)
Работни часове+ Преемптивен
GCP за Уеб
n1-standard-1 x 8 = n1-standard-8
$194.18
23 дни * 12ч * 0.38 = 104.88$
23 дни * 12ч * 0.08 = 22.08$
Sauce Labs за веб
Виртуални Cloud8 паралелни тестове
$1.559
—
—
GCP за Android
n1-standard-4 x 8: n1-standard-16
$776.72
23 дни * 12ч * 1.52 = 419.52$
23 дни * 12ч * 0.32 = 88.32$
Sauce Labs за Android
Клауд на реални устройства 8 паралелни теста
$1.999
—
—
Както виждате, разликата в цената е огромна, особено ако стартирате тестове само в работния 12-часов интервал. Но можете да намалите разходите още повече, ако използвате preemptible машини. Какво е това?
Preemptible VM е инстанция, която можете да създадете и стартирате на много по-ниска цена от нормалните инстанции. Въпреки това, Compute Engine може да прекрати (preempt) тези инстанции, ако се нуждае от достъп до тези ресурси за други задачи. Preemptible инстанциите са излишен капацитет на Compute Engine, така че наличността им варира с употребата.
Ако вашите приложения са устойчиви на неизправности и могат да издържат на възможни прекратявания на инстанции, то preemptible инстанциите могат значително да намалят вашите разходи за Compute Engine. Например, задачи за пакетна обработка могат да се изпълняват на preemptible инстанции. Ако някои от тези инстанции се прекратят по време на обработката, работата забавя, но не спира напълно. Preemptible инстанциите завършват задачите ви за пакетна обработка, без да натоварват допълнително съществуващите инстанции и без да е необходимо да плащате пълна цена за допълнителни нормални инстанции.
И това все още не е краят! В действителност, съм сигурен, че никой не стартира тестове в продължение на 12 часа без прекъсване. И ако е така, можете автоматично да стартирате и спирате виртуални машини, когато не са необходими. Реалното време на използване може да намалее до 6 часа на ден. В този случай плащането в контекста на нашата задача ще спадне до 11$ на месец за 8 браузъра. Чудесно, нали? Но с preemptible машини трябва да бъдем внимателни и да се подготвим за прекъсвания и нестабилна работа, въпреки че тези ситуации могат да бъдат предвидени и обработени програмно. Струва си!
Но по никакъв начин не казвам 'никога не използвайте облачни тестови ферми'. Те имат редица предимства. Първо, това не е просто виртуална машина, а пълноценно решение за автоматизация на тестове с функционалност 'от кутията': дистанционен достъп, логове, скрийншоти, видеозаписи, различни браузъри и физически мобилни устройства. В много ситуации това може да бъде незаменима алтернатива. Особено тестовите платформи са полезни за IOS-автоматизация, когато публичните облаци предлагат само Linux/Windows системи. Но разговорът за IOS ще бъде в следващите статии. Препоръчвам винаги да се гледа по ситуацията и да се вземат предвид задачите: в някои случаи е по-евтино и ефективно да се използват публични облаци, а в други тестовите платформи определено си заслужават парите.
Илюстрация на текущото състояние на инфраструктурата
Линкове за проучване
Аналогични инструменти:
6. Оркестрация
Кратко описание на технологията
Имам добри новини – почти достигнахме края на статията! В момента нашата инфраструктура за автоматизация се състои от уеб и Android тестове, които пускаме чрез GitLab CI паралелно, използвайки инструменти с поддръжка на Docker: Selenium grid и Selenoid. Освен това, използваме виртуални машини, създадени чрез GCP, за стартиране на контейнери с браузъри и емулатори. За да намалим разходите, пускаме тези виртуални машини само при нужда и ги спираме, когато не се провеждат тестове. Има ли нещо друго, което може да подобри нашата инфраструктура? Отговорът е – да! Поздравете Kubernetes (K8s)!
Първо, нека разгледаме как думите оркестрация, клъстер и Kubernetes са свързани помежду си. На високо ниво оркестрацията е система, която разгръща и управлява приложения. За автоматизация на тестовете такова контейнеризирано приложение е Selenium grid и Selenoid. Docker и K8s се допълват. Първият се използва за разгръщане на приложения, вторият – за оркестрация. От своя страна K8s е клъстер. Задачата на клъстера е да използва виртуални машини (VM) като Nodes, което позволява инсталиране на различен функционал, програми и услуги в рамките на един сървър (клъстер). Ако някой от Nodes падне, другите Nodes поемат отговорността, осигурявайки безпроблемна работа на нашето приложение. В допълнение, K8s разполага с важна функционалност, свързана със скалиране (scaling), благодарение на което автоматично получаваме оптимален брой ресурси, основани на натоварването и зададените ограничения.
Всъщност, ръчното разгръщане на Kubernetes от нулата е съвсем не тривиална задача. Ще оставя връзка към известното ръководство "Kubernetes The Hard Way", и ако ви е интересно, можете да упражнявате. Но, за щастие, съществуват алтернативни методи и инструменти. Най-лесният от тях е да се използва Google Kubernetes Engine (GKE) в GCP, което ще ви позволи да получите работещ кластер след няколко кликвания. За начало на изучаване, препоръчвам точно този подход, тъй като той ще ви позволи да се фокусирате върху изучаването на начина, по който да използвате K8s за вашите задачи, вместо да проучвате как вътрешните компоненти трябва да бъдат интегрирани помежду си.
Стойност за инфраструктурата на автоматизация
Нека разгледаме няколко важни функции, които предлага K8s:
- разгръщане на приложения: използване на многонодови клъстери, вместо ВМ;
- динамично мащабиране: намалява разходите за ресурси, които се използват само при необходимост;
- самовъзстановяване (Self-healing): автоматично възстановяване на pods (в резултат на което се възстановяват и контейнерите);
- разгърнате актуализации и връщания на промени без престой: актуализирането на инструменти, браузъри и емулатори не прекъсва работата на текущите потребители.
Но K8s все още не е сребърна куршума. За да разберем всички предимства и ограничения в контекста на разглежданите от нас инструменти (Selenium grid, Selenoid), накратко ще обсъдим структурата на K8s. Клъстерът съдържа два типа Nodes: Master Nodes и Workers Nodes. Master Nodes отговарят за управлението, разгръщането и решенията за планиране. Workers nodes са там, където приложенията се изпълняват. Nodes също съдържат среда за изпълнение на контейнери. В нашия случай това е Docker, който отговаря за операциите, свързани с контейнерите. Но има и алтернативни решения, например. Важно е да разберете, че мащабирането или самовъзстановяването не се отнася директно до контейнерите. Това се реализира чрез добавяне/намаляване на броя на pods, които от своя страна съдържат контейнери (обикновено един контейнер на pod, но в зависимост от задачата може да има и повече). Високото ниво на йерархия представлява worker nodes, вътре в които се намират pods, вътре в които са повдигнати контейнерите.
Функцията за мащабиране е ключова и може да бъде приложена както към nodes в cluster node-pool, така и към pods в node. Съществуват два типа мащабиране, които се отнасят както до nodes, така и до pods. Първият тип - хоризонтален - мащабирането става чрез увеличаване на броя на nodes/pods. Този тип е по-предпочитан. Вторият тип, съответно, е вертикален. Мащабирането се извършва чрез увеличаване на размерите на nodes/pods, а не на техния брой.
Сега да разгледаме нашите инструменти в контекста на споменатите термини.
Selenium grid
Както беше споменато по-рано, Selenium grid е много популярен инструмент, и не е изненада, че той е контейнеризиран (containerised). Следователно, не е учудващо, че Selenium grid може да бъде разположен в K8s. Пример за това как да стане може да се намери в официалното K8s хранилище. Както обикновено, прикрепям линкове в края на секцията. В допълнение, в практическото ръководство се показва как да се направи това с Terraform. Има и инструкция как да се мащабира броят на pods, съдържащи контейнери с браузъри. Но функционалността за автоматично мащабиране в контекста на K8s все още не е напълно ясна задача. Когато започнах да изучавам, не намерих никакво практическо ръководство или препоръки. След няколко изследвания и експерименти с помощта на DevOps екипа, ние избрахме подход за стартиране на контейнери с нужните браузъри вътре в един pod, който е в рамките на един worker node. Този метод ни позволява да приложим стратегия за хоризонтално мащабиране на nodes чрез увеличаване на техния брой. Надявам се в бъдеще ситуацията да се промени и да видим все повече описания на най-добрите подходи и готови решения, особено след пускането на Selenium grid 4 с изменена вътрешна архитектура.
Selenoid:
В момента разполагането на Selenoid в K8s е най-голямото разочарование. Те не са съвместими. Теоретично можем да стартираме Selenoid контейнер вътре в pod, но когато Selenoid започне да стартира контейнери с браузъри, те все още ще бъдат в рамките на същия pod. Това прави мащабирането невъзможно и, в резултат, работата на Selenoid вътре в кластера няма да се различава от работата вътре в виртуална машина. Край на историята.
Moon:
Зная за узкото място при работа с Selenoid, разработчиците издадоха по-мощен инструмент, който нарекоха Moon. Този инструмент първоначално беше проектиран за работа с Kubernetes и, като резултат, може и трябва да се използва функцията за автоматично мащабиране. Още повече, бих казал, че в момента това е единственото инструментът в света на Selenium, който от кутията има native K8s cluster поддръжка (вече няма, вижте следващия инструмент ). Ключовата особеност на Moon, която осигурява тази поддръжка, е:
Напълно безсъстояние. Selenoid съхранява в паметта информация за текущо работещите сесии на браузъра. Ако по някаква причина процесът му се срине - всички текущи сесии се губят. Moon напротив няма вътрешно състояние и може да бъде репликиран в центрове за данни. Сесиите на браузъра остават активни дори ако един или повече реплики паднат.
И така, Moon е страхотно решение, но с един проблем, той не е безплатен. Цената зависи от броя на сесиите. Безплатно можете да стартирате само 0-4 сесии, което не е особено полезно. Но, започвайки от петата сесия, ще трябва да платите по 5$ за всяка. Ситуацията може да се различава от фирма на фирма, но в нашия случай използването на Moon е безсмислено. Както описах по-горе, можем да стартираме VMs с Selenium Grid по искане или да увеличим броя на Nodes в кластера. Приблизително на един pipeline стартираме 500 браузъра и спираме всички ресурси след завършване на тестовете. Ако бяхме използвали Moon, щяхме да трябва да платим допълнителни 500 x 5 = 2500 $ на месец и няма значение колко често стартираме тестовете. И отново, не казвам "не използвайте Moon". За вашите задачи това може да бъде незаменимо решение, например, ако в организацията имате много проекти/екипи и ви трябва огромен общ кластер за всички. Както винаги, оставям линк в края и препоръчвам да направите всички необходими изчисления в контекста на задачата си.
Callisto: (Внимание! Това не е в оригиналната статия и се съдържа само в българския превод)
Както споменах, Selenium е много популярен инструмент, а сфера ИТ се развива бързо. Докато работих по превода, в мрежата се появи нова обещаваща工具 Callisto (здравейте Cypress и другите убиец на Selenium). Той работи нативно с K8s и позволява стартиране на Selenoid контейнери в pods, разпределено по Nodes. Всичко работи веднага от кутията, включително автоматично мащабиране. Фантастика, но трябва да се тества. Успях да разположа този инструмент и да проведа няколко експеримента. Но все още е рано за изводи, след получаване на резултати на дълга дистанция, вероятно ще направя преглед в следващите статии. В момента оставям само линкове за самостоятелно проучване.
Илюстрация на текущото състояние на инфраструктурата
Линкове за проучване
Линкове за проучване
Подобни инструменти
7. Инфраструктура като код (IaC)
Кратко описание на технологията
И така стигаме до последната секция. Обикновено, тази технология и свързаните с нея задачи не попадат в областта на отговорност на инженери по автоматизация. И за това има свои причини. Първо, в много организации инфраструктурните въпроси са под контрола на DevOps отдела и екипите за разработка не се обаждат много за това, какво прави pipeline и как трябва да поддържат всичко, свързано с него. Второ, да бъдем честни, практиката „Инфраструктура като код (IaC)“ все още не се прилага в много компании. Но определено стана популярен тренд и е важно да се стремим да бъдем включени в свързаните с това процеси, подходи и инструменти. Или поне да бъдем в течение на събитията.
Нека започнем с мотивацията за използването на този подход. Вече обсъдихме, че за да стартираме тестове в GitlabCI, ще ни трябват минимум ресурси за стартиране на Gitlab Runner. А за да стартираме контейнери с браузъри/емулатори, трябва да резервираме VM или клъстер. Освен ресурсите за тестване, ни е нужно значително количество мощности за поддържане на средите за разработка, стейджинг, продукция, което включва и бази данни, автоматични графици, мрежови конфигурации, балансировка на натоварването, права на потребителите и т.н. Ключовият проблем е в необходимите усилия за поддържане на всичко това. Има няколко начина, по които можем да правим промени и да разпределяме актуализации. Например, в контекста на GCP можем да използваме UI конзолата в браузъра и да извършваме всички действия, кликайки бутони. Алтернативен начин може да бъде използването на API заявки за взаимодействие с облачните единици или прилагането на командния инструмент gcloud за извършване на необходимите манипулации. Но при наистина голямо количество различни единици и инфраструктурни елементи става трудно или дори невъзможно да извършваме всички операции ръчно. Освен това, всички тези ръчни действия не са контролируеми. Не можем да ги изпратим на преглед преди изпълнението, да използваме система за контрол на версиите и бързо да отменим корекции, довели до инцидент. За решаване на такива проблеми инженери създавали и създават автоматизирани bash/shell скриптове, което не е много по-добро от предишните методи, тъй като не е особено лесно бързо да се прочетат, разберат, поддържат и модифицират в процедурен стил.
В тази статия и практическия наръчник ще използвам 2 инструмента, свързани с IaC практиката. Те са Terraform и Ansible. Някои считат, че няма смисъл да ги използваме едновременно, тъй като функционалността им е сходна и те са взаимозаменяеми. Но работата е там, че първоначално пред тях се поставят напълно различни задачи. И фактът, че тези инструменти трябва да се допълват, беше потвърден по време на съвместната презентация на разработчиците от HashiCorp и RedHat. Концептуалната разлика е, че Terraform е инструмент за provisioning, който управлява самите сървъри. Докато Ansible е инструмент за управление на конфигурации, чиято задача е инсталирането, настройването и управлението на софтуера на тези сървъри.
Още една ключова отличителна черта на тези инструменти е стилът на писане на кода. За разлика от bash и Ansible, Terraform използва декларативен стил, основан на описание на желаното крайно състояние, което трябва да се постигне в резултат на изпълнението. Например, ако планираме да създадем 10 VMs и да приложим промените чрез Terraform, ще получим 10 VMs. Ако приложим скрипта отново, нищо няма да се случи, тъй като вече имаме 10 VMs, и Terraform знае това, тъй като съхранява текущото състояние на инфраструктурата в state-файл. От друга страна, Ansible използва процедурен подход и, ако го помолим да създаде 10 VMs, то при първото изпълнение ще получим 10 VMs, подобно на Terraform. Но след повторното изпълнение ще имаме 20 VMs. В това се състои важната разлика. В процедурния стил не съхраняваме текущото състояние, а просто описваме последователността от стъпки, които трябва да бъдат изпълнени. Разбира се, можем да обработим различни ситуации, да добавим някои проверки за съществуването на ресурси и текущото състояние, но няма смисъл да губим времето си и да полагаме усилия за контрол върху тази логика. Освен това, това увеличава риска от грешки.
Обобщавайки всичко казано, можем да заключим, че за provisioning на сървъри по-подходящият инструмент е Terraform и декларативната нотация. А работата по управление на конфигурациите е по-добре да се делегира на Ansible. Разбирайки това, нека погледнем примери за употреба в контекста на автоматизацията.
Стойност за инфраструктурата на автоматизация
Тук е важно да се разбере, че инфраструктурата за автоматизиране на тестовете трябва да се разглежда като част от цялата инфраструктура на компанията. Това означава, че всички практики за IaC трябва да се прилагат глобално към ресурсите на цялата организация. Кой е отговорен за това, зависи от вашите процеси. Екипът DevOps е по-опитен в тези въпроси и вижда цялата картина на случващото се. Въпреки това, QA инженерите са по-силно ангажирани в процеса на изграждане на автоматизация и структурата на потока, което им позволява да виждат по-добре всички необходими промени и възможности за подобрение. Най-добрият вариант е да работите заедно, да обменяте знания и идеи за постигане на очаквания резултат.
Нека дам няколко примера за използването на Terraform и Ansible в контекста на автоматизацията на тестовете и инструментите, които обсъждахме преди това:
1. Да опишем чрез Terraform необходимите характеристики и параметри на ВМ и клъстери.
2. Да инсталираме с помощта на Ansible необходимите за тестовете инструменти: docker, Selenoid, Selenium Grid и да заредим нужните версии на браузъри/емулации.
3. Да опишем чрез Terraform характеристиките на ВМ, в която ще бъде стартиран GitLab Runner.
4. Да инсталираме с помощта на Ansible GitLab Runner и необходимите съпътстващи инструменти, да зададем настройки и конфигурации.
Илюстрация на текущото състояние на инфраструктурата
Линкове за проучване:
Подобни инструменти
Нека обобщим!
Стъпка
Технология
Инструменти
Стойност за инфраструктурата на автоматизация
1
Локално изпълнение
Node.js, Selenium, Appium
- Най-популярните инструменти за уеб и мобилни приложения
- Поддръжка на много езици и платформи (включително Node.js)
2
Системи за контрол на версиите
Git
- Аналогични предимства с кода на разработка
3
Контейнеризация
Docker, Selenium grid, Selenoid (Web, Android)
- Паралелно изпълнение на тестовете
- Изолирани среди
- Лесно, гъвкаво обновление на версиите
- Динамично спиране на неизползваните ресурси
- Лесно за настройка
4
CI / CD
Gitlab CI
- Тестовете са част от конвейера
- Бърза обратна връзка
- Видимост за цялата компания/екип
5
Облачни платформи
Google Cloud Platform
- Ресурси при поискване (плащаме само когато са нужни)
- Лесно управление и обновяване
- Видимост и контрол на всички ресурси
6
Оркестрация
Kubernetes
В контекста на контейнери с браузъри/емулации в pods:
- Мащабируемост/авто-мащабируемост
- Самовъзстановяване
- Обновления и връщания без прекъсвания
7
Инфраструктура като код (IaC)
Terraform, Ansible
- Аналогични предимства с инфраструктурата за разработка
- Всички предимства на версионирането на кода
- Лесно извършване на промени и поддръжка
- Напълно автоматизирано
Ментални карти: еволюция на инфраструктурата
стъпка 1: Локално
стъпка 2: VCS
стъпка 3: Контейнеризация
стъпка 4: CI/CD
стъпка 5: Облачни платформи
стъпка 6: Оркестрация
стъпка 7: IaC
Какво следва?
И така, тук свършва статията. Но в заключение искам да установя някои договорености с вас.
От ваша страна
Както беше споменато в началото, бих искал статията да носи практическа полза и да ви помогне да приложите усвоените знания в реалната работа. Повтарям.
Но дори и след това не спирайте, практикувайте, изучавайте свързаните линкове и книги, научете как работи това във вашата компания, търсете места за подобрение и участвайте в тях. Успех!
От моя страна
От заглавието е видно, че това беше само първата част. Въпреки че стана доста дълга, все още не са разгледани важни теми. Във втората част планирам да разгледам инфраструктурата за автоматизация в контекста на IOS. Поради ограниченията на Apple, свързани с пускането на IOS симулатори само на macOS системи, нашият набор от решения е стеснен. Например, нямаме възможността да използваме Docker за стартиране на симулатора или публични облаци за стартиране на виртуални машини. Но това не значи, че няма други алтернативи. Ще се постарая да ви информирам за най-съвременните решения и инструменти!
Също така не споменах доста значителни теми, свързани с мониторинга. В част 3 планирам да разгледам най-популярните инструменти за мониторинг на инфраструктурата, както и какви данни и метрики трябва да вземем предвид.
И накрая. В бъдеще планирам да издам видео курс за изграждане на тестова инфраструктура и популярни инструменти. В момента в интернет има много курсове и лекции по DevOps, но всички материали са представени в контекста на разработка, а не автоматизация на тестове. В това отношение ми е много нужна обратна връзка, дали такъв курс би бил интересен и ценен за общността на тестерите и автоматизаторите. Благодаря предварително!
Източник: habr.com
