Часть 1: Web / Android
Operacja: ten artykuł jest tłumaczeniem oryginalnego artykułu na język rosyjski Jednakże wszystkie ilustracje, linki, cytaty i terminy zachowano w języku oryginalnym, aby uniknąć zniekształcenia znaczenia po przetłumaczeniu na język rosyjski. Życzę miłej nauki!
Obecnie specjalność DevOps jest jedną z najbardziej poszukiwanych w branży IT. Jeśli otworzysz popularne strony z ofertami pracy i przefiltrujesz według wynagrodzenia, zobaczysz, że oferty pracy związane z DevOps znajdują się na górze listy. Należy jednak pamiętać, że odnosi się to głównie do stanowiska „starszego”, co oznacza, że kandydat posiada wysoki poziom umiejętności, wiedzy na temat technologii i narzędzi. Wiąże się to również z dużą odpowiedzialnością związaną z nieprzerwanym funkcjonowaniem produkcji. Zaczęliśmy jednak zapominać, czym jest DevOps. Początkowo nie była to żadna konkretna osoba ani dział. Jeśli będziemy szukać definicji tego terminu, znajdziemy wiele pięknych i poprawnych rzeczowników, takich jak metodologia, praktyki, filozofia kultury, grupa pojęć i tak dalej.
Moją specjalizacją jest inżynier automatyzacji testów (inżynier automatyzacji QA), jednak uważam, że nie należy jej kojarzyć wyłącznie z pisaniem autotestów czy tworzeniem architektury frameworka testowego. W 2020 roku niezbędna będzie także znajomość infrastruktury automatyki. Dzięki temu możesz samodzielnie zorganizować proces automatyzacji, od przeprowadzenia testów po dostarczenie wyników wszystkim interesariuszom zgodnie z Twoimi celami. W rezultacie umiejętności DevOps są niezbędne do wykonania zadania. I wszystko to dobrze, ale niestety jest problem (spoiler: w tym artykule podjęto próbę uproszczenia tego problemu). Rzecz w tym, że DevOps jest trudny. I to jest oczywiste, bo firmy nie zapłacą dużo za coś, co jest łatwe do zrobienia... W świecie DevOps istnieje ogromna liczba narzędzi, terminów i praktyk, które trzeba opanować. Jest to szczególnie trudne na początku kariery i zależy od zgromadzonego doświadczenia technicznego.
Źródło:
Na tym prawdopodobnie zakończymy część wprowadzającą i skupimy się na celu tego artykułu.
O czym jest ten artykuł
W tym artykule podzielę się swoim doświadczeniem w budowaniu infrastruktury automatyzacji testów. W Internecie istnieje wiele źródeł informacji o różnych narzędziach i sposobie ich wykorzystania, jednak ja chciałbym na nie spojrzeć wyłącznie w kontekście automatyzacji. Wierzę, że wielu automatykom znana jest sytuacja, gdy nikt poza Tobą nie uruchamia opracowanych testów ani nie dba o ich utrzymanie. W rezultacie testy stają się nieaktualne i trzeba tracić czas na ich aktualizację. Ponownie, na początku kariery może to być dość trudne zadanie: mądrze zdecydować, które narzędzia powinny pomóc wyeliminować dany problem, jak je wybrać, skonfigurować i utrzymać. Niektórzy testerzy zwracają się o pomoc do DevOps (ludzi) i, bądźmy szczerzy, to podejście działa. W wielu przypadkach może to być jedyna opcja, ponieważ nie mamy wglądu we wszystkie zależności. Ale jak wiemy, DevOps to bardzo zajęci ludzie, ponieważ muszą myśleć o całej infrastrukturze firmy, wdrażaniu, monitorowaniu, mikroserwisach i innych podobnych zadaniach w zależności od organizacji/zespołu. Jak to zwykle bywa, automatyzacja nie jest priorytetem. W takiej sytuacji musimy od początku do końca zrobić wszystko, co w naszej mocy. Zmniejszy to zależności, przyspieszy pracę, poprawi nasze umiejętności i pozwoli nam zobaczyć szerszą perspektywę tego, co się dzieje.
W artykule przedstawiono najpopularniejsze i popularne narzędzia oraz pokazano, jak krok po kroku wykorzystać je do budowy infrastruktury automatyzacji. Każda grupa jest reprezentowana przez narzędzia, które zostały przetestowane na podstawie osobistego doświadczenia. Ale to nie znaczy, że musisz używać tego samego. Same narzędzia nie są ważne, pojawiają się i stają się przestarzałe. Naszym zadaniem inżynierskim jest zrozumienie podstawowych zasad: po co nam ta grupa narzędzi i jakie problemy pracy możemy rozwiązać za ich pomocą. Dlatego na końcu każdej sekcji zostawiam linki do podobnych narzędzi, które można zastosować w Twojej organizacji.
Czego nie ma w tym artykule
Powtarzam jeszcze raz, że artykuł nie jest o konkretnych narzędziach, więc nie będzie w nim wstawek kodu z dokumentacji i opisów konkretnych poleceń. Ale na końcu każdej sekcji zostawiam linki do szczegółowych badań.
Dzieje się tak, ponieważ:
- materiał ten jest bardzo łatwy do znalezienia w różnych źródłach (dokumentacja, książki, kursy wideo);
- jeśli zaczniemy zagłębiać się w szczegóły, będziemy musieli napisać 10, 20, 30 części tego artykułu (choć w planach jest 2-3);
- Po prostu nie chcę marnować Twojego czasu, ponieważ możesz chcieć użyć innych narzędzi, aby osiągnąć te same cele.
Praktyka
Bardzo chciałbym, żeby ten materiał był przydatny dla każdego czytelnika, a nie tylko przeczytany i zapomniany. W każdym badaniu praktyka jest bardzo ważnym elementem. W tym celu przygotowałem. Czeka na Ciebie także praca domowa, dzięki której będziesz mieć pewność, że nie kopiujesz bezmyślnie linijek poleceń, które wykonujesz.
plan
Krok
Technologia
Narzędzia
1
Uruchomienie lokalne (przygotuj testy demonstracyjne Internetu/Androida i uruchom je lokalnie)
Node.js, Selenium, Appium
2
Systemy kontroli wersji
git
3
Konteneryzacja
Docker, Selenium grid, Selenoid (Web, Android)
4
CI/CD
Gitlab CI
5
Platformy chmurowe
Platforma Google Cloud
6
orkiestracja
Kubernetes
7
Infrastruktura jako kod (IaC)
Terraform, Ansible
Struktura każdej sekcji
Aby narracja była jasna, każda sekcja została opisana zgodnie z następującym schematem:
- krótki opis technologii,
- wartość dla infrastruktury automatyki,
- ilustracja aktualnego stanu infrastruktury,
- linki do studiów,
- podobne narzędzia.
1. Uruchom testy lokalnie
Krótki opis technologii
To tylko krok przygotowawczy do lokalnego uruchomienia testów demonstracyjnych i sprawdzenia, czy przeszły pomyślnie. W części praktycznej używany jest Node.js, ale język programowania i platforma również nie są istotne i możesz skorzystać z tych, które są używane w Twojej firmie.
Однако в качестве инструментов автоматизации я рекомендую использовать Selenium WebDriver для web-платформ и Appium для Android-платформы соответственно, так как на следующих шагах мы будем использовать Docker-образы, которые заточены на работу конкретно с этими инструментами. Более того, ссылаясь на требования в вакансиях, эти инструменты наиболее востребованы на рынке.
Как вы могли заметить, мы рассматриваем только web и Android-тесты. К сожалению, IOS – совершенно другая история (спасибо Apple). Я планирую продемонстрировать решения и практики, связанные с IOS, в следующих частях.
Wartość dla infrastruktury automatyzacji
Z punktu widzenia infrastruktury działanie lokalne nie zapewnia żadnej wartości. Sprawdzasz jedynie, czy testy działają na komputerze lokalnym w lokalnych przeglądarkach i symulatorach. Ale w każdym razie jest to niezbędny punkt wyjścia.
Ilustracja przedstawiająca aktualny stan infrastruktury
Linki do eksploracji
Podobne narzędzia
- dowolny język programowania, który lubisz w połączeniu z testami Selenium/Appium;
- wszelkie testy;
- jakikolwiek biegacz testowy.
2. Systemy kontroli wersji (Git)
Krótki opis technologii
Nie będzie dla nikogo wielką rewelacją, jeśli powiem, że kontrola wersji jest niezwykle ważną częścią rozwoju, zarówno w zespole, jak i indywidualnie. Na podstawie różnych źródeł można śmiało stwierdzić, że najpopularniejszym przedstawicielem jest Git. System kontroli wersji zapewnia wiele korzyści, takich jak udostępnianie kodu, przechowywanie wersji, przywracanie do poprzednich gałęzi, monitorowanie historii projektów i tworzenie kopii zapasowych. Nie będziemy szczegółowo omawiać każdego punktu, ponieważ jestem pewien, że doskonale go znasz i wykorzystujesz w swojej codziennej pracy. Ale jeśli nagle nie, zalecam przerwę w czytaniu tego artykułu i jak najszybsze wypełnienie tej luki.
Wartość dla infrastruktury automatyzacji
I tutaj możesz zadać rozsądne pytanie: „Dlaczego opowiada nam o Gicie? Każdy o tym wie i używa go zarówno do programowania, jak i do automatycznego testowania kodu. Będziesz mieć całkowitą rację, ale w tym artykule mówimy o infrastrukturze i ta sekcja stanowi podgląd sekcji 7: „Infrastruktura jako kod (IaC)”. Dla nas oznacza to, że cała infrastruktura, łącznie z testowaniem, jest opisana w postaci kodu, dzięki czemu możemy zastosować do niej również systemy wersjonowania i uzyskać podobne korzyści jak w przypadku kodu deweloperskiego i automatyzującego.
Przyjrzymy się IaC bardziej szczegółowo w kroku 7, ale nawet teraz możesz zacząć używać Git lokalnie, tworząc lokalne repozytorium. Pełniejszy obraz zostanie poszerzony, gdy do infrastruktury dodamy zdalne repozytorium.
Ilustracja przedstawiająca aktualny stan infrastruktury
Linki do eksploracji
Podobne narzędzia
3. Konteneryzacja (Docker)
Krótki opis technologii
Aby zademonstrować, jak konteneryzacja zmieniła zasady gry, cofnijmy się w czasie o kilka dekad. W tamtych czasach ludzie kupowali i używali maszyn serwerowych do uruchamiania aplikacji. Jednak w większości przypadków wymagane zasoby startowe nie były znane z góry. W rezultacie firmy wydawały pieniądze na zakup drogich, wydajnych serwerów, ale część tej pojemności nie została w pełni wykorzystana.
Kolejnym etapem ewolucji były maszyny wirtualne (VM), które rozwiązały problem marnowania pieniędzy na niewykorzystane zasoby. Technologia ta umożliwiła niezależne od siebie uruchamianie aplikacji w ramach tego samego serwera, alokując całkowicie izolowaną przestrzeń. Ale niestety każda technologia ma swoje wady. Uruchomienie maszyny wirtualnej wymaga pełnego systemu operacyjnego, który zużywa procesor, pamięć RAM, pamięć masową i, w zależności od systemu operacyjnego, należy wziąć pod uwagę koszty licencji. Czynniki te wpływają na prędkość ładowania i utrudniają przenoszenie.
A teraz dochodzimy do konteneryzacji. Po raz kolejny technologia ta rozwiązuje poprzedni problem, ponieważ kontenery nie korzystają z pełnego systemu operacyjnego, co uwalnia dużą ilość zasobów i zapewnia szybkie i elastyczne rozwiązanie zapewniające przenośność.
Конечно, технология контейнеризации не является чем-то новым и впервые была представлена в конце 70-х. В те времена проводилось много исследований, наработок, и попыток. Но именно Docker адаптировал эту технологию и сделал ее легкодоступной для масс. В наше время, когда мы говорим о контейнерах, в большинстве случаев мы имеем ввиду Docker. Когда мы говорим о Docker-контейнерах, мы подразумеваем Linux-контейнеры. Мы можем использовать Windows и macOS-системы для запуска контейнеров, но важно понимать, что в таком случае появляется дополнительная прослойка. Например, Docker на Mac незаметно запускает контейнеры внутри легковесной Linux VM. Мы еще вернемся к этой теме, когда будем обсуждать запуск Android-эмуляторов внутри контейнеров, так так здесь появляется очень важной нюанс, который необходимо разобрать более подробно.
Wartość dla infrastruktury automatyzacji
Odkryliśmy, że konteneryzacja i Docker są fajne. Spójrzmy na to w kontekście automatyzacji, bo każde narzędzie czy technologia musi rozwiązać jakiś problem. Nakreślmy oczywiste problemy automatyzacji testów w kontekście testów UI:
- ogromna liczba zależności podczas instalacji Selenium, a zwłaszcza Appium;
- problemy ze zgodnością pomiędzy wersjami przeglądarek, symulatorów i sterowników;
- brak wydzielonej przestrzeni dla przeglądarek/symulatorów, co jest szczególnie istotne przy pracy równoległej;
- trudne w zarządzaniu i utrzymaniu, jeśli chcesz jednocześnie uruchomić 10, 50, 100 lub nawet 1000 przeglądarek.
Ponieważ jednak Selenium jest najpopularniejszym narzędziem do automatyzacji, a Docker jest najpopularniejszym narzędziem do konteneryzacji, nie powinno dziwić, że ktoś próbował je połączyć, aby stworzyć potężne narzędzie do rozwiązania wyżej wymienionych problemów. Rozważmy takie rozwiązania bardziej szczegółowo.
Siatka selenowa w oknie dokowanym
Этот инструмент является самым популярным в мире Selenium для запуска нескольких браузеров на нескольких машинах и управления ими из центрального узла. Для запуска необходимо зарегистрировать как минимум 2 части: Hub и Node(s). Hub – это центральный узел, который получает все запросы от тестов и распределяет их по соответствующим Nodes. Для каждого Node мы можем настроить конкретную конфигурацию, например, указав нужный браузер и его версию. Однако нам все еще необходимо самим позаботиться о совместимых драйверах для браузеров и установить их на нужные Nodes. По этой причине Selenium grid не используется в чистом виде, за исключением тех случаев, когда нам нужно работать с браузерами, которые нельзя установить на Linux OS. Для всех остальных случаев значительно гибким и правильным решением будет использование Docker-образов для запуска Selenium grid Hub и Nodes. Такой подход сильно упрощает управление узлами, так как мы можем выбрать нужный нам образ с уже установленными совместимыми версиями браузеров и драйверов.
Pomimo negatywnych opinii na temat stabilności, zwłaszcza przy równoległym uruchamianiu dużej liczby węzłów, siatka Selenium jest nadal najpopularniejszym narzędziem do równoległego uruchamiania testów Selenium. Należy zauważyć, że w oprogramowaniu open source stale pojawiają się różne ulepszenia i modyfikacje tego narzędzia, które eliminują różne wąskie gardła.
Selenoid dla Internetu
To narzędzie stanowi przełom w świecie Selenium, ponieważ działa od razu po wyjęciu z pudełka i znacznie ułatwiło życie wielu inżynierom automatykom. Przede wszystkim nie jest to kolejna modyfikacja siatki Selenium. Zamiast tego programiści stworzyli zupełnie nową wersję Selenium Hub w Golang, co w połączeniu z lekkimi obrazami Dockera dla różnych przeglądarek dało impuls do rozwoju automatyzacji testów. Co więcej, w przypadku Selenium Grid musimy z góry określić wszystkie wymagane przeglądarki i ich wersje, co nie stanowi problemu w przypadku pracy tylko z jedną przeglądarką. Jednak jeśli chodzi o wiele obsługiwanych przeglądarek, Selenoid jest rozwiązaniem numer jeden dzięki funkcji „przeglądarki na żądanie”. Jedyne, co jest od nas wymagane, to wcześniejsze pobranie niezbędnych obrazów za pomocą przeglądarek i aktualizacja pliku konfiguracyjnego, z którym współpracuje Selenoid. Gdy Selenoid otrzyma żądanie z testów, automatycznie uruchomi żądany kontener w żądanej przeglądarce. Po zakończeniu testu Selenoid wycofa kontener, uwalniając w ten sposób zasoby na przyszłe żądania. Takie podejście całkowicie eliminuje dobrze znany problem „degradacji węzła”, który często spotykamy w siatce Selenium.
Ale, niestety, Selenoid nadal nie jest srebrną kulą. Dostępna jest funkcja „przeglądarka na żądanie”, ale funkcja „zasoby na żądanie” nadal nie jest dostępna. Aby skorzystać z Selenoidu, musimy wdrożyć go na sprzęcie fizycznym lub na maszynie wirtualnej, co oznacza, że musimy z góry wiedzieć, ile zasobów należy przydzielić. Myślę, że nie stanowi to problemu w przypadku małych projektów, w których równolegle działa 10, 20, a nawet 30 przeglądarek. Ale co, jeśli potrzebujemy 100, 500, 1000 i więcej? Nie ma sensu utrzymywać i płacić za tak wiele zasobów przez cały czas. W punktach 5 i 6 tego artykułu omówimy rozwiązania, które pozwalają na skalowalność, a tym samym znacząco obniżają koszty przedsiębiorstwa.
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 внутри.
Ilustracja przedstawiająca aktualny stan infrastruktury
В контексте этой статьи мы добавим 2 инструмента для иллюстрации инфраструктуры. Это Selenium grid для web-тестов и Selenoid для Android-тестов. В руководстве на GitHub я также покажу, как использовать Selenoid для запуска web-тестов.
Linki do eksploracji
Podobne narzędzia
- Istnieją inne narzędzia do konteneryzacji, ale Docker jest najpopularniejszy. Jeśli chcesz spróbować czegoś innego, pamiętaj, że narzędzia, które omówiliśmy do równoległego uruchamiania testów Selenium, nie będą działać od razu po wyjęciu z pudełka.
- Jak już powiedziano, istnieje wiele modyfikacji siatki Selenium, na przykład:.
4.CI/CD
Krótki opis technologii
Praktyka ciągłej integracji jest dość popularna w programowaniu i dorównuje systemom kontroli wersji. Mimo to mam wrażenie, że w terminologii panuje zamieszanie. W tym akapicie chciałbym opisać 3 modyfikacje tej technologii z mojego punktu widzenia. W Internecie znajdziesz wiele artykułów z różnymi interpretacjami i jest całkowicie normalne, jeśli Twoje zdanie jest odmienne. Najważniejsze jest to, że jesteś na tej samej stronie ze swoimi współpracownikami.
Istnieją więc 3 terminy: CI – ciągła integracja, CD – ciągłe dostarczanie i ponownie CD – ciągłe wdrażanie. (Poniżej będę używał tych terminów w języku angielskim). Każda modyfikacja dodaje kilka dodatkowych kroków do potoku programowania. Ale słowo ciągły (ciągły) jest najważniejszą rzeczą. W tym kontekście mamy na myśli coś, co dzieje się od początku do końca, bez przerwy i ręcznej interwencji. Przyjrzyjmy się w tym kontekście CI & CD i CD.
- Ciągła integracja jest to początkowy etap ewolucji. Po przesłaniu nowego kodu na serwer spodziewamy się szybkiej informacji zwrotnej, że wprowadzone przez nas zmiany są prawidłowe. Zazwyczaj CI obejmuje uruchomienie narzędzi do statycznej analizy kodu oraz testów jednostkowych/wewnętrznych API, co pozwala nam uzyskać informacje o naszym kodzie w ciągu kilku sekund/minut.
- Ciągłe dostawy to bardziej zaawansowany etap, w którym przeprowadzamy testy integracyjne/UI. Jednak na tym etapie nie uzyskujemy efektów tak szybko jak przy CI. Po pierwsze, tego typu testy trwają dłużej. Po drugie, przed uruchomieniem musimy wdrożyć nasze zmiany w środowisku testowym/stagingowym. Co więcej, jeśli mówimy o rozwoju mobilnym, dodatkowym krokiem wydaje się stworzenie kompilacji naszej aplikacji.
- Ciągłe wdrażanie zakłada, że automatycznie wypuścimy nasze zmiany do produkcji, jeśli wszystkie testy akceptacyjne przeszły pomyślnie na poprzednich etapach. Oprócz tego po etapie wydania możesz skonfigurować różne etapy, takie jak przeprowadzanie testów dymnych na produkcji i zbieranie interesujących wskaźników. Ciągłe wdrażanie jest możliwe tylko przy dobrym pokryciu testami automatycznymi. Jeśli wymagane są jakiekolwiek ręczne interwencje, w tym testowanie, to już nie jest Ciągły (ciągły). Wtedy możemy powiedzieć, że nasz rurociąg spełnia wyłącznie praktykę Continuous Delivery.
Wartość dla infrastruktury automatyzacji
W tej sekcji powinienem wyjaśnić, że kiedy mówimy o kompleksowych testach interfejsu użytkownika, oznacza to, że powinniśmy wdrożyć nasze zmiany i powiązane usługi w środowiskach testowych. Continuous Integration – proces nie ma zastosowania do tego zadania i musimy zadbać o wdrożenie przynajmniej praktyk Continuous Deliver. Continuous Deployment ma również sens w kontekście testów UI, jeśli zamierzamy uruchomić je na produkcji.
I zanim spojrzymy na ilustrację zmiany architektury, chcę powiedzieć kilka słów o GitLab CI. W przeciwieństwie do innych narzędzi CI/CD, GitLab zapewnia zdalne repozytorium i wiele innych dodatkowych funkcji. Zatem GitLab to coś więcej niż CI. Obejmuje zarządzanie kodem źródłowym, zarządzanie Agile, potoki CI/CD, narzędzia do rejestrowania i zbieranie metryk od razu po wyjęciu z pudełka. Architektura GitLab składa się z Gitlab CI/CD i GitLab Runner. Oto krótki opis z oficjalnej strony:
Gitlab CI/CD to aplikacja internetowa z API, która przechowuje swój stan w bazie danych, zarządza projektami/kompilacjami i udostępnia interfejs użytkownika. GitLab Runner to aplikacja przetwarzająca kompilacje. Można go wdrożyć osobno i współpracuje z GitLab CI/CD poprzez API. Do uruchomienia testów potrzebujesz zarówno instancji Gitlab, jak i Runnera.
Ilustracja przedstawiająca aktualny stan infrastruktury
Linki do eksploracji
Podobne narzędzia
- I wiele innych
5. Platformy chmurowe
Krótki opis technologii
W tej części omówimy popularny trend zwany „chmurami publicznymi”. Pomimo ogromnych korzyści, jakie dają opisane powyżej technologie wirtualizacji i konteneryzacji, wciąż potrzebujemy zasobów obliczeniowych. Firmy kupują drogie serwery lub wynajmują centra danych, ale w tym przypadku konieczne jest dokonanie (czasami nierealnych) obliczeń, ile zasobów będziemy potrzebować, czy będziemy z nich korzystać 24 godziny na dobę, 7 dni w tygodniu i w jakich celach. Na przykład produkcja wymaga serwera działającego XNUMX godziny na dobę, XNUMX dni w tygodniu, ale czy potrzebujemy podobnych zasobów do testowania poza godzinami pracy? Zależy to również od rodzaju przeprowadzanego badania. Przykładem mogą być testy obciążeniowe/stresowe, które planujemy przeprowadzić poza godzinami pracy, aby uzyskać wyniki następnego dnia. Jednak zdecydowanie dostępność serwera XNUMX godziny na dobę, XNUMX dni w tygodniu nie jest wymagana w przypadku kompleksowych testów automatycznych, a zwłaszcza w środowiskach testów ręcznych. W takich sytuacjach dobrze byłoby pozyskać na żądanie tyle zasobów, ile potrzeba, wykorzystać je i przestać płacić, gdy nie są już potrzebne. Co więcej, byłoby wspaniale otrzymać je natychmiast, wykonując kilka kliknięć myszką lub uruchamiając kilka skryptów. Do tego służą chmury publiczne. Spójrzmy na definicję:
„Chmurę publiczną definiuje się jako usługi obliczeniowe oferowane przez zewnętrznych dostawców za pośrednictwem publicznego Internetu, udostępniające je każdemu, kto chce z nich korzystać lub je kupić. Mogą być bezpłatne lub sprzedawane na żądanie, dzięki czemu klienci płacą tylko za wykorzystanie cykli procesora, pamięci masowej lub wykorzystywanej przepustowości.
Istnieje opinia, że chmury publiczne są drogie. Ale ich kluczową ideą jest redukcja kosztów firmy. Jak wspomniano wcześniej, chmury publiczne pozwalają na pobieranie zasobów na żądanie i płacenie tylko za czas ich wykorzystania. Czasem zapominamy też, że pracownicy otrzymują pensje, a specjaliści też są drogim zasobem. Trzeba wziąć pod uwagę, że chmury publiczne znacznie ułatwiają obsługę infrastruktury, co pozwala inżynierom skupić się na ważniejszych zadaniach.
Wartość dla infrastruktury automatyzacji
Jakich konkretnych zasobów potrzebujemy do kompleksowych testów interfejsu użytkownika? Zasadniczo są to maszyny wirtualne lub klastry (o Kubernetesie porozmawiamy w następnej sekcji) do uruchamiania przeglądarek i emulatorów. Im więcej przeglądarek i emulatorów chcemy uruchomić jednocześnie, tym więcej potrzeba procesora i pamięci i tym więcej pieniędzy musimy za to zapłacić. Tym samym chmury publiczne w kontekście automatyzacji testów pozwalają nam na uruchamianie dużej liczby (100, 200, 1000...) przeglądarek/emulatorów na żądanie, uzyskiwanie wyników testów tak szybko, jak to możliwe i przestają płacić za tak szalenie zasobochłonne moc.
Najpopularniejszymi dostawcami usług chmurowych są Amazon Web Services (AWS), Microsoft Azure, Google Cloud Platform (GCP). Przewodnik zawiera przykłady korzystania z GCP, ale ogólnie rzecz biorąc, nie ma znaczenia, czego używasz do zadań automatyzacji. Wszystkie zapewniają w przybliżeniu tę samą funkcjonalność. Zazwyczaj przy wyborze dostawcy kierownictwo koncentruje się na całej infrastrukturze firmy i wymaganiach biznesowych, co wykracza poza zakres tego artykułu. Dla inżynierów automatyków bardziej interesujące będzie porównanie wykorzystania dostawców usług chmurowych z wykorzystaniem platform chmurowych specjalnie do celów testowych, takich jak Sauce Labs, BrowserStack, BitBar i tak dalej. Więc i my to zróbmy! Moim zdaniem Sauce Labs to najsłynniejsza farma testująca chmury, dlatego użyłem jej do porównania.
GCP vs Sauce Labs do celów automatyzacji:
Представим, что нам нужно прогнать одновременно 8 web-тестов и 8 Android-тестов. Для этого мы будем использовать GCP и запустим 2 виртуальные машины с Selenoid. На первой мы поднимем 8 контейнеров с браузерами. На второй – 8 контейнеров с эмуляторами. Давайте взглянем на цены:
Aby uruchomić jeden kontener z Chrome, potrzebujemy n1-standard-1 машина. В случае с Android tak będzie n1-standard-4 dla jednego emulatora. W rzeczywistości bardziej elastycznym i tańszym sposobem jest ustawienie określonych wartości użytkownika dla procesora/pamięci, ale w tej chwili nie jest to ważne w porównaniu z Sauce Labs.
A oto taryfy za korzystanie z Sauce Labs:
Myślę, że już zauważyłeś różnicę, ale nadal podam tabelę z obliczeniami dla naszego zadania:
Wymaganych zasobów
Miesięczny
W pracy(8:8 - XNUMX:XNUMX)
W pracy+Możliwe do wywłaszczenia
GCP dla Internetu
n1-standard-1 x 8 = n1-standard-8
$194.18
23 dni * 12 godzin * 0.38 = 104.88 USD
23 dni * 12 godzin * 0.08 = 22.08 USD
Laboratoria sosów dla Internetu
Testy równoległe Virtual Cloud8
$1.559
-
-
GCP for Android
n1-standard-4 x 8: n1-standard-16
$776.72
23 dni * 12 godzin * 1.52 = 419.52 USD
23 days * 12h * 0.32 = 88.32$
Sauce Labs for Android
Testy równoległe Real Device Cloud 8
$1.999
-
-
Jak widać różnica w kosztach jest ogromna, szczególnie jeśli testy przeprowadzasz tylko w ciągu dwunastogodzinnego okresu pracy. Możesz jednak jeszcze bardziej obniżyć koszty, jeśli użyjesz maszyn z możliwością wywłaszczania. Co to jest?
Maszyna wirtualna z możliwością wywłaszczania to instancja, którą można utworzyć i uruchomić po znacznie wyższej cenie niż zwykłe instancje. Jednak Compute Engine może zakończyć (wywłaszczyć) te instancje, jeśli wymaga dostępu do tych zasobów do innych zadań. Instancje, które można wywłaszczyć, to nadmierna pojemność Compute Engine, więc ich dostępność różni się w zależności od użycia.
Jeśli Twoje aplikacje są odporne na awarie i są w stanie wytrzymać możliwe wywłaszczanie instancji, instancje z możliwością wywłaszczania mogą znacznie obniżyć koszty Compute Engine. Na przykład zadania przetwarzania wsadowego mogą być uruchamiane w instancjach, które można wywłaszczyć. Jeśli niektóre z tych wystąpień zostaną zakończone w trakcie przetwarzania, zadanie zostanie spowolnione, ale nie zatrzymane całkowicie. Instancje z możliwością wywłaszczania realizują zadania przetwarzania wsadowego bez dodatkowego obciążenia istniejących instancji i bez konieczności płacenia pełnej ceny za dodatkowe normalne instancje.
И это все еще не конец! В действительности я уверен, что никто не запускает тесты по 12 часов без перерыва. И если это так, то вы можете автоматически запускать и останавливать виртуальные машины, когда они не нужны. Реальное время использования может снизиться до 6 часов в сутки. Тогда оплата в контексте нашей задачи уменьшится аж до 11$ в месяц за 8 браузеров. Разве это не прекрасно? Но с preemptible машинами мы должны быть осторожны и готовы к прерываниям и нестабильной работе, хотя эти ситуации могут быть предусмотрены и обработаны программно. Оно того стоит!
Но ни в коем случае я не говорю ‘никогда не используйте облачные тестовые фермы’. Они имеют ряд преимуществ. Прежде всего это не просто виртуальная машина, а полноценное решение для автоматизации тестирования с набором функционала из коробки: удаленный доступ, логи, скриншоты, видеозапись, различные браузеры и физические мобильные устройства. Во многих ситуациях это может быть незаменимой шикарной альтернативой. Особенно тестовые платформы полезны для IOS-автоматизации, когда публичные облака могут предложить только Linux/Windows-системы. Но разговор про IOS будет в следующих статьях. Я рекомендую всегда смотреть по ситуации и отталкиваться от задач: в каких-то дешевле и эффективнее использовать публичные облака, а в каких то тестовые платформы определено стоят потраченных денег.
Ilustracja przedstawiająca aktualny stan infrastruktury
Linki do eksploracji
Podobne narzędzia:
6. Orkiestracja
Krótki opis technologii
У меня хорошие новости – мы почти достигли конца статьи! На данный момент наша инфраструктура автоматизации состоит из web и Android-тестов, которые мы запускаем через GitLab CI параллельно, используя инструменты с поддержкой Docker: Selenium grid и Selenoid. Более того, мы используем созданные через GCP виртуальные машины для поднятия в них контейнеров с браузерами и эмуляторами. Для уменьшения расходов мы запускаем этим виртуальные машины только по требованию и останавливаем, когда тестирование не проводится. Существует ли что-то еще, что может улучшить нашу инфраструктуру? Ответ – да! Встречаем Kubernetes (K8s)!
Najpierw przyjrzyjmy się, jak słowa orkiestracja, klaster i Kubernetes są ze sobą powiązane. Na wysokim poziomie orkiestracja to system, który wdraża aplikacje i zarządza nimi. W przypadku automatyzacji testów takimi kontenerowymi aplikacjami są Selenium Grid i Selenoid. Docker i K8 uzupełniają się nawzajem. Pierwszy służy do wdrażania aplikacji, drugi do orkiestracji. Z kolei K8s jest klastrem. Zadaniem klastra jest wykorzystanie maszyn wirtualnych jako węzłów, co pozwala na instalację różnych funkcjonalności, programów i usług w ramach jednego serwera (klastra). W przypadku awarii któregoś z Węzłów, pozostałe Węzły podejmą działania, co zapewnia nieprzerwane działanie naszej aplikacji. Oprócz tego K8s posiada ważną funkcjonalność związaną ze skalowaniem, dzięki której automatycznie uzyskujemy optymalną ilość zasobów na podstawie obciążenia i ustawionych limitów.
Tak naprawdę ręczne wdrożenie Kubernetesa od zera nie jest wcale trywialnym zadaniem. Zostawiam link do słynnego poradnika „Kubernetes The Hard Way”, a jeśli jesteś zainteresowany, możesz go przećwiczyć. Ale na szczęście istnieją alternatywne metody i narzędzia. Najłatwiej jest skorzystać z Google Kubernetes Engine (GKE) w GCP, co pozwoli Ci w kilku kliknięciach uzyskać gotowy klaster. Polecam zastosować to podejście na początku nauki, ponieważ pozwoli Ci to skoncentrować się na nauce obsługi K8 do Twoich zadań, zamiast na nauce integracji wewnętrznych komponentów.
Wartość dla infrastruktury automatyzacji
Przyjrzyjmy się kilku istotnym funkcjom, które zapewnia K8s:
- wdrażanie aplikacji: wykorzystanie klastra wielowęzłowego zamiast maszyn wirtualnych;
- skalowanie dynamiczne: zmniejsza koszt zasobów wykorzystywanych tylko na żądanie;
- samoleczenie: automatyczne odzyskiwanie strąków (w wyniku czego przywracane są również pojemniki);
- wdrażanie aktualizacji i wycofywanie zmian bez przestojów: aktualizacja narzędzi, przeglądarek i emulatorów nie zakłóca pracy obecnych użytkowników
Ale K8s nadal nie jest srebrną kulą. Aby zrozumieć wszystkie zalety i ograniczenia w kontekście rozważanych przez nas narzędzi (siatka Selenium, Selenoid), omówimy pokrótce strukturę K8. Klaster zawiera dwa typy węzłów: węzły główne i węzły robocze. Węzły główne są odpowiedzialne za decyzje dotyczące zarządzania, wdrażania i planowania. Węzły robocze to miejsce, w którym uruchamiane są aplikacje. Węzły zawierają także środowisko uruchomieniowe kontenera. W naszym przypadku jest to Docker, który odpowiada za operacje na kontenerach. Ale są też rozwiązania alternatywne np. Ważne jest, aby zrozumieć, że skalowanie lub samoleczenie nie dotyczy bezpośrednio kontenerów. Realizuje się to poprzez dodanie/zmniejszenie liczby podów, które z kolei zawierają kontenery (zwykle jeden kontener na pod, ale w zależności od zadania może być ich więcej). Hierarchia wysokiego poziomu składa się z węzłów roboczych, wewnątrz których znajdują się pody, wewnątrz których podnoszone są kontenery.
Funkcja skalowania jest kluczowa i można ją zastosować zarówno do węzłów w puli węzłów klastra, jak i do zasobników w węźle. Istnieją 2 typy skalowania, które mają zastosowanie zarówno do węzłów, jak i do zasobników. Pierwszy typ jest poziomy – skalowanie następuje poprzez zwiększenie liczby węzłów/strąków. Ten typ jest bardziej preferowany. Drugi typ jest odpowiednio pionowy. Skalowanie odbywa się poprzez zwiększanie rozmiaru węzłów/strąków, a nie ich liczby.
Przyjrzyjmy się teraz naszym narzędziom w kontekście powyższych terminów.
Siatka selenowa
Jak wspomniano wcześniej, siatka Selenium jest bardzo popularnym narzędziem i nic dziwnego, że została skonteneryzowana. Dlatego nie jest zaskoczeniem, że siatka Selenium może zostać zastosowana w K8. Przykład, jak to zrobić, można znaleźć w oficjalnym repozytorium K8s. Tradycyjnie na końcu działu załączam linki. Ponadto poradnik pokazuje, jak to zrobić w Terraform. Istnieją również instrukcje dotyczące skalowania liczby podów zawierających kontenery przeglądarki. Ale funkcja automatycznego skalowania w kontekście K8s nadal nie jest zadaniem całkowicie oczywistym. Kiedy zaczynałem studiować, nie znalazłem żadnych praktycznych wskazówek ani zaleceń. Po kilku badaniach i eksperymentach przy wsparciu zespołu DevOps wybraliśmy podejście polegające na pozyskiwaniu kontenerów z niezbędnymi przeglądarkami w ramach jednego poda, który znajduje się wewnątrz jednego węzła roboczego. Metoda ta pozwala na zastosowanie strategii poziomego skalowania węzłów poprzez zwiększanie ich liczby. Mam nadzieję, że w przyszłości to się zmieni i będziemy widzieć coraz więcej opisów lepszych podejść i gotowych rozwiązań, szczególnie po wydaniu Selenium grid 4 ze zmienioną architekturą wewnętrzną.
Selenoid:
Wdrożenie Selenoidów w K8 jest obecnie największym rozczarowaniem. Nie są kompatybilne. Teoretycznie możemy podnieść kontener Selenoid wewnątrz kapsuły, ale kiedy Selenoid zacznie uruchamiać kontenery za pomocą przeglądarek, nadal będą one znajdować się w tym samym zasobniku. Uniemożliwia to skalowanie, dzięki czemu praca Selenoida wewnątrz klastra nie będzie się różnić od pracy wewnątrz maszyny wirtualnej. Koniec opowieści.
Księżyc:
Znając to wąskie gardło podczas pracy z Selenoidem, programiści wypuścili potężniejsze narzędzie o nazwie Moon. Narzędzie to zostało pierwotnie zaprojektowane do współpracy z Kubernetesem, w związku z czym można i należy korzystać z funkcji autoskalowania. Co więcej, powiedziałbym, że w tej chwili tak pojedynczy narzędzie w świecie Selenium, które od razu po wyjęciu z pudełka ma natywną obsługę klastrów K8 (nie jest już dostępny, zobacz następne narzędzie ). Kluczowe cechy Moon, które zapewniają to wsparcie to:
Całkowicie bezpaństwowy. Selenoid przechowuje w pamięci informacje o aktualnie uruchomionych sesjach przeglądarki. Jeśli z jakiegoś powodu proces ulegnie awarii — wszystkie uruchomione sesje zostaną utracone. W przeciwieństwie do tego Moon nie ma stanu wewnętrznego i można go replikować w centrach danych. Sesje przeglądarki pozostają aktywne, nawet jeśli jedna lub więcej replik ulegnie awarii.
Moon jest więc świetnym rozwiązaniem, ale jest jeden problem: nie jest darmowy. Cena uzależniona jest od ilości sesji. Za darmo możesz przeprowadzić tylko 0-4 sesje, co nie jest szczególnie przydatne. Ale począwszy od piątej sesji, za każdą będziesz musiał zapłacić 5 dolarów. Sytuacja może się różnić w zależności od firmy, ale w naszym przypadku używanie Moona nie ma sensu. Jak opisałem powyżej, możemy na żądanie uruchomić maszyny wirtualne z Selenium Grid lub zwiększyć liczbę Nodów w klastrze. Dla mniej więcej jednego potoku uruchamiamy 500 przeglądarek i po zakończeniu testów zatrzymujemy wszystkie zasoby. Gdybyśmy korzystali z Moona, musielibyśmy płacić dodatkowo 500 x 5 = 2500 $ miesięcznie, niezależnie od tego, jak często przeprowadzamy testy. Jeszcze raz powtarzam, że nie mówię, żeby nie używać Moona. Dla Twoich zadań może to być niezastąpione rozwiązanie, jeśli np. masz w organizacji wiele projektów/zespołów i potrzebujesz ogromnego, wspólnego dla wszystkich klastra. Jak zawsze zostawiam link na końcu i polecam wykonanie wszystkich niezbędnych obliczeń w kontekście Twojego zadania.
Callisto: (Uwaga! Nie ma tego w oryginalnym artykule i jest zawarte jedynie w tłumaczeniu na język rosyjski)
Jak mówiłem, Selenium jest bardzo popularnym narzędziem, a dziedzina IT rozwija się bardzo szybko. Kiedy pracowałem nad tłumaczeniem, w sieci pojawiło się nowe obiecujące narzędzie o nazwie Callisto (witajcie Cypress i inni zabójcy Selenium). Działa natywnie z K8 i umożliwia uruchamianie kontenerów Selenoid w zasobnikach rozproszonych w węzłach. Wszystko działa od razu po wyjęciu z pudełka, łącznie z automatycznym skalowaniem. Fantastyczne, ale wymaga przetestowania. Udało mi się już wdrożyć to narzędzie i przeprowadzić kilka eksperymentów. Ale jest zbyt wcześnie, aby wyciągać wnioski, po otrzymaniu wyników na dużą odległość, być może zrobię recenzję w przyszłych artykułach. Na razie pozostawiam jedynie linki do niezależnych badań.
Ilustracja przedstawiająca aktualny stan infrastruktury
Linki do eksploracji
Podobne narzędzia
7. Infrastruktura jako kod (IaC)
Krótki opis technologii
I teraz dochodzimy do ostatniej sekcji. Zwykle za tę technologię i związane z nią zadania nie odpowiadają inżynierowie automatycy. I są ku temu powody. Po pierwsze, w wielu organizacjach kwestie związane z infrastrukturą są pod kontrolą działu DevOps, a zespoły programistyczne tak naprawdę nie przejmują się tym, co sprawia, że rurociąg działa i jak wszystko z nim związane musi być wspierane. Po drugie, bądźmy szczerzy, praktyka Infrastructure as Code (IaC) wciąż nie jest przyjęta w wielu firmach. Jednak zdecydowanie stał się on popularnym trendem i ważne jest, aby spróbować zaangażować się w procesy, podejścia i narzędzia z nim związane. Albo chociaż bądź na bieżąco.
Zacznijmy od motywacji stosowania tego podejścia. Mówiliśmy już, że aby uruchomić testy w GitlabCI, będziemy potrzebować przynajmniej zasobów do uruchomienia Gitlab Runner. Aby uruchamiać kontenery z przeglądarkami/emulatorami, musimy zarezerwować maszynę wirtualną lub klaster. Oprócz zasobów testowych potrzebujemy znacznej pojemności do obsługi środowisk programistycznych, testowych i produkcyjnych, które obejmują również bazy danych, automatyczne harmonogramy, konfiguracje sieci, moduły równoważenia obciążenia, prawa użytkowników i tak dalej. Kluczową kwestią jest wysiłek wymagany do utrzymania tego wszystkiego. Istnieje kilka sposobów wprowadzania zmian i wdrażania aktualizacji. Przykładowo w kontekście GCP możemy skorzystać z konsoli UI w przeglądarce i wszystkie akcje wykonywać poprzez klikanie przycisków. Alternatywą byłoby użycie wywołań API do interakcji z jednostkami w chmurze lub użycie narzędzia wiersza poleceń gcloud w celu wykonania żądanych manipulacji. Jednak przy naprawdę dużej liczbie różnych podmiotów i elementów infrastruktury ręczne wykonanie wszystkich operacji staje się trudne lub wręcz niemożliwe. Co więcej, wszystkie te ręczne działania są niekontrolowane. Nie możemy przesłać ich do sprawdzenia przed wykonaniem, skorzystać z systemu kontroli wersji i szybko wycofać zmian, które doprowadziły do incydentu. Aby rozwiązać takie problemy, inżynierowie stworzyli i tworzą automatyczne skrypty bash/shell, które nie są dużo lepsze od poprzednich metod, ponieważ nie są łatwe do szybkiego odczytania, zrozumienia, utrzymywania i modyfikowania w stylu proceduralnym.
W tym artykule i poradniku używam 2 narzędzi związanych z praktyką IaC. Są to Terraform i Ansible. Niektórzy uważają, że nie ma sensu używać ich jednocześnie, gdyż ich funkcjonalność jest podobna i można je stosować zamiennie. Ale faktem jest, że początkowo otrzymują zupełnie inne zadania. A fakt, że te narzędzia powinny się uzupełniać, potwierdziła wspólna prezentacja deweloperów reprezentujących HashiCorp i RedHat. Różnica koncepcyjna polega na tym, że Terraform jest narzędziem do zarządzania samymi serwerami. Natomiast Ansible to narzędzie do zarządzania konfiguracją, którego zadaniem jest instalacja, konfiguracja i zarządzanie oprogramowaniem na tych serwerach.
Kolejną kluczową cechą wyróżniającą te narzędzia jest styl kodowania. W przeciwieństwie do basha i Ansible, Terraform używa stylu deklaratywnego opartego na opisie pożądanego stanu końcowego, który ma zostać osiągnięty w wyniku wykonania. Na przykład, jeśli zamierzamy utworzyć 10 maszyn wirtualnych i zastosować zmiany poprzez Terraform, otrzymamy 10 maszyn wirtualnych. Jeśli uruchomimy skrypt jeszcze raz nic się nie stanie, gdyż mamy już 10 VM, a Terraform o tym wie, bo przechowuje aktualny stan infrastruktury w pliku stanu. Ale Ansible stosuje podejście proceduralne i jeśli poprosisz go o utworzenie 10 maszyn wirtualnych, to przy pierwszym uruchomieniu otrzymamy 10 maszyn wirtualnych, podobnie jak Terraform. Ale po ponownym uruchomieniu będziemy już mieć 20 maszyn wirtualnych. To jest istotna różnica. W stylu proceduralnym nie przechowujemy bieżącego stanu, a jedynie opisujemy sekwencję kroków, które należy wykonać. Oczywiście możemy sobie poradzić z różnymi sytuacjami, dodać kilka kontroli istnienia zasobów i aktualnego stanu, ale nie ma sensu tracić czasu i wkładać wysiłku w kontrolowanie tej logiki. Ponadto zwiększa to ryzyko popełnienia błędów.
Podsumowując wszystko powyższe, możemy stwierdzić, że Terraform i notacja deklaratywna są bardziej odpowiednim narzędziem do udostępniania serwerów. Lepiej jednak oddelegować pracę związaną z zarządzaniem konfiguracją do Ansible. Pomijając to, spójrzmy na przypadki użycia w kontekście automatyzacji.
Wartość dla infrastruktury automatyzacji
Jedyną ważną rzeczą do zrozumienia jest to, że infrastrukturę automatyzacji testów należy traktować jako część całej infrastruktury firmy. Oznacza to, że wszystkie praktyki IaC muszą być stosowane globalnie do zasobów całej organizacji. Kto jest za to odpowiedzialny, zależy od Twoich procesów. Zespół DevOps jest w tych zagadnieniach bardziej doświadczony, widzi pełny obraz tego co się dzieje. Jednak inżynierowie QA są bardziej zaangażowani w proces automatyzacji budynku i konstrukcję rurociągu, co pozwala im lepiej dostrzec wszystkie wymagane zmiany i możliwości ulepszeń. Najlepszą opcją jest wspólna praca, wymiana wiedzy i pomysłów, aby osiągnąć oczekiwany rezultat.
Oto kilka przykładów wykorzystania Terraform i Ansible w kontekście automatyzacji testów oraz narzędzi, o których mówiliśmy wcześniej:
1. Opisać niezbędne cechy i parametry maszyn wirtualnych i klastrów wykorzystujących Terraform.
2. Za pomocą Ansible zainstaluj narzędzia niezbędne do testów: docker, Selenoid, Selenium Grid i pobierz wymagane wersje przeglądarek/emulatorów.
3. Korzystając z Terraform, opisz charakterystykę maszyny wirtualnej, na której zostanie uruchomiony GitLab Runner.
4. Zainstaluj GitLab Runner i niezbędne narzędzia towarzyszące za pomocą Ansible, ustaw ustawienia i konfiguracje.
Ilustracja przedstawiająca aktualny stan infrastruktury
Linki do eksploracji:
Podobne narzędzia
Podsumujmy to!
Krok
Technologia
Narzędzia
Wartość dla infrastruktury automatyzacji
1
Bieganie lokalne
Node.js, Selenium, Appium
- Najpopularniejsze narzędzia webowe i mobilne
- Obsługuje wiele języków i platform (w tym Node.js)
2
Systemy kontroli wersji
git
- Podobne korzyści z kodem programistycznym
3
Konteneryzacja
Docker, Selenium grid, Selenoid (Web, Android)
- Uruchamianie testów równolegle
- Izolowane środowiska
- Proste i elastyczne aktualizacje wersji
- Dynamiczne zatrzymywanie nieużywanych zasobów
- Łatwe do skonfigurowania
4
CI/CD
Gitlab CI
- Testuje część rurociągu
- Szybka informacja zwrotna
- Widoczność dla całej firmy/zespołu
5
Platformy chmurowe
Platforma Google Cloud
- Zasoby na żądanie (płacimy tylko wtedy, gdy są potrzebne)
- Łatwe w zarządzaniu i aktualizacji
- Widoczność i kontrola wszystkich zasobów
6
orkiestracja
Kubernetes
W kontekście kontenerów z przeglądarkami/emulatorami wewnątrz podów:
- Skalowanie/automatyczne skalowanie
- Samo leczenie
- Aktualizacje i wycofywanie bez zakłóceń
7
Infrastruktura jako kod (IaC)
Terraform, Ansible
- Podobne korzyści z infrastrukturą deweloperską
- Wszystkie zalety wersjonowania kodu
- Łatwe wprowadzanie zmian i konserwacja
- Całkowicie automatyczny
Diagramy map myśli: ewolucja infrastruktury
krok 1: Lokalnie
krok 2: VCS
krok 3: Konteneryzacja
krok 4: CI/CD
krok 5: Platformy chmurowe
krok 6: Orkiestracja
krok 7: IaC
Co dalej?
A zatem to koniec artykułu. Ale podsumowując, chciałbym zawrzeć z Tobą pewne umowy.
Z Twojej strony
Jak wspomniałem na początku, chciałbym, aby artykuł miał praktyczne zastosowanie i pomógł zastosować zdobytą wiedzę w rzeczywistej pracy. Dodaję ponownie.
Ale nawet potem nie zatrzymuj się, ćwicz, przestudiuj odpowiednie linki i książki, dowiedz się, jak to działa w Twojej firmie, znajdź miejsca, które można ulepszyć i weź w tym udział. Powodzenia!
Z mojej strony
Из заголовка видно, что это была только первая часть. Несмотря на то, что она получилось довольно большой, здесь все еще не раскрыты важные темы. Во второй части я планирую рассмотреть инфраструктуру автоматизации в контексте IOS. Из-за ограничений Apple, связанных с запусками IOS симуляторов только на macOS системах, наш набор решений сужен. Например, мы лишены возможности использовать Docker для запуска симулятора или публичных облаков для запуска виртуальных машин. Но это не означает, что нет других альтернатив. Я постараюсь держать вас в курсе передовых решений и современных инструментов!
Nie wspomniałem też o dość obszernych tematach związanych z monitoringiem. W części 3 przyjrzę się najpopularniejszym narzędziom do monitorowania infrastruktury oraz tym, jakie dane i metryki należy wziąć pod uwagę.
I w końcu. W przyszłości planuję wypuścić kurs wideo na temat budowy infrastruktury testowej i popularnych narzędzi. Obecnie w Internecie jest sporo kursów i wykładów na temat DevOps, ale wszystkie materiały prezentowane są w kontekście developmentu, a nie automatyzacji testów. W tej kwestii bardzo potrzebuję informacji zwrotnej, czy taki kurs będzie ciekawy i wartościowy dla społeczności testerów i inżynierów automatyków. Z góry dziękuję!
Źródło: www.habr.com
