Część 1: Internet/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
Ewolucja krok po kroku
Technologia
Tools
1
Uruchomienie lokalne (przygotuj testy demonstracyjne Internetu/Androida i uruchom je lokalnie)
Node.js, Selenium, Appium
2
Systemy kontroli wersji
git
3
Konteneryzacja
Docker, siatka Selenium, 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.
Jako narzędzia do automatyzacji polecam jednak odpowiednio Selenium WebDriver dla platform internetowych i Appium dla platformy Android, ponieważ w kolejnych krokach będziemy używać obrazów Dockera, które są dostosowane do współpracy specjalnie z tymi narzędziami. Co więcej, biorąc pod uwagę wymagania stanowiska, narzędzia te cieszą się największym zainteresowaniem na rynku.
Jak zapewne zauważyłeś, bierzemy pod uwagę tylko testy internetowe i Androida. Niestety iOS to zupełnie inna historia (dzięki Apple). W nadchodzących częściach planuję zaprezentować rozwiązania i praktyki związane z 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ść.
Oczywiście technologia konteneryzacji nie jest niczym nowym i została wprowadzona po raz pierwszy pod koniec lat 70-tych. W tamtych czasach przeprowadzono wiele badań, udoskonaleń i prób. Ale to Docker zaadaptował tę technologię i uczynił ją łatwo dostępną dla mas. W dzisiejszych czasach, gdy mówimy o kontenerach, w większości przypadków mamy na myśli Dockera. Kiedy mówimy o kontenerach Docker, mamy na myśli kontenery Linux. Do uruchamiania kontenerów możemy używać systemów Windows i macOS, jednak należy pamiętać, że w tym przypadku pojawia się dodatkowa warstwa. Na przykład Docker na komputerze Mac dyskretnie uruchamia kontenery w lekkiej maszynie wirtualnej z systemem Linux. Powrócimy do tego tematu, gdy będziemy omawiać uruchamianie emulatorów Androida w kontenerach, dlatego tutaj pojawia się bardzo ważny niuans, który należy omówić bardziej szczegółowo.
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
To narzędzie jest najpopularniejsze w świecie Selenium do uruchamiania wielu przeglądarek na wielu komputerach i zarządzania nimi z centralnego koncentratora. Aby rozpocząć, musisz zarejestrować co najmniej 2 części: Hub i Node(y). Hub to węzeł centralny, który odbiera wszystkie żądania z testów i rozdziela je do odpowiednich węzłów. Dla każdego Node'a możemy skonfigurować konkretną konfigurację, na przykład określając żądaną przeglądarkę i jej wersję. Jednak nadal musimy sami zadbać o kompatybilne sterowniki przeglądarki i zainstalować je na wybranych węzłach. Z tego powodu siatka Selenium nie jest używana w czystej postaci, z wyjątkiem sytuacji, gdy musimy pracować z przeglądarkami, których nie można zainstalować w systemie operacyjnym Linux. We wszystkich innych przypadkach znacznie elastycznym i poprawnym rozwiązaniem byłoby użycie obrazów Dockera do uruchomienia centrum i węzłów Selenium Grid. Takie podejście znacznie upraszcza zarządzanie węzłami, ponieważ możemy wybrać potrzebny obraz z kompatybilnymi wersjami przeglądarek i już zainstalowanymi sterownikami.
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 dla Androida
Po sukcesie Selenoida jako narzędzia do automatyzacji sieci ludzie chcieli czegoś podobnego na Androida. I tak się stało – Selenoid został wydany ze wsparciem dla Androida. Z punktu widzenia użytkownika wysokiego poziomu zasada działania jest podobna do automatyzacji sieci. Jedyna różnica polega na tym, że zamiast kontenerów przeglądarki Selenoid uruchamia kontenery emulatora Androida. Moim zdaniem jest to obecnie najpotężniejsze darmowe narzędzie do równoległego uruchamiania testów Androida.
Naprawdę nie chciałbym mówić o negatywnych aspektach tego narzędzia, ponieważ naprawdę mi się podoba. Ale nadal istnieją te same wady, które dotyczą automatyzacji sieci i są związane ze skalowaniem. Oprócz tego musimy porozmawiać o jeszcze jednym ograniczeniu, które może zaskoczyć, jeśli konfigurujemy narzędzie po raz pierwszy. Aby uruchomić obrazy Androida, potrzebujemy maszyny fizycznej lub maszyny wirtualnej z obsługą zagnieżdżonej wirtualizacji. W przewodniku instruktażowym pokazuję, jak włączyć tę opcję na maszynie wirtualnej z systemem Linux. Jeśli jednak jesteś użytkownikiem systemu macOS i chcesz wdrożyć Selenoid lokalnie, uruchomienie testów Androida nie będzie możliwe. Ale zawsze możesz uruchomić lokalnie maszynę wirtualną z systemem Linux ze skonfigurowaną „wirtualizacją zagnieżdżoną” i wdrożyć w niej Selenoid.
Ilustracja przedstawiająca aktualny stan infrastruktury
W kontekście tego artykułu dodamy 2 narzędzia ilustrujące infrastrukturę. Są to siatka Selenium do testów internetowych i Selenoid do testów Androida. W samouczku GitHub pokażę Ci również, jak używać Selenoid do uruchamiania testów sieciowych.
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:
Wyobraźmy sobie, że musimy jednocześnie przeprowadzić 8 testów internetowych i 8 testów Androida. W tym celu użyjemy GCP i uruchomimy 2 maszyny wirtualne z Selenoidem. Na pierwszym podniesiemy 8 kontenerów z przeglądarkami. Na drugim znajduje się 8 pojemników z emulatorami. Przyjrzyjmy się cenom:
Aby uruchomić jeden kontener z Chrome, potrzebujemy n1-standard-1 samochód. W przypadku Androida 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 na Androida
n1-standard-4 x 8: n1-standard-16
$776.72
23 dni * 12 godzin * 1.52 = 419.52 USD
23 dni * 12 godzin * 0.32 = 88.32 USD
Laboratoria sosów dla Androida
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.
A to jeszcze nie koniec! W rzeczywistości jestem pewien, że nikt nie prowadzi testów przez 12 godzin bez przerwy. A jeśli tak, możesz automatycznie uruchamiać i zatrzymywać maszyny wirtualne, gdy nie są potrzebne. Rzeczywisty czas użytkowania może zostać skrócony do 6 godzin dziennie. Wtedy opłata w ramach naszego zadania obniży się do 11 dolarów miesięcznie za 8 przeglądarek. Czy to nie cudowne? Jednak w przypadku maszyn z możliwością wywłaszczania musimy być ostrożni i przygotowani na zakłócenia i niestabilność, chociaż takie sytuacje można przewidzieć i obsłużyć w oprogramowaniu. To jest tego warte!
Ale w żadnym wypadku nie mówię: „nigdy nie używaj farm testowych w chmurze”. Mają wiele zalet. Przede wszystkim nie jest to tylko maszyna wirtualna, ale pełnoprawne rozwiązanie do automatyzacji testów z zestawem gotowych funkcjonalności: zdalny dostęp, logi, zrzuty ekranu, nagrywanie wideo, różne przeglądarki i fizyczne urządzenia mobilne. W wielu sytuacjach może to być niezbędna, elegancka alternatywa. Platformy testowe są szczególnie przydatne w automatyzacji IOS, gdy chmury publiczne mogą oferować tylko systemy Linux/Windows. Ale o iOS porozmawiamy w kolejnych artykułach. Polecam zawsze przyjrzeć się sytuacji i zacząć od zadań: w niektórych przypadkach taniej i efektywniej jest skorzystać z chmur publicznych, a w innych zdecydowanie warte są wydanych pieniędzy platformy testowe.
Ilustracja przedstawiająca aktualny stan infrastruktury
Linki do eksploracji
Podobne narzędzia:
6. Orkiestracja
Krótki opis technologii
Mam dobrą wiadomość – jesteśmy już prawie na końcu artykułu! W tej chwili nasza infrastruktura automatyzacji składa się z testów webowych i Android, które przeprowadzamy równolegle poprzez GitLab CI, wykorzystując narzędzia obsługujące Docker: Selenium grid i Selenoid. Ponadto używamy maszyn wirtualnych utworzonych za pośrednictwem GCP do hostowania kontenerów z przeglądarkami i emulatorami. Aby obniżyć koszty, uruchamiamy te maszyny wirtualne tylko na żądanie i zatrzymujemy je, gdy nie są przeprowadzane testy. Czy jest coś jeszcze, co może ulepszyć naszą infrastrukturę? Odpowiedź brzmi tak! Poznaj Kubernetesa (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!
Ewolucja krok po kroku
Technologia
Tools
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, siatka Selenium, 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
Po tytule widać, że to dopiero pierwsza część. Mimo, że okazał się dość obszerny, to nadal nie zostały tu poruszone ważne tematy. W drugiej części planuję przyjrzeć się infrastrukturze automatyzacji w kontekście IOS. Ze względu na ograniczenia Apple dotyczące uruchamiania symulatorów iOS wyłącznie na systemach macOS, nasza oferta rozwiązań jest zawężona. Nie możemy na przykład użyć Dockera do uruchomienia symulatora ani chmur publicznych do uruchomienia maszyn wirtualnych. Nie oznacza to jednak, że nie ma innych alternatyw. Postaram się na bieżąco informować Cię o zaawansowanych rozwiązaniach i nowoczesnych narzędziach!
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