Частина 1: Web / Android
Примітка: Ця стаття є перекладом на російську мову оригінальної статті Однак усі ілюстрації, посилання, цитати та терміни збережені мовою оригіналу, щоб уникнути спотворення сенсу під час перекладу російською мовою. Бажаю вам приємного вивчення!
В даний час спеціальність DevOps є однією з найбільш популярних в IT-індустрії. Якщо ви відкриєте популярні сайти з пошуку роботи та задасте фільтр із зарплат, то побачите, що вакансії, пов'язані з DevOps, знаходяться на початку списку. Однак важливо розуміти, що це в основному відноситься до позиції 'Senior', що передбачає, що кандидат має високий рівень навичок, знання технологій та інструментів. До цього також додається високий рівень відповідальності, пов'язаний з безперебійною роботою production. Однак ми почали забувати, що таке DevOps. Спочатку це не була якась конкретна людина чи департамент. Якщо пошукати визначення цього терміна, то ми знайдемо багато красивих і правильних іменників, таких як методологія, практики, культурна філософія, група концептів тощо.
Моя спеціалізація – інженер з автоматизації тестування (QA automation engineer), але я вважаю, що вона не повинна бути пов'язана лише з написанням авто-тестів або розробкою архітектури тестового framework. У 2020 році знання інфраструктури автоматизації також необхідні. Це дозволяє організувати процес автоматизації самостійно, починаючи від запуску тестів та закінчуючи наданням результатів усім зацікавленим особам відповідно до поставлених цілей. В результаті чого, навички DevOps є обов'язковим фактором для виконання цієї роботи. І все це добре, але, на жаль, є проблема (spoiler: дана стаття робить спроби спростити цю проблему). Вона полягає в тому, що DevOps це складно. І це очевидно, адже компанії не платитимуть багато за те, що легко зробити… У світі DevOps велика кількість інструментів, термінів, практик, які потрібно оволодіти. Особливо це важко дається на початку кар'єри та залежить від накопиченого технічного досвіду.
Джерело:
Тут ми, мабуть, завершимо з вступною частиною і сфокусуємося на цілі цієї статті.
Про що ця стаття
У цій статті я збираюся поділитись моїм досвідом побудови інфраструктури автоматизації тестування. В інтернеті можна знайти багато джерел інформації про різні інструменти і як їх використовувати, але я хотів би розглянути їх виключно в контексті автоматизації. Я вважаю, що багатьом інженерам з автоматизації знайома ситуація, коли розроблені тести, крім вас самих, ніхто не запускає і не піклується про їхню підтримку. Внаслідок чого тести стають застарілими і доводиться витрачати час на їхню актуалізацію. Знову ж таки на початку кар'єри це може бути досить складним завданням: грамотно вирішити, які інструменти повинні допомогти усунути цю проблему, як їх вибрати, налаштувати та підтримувати. Деякі тестувальники звертаються за допомогою до DevOps (людям) і, будемо чесними, такий підхід працює. У багатьох випадках це може бути єдиним варіантом, оскільки ми не маємо видимості всіх залежностей. Але, як ми знаємо, DevOps – дуже зайняті хлопці, адже вони повинні думати про інфраструктуру всієї компанії, deployment, моніторинг, мікросервіси та інші подібні завдання в залежності від організації/команди. Як це зазвичай буває, автоматизація перестав бути пріоритетом. У такому разі ми повинні спробувати зробити все можливе з нашого боку від початку до кінця. Це зменшить залежності, прискорить робочий процес, удосконалить наші навички та дозволить побачити ширшу картину того, що відбувається.
У статті представлені найпопулярніші та найпопулярніші інструменти та показано, як їх використовувати для покрокової побудови інфраструктури автоматизації. Кожна група представлена інструментами, перевіреними на особистому досвіді. Але це не означає, що ви повинні використовувати те саме. Самі інструменти не важливі, вони з'являються та старіють. Наше інженерне завдання – розуміння базових принципів: навіщо нам потрібна ця група інструментів та які робочі завдання ми можемо з їхньою допомогою вирішити. Тому наприкінці кожної секції я залишаю посилання на аналогічні інструменти, які, можливо, використовуються у вашій організації.
Чого у цій статті немає
Ще раз повторюю, що стаття не про конкретні інструменти, тому тут не буде вставок коду з документації та опису конкретних команд. Але наприкінці кожної секції я залишаю посилання на детальне вивчення.
Це зроблено через те, що:
- цей матеріал дуже легко знайти у різних джерелах (документація, книги, відео курси);
- якщо ми почнемо заглиблюватися, доведеться написати 10, 20, 30 частин цієї статті (тоді як у планах 2-3);
- я просто не хочу витрачати ваш час, тому що, можливо, ви хочете використовувати інші інструменти для досягнення тих же цілей.
Практика
Мені дуже хотілося б, щоб цей матеріал був корисний для кожного читача, а не просто був прочитаний і забутий. У будь-якому вивченні практика є дуже важливою складовою. Для цього я підготував. Також на вас чекає домашня робота, щоб бути впевненим, що ви бездумно не скопіювали рядки виконуваних команд
План
Крок
Технологія
Tools
1
Local running (prepare web / android demo tests and run it locally)
Node.js, Selenium, Appium
2
Version control systems
Git
3
Контейнерізація
Docker, Selenium grid, Selenoid (Web, Android)
4
CI/CD
Gitlab CI
5
Хмарні платформи
Google Cloud Platform
6
Оркестрація
Кубернетес
7
Infrastructure as a code (IaC)
Terraform, Ansible
Структура кожної секції
Для підтримки розповіді в наочному вигляді кожна секція описана за наступним планом:
- короткий опис технології,
- цінність для інфраструктури автоматизації,
- ілюстрація поточного стану інфраструктури,
- посилання для вивчення,
- аналогічні інструменти.
1. Локальний запуск тестів
Короткий опис технології
Це лише підготовчий крок для запуску демонстраційних тестів локально та для перевірки, що вони успішно проходять. У практичній частині використовується Node.js, але мова програмування та платформа також не важливі і можна використовувати ті, що використовуються у вашій компанії.
Однак як інструменти автоматизації я рекомендую використовувати Selenium WebDriver для web-платформ і 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, потрібно враховувати витрати на ліцензію. Ці фактори впливають на швидкість завантаження та ускладнюють переносимість.
І ось ми підійшли до контейнеризації. І знову дана технологія вирішила попередню проблему, оскільки контейнери не використовують повноцінну 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 in 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 for Web
Цей інструмент є проривом у світі Selenium, тому що він працює одразу з коробки і зробив життя багатьох інженерів з автоматизації значно простіше. Насамперед, це не чергова модифікація Selenium grid. Натомість розробники створили абсолютно нову версію Selenium Hub мовою Golang, що у зв'язці з легковажними Docker-образами для різних браузерів дало поштовх у розвитку автоматизації тестування. Більше того, у випадку Selenium Grid ми повинні визначити всі необхідні браузери та їх версії заздалегідь, що не є проблемою, коли робота йде лише з одним браузером. Але коли йдеться про декілька підтримуваних браузерів, то Selenoid – це рішення номер один завдяки функції 'браузер на вимогу'. Все, що нам потрібно, це заздалегідь вивантажити потрібні образи з браузерами і оновити файл конфігурації, з яким взаємодіє Selenoid. Після того, як Selenoid отримає запит від тестів, він автоматично запустить потрібний контейнер із потрібним браузером. Коли тест завершиться, Selenoid відставить контейнер, тим самим звільнивши ресурси для наступних запитів. Такий підхід повністю усуває відому проблему 'деградації вузлів', що часто зустрічаємо в Selenium grid.
Але, на жаль, Selenoid все ще не срібна куля. Ми отримали функцію 'браузер на вимогу', але функція 'ресурси на вимогу' все ще недоступна. Для використання Selenoid ми повинні розгорнути його на фізичному залізі або VM, що означає, що ми повинні заздалегідь знати, скільки ресурсів необхідно виділити. Я вважаю, що це не проблема для маленьких проектів, які запускають 10, 20 або навіть 30 браузерів паралельно. Але якщо нам потрібно 100, 500, 1000 і більше? Не має сенсу підтримувати і платити за таку кількість ресурсів постійно. У секціях 5 і 6 цієї статті ми обговоримо рішення, які дозволяють масштабуватись, тим самим значно знижуючи витрати компанії.
Selenoid for Android
Після успіху Selenoid як інструмент для web-автоматизації, люди хотіли отримати щось подібне для Android. І це відбулося - Selenoid був випущений за допомогою Android. З високорівневої точки зору користувача принцип роботи аналогічний web-автоматизації. Єдина відмінність полягає в тому, що замість контейнерів із браузерами Selenoid запускає контейнери з Android-емуляторами. На мій погляд, на сьогодні це найпотужніший безкоштовний інструмент для запуску Android-тестів паралельно.
Мені дуже не хотілося б говорити про негативні сторони даного інструменту, оскільки він дійсно мені дуже подобається. Але все ж таки тут присутні ті ж недоліки, що відносяться і до web-автоматизації, пов'язані з масштабуванням. На додаток до цього потрібно розповісти про ще одне обмеження, яке може стати несподіванкою, якщо ми налаштовуємо інструмент уперше. Для запуску Android-образів нам потрібна фізична машина або VM з nested virtualisation - підтримкою. У практичному посібнику я демонструю, як це активувати на Linux VM. Однак, якщо ви є macOS користувачем і хочете розгорнути Selenoid локально, то для запуску Android-тестів це буде неможливо. Але ви завжди можете запустити Linux VM локально з налаштованою 'nested virtualisation' і розгорнути Selenoid всередині.
Ілюстрація поточного стану інфраструктури
У контексті цієї статті ми додамо два інструменти для ілюстрації інфраструктури. Це Selenium grid для web-тестів та Selenoid для Android-тестів. У посібнику GitHub я також покажу, як використовувати Selenoid для запуску web-тестів.
Посилання для вивчення
Аналогічні інструменти
- Існують інші інструменти контейнеризації, але Docker – найпопулярніший. Якщо ви хочете спробувати ще щось, то врахуйте, що ті інструменти, які ми розглянули для паралельного запуску Selenium-тестів, не будуть працювати з коробки.
- Як було сказано, існує багато модифікацій Selenium grid, наприклад,.
4. CI/CD
Короткий опис технології
Практика безперервної інтеграції досить популярна в розробці і стоїть в одному ряду із системами контролю версій. Не зважаючи на це, я відчуваю, що існує плутанина у термінології. У цьому параграфі я хотів би описати 3 модифікації даної технології з моєї точки зору. В інтернеті ви зможете знайти багато статей з різними інтерпретаціями, і це абсолютно нормально, якщо ваша думка відрізнятиметься. Найголовніше, щоб ви були на одній хвилі з вашими колегами.
Отже, існують 3 терміни: CI - Continuous Integration (безперервна інтеграція), CD - Continuous Delivery (безперервне постачання) і знову CD - Continuous Deployment (безперервне розгортання). (Далі я використовуватиму ці терміни англійською мовою). Кожна модифікація додає кілька додаткових етапів до конвеєра розробки. Але слово безперервний (Безперервна) є найголовнішим. У цьому контексті ми маємо на увазі щось, що відбувається від початку до кінця, без переривань або ручного впливу. Давайте подивимося на CI & CD та CD в даному контексті.
- Continuous Integration – це початковий крок еволюції. Після надсилання нового коду на сервер, ми очікуємо отримати швидкий зворотний зв'язок, що з нашими змінами все гаразд. Зазвичай CI включає запуск інструментів статичного аналізу коду та модульні/внутрішні API тести Це дозволяє отримувати інформацію про наш код вже кілька секунд/хв.
- Безперервна доставка є просунутим кроком, на якому ми запускаємо інтеграційні/UI-тести. Однак на даному етапі ми не отримуємо результатів так само швидко, як у випадку з CI. По-перше, ці типи тестів потребують більше часу для проходження. По-друге, перед запуском ми маємо розгорнути наші зміни на test/staging – середовищі. Більше того, якщо ми говоримо про мобільну розробку, то з'являється додатковий етап для створення складання нашої програми.
- Постійне розгортання передбачає, що ми автоматично випускаємо (release) наші зміни на production, якщо всі приймальні тести пройшли попередніх етапах. На додаток до цього після етапу release можна налаштувати різні етапи, такі як запуск smoke - тестів на production і збір метрик, що цікавлять. Continuous Deployment можливе лише при хорошому покритті автоматизованими тестами. Якщо потрібні якісь ручні втручання, у тому числі й тестування, то це більше не безперервна (Безперервне). Тоді ми можемо говорити, що наш конвеєр відповідає лише практиці Continuous Delivery.
Цінність для інфраструктури автоматизації
У цьому розділі я повинен уточнити, що коли ми говоримо про end-to-end UI-тестів, це передбачає, що ми повинні розгортати наші зміни та пов'язані сервіси на тестових середовищах. Continuous Integration - процес не застосовний для даної задачі і ми повинні подбати про впровадження як мінімум Continuous Deliver практик. Continuous Deployment також має сенс у контексті UI-тестів, якщо ми збираємось запускати їх на production.
І перед тим, як ми подивимося на ілюстрацію зміни архітектури, я хочу сказати кілька слів про GitLab CI. На відміну від інших CI/CD-інструментів, GitLab надає віддалений репозиторій та багато інших додаткових функцій. Таким чином, GitLab – це більше, ніж CI. Він включає з коробки управління вихідним кодом, Agile управління, CI/CD pipelines, інструменти логування та збори метрик. Архітектура GitLab складається з Gitlab CI/CD та GitLab Runner. Наводжу короткий опис з офіційного сайту:
Gitlab CI/CD є веб-пристосуванням з API, що його держадреси держадреси в database, management projects/builds and provides a user interface. GitLab Runner is application which processes builds. Це може бути розроблений окремо і роботи з GitLab CI/CD через API. Для tests running you need both Gitlab instance and Runner.
Ілюстрація поточного стану інфраструктури
Посилання для вивчення
Аналогічні інструменти
- І багато інших
5. Хмарні платформи
Короткий опис технології
У цьому розділі ми поговоримо про популярний тренд, який називається 'публічні хмари'. Незважаючи на величезну користь, яку дають описані вище технології віртуалізації та контейнеризації, нам все ще потрібні обчислювальні ресурси. Компанії купують дорогі сервери або орендують дата-центри, але в такому разі необхідно зробити розрахунки (іноді нереалістичні) того, як багато ресурсів нам знадобиться, чи будемо їх використовувати 24/7 і для яких цілей. Наприклад, для production потрібен працюючий цілодобово сервер, але чи потрібні нам аналогічні ресурси для тестування у неробочий час? Це також залежить від типу тестування, що виконується. Прикладом можуть бути навантажувальні/стресові тести, які ми плануємо проганяти в неробочий годинник, щоб отримати результати наступного дня. Але, безперечно, цілодобова доступність серверів не потрібна для end-to-end авто-тестів і особливо для середовищ ручного тестування. Для таких ситуацій було б добре отримувати стільки ресурсів, скільки потрібно на вимогу, використовувати їх і припиняти платити, коли вони більше не потрібні. Більше того, було б чудово отримувати їх миттєво, зробивши кілька кліків мишкою або запустивши пару скриптів. Для цього використовуються публічні хмари. Давайте подивимося на визначення:
«Суспільство cloud is defined as computing services offered by third-party providers over public Internet, показуючи їх доступні до будь-яких, хто намагається використати або купити їх. Вони можуть бути вільними або виконані віртуальними, заощаджуючими клієнтами тільки плата за використання для CPU cycles, storage, або bandwidth they consume».
Існує думка, що публічні хмари – це дорого. Але їхня ключова ідея – зменшення витрат компанії. Як було згадано раніше, публічні хмари дозволяють отримати ресурси на вимогу та платити лише за час їх використання. Також іноді ми забуваємо, що співробітники отримують зарплату, а фахівці теж є дорогим ресурсом. Необхідно враховувати, що публічні хмари значно полегшують підтримку інфраструктури, що дозволяє інженерам сфокусуватися на найважливіших завданнях.
Цінність для інфраструктури автоматизації
Які ресурси нам необхідні для 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 web-тестів та 8 Android-тестів. Для цього ми будемо використовувати GCP і запустимо 2 віртуальні машини із Selenoid. На першій ми піднімемо 8 контейнерів із браузерами. На другий – 8 контейнерів із емуляторами. Давайте подивимося на ціни:
Для запуску одного контейнера з Chrome нам знадобиться n1-стандарт-1 авто. У випадку з Android це буде n1-стандарт-4 для одного емулятора. Насправді більш гнучкий і дешевий спосіб – це завдання конкретних значень користувача для CPU/Memory, але в даний момент для порівняння з Sauce Labs це не принципово.
А ось тарифи на використання Sauce Labs:
Я вважаю, ви вже помітили різницю, але все ж таки наведу таблицю з розрахунками для нашого завдання:
Необхідні ресурси
Щомісяця
Робочі години(8 am - 8 pm)
Робочі години+ Preemptible
GCP for Web
n1-standard-1 x 8 = n1-standard-8
$194.18
23 days * 12h * 0.38 = 104.88$
23 days * 12h * 0.08 = 22.08$
Sauce Labs for Web
Virtual Cloud8 parallel tests
$1.559
-
-
GCP for Android
n1-standard-4 x 8: n1-standard-16
$776.72
23 days * 12h * 1.52 = 419.52$
23 days * 12h * 0.32 = 88.32$
Sauce Labs for Android
Real Device Cloud 8 parallel tests
$1.999
-
-
Як видно, різниця у вартості величезна, особливо якщо запускати тести лише у робочий дванадцятигодинний проміжок. Але можна ще сильніше скоротити витрати, якщо використати преemptible машини. Що це таке?
A preemptible VM is instance, що ви можете створити і керувати в величезній вартості, що існують певні умови. However, Compute Engine короткий термін (переempt) ці instances if it requires access to thos resources for other tasks. Перехідні умови є розповсюдження комп'ютерної техніки здібності, з їх наявністю варіації з використанням.
Якщо ваші пристосування є форс-толерантом і можуть бутипідтримані встановлення клопоту, будуть сприятливі умови можуть зменшити ваші Compute Engine costs significantly. Для прикладу, batch processing jobs can run on preemptible instances. Якщо деякі з цих положень terminate під час процесу, роботою зменшуються, але не повністю стоп. Перехідні умови розраховують ваші batch processing tasks без placing additional workload on your existing instances and with requiring you to all full price for additional normal instances.
І це досі не кінець! Насправді, я впевнений, що ніхто не запускає тести по 12 годин без перерви. І якщо це так, то ви можете автоматично запускати та зупиняти віртуальні машини, коли вони не потрібні. Реальний час використання може знизитись до 6 годин на добу. Тоді оплата у контексті нашого завдання зменшиться аж до 11$ на місяць за 8 браузерів. Хіба це не чудово? Але з preemptible машин ми повинні бути обережні і готові до переривань і нестабільної роботи, хоча ці ситуації можуть бути передбачені та оброблені програмно. Воно того варте!
Але ні в якому разі я не говорю 'ніколи не використовуйте хмарні тестові ферми'. Вони мають низку переваг. Насамперед це не просто віртуальна машина, а повноцінне рішення для автоматизації тестування з набором функціоналу із коробки: віддалений доступ, логи, скріншоти, відеозапис, різні браузери та фізичні мобільні пристрої. У багатьох ситуаціях це може бути незамінною розкішною альтернативою. Особливо тестові платформи корисні для IOS-автоматизації, коли публічні хмари можуть запропонувати лише Linux/Windows-системи. Але розмова про IOS буде у наступних статтях. Я рекомендую завжди дивитися по ситуації і відштовхуватися від завдань: у якихось дешевше та ефективніше використовувати публічні хмари, а в якихось тестових платформах безумовно коштують витрачені гроші.
Ілюстрація поточного стану інфраструктури
Посилання для вивчення
Аналогічні інструменти:
6. Оркестрація
Короткий опис технології
У мене добрі новини – ми майже досягли кінця статті! На даний момент наша інфраструктура автоматизації складається з web та Android-тестів, які ми запускаємо через GitLab CI паралельно, використовуючи інструменти з підтримкою Docker: Selenium grid та Selenoid. Більш того, ми використовуємо створені через GCP віртуальні машини для підняття в них контейнерів із браузерами та емуляторами. Для зменшення витрат ми запускаємо цим віртуальні машини лише на вимогу та зупиняємо, коли тестування не проводиться. Чи існує ще щось, що може покращити нашу інфраструктуру? Відповідь – так! Зустрічаємо Kubernetes (K8s)!
Спочатку розглянемо, як слова оркестрація, кластер і Kubernetes пов'язані між собою. На високому рівні оркестрація – це система, яка розгортає та керує додатками. Для автоматизації тестування такими додатками, що контейнерізуються (containerised), є Selenium grid і Selenoid. Docker та K8s доповнюють один одного. Перший використовується для розгортання програм, другий – для оркестрації. У свою чергу, K8s є кластером. Завдання кластера використовувати VM як Nodes, що дозволяє встановлювати різний функціонал, програми та сервіси в рамках одного сервера (кластера). Якщо якийсь із Node впаде, то підхопляться інші Nodes, що забезпечує нашому додатку безперебійну роботу. На додаток до цього K8s має важливу функціональність, пов'язану з масштабуванням (scaling), завдяки чому ми автоматично отримуємо оптимальну кількість ресурсів, ґрунтуючись на навантаженні та встановлених обмеженнях.
Правду кажучи, ручне розгортання Kubernetes з нуля є зовсім нетривіальним завданням. Я залишу посилання на відоме практичне керівництво Kubernetes The Hard Way, і, якщо вам цікаво, ви можете попрактикуватися. Але, на щастя, існують альтернативні способи та інструменти. Найлегший з них – використовувати Google Kubernetes Engine (GKE) у GCP, що дозволить отримати готовий кластер після кількох кліків. Для початку вивчення я рекомендую використовувати саме цей підхід, тому що він дозволить вам сфокусуватися на вивченні того, як використовувати K8s для своїх завдань замість дослідження того, як внутрішні компоненти повинні бути інтегровані між собою.
Цінність для інфраструктури автоматизації
Розглянемо кілька важливих функцій, які надає K8s:
- розгортання програми: використання multi-nodes кластера, замість VMs;
- динамічне масштабування: зменшує витрати на ресурси, які використовуються лише на вимогу;
- самовідновлення (Self-healing): автоматичне відновлення pods (внаслідок чого відновлюються контейнери);
- викочування оновлення та відкатів змін без простою: оновлення інструментів, браузерів та емуляторів не перериває роботу поточних користувачів
Але K8s - все ще не срібна куля. Для розуміння всіх переваг та обмежень у контексті аналізованих нами інструментів (Selenium grid, Selenoid) коротко обговоримо будову K8s. Cluster містить два типи Nodes: Master Nodes та Workers Nodes. Master Nodes відповідають за управління, розгортання та scheduling decisions. Workers nodes – це те, де програми запущені. Nodes також містять середовище запуску контейнерів. У нашому випадку це Docker, який відповідає за операції, пов'язані із контейнерами. Але є й альтернативні рішення, наприклад. Важливо розуміти, що масштабування чи самовідновлення не належить безпосередньо до контейнерів. Це реалізується через додавання/зменшення числа pods, які у свою чергу містять контейнери (зазвичай один container на 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. Такий спосіб дозволяє нам застосувати стратегію горизонтального масштабування за рахунок збільшення їх числа. Я сподіваюся, що в майбутньому ситуація зміниться, і ми побачимо все більше і більше описів найкращих підходів та готових рішень, особливо після випуску Selenium grid 4 із зміненою внутрішньою архітектурою.
Селеноїд:
В даний час розгортання Selenoid у K8s є найбільшим розчаруванням. Вони не сумісні. Теоретично ми можемо підняти Selenoid-контейнер всередині pod, але коли Selenoid почне запускати контейнери з браузерами, вони все ще будуть перебувати всередині цього ж під. Це робить scaling неможливим і, як результат, робота Selenoid всередині кластера не відрізнятиметься від роботи всередині віртуальної машини. Кінець історії.
Moon:
Знаючи це вузьке місце при роботі з Selenoid, розробники випустили потужніший інструмент, який назвали Moon. Цей інструмент був задуманий для роботи з Kubernetes і, як результат, можна і потрібно використовувати функцію автомасштабування. Більше того, я сказав би, що зараз це єдиний інструмент у світі Selenium, який з коробки має native K8s cluster-підтримку (вже ні, див. наступний інструмент ). Ключовою особливістю Moon, яка забезпечує цю підтримку, є:
Completely stateless. Selenoid stores in memory information o currently running browser sessions. If for some reason its process crashes — then all running sessions are lost. Moon contrarily has no internal state and can be replicated across data centers. Browser sessions remain alive even if one or more replicas go down.
Отже, Moon шикарне рішення, але з однією проблемою він не безкоштовний. Ціна залежить від кількості сесій. Безкоштовно можна запустити лише 0-4 сесії, що не дуже корисно. Але, починаючи вже із п'ятої сесії, доведеться заплатити по 5$ за кожну. Ситуація може відрізнятись від компанії до компанії, але в нашому випадку використання Moon безглуздо. Як я описував вище, ми можемо запустити VM з Selenium Grid на вимогу або збільшити число Nodes в кластері. Приблизно на один pipeline ми запускаємо 500 браузерів та зупиняємо всі ресурси після завершення тестів. Якби ми використовували Moon, нам довелося б заплатити додаткових 500 x 5 = 2500 $ на місяць і не важливо, як часто ми запускаємо тести. І знову ж таки, я не кажу «не використовуйте Moon». Для ваших завдань це може бути незамінним рішенням, наприклад, якщо у вас в організації багато проектів/команд і вам потрібний величезний кластер для всіх. Як завжди, я залишаю посилання наприкінці та рекомендую зробити всі необхідні розрахунки в контексті вашого завдання.
Каллісто: (Увага! Цього немає в оригінальній статті і міститься лише у російському перекладі)
Як я й сказав, Selenium – дуже популярний інструмент, а сфера ІТ розвивається дуже швидко. Поки я працював над перекладом, у мережі з'явився новий багатообіцяючий інструмент Callisto (привіт Cypress та іншим вбивцям Selenium). Він працює нативно з K8s і дозволяє запускати Selenoid-контейнери в pods, розподілений по Nodes. Все працює відразу з коробки, включаючи автомасштабування. Фантастика, але треба випробувати. Мені вже вдалося розгорнути цей інструмент і поставити кілька експериментів. Але висновки робити рано після отримання результатів на довгій дистанції, можливо, я зроблю огляд у наступних статтях. Поки що залишаю лише посилання для самостійних досліджень.
Ілюстрація поточного стану інфраструктури
Посилання для вивчення
Аналогічні інструменти
7. Інфраструктура як код (IaC)
Короткий опис технології
І ось ми підібралися до останнього розділу. Зазвичай, дана технологія та пов'язані з нею завдання не входять до зони відповідальності інженерів з автоматизації. І на це є причини. По-перше, у багатьох організаціях інфраструктурні питання перебувають під контролем DevOps відділу і команди розробки не надто дбають про те, завдяки чому працює pipeline і як потрібно підтримувати все, що з ним пов'язано. По-друге, будемо чесними, практика Інфраструктура як код (IaC) все ще не застосовується в багатьох компаніях. Але безперечно це стало популярним трендом і важливо намагатися бути залученим у пов'язані з цим процеси, підходи та інструменти. Або принаймні бути в курсі подій.
Почнемо з мотивації використання цього підходу. Ми вже обговорили, що для запуску тестів у GitlabCI нам знадобляться як мінімум ресурси для запуску Gitlab Runner. А для запуску контейнерів із браузерами/емуляторами нам потрібно зарезервувати VM або кластер. Крім ресурсів для тестування, нам потрібна значна кількість потужностей для підтримки середовищ розробки, staging, production, що також включає бази даних, автоматичні розклади, конфігурації мережі, балансувальник навантаження, права користувачів тощо. Ключова проблема полягає у необхідних зусиллях для підтримки цього всього. Є кілька способів того, як ми можемо вносити зміни та викочувати оновлення. Наприклад, у контексті GCP ми можемо використовувати UI-консоль у браузері та виконувати всі дії, натискаючи кнопки. Альтернативним способом може бути використання API-дзвінків для взаємодії з хмарними сутностями або застосування утиліти командного терміну gcloud для виконання потрібних маніпуляцій. Але при дійсно великій кількості різних сутностей та інфраструктурних елементів стає важко чи навіть неможливо виконувати всі операції вручну. Більше того, всі ці ручні дії є неконтрольованими. Ми не можемо надіслати їх на review перед виконанням, використовувати систему контролю версій та швидко відкотити правки, які призвели до інциденту. Для вирішення таких проблем інженери створювали і створюють автоматичні 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-інженери сильніше залучені до процесу побудови автоматизації та структури pipeline, що дозволяє їм краще бачити всі необхідні зміни та можливості для покращення. Найкращий варіант – це працювати спільно, обмінюватися знаннями та ідеями для досягнення очікуваного результату.
Наведу кілька прикладів використання Terraform та Ansible у контексті автоматизації тестування та інструментів, які ми обговорювали до цього:
1. Описати через Terraform необхідні характеристики та параметри VMs та кластерів.
2. Встановити за допомогою Ansible необхідні для тестування інструменти: docker, Selenoid, Selenium Grid та завантажити потрібні версії браузерів/емуляторів.
3. Описати через Terraform характеристики VM, де буде запущений GitLab Runner.
4. Встановити за допомогою Ansible GitLab Runner та необхідні супутні інструменти, встановити налаштування та конфігурації.
Ілюстрація поточного стану інфраструктури
Посилання для вивчення:
Аналогічні інструменти
Підведемо підсумки!
Крок
Технологія
Tools
Цінність для інфраструктури автоматизації
1
Місцевий біг
Node.js, Selenium, Appium
- Найбільш популярні інструменти для web та mobile
- Підтримка багатьох мов та платформ (включаючи Node.js)
2
Version control systems
Git
- Аналогічні переваги з кодом розробки
3
Контейнерізація
Docker, Selenium grid, Selenoid (Web, Android)
- Паралельний запуск тестів
- Ізольовані середовища
- Просте, гнучке оновлення версій
- Динамічна зупинка ресурсів, що не використовуються.
- легко налаштувати
4
CI/CD
Gitlab CI
- Тести частина конвеєра
- Швидкий зворотний зв'язок
- Видимість для всієї компанії / команди
5
Хмарні платформи
Google Cloud Platform
- Ресурси на вимогу (платимо тільки коли потрібні)
- Легко керувати та оновлювати
- Видимість та контроль усіх ресурсів
6
Оркестрація
Кубернетес
У контексті контейнерів із браузерами/емуляторами всередині pods:
- Масштабування / автомасштабування
- самовідновлення
- Оновлення та відкати без переривань
7
Infrastructure as a code (IaC)
Terraform, Ansible
- Аналогічні переваги з інфраструктурою розробки
- Усі переваги версіонування коду
- Легко вносити зміни та підтримувати
- Повністю автоматизовано
Mind map діаграми: еволюція інфраструктури
step1: Local
step2: VCS
step3: Containerisation
step4: CI/CD
step5: Cloud Platforms
step6: Orchestration
step7: IaC
Що далі?
Тож це кінець статті. Але на завершення я хотів би встановити з вами деякі домовленості.
З вашого боку
Як було сказано спочатку, я хотів би, щоб стаття несла практичну користь і допомогла вам застосувати отримані знання в реальній роботі. Додаю ще раз.
Але навіть після цього не зупиняйтесь, практикуйтеся, вивчайте відповідні посилання та книжки, дізнавайтеся, як це працює у вас у компанії, знаходите місця, які можна покращити та беріть у цьому участь. Успіхів!
З мого боку
Із заголовка видно, що це була лише перша частина. Незважаючи на те, що вона вийшла досить великою, тут досі не розкрито важливих тем. У другій частині я планую розглянути інфраструктуру автоматизації у контексті IOS. Через обмеження Apple, пов'язані з запусками IOS симуляторів тільки на macOS системах, наш набір рішень звужений. Наприклад, ми не маємо можливості використовувати Docker для запуску симулятора або публічних хмар для запуску віртуальних машин. Але це не означає, що немає інших альтернатив. Я постараюся тримати вас у курсі передових рішень та сучасних інструментів!
Також я не згадав чималих тем, пов'язаних з моніторингом. У частині 3 я збираюся розглянути найбільш популярні інструменти для моніторингу інфраструктури, а також які дані та метрики варто взяти до уваги.
І на останок. У майбутньому я планую випустити відео курс із побудови тестової інфраструктури та популярних інструментів. В даний час в інтернеті досить багато курсів та лекцій з DevOps, але всі матеріали представлені в контексті розробки, але не автоматизації тестування. У цьому питанні мені дуже потрібний зворотний зв'язок, чи такий курс буде цікавим і цінним для спільноти тестувальників і автоматизаторів. Заздалегідь дякую!
Джерело: habr.com