1. rész: Web / Android
Megjegyzés: ez a cikk az eredeti cikk magyar nyelvű fordítása Fontos megjegyezni, hogy minden illusztráció, hivatkozás, idézet és kifejezés az eredeti nyelven maradt, hogy elkerüljük a jelentés torzulását a magyarra fordítás során. Kellemes tanulást kívánok!
Jelenleg a DevOps szakma az egyik legkeresettebb az IT iparban. Ha népszerű álláskereső oldalakat nyit meg, és a fizetések alapján szűr, láthatja, hogy a DevOps-szal kapcsolatos állások a lista elején szerepelnek. Fontos azonban megérteni, hogy ez főként a 'Senior' pozíciókra vonatkozik, ami azt jelenti, hogy a jelölt magas szintű szakértelemmel és technológiai ismeretekkel rendelkezik. Ehhez magas fokú felelősség is társul, amely a folyamatos production működésével jár. Azonban hajlamosak vagyunk elfelejteni, hogy mi is a DevOps. Kezdetben nem volt egy konkrét személy vagy osztály. Ha megkeressük ennek a kifejezésnek a meghatározásait, sok szép és helyes főnevet találunk, például metodológia, gyakorlatok, kulturális filozófia, fogalomcsoportok stb.
A szakterületem a tesztelési automatizálás mérnöke (QA automation engineer), de úgy gondolom, hogy ez nem csupán az automatikus tesztek írására vagy a tesztkeretrendszer fejlesztésére vonatkozik. 2020-ban az automatizálási infrastruktúra tudása is elengedhetetlen. Ez lehetővé teszi, hogy önállóan szervezze meg az automatizálási folyamatot, a tesztek futtatásától kezdve a resultatenek minden érdekelt fél számára történő bemutatásáig az előírt céloknak megfelelően. Ennek eredményeképpen a DevOps készségek kötelező tényezők a munkakör betöltéséhez. Mindez szép, de sajnos van egy probléma (spoiler: ez a cikk megpróbálja leegyszerűsíteni ezt a problémát.). A DevOps összetett. És ez egyértelmű, hiszen a cégek nem fognak sokat fizetni azért, amit könnyen meg lehet csinálni… A DevOps világában számos eszköz, kifejezés és gyakorlat létezik, amelyeket el kell sajátítani. Ez különösen nehéz lehet a karrier elején, és az eddig megszerzett technikai tapasztalattól függ.
Forrás:
Itt talán befejezzük az bevezető részt, és a cikk céljára összpontosítunk.
Miről szól ez a cikk
Ebben a cikkben meg fogom osztani a tesztelési automatizálás infrastruktúrájának kiépítésével kapcsolatos tapasztalataimat. Az interneten sok információforrás található a különböző eszközökről és azok használatáról, de én szeretném őket kizárólag az automatizálás kontextusában megvizsgálni. Meggyőződésem, hogy sok automatizáló mérnök ismeri azt a helyzetet, amikor a kidolgozott teszteket senki más nem futtatja és nem törődik a karbantartásukkal, csak ti magatok. Ennek következtében a tesztek elavulttá válnak, és időt kell áldoznunk a frissítésükre. Ismét, a karrier elején ez meglehetősen nehéz feladat lehet: okosan eldönteni, hogy mely eszközök segíthetnek megoldani ezt a problémát, hogyan válasszuk ki, állítsuk be és támogassuk őket. Néhány tesztelő segítséget kér a DevOps-tól (emberektől), és legyünk őszinték, ez a megközelítés működik. Sok esetben ez lehet az egyetlen lehetőség, mivel hiányzik a teljes áttekintés az összes függőségről. De, ahogy tudjuk, a DevOps nagyon elfoglalt fiúk, hiszen az egész cég infrastruktúráján, a telepítésen, a monitorozáson, a mikroszolgáltatásokon és hasonló feladatokon kell gondolkodniuk a szervezettől/csapatoktól függően. Ahogy általában lenni szokott, az automatizálás nem prioritás. Ilyen esetekben próbálnunk kell a lehető legjobbat kihozni magunktól az elejétől a végéig. Ez csökkenti a függőségeket, felgyorsítja a munkafolyamatot, simábbá teszi a készségeinket, és lehetővé teszi, hogy átfogóbb képet kapjunk arról, ami történik.
A cikk a legkeresettebb és legnépszerűbb eszközöket mutatja be, valamint azt, hogyan használhatók lépésről lépésre az automatizálási infrastruktúra felépítésére. Minden csoport olyan eszközöket tartalmaz, amelyeket személyes tapasztalat alapján ellenőriztek. De ez nem jelenti azt, hogy ugyanazt kell használnod. Maguk az eszközök nem lényegesek, folyamatosan megjelennek és elavulnak. Mérnöki feladatunk a alapelvek megértése: miért van szükség erre a csoport eszközökre és milyen munkafeladatokat oldhatunk meg a segítségükkel. Ezért minden szakasz végén linkeket hagyok hasonló eszközökhöz, amelyeket esetleg a te szervezetedben is használnak.
Mi hiányzik a cikkből
Még egyszer hangsúlyozom, hogy a cikk nem konkrét eszközökről szól, ezért nem lesznek benne kódrészletek a dokumentációból és konkrét parancsok leírása. De minden szakasz végén linkeket hagyok a részletes tanulmányozáshoz.
Ez annak a következménye, hogy:
- ezt az anyagot nagyon könnyű megtalálni különböző forrásokban (dokumentáció, könyvek, videókurzusok);
- ha mélyebbre ásunk, akkor 10, 20, 30 részletet kellene írnom erről a cikkről (míg én 2-3 részre terveztem);
- egyszerűen nem szeretném pazarolni az idődet, mivel lehet, hogy más eszközöket szeretnél használni ugyanezen célok eléréséhez.
Gyakorlat
Nagyon szeretném, ha ez az anyag minden olvasónak hasznos lenne, nem csak elolvasva és elfelejtve. Bármelyik tanulmányozásban a gyakorlat rendkívül fontos elem. Ehhez készítettem. Emellett otthoni feladat vár rád, hogy biztos lehess benne, hogy nem másoltad gondolkodás nélkül a végrehajtandó parancsokat
Terv
Lépés
Technológia
Helyi futtatás (web / android bemutató tesztek előkészítése és helyi futtatásuk)
1
Node.js, Selenium, Appium
Verziókezelő rendszerek
2
Git
Konténerizálás
3
Docker, Selenium grid, Selenoid (Web, Android)
CI / CD
4
Gitlab CI
Felhőplatformok
5
Orkesztráció
Google Cloud Platform
6
Infrastruktúra mint kód (IaC)
Kubernetes
7
Terraform, Ansible
Minden szakasz felépítése
Az elbeszélés szemléletes fenntartásának érdekében minden szakasz a következő terv szerint van leírva:
a technológia rövid leírása,
- érték az automatizálási infrastruktúrában,
- a jelenlegi infrastruktúra állapotának illusztrációja,
- linkek a tanulmányozáshoz,
- hasonló eszközök.
- 1. Helyi tesztek futtatása
A technológia rövid leírása
Körvonalazott technológia
Ez csupán előkészítő lépés a helyi demótesztek elindításához és annak ellenőrzéséhez, hogy sikeresen teljesülnek. A gyakorlati rész Node.js-t használ, de a programozási nyelv és a platform nem lényeges, használhatja azokat, amelyek a cégnél rendelkezésre állnak.
Automatizálási eszközökként azonban javaslom a Selenium WebDriver használatát webplatformokhoz és az Appiumot Android-platformhoz, mivel a következő lépésekben Docker-képeket fogunk használni, amelyek kifejezetten ezekkel az eszközökkel működnek. Továbbá, az álláshirdetések követelményeire hivatkozva, ezek az eszközök a legkeresettebbek a piacon.
Ahogy észrevehette, csak a web- és Android-teszteket vizsgáljuk. Sajnos az IOS – teljesen más történet (köszönjük Apple). A tervek szerint a következő részekben szeretném bemutatni az IOS-szal kapcsolatos megoldásokat és gyakorlatokat.
Érték az automatizálási infrastruktúrához
Infrastruktúra szempontjából a helyi indításnak nincs értéke. Csak annyit ellenőriz, hogy a tesztek működnek a helyi gépen helyi böngészőkben és szimulátorokban. De mindenképpen ez egy szükséges kiindulópont.
A jelenlegi infrastruktúra állapotának illusztrációja
Tanulmányozásra vonatkozó linkek
Hasonló eszközök
- bármilyen programozási nyelv, amelyet szeret, a Selenium/Appium – tesztekkel;
- bármilyen teszt;
- bármilyen tesztfuttató.
2. Verziókezelő rendszerek (Git)
Körvonalazott technológia
Senkit sem ér meglepetésként, ha azt mondom, hogy a verziókezelő rendszer rendkívül fontos része a fejlesztésnek csapatban és egyedül is. Különböző forrásokra támaszkodva, magabiztosan mondhatjuk, hogy a Git a legnépszerűbb képviselő. A verziókezelő rendszer számos előnyt kínál, például kódmegosztást, verziók tárolását, visszaállítást előző ágakra, a projekt történetének figyelemmel kísérését és biztonsági másolatokat. Nem fogunk minden egyes pontot részletesen megvitatni, mivel biztos vagyok benne, hogy ezzel jól ismeri és használja a mindennapi munkájában. De ha esetleg nem, javaslom, hogy álljon meg a cikk olvasásában, és amilyen gyorsan csak lehet, pótolja ezt a hiányosságot.
Érték az automatizálási infrastruktúrához
Itt feltehetjük a jogos kérdést: „Miért mesél nekünk a Git-ről? Ezt mindenki tudja, és használja a fejlesztési kód és az automatikus tesztelés kódja számára.” Teljesen igaza van, de ebben a cikkben az infrastruktúráról beszélünk, és ez a rész áttekintést nyújt a 7. szakaszhoz: „Infrastruktúra mint kód (IaC)”. Számunkra ez azt jelenti, hogy az egész infrastruktúra, beleértve a tesztkörnyezetet is, kódként van leírva, ezért a verziókezelő rendszereket is rá lehet alkalmazni, és hasonló előnyöket élvezhetünk, mint a fejlesztési kód esetében.
Részletesebben fogunk foglalkozni az IaC-vel a 7. lépésben, de még most is elkezdhetjük használni a Git-et helyben, egy helyi tároló létrehozásával. Az általános kép bővülni fog, amikor távoli tárolót adunk az infrastruktúrához.
A jelenlegi infrastruktúra állapotának illusztrációja
Tanulmányozásra vonatkozó linkek
Hasonló eszközök
3. Konténerizáció (Docker)
Körvonalazott technológia
A konténerizációs technológia játékváltoztatását bemutatandó, menjünk vissza több évtizeddel ezelőttre. Akkoriban az emberek szervergépeket vásároltak és használtak az alkalmazások futtatásához. De a szükséges erőforrások többsége nem volt előre ismert. Ennek következtében a cégek pénzt költöttek drága, erős szerverek vásárlására, de ezen kapacitások egy része nem volt teljesen kihasználva.
A következő evolúciós lépés a virtuális gépek (VM) bevezetése volt, amelyek megoldották a felhasználatlan erőforrások költségsorvasztását. Ez a technológia lehetővé tette az alkalmazások független futtatását egyetlen szerveren belül, teljesen elkülönített környezet biztosításával. De sajnos, bármely technológiának megvannak a saját hátrányai. A VM-ek indítása teljes operációs rendszert igényel, ami CPU-, RAM-, tárolási igényt jelent, és az OS-tól függően figyelembe kell venni a licenszköltségeket is. Ezek a tényezők befolyásolják a betöltési sebességet és bonyolítják a hordozhatóságot.
Így elérkeztünk a konténerizációhoz. Ismét ez a technológia megoldotta az előző problémát, mivel a konténerek nem használnak teljes operációs rendszert, ami jelentős erőforrás-kibocsátást tesz lehetővé, és gyors, rugalmas megoldást kínál a hordozhatóságra.
Természetesen a konténerizációs technológia nem újkeletű, és először az 1970-es évek végén jelent meg. Ezekben az időkben számos kutatás, fejlesztés és kísérlet folyt. De pontosan a Docker alkalmazta ezt a technológiát, és tette tömegek számára könnyen hozzáférhetővé. Manapság, amikor a konténerekről beszélünk, többnyire a Dockerra gondolunk. Amikor Docker-konténerekről beszélünk, Linux-konténereket értünk alatta. Használhatunk Windows- és macOS-rendszereket is konténerek futtatására, de fontos megérteni, hogy ebben az esetben további réteg jelenik meg. Például a Docker a Mac-en láthatatlanul indítja a konténereket egy könnyű Linux VM belsejében. Ezzel a témával még visszatérünk, amikor az Android-emulátorok konténerekben történő futtatásáról beszélünk, mivel itt egy nagyon fontos szempont merül fel, amelyet részletesebben kell megvizsgálnunk.
Érték az automatizálási infrastruktúrához
Megállapítottuk, hogy a konténerizáció és a Docker nagyszerű. Nézzük meg ezt az automatizáció kontextusában, hiszen minden eszköznek vagy technológiának meg kell oldania valamilyen problémát. Jelöljük meg az automatizált tesztelés nyilvánvaló problémáit a UI-tesztek kontextusában:
- rengeteg függőség a Selenium és különösen az Appium telepítésekor;
- kompatibilitási problémák a böngészők, szimulátorok és driverek verziói között;
- izolált tér hiánya a böngészők/szimulátorok számára, ami különösen kritikus a párhuzamos futtatás során;
- nehéz kezelni és karbantartani, ha egyszerre 10, 50, 100 vagy akár 1000 böngészőt kell futtatnunk.
De mivel a Selenium a legnépszerűbb automatizálási eszköz, míg a Docker a legnépszerűbb konténerizálási eszköz, senkit nem lephet meg, hogy valaki megpróbálta őket kombinálni, hogy egy erőteljes eszközt kapjon a fent említett problémák megoldására. Nézzük meg ezeket a megoldásokat részletesebben.
Selenium grid dockerben
Ez az eszköz a világ legnépszerűbb Selenium eszköze a több böngésző egyidejű futtatására több gépen, központi csomópontból történő kezelés mellett. A futtatáshoz legalább 2 részegységet kell regisztrálni: Hub és Node(s). A Hub a központi csomópont, amely megkap minden kérést a tesztektől, és elosztja azokat a megfelelő Nodes-ra. Minden Node számára beállíthatunk egy konkrét konfigurációt, például megadhatjuk a kívánt böngészőt és annak verzióját. Azonban nekünk magunknak is gondoskodnunk kell a böngészők megfelelő illesztőprogramjairól, és telepítenünk kell őket a szükséges Nodes-ra. Éppen ezért a Selenium grid tiszta formában nem használható, kivéve azon eseteket, amikor olyan böngészőkkel kell dolgoznunk, amelyeket nem lehet telepíteni Linux OS-re. Minden egyéb esetben jelentősen rugalmasabb és helyes megoldás a Docker-képek használata a Selenium grid Hub és Nodes indításához. Ez a megközelítés jelentősen leegyszerűsíti a csomópontok kezelését, mivel kiválaszthatjuk a számunkra szükséges képet, amely már tartalmazza a megfelelő böngésző- és illesztőprogram-verziókat.
A stabilitásával kapcsolatos negatív vélemények ellenére, különösen ha sok Node-ot indítunk párhuzamosan, a Selenium grid még mindig a legnépszerűbb eszköz a párhuzamos Selenium-tesztek futtatására. Fontos megjegyezni, hogy az open-source folyamatban folyamatosan különféle fejlesztések és módosítások jelennek meg, amelyek a különböző szűk keresztmetszetek ellen küzdenek.
Selenoid for Web
Ez az eszköz áttörést jelent a Selenium világában, mivel azonnal működik, és jelentősen megkönnyítette sok automatizálási mérnök életét. Mindenekelőtt nem egy újabb módosítása a Selenium grid-nek. Ehelyett a fejlesztők egy teljesen új Selenium Hub verziót hoztak létre Golang nyelven, ami a különböző böngészőkhez készült könnyű Docker-képek kombinációjával lökést adott a tesztelés automatizálásának fejlődésében. Ráadásul a Selenium Grid esetében előre meg kell határoznunk az összes szükséges böngészőt és azok verzióit, ami nem jelent problémát, ha csak egyetlen böngészővel dolgozunk. De amikor több támogatható böngészőről van szó, a Selenoid az első számú megoldás, köszönhetően a 'böngésző igény szerint' funkciónak. Minden, amire szükségünk van, az előre lementett szükséges képek és a Selenoid által használt konfigurációs fájl frissítése. Miután a Selenoid kérést kap a tesztektől, automatikusan elindítja a szükséges konténert a megfelelő böngészővel. Amikor a teszt befejeződik, a Selenoid leállítja a konténert, ezzel felszabadítva az erőforrásokat a következő kérésekhez. Ez a megközelítés teljesen megszünteti a 'csomópontok degradációjának' ismert problémáját, amit gyakran tapasztalunk a Selenium grid esetében.
De sajnos a Selenoid még mindig nem ezüstlövedék. Megkaptuk a 'böngésző igény szerint' funkciót, de a 'különböző erőforrások igény szerint' még nem elérhető. A Selenoid használatához fizikai gépen vagy virtuális gépen kell telepítenünk, ami azt jelenti, hogy előre tudnunk kell, mennyi erőforrást kell biztosítanunk. Úgy gondolom, hogy ez nem probléma a kis projektek számára, amelyek párhuzamosan 10, 20 vagy akár 30 böngészőt futtatnak. De mi van, ha 100, 500, 1000 és annál több kell? Nincs értelme folyamatosan fenntartani és fizetni ennyi erőforrásért. Az 5. és 6. szekcióban beszélni fogunk azokról a megoldásokról, amelyek lehetővé teszik a skálázást, ezzel jelentősen csökkentve a cég költségeit.
Selenoid Androidhoz
A Selenoid sikerét követően, mint webautomatikai eszköz, az emberek valami hasonlót szerettek volna Android számára. És ez megtörtént – a Selenoid megjelent Android támogatással. Magas szintű felhasználói szempontból a működési elv hasonló a webautomatikához. Az egyetlen különbség, hogy a böngészőkkel ellátott konténerek helyett a Selenoid Android-emulátorokkal ellátott konténereket indít. Véleményem szerint ez a legfejlettebb ingyenes eszköz az Android-teszteken párhuzamos futtatására.
Nagyon nem szeretném megemlíteni ennek az eszköznek a negatív oldalait, mivel valóban nagyon tetszik. De mégis, ugyanazok a problémák jelentkeznek itt is, amelyek a webautomatikához kapcsolódnak, és amelyek skálázással kapcsolatosak. Ezen felül egy másik korlátozásról is beszélnem kell, amely meglepetést okozhat, ha először állítjuk be az eszközt. Android-képek futtatásához fizikai gépre vagy VM-re van szükség, amely támogatja a nested virtualisation-t. A gyakorlati útmutatómban megmutatom, hogyan aktiválhatjuk ezt Linux VM-en. Azonban, ha macOS felhasználó vagy, és helyben szeretnéd telepíteni a Selenoid-ot, az Android-tesztek futtatása lehetetlen lesz. De mindig elindíthatod a Linux VM-et helyben, a beállított ‘nested virtualisation’-nal és futtathatod a Selenoid-ot belül.
A jelenlegi infrastruktúra állapotának illusztrációja
A cikk kontextusában 2 eszközt fogunk hozzáadni az infrastruktúra illusztrálásához. Ezek a Selenium grid webtesztekhez és a Selenoid Android-tesztekhez. A GitHub útmutatómban azt is meg fogom mutatni, hogyan használhatjuk a Selenoid-ot webtesztek futtatására.
Tanulmányozásra vonatkozó linkek
Hasonló eszközök
- Vannak más konténerizáló eszközök is, de a Docker a legnépszerűbb. Ha valami mást szeretnél kipróbálni, vedd figyelembe, hogy azok az eszközök, amelyeket a Selenium-tesztek párhuzamos futtatására megvizsgáltunk, nem fognak működni dobozból kivéve.
- Ahogy már említettem, sok Selenium grid módosítás létezik, például.
4. CI / CD
Körvonalazott technológia
A folyamatos integráció gyakorlata meglehetősen népszerű a fejlesztésben, és egy szinten áll a verziókezelő rendszerekkel. Ennek ellenére úgy érzem, hogy némi zűrzavar van a terminológiát illetően. Ebben a bekezdésben szeretném bemutatni ennek a technológiának három módosítását az én nézőpontomból. Az interneten számos cikket találhat különböző értelmezésekkel, és ez teljesen normális, ha a véleménye eltér a másokétól. A legfontosabb, hogy egy hullámhosszon legyen a kollégáival.
Tehát, három kifejezés létezik: CI — Continuous Integration (folyamatos integráció), CD — Continuous Delivery (folyamatos szállítás) és újra CD — Continuous Deployment (folyamatos telepítés). (A továbbiakban ezeket a kifejezéseket angol nyelven fogom használni.). Minden módosítás kiegészít néhány extra lépést a fejlesztési folyamatában. De a szó continuous (folyamatos) a legfontosabb. Ebben a kontextusban valami olyasmit értünk, ami a kezdetektől a végéig, megszakítások vagy manuális beavatkozás nélkül történik. Nézzük meg a CI & CD-t és a CD-t ebben a kontextusban.
- A Continuous Integration – a fejlődés első lépése. Miután új kódot küldünk a szerverre, gyors visszajelzést várunk arról, hogy a módosításainkkal minden rendben van. A CI általában magában foglalja a statikus kód-elemző eszközök és a moduláris/belső API-tesztek futtatását. Ez lehetővé teszi számunkra, hogy néhány másodpercen vagy percen belül információt nyerjünk a kódunkról.
- A Continuous Delivery a fejlettebb lépés, ahol integrációs/UI teszteket futtatunk. Azonban ezen a ponton nem kapunk visszajelzéseket olyan gyorsan, mint a CI esetében. Először is, ezek a tesztek több időt igényelnek a végrehajtáshoz. Másodszor, a futtatás előtt a változtatásokat a teszt/staging környezetbe kell telepíteni. Továbbá, ha mobilfejlesztésről beszélünk, akkor egy plusz lépés is van az alkalmazásunk építésének elkészítésére.
- A Continuous Deployment A folyamattal automatikusan kiadjuk (release) a módosításainkat a production-ra, ha az összes elfogadási tesztet sikeresen teljesítettük az előző szakaszokban. Ezen kívül a kiadási szakasz után különféle lépéseket, például smoke tesztek futtatását a production-on és érdekes metrikák gyűjtését is beállíthatjuk. A Folyamatos Telepítés csak akkor lehetséges, ha az automatizált tesztekkel való lefedettség megfelelő. Ha bármilyen manuális beavatkozásra, beleértve a tesztelést is, szükség van, akkor az már nem Folyamatos (continuous). Ekkor azt mondhatjuk, hogy a vezérlőnk csak a Folyamatos Kiszállítás gyakorlatainak felel meg.
Érték az automatizálási infrastruktúrához
Ebben a fejezetben pontosítanom kell, hogy amikor az end-to-end UI-tesztekről beszélünk, ez azt jelenti, hogy be kell állítanunk a módosításainkat és a kapcsolódó szolgáltatásokat a tesztkörnyezetekben. A Folyamatos Integrációs folyamat nem alkalmazható erre a feladatra, ezért legalább a Folyamatos Kiszállítás gyakorlatait be kell vezetnünk. A Folyamatos Telepítés szintén értelmet nyer az UI-tesztekkel kapcsolatban, ha a production-on szeretnénk futtatni őket.
Mielőtt a struktúra módosításának példájára rátérnénk, szeretnék néhány szót szólni a GitLab CI-ről. Más CI/CD eszközökkel ellentétben a GitLab távoli tárolót és sok egyéb kiegészítő funkciót is kínál. Így a GitLab több mint CI. Alapértelmezés szerint tartalmaz forráskódkezelést, Agile menedzsmentet, CI/CD pipeline-okat, naplózási eszközöket és metrikák gyűjtését. A GitLab architektúrája a GitLab CI/CD-ből és a GitLab Runnerből áll. Az alábbiakban bemutatok egy rövid leírást a hivatalos weboldalról:
A Gitlab CI/CD egy webalkalmazás, amely API-val rendelkezik, állapotát egy adatbázisban tárolja, projektek/építkezések kezelésére és felhasználói felület biztosítására szolgál. A GitLab Runner egy alkalmazás, amely feldolgozza az építkezéseket. Külön telepíthető és a GitLab CI/CD-vel API-n keresztül működik. A tesztek futtatásához szükséged van mind a GitLab példányra, mind a Runner-re.
A jelenlegi infrastruktúra állapotának illusztrációja
Tanulmányozásra vonatkozó linkek
Hasonló eszközök
- És sok más
5. Felhőplatformok
Körvonalazott technológia
Ebben a szakaszban a népszerű írányról beszélünk, amelyet 'nyilvános felhőknek' neveznek. Annak ellenére, hogy a fent említett virtualizációs és konténerizációs technológiák óriási előnyöket nyújtanak, még mindig szükségünk van számítási erőforrásokra. A vállalatok drága szervereket vásárolnak vagy adatközpontokat bérelnek, de ilyenkor el kell végezniük a számításokat (néha irreálisakat) arról, mennyi erőforrásra lesz szükségünk, fogjuk-e azokat 24/7-ben használni és mire. Például a gyártási környezethez 24 órás működésű szerver szükséges, de szükségünk van hasonló erőforrásokra a teszteléshez munkaidőn kívül? Ez szintén a végrehajtott tesztelés típusától függ. Például terhelés- vagy stresszteszteket tervezünk futtatni munkaidőn kívül, hogy másnapra eredményeket kapjunk. De a végpontok közötti automatikus tesztekhez és különösen a manuális tesztelési környezetekhez nem szükséges a szerverek 24 órás elérhetősége. Az ilyen helyzetekre jó lenne annyi erőforrást kapni, amennyire szükség van, használni őket, és leállítani a fizetést, amikor már nincs rájuk szükség. Ráadásul nagyszerű lenne azokat azonnal megkapni, mindössze néhány kattintással vagy pár szkript futtatásával. Erre szolgálnak a nyilvános felhők. Nézzük meg a definíciót:
A nyilvános felhő azon számítási szolgáltatásokat jelenti, amelyeket harmadik fél szolgáltatói nyújtanak a nyilvános Interneten, lehetővé téve, hogy bárki igénybe vegye vagy megvásárolja azokat. Ezek lehetnek ingyenesek vagy kérésre értékesíthetők, lehetővé téve a vásárlók számára, hogy csak a felhasznált CPU ciklusokért, tárolásért vagy sávszélességért fizessenek.
Az a vélemény terjedt el, hogy a nyilvános felhők drágák. De a kulcsfontosságú koncepciójuk a vállalat költségeinek csökkentése. Mint említettem, a nyilvános felhők lehetővé teszik az erőforrások igény szerinti beszerzését, és csak a használatuk időtartama után kell fizetni. Ezen kívül néha elfelejtjük, hogy a munkavállalók fizetést kapnak, és a szakemberek is drága erőforrásnak számítanak. Figyelembe kell venni, hogy a nyilvános felhők jelentősen megkönnyítik az infrastruktúra karbantartását, lehetővé téve, hogy a mérnökök fontosabb feladatokra összpontosítsanak.
Érték az automatizálási infrastruktúrához
Milyen konkrét erőforrásokra van szükségünk az end-to-end UI teszteléshez? Főként virtuális gépekre vagy klaszterekre (a Kubernetesről a következő szekcióban beszélünk) van szükségünk a böngészők és emulátorok futtatásához. Minél több böngészőt és emulátort szeretnénk egyszerre futtatni, annál több CPU-ra és memóriára van szükség, és annál többet kell ezért fizetnünk. Így a nyilvános felhők az automatizált tesztelés szempontjából lehetővé teszik számunkra, hogy igény szerint nagy számú (100, 200, 1000 …) böngészőt/emulátort futtassunk, a tesztelési eredményekhez a lehető leggyorsabban hozzáférjünk, és abbahagyjuk az ilyen őrült erőforrásigényes kapacitásokért való fizetést.
A legnépszerűbb felhőszolgáltatók közé tartozik az Amazon Web Services (AWS), a Microsoft Azure és a Google Cloud Platform (GCP). A gyakorlati útmutatóban a GCP használatának példáit mutatjuk be, de lényegében nem számít, hogy mit használsz az automatizálási feladatokhoz. Mindegyik körülbelül hasonló funkciókat kínál. Általában, a szolgáltató kiválasztásánál az útmutató az egész vállalat infrastruktúrájának és üzleti követelményeinek fókuszál, ami túlmutat a cikk keretein. Az automatizálási mérnökök számára érdekesebb lenne összehasonlítani a felhőszolgáltatók és a kifejezetten tesztelési célokra szolgáló felhőplatformok, mint a Sauce Labs, a BrowserStack, a BitBar stb. használatát. Szóval, nézzük is meg! Véleményem szerint a Sauce Labs a legismertebb felhőtesztelő szolgáltatás, ezért ezt választottam összehasonlításra.
GCP vs Sauce Labs automatizálási célokra:
Képzeljük el, hogy egyszerre 8 webtesztet és 8 Android tesztet kell futtatnunk. Ehhez a GCP-t fogjuk használni, és 2 virtuális gépet indítunk el Selenoid-dal. Az elsőn 8 böngésző konténert fogunk indítani. A másodikon – 8 emulátor konténert. Nézzük meg az árakat:
Egy Chrome konténer elindításához szükségünk lesz n1-standard-1 gép. Android esetén ez lesz n1-standard-4 az egyik emulátorhoz. Valójában egy rugalmasabb és olcsóbb megoldás, ha konkrét felhasználói értékeket állítunk be a CPU/Memória számára, de jelenleg a Sauce Labs-szal való összehasonlítás szempontjából ez nem lényeges.
És itt vannak a Sauce Labs használati tarifái:
Azt hiszem, már észrevetted a különbséget, de mindenesetre itt egy táblázat a számításainkról a feladatunkhoz:
Szükséges erőforrások
Havi
Munkaórák(8 a.m — 8 p.m)
Munkaórák+ Preemptible
GCP Webhez
n1-standard-1 x 8 = n1-standard-8
$194.18
23 nap * 12 óra * 0.38 = 104.88$
23 nap * 12 óra * 0.08 = 22.08$
Sauce Labs a Webből
Virtuális Cloud8 párhuzamos tesztelés
$1.559
—
—
GCP Androidra
n1-standard-4 x 8: n1-standard-16
$776.72
23 nap * 12 óra * 1.52 = 419.52$
23 nap * 12 óra * 0.32 = 88.32$
Sauce Labs Androidra
Valós Eszköz Felhő 8 párhuzamos tesztelés
$1.999
—
—
Ahogy látható, az árkülönbség hatalmas, különösen ha a teszteket csak a munkaidő 12 órás időtartamában futtatjuk. De a költségek még tovább csökkenthetők, ha preemptible gépeket használunk. Mi is az?
A preemptible VM egy olyan példány, amelyet sokkal alacsonyabb áron hozhatunk létre és futhatunk, mint a normál példányok. Azonban a Compute Engine megszüntetheti (preempt) ezeket a példányokat, ha más feladatokhoz hozzáférésre van szüksége. A preemptible példányok a Compute Engine felesleges kapacitása, így a rendelkezésre állásuk a használattal változik.
Ha az alkalmazásai hibatűrőek, és elbírják a példányok esetleges megszüntetését, akkor a preemptible példányok jelentősen csökkenthetik a Compute Engine költségeit. Például a tételes feldolgozó munka futtatható preemptible példányokon. Ha ezek közül néhány példány megszűnik a feldolgozás során, a munka lelassul, de nem áll meg teljesen. A preemptible példányok befejezik a tételes feldolgozási feladatait anélkül, hogy további terhet rónának a meglévő példányaira, és anélkül, hogy teljes árat kellene fizetnie további normál példányokért.
És ez még nem minden! Valójában biztos vagyok benne, hogy senki sem futtat teszteket 12 órán keresztül megszakítás nélkül. Ha így van, akkor automatikusan indíthatja és leállíthatja a virtuális gépeket, amikor nincsenek szükség. A tényleges használati idő lecsökkenthető akár napi 6 órára is. Ekkor a költségek a mi feladatunk kontextusában havi 11$-ra csökkennek 8 böngésző esetén. Nem csodás? De a preemptible gépekkel óvatosnak kell lennünk, és készen kell állnunk az megszakításokra és a nem stabil működésre, bár ezek a helyzetek előre megfontolhatók és programozásilag kezelhetők. Megéri!
De semmiképpen sem mondom, hogy 'soha ne használja a felhős tesztelési farmokat'. Számos előnyük van. Először is, ez nem csak egy virtuális gép, hanem egy valódi automatizálási megoldás beépített funkciókkal: távoli hozzáférés, naplók, képernyőfelvételek, video rögzítés, különféle böngészők és valós mobil eszközök. Sok helyzetben ez pótolhatatlan, luxus alternatíva lehet. Különösen a tesztelési platformokat hasznosak az IOS automatizálására, amikor a nyilvános felhők csak Linux/WIndows rendszereket tudnak kínálni. De az IOS-ról a következő cikkekben fogunk beszélni. Mindig azt javaslom, hogy a helyzet alapján döntsünk, és a feladatoktól induljunk ki: egyes helyzetekben olcsóbb és hatékonyabb nyilvános felhőket használni, míg másokban a tesztelési platformok kétségtelenül megérik a pénzüket.
A jelenlegi infrastruktúra állapotának illusztrációja
Tanulmányozásra vonatkozó linkek
Hasonló eszközök:
6. Orkestráció
Körvonalazott technológia
Jó hírem van – majdnem a cikk végére értünk! Jelenleg az automatizálási infrastruktúránk a web- és Android-teszteket tartalmazza, amelyeket a GitLab CI párhuzamosan futtatunk Docker-támogató eszközökkel: Selenium grid és Selenoid. Ezen kívül a GCP-n keresztül létrehozott virtuális gépeinket használjuk böngészőkkel és emulátorokkal teli konténerek indítására. A költségek csökkentése érdekében ezeket a virtuális gépeket csak igény szerint indítjuk el, és leállítjuk, amikor nincs folyamatban tesztelés. Van még valami, ami javíthatja az infrastruktúránkat? A válasz – igen! Üdvözöljük a Kubernetest (K8s)!
Először nézzük meg, hogyan kapcsolódnak egymáshoz az orkestráció, a klaszter és a Kubernetes. Magas szinten az orkestráció egy rendszer, amely telepíti és kezeli az alkalmazásokat. Az automatizált teszteléshez ilyen konténerizálható alkalmazások a Selenium grid és a Selenoid. A Docker és a K8s kiegészítik egymást. Az elsőt alkalmazások telepítésére, a másodikat orkestrációra használják. A K8s viszont egy klaszter. A klaszter feladata, hogy a virtuális gépeket node-ként használja, ami lehetővé teszi különböző funkciók, programok és szolgáltatások telepítését egyetlen szerveren (klaszteren) belül. Ha valamelyik node leáll, a többi node átveszi a feladatokat, biztosítva az alkalmazásunk zökkenőmentes működését. Ezen kívül a K8s fontos funkcióval rendelkezik a skálázás (scaling) terén, amely lehetővé teszi számunkra az optimális erőforrások automatikus beszerzését a terhelés és az előírt korlátok alapján.
Az igazság az, hogy a Kubernetes manuális telepítése a nulláról egyáltalán nem triviális feladat. Hivatkozom a híres "Kubernetes The Hard Way" gyakorlati útmutatóra, és ha érdekel, gyakorolhatsz is. Szerencsére azonban léteznek alternatív módok és eszközök. Az egyik legegyszerűbb a Google Kubernetes Engine (GKE) használata a GCP-n, amely lehetővé teszi, hogy néhány kattintással készen álló klasztert kapjunk. Az alapképzésemhez kifejezetten ezt a megközelítést ajánlom, mert lehetővé teszi, hogy arra összpontosíts, hogyan használd a K8s-t a feladataidhoz, ahelyett, hogy azzal foglalkoznál, hogyan kell az egyes belső komponenseket integrálni egymással.
Érték az automatizálási infrastruktúrához
Nézzük meg néhány jelentős funkciót, amelyet a K8s nyújt:
- alkalmazás telepítése: multi-node klaszter használata, a VM-ek helyett;
- dinamikus skálázás: csökkenti az erőforrások költségeit, amelyeket csak igény szerint használnak;
- önjavítás (Self-healing): automatikus helyreállítás a pods esetén (ami visszaállítja a konténereket is);
- frissítések kiadása és változások visszaállítása leállás nélkül: az eszközök, böngészők és emulátorok frissítése nem zavarja a jelenlegi felhasználók munkáját
De a K8s még mindig nem ezüst nyílvessző. Hogy megértsük az összes előnyét és korlátozását az általunk vizsgált eszközök (Selenium grid, Selenoid) kontextusában, röviden beszéljünk a K8s felépítéséről. A klaszter két típusú csomópontot tartalmaz: Master Nodes és Worker Nodes. A Master Nodes felelősek a kezelésért, telepítésért és a ütemezési döntésekért. A Worker Nodes az, ahol az alkalmazások futnak. A Csomópontok tartalmazzák a konténer futtatási környezetét is. Esetünkben ez a Docker, amely felelős a konténerekkel kapcsolatos műveletekért. De léteznek alternatív megoldások is, például. Fontos megérteni, hogy a skálázás vagy az önjavítás nem közvetlenül a konténerekre vonatkozik. Ez a pods számának hozzáadásával/csökkentésével valósul meg, amelyek viszont konténereket tartalmaznak (általában egy konténer pod-on, de a feladat függvényében lehet több is). A magas szintű hierarchia a worker nodes-t képviseli, amelyekben pods találhatók, és amelyekben konténerek működnek.
A skálázási funkció kulcsfontosságú, és alkalmazható mind a cluster node-pool belsejében található nodes, mind a node-on belüli pods esetében. Kétféle skálázás létezik, amelyek mind a nodes-ra, mind a pods-ra vonatkozhatnak. Az első típusa - horizontális - a nodes/pods számának növelésével valósul meg. Ez a típus a preferáltabb. A második típus, ennek megfelelően, vertikális. A skálázás a nodes/pods méretének növelésével történik, nem pedig a számukével.
Most nézzük meg eszközeinket a fent említett kifejezések tükrében.
Selenium grid
Ahogyan azt korábban említettük, a Selenium grid nagyon népszerű eszköz, és nem meglepő, hogy konténerizálták. Következésképpen nem meglepő, hogy a Selenium grid telepíthető K8s-be. Példa arra, hogyan kell ezt megtenni, megtalálható a hivatalos K8s-repozitóriumban. Mint mindig, linkeket csatolok a szekció végén. Ezenkívül a gyakorlati útmutató bemutatja, hogyan lehet ezt megtenni Terraformon keresztül. Van egy útmutató is, amely bemutatja, hogyan lehet skálázni a pods számát, amelyek böngészőket tartalmazó konténereket tartalmaznak. Azonban az automatikus skálázási funkció a K8s kontextusában még mindig nem teljesen egyértelmű feladat. Amikor elkezdtem a tanulást, nem találtam gyakorlati útmutatót vagy ajánlásokat. Több kutatás és kísérlet után, a DevOps csapat támogatásával, a böngészőket tartalmazó konténerek egy pod-on belüli felállításának megközelítését választottuk, amely egy worker node-on található. Ez a megoldás lehetővé teszi számunkra a nodes horizontális skálázási stratégiájának alkalmazását a számuk növelésével. Remélem, hogy a jövőben helyzet változni fog, és egyre több leírást és kész megoldást látunk, különösen a Selenium grid 4 kibocsátása után, amely átalakított belső architektúrával rendelkezik.
Selenoid:
Jelenleg a Selenoid K8s-ben való telepítése a legnagyobb csalódás. Nem kompatibilisek. Elméletileg fel tudjuk emelni a Selenoid konténert egy pod-on belül, de amikor a Selenoid böngészőket futtatni kezd, azok még mindig ugyanabban a pod-ban lesznek. Ez lehetetlenné teszi a skálázást, és ennek eredményeként a Selenoid munkája a klaszterben nem különbözik a virtuális gépen való működéstől. A történet vége.
Moon:
Tudva ezt a szűk keresztmetszetet a Selenoid használata során, a fejlesztők egy erősebb eszközt jelentettek be, amelyet Moonnak hívtak. Ez az eszköz eredetileg a Kubernetes kezelésére lett tervezve, ezért lehetésges és szükséges az automatikus skálázás funkció használata. Sőt, azt mondanám, hogy jelenleg ez a cikk bemutatja az etcd adatok közvetlen kezelésének lehetőségét, vagyis a Kubernetes API megkerülését. Néha ez a megközelítés lehetővé teszi, hogy 'furfangos dolgokat' csináljunk. A szövegben bemutatott műveleteket valódi K8s klasztereken teszteltük. Azonban a széleskörű felhasználásra való alkalmasságuk státusza - az eszköz a Selenium világában, amely dobozból kivéve támogatja a natív K8s klasztert (már nem, lásd a következő eszközt ). A Moon kulcsfontosságú jellemzője, amely biztosítja ezt a támogatást, a következő:
Teljesen állapotmentes. A Selenoid memóriában tárolja a jelenleg futó böngésző ülésekről szóló információkat. Ha valamilyen okból a folyamata összeomlik, akkor az összes futó ülés elveszik. Ezzel szemben a Moonnak nincsen belső állapota, és sok példányban replikálható adatközpontok között. A böngésző ülések életben maradnak, még akkor is, ha egy vagy több replikát leállítanak.
Tehát a Moon egy nagyszerű megoldás, de van egy problémája: nem ingyenes. Az ár a ülések számától függ. Ingyen csak 0-4 ülést indíthat, ami nem igazán hasznos. De az ötödik üléstől kezdve minden egyes ülésért 5 dollárt kell fizetni. A helyzet cégről cégre változhat, de a mi esetünkben a Moon használata értelmetlen. Ahogy fentebb már említettem, indíthatunk VMs-t Selenium Grid-del igény szerint, vagy növelhetjük a Nodes számát a klaszterben. Körülbelül egy pipeline-on 500 böngészőt indítunk el, és minden erőforrást leállítunk a tesztek befejezése után. Ha Moon-t használnánk, 500 x 5 = 2500 dollárt kellene fizetnünk havonta, függetlenül attól, hogy milyen gyakran futtatjuk a teszteket. Ismétlem, nem azt mondom, hogy „ne használja a Moon-t”. A feladataihoz ez elengedhetetlen megoldás lehet, például, ha a szervezetében sok projekt/csapat van, és egy hatalmas közös klaszterre van szüksége mindenkinek. Mint mindig, a cikk végén linket hagyok, és ajánlom, hogy végezze el a szükséges számításokat a saját helyzete szempontjából.
Callisto: (Figyelem! Ez nem szerepel az eredeti cikkben, és csak a orosz fordításban található.)
Ahogy mondtam, a Selenium egy nagyon népszerű eszköz, és az IT szféra nagyon gyorsan fejlődik. Amíg a fordításon dolgoztam, megjelent egy új, ígéretes eszköz, a Callisto (helló Cypress és más Selenium-ölők). Ez natívan működik a K8s-szel, és lehetővé teszi a Selenoid-konténerek indítását a pods-ban, elosztva a Nodes-on. Minden azonnal működik dobozból kivéve, beleértve az automatikus skálázást is. Fantasztikus, de tesztelni kell. Már sikerült telepítenem ezt az eszközt, és elvégezni néhány kísérletet. De korai lenne következtetéseket levonni, hosszú távú eredmények után talán írok egy áttekintést a következő cikkekben. Most csak linkeket hagyok az önálló kutatáshoz.
A jelenlegi infrastruktúra állapotának illusztrációja
Tanulmányozásra vonatkozó linkek
Tanulmányozásra vonatkozó linkek
Hasonló eszközök
7. Infrastruktúra, mint kód (IaC)
Körvonalazott technológia
És itt vagyunk az utolsó fejezetnél. Általában ez a technológia és a hozzá kapcsolódó feladatok nem tartoznak az automatizáló mérnökök felelősségi körébe. Ennek megvannak a maga okai. Először is, sok szervezetben az infrastruktúra kérdéseit a DevOps osztály irányítja, és a fejlesztőcsapatok nem különösebben aggódnak amiatt, hogy mivel működik a pipeline, és hogyan kell fenntartani mindazt, ami kapcsolódik hozzá. Másodszor, legyünk őszinték, az „Infrastruktúra, mint kód (IaC)” gyakorlata még mindig nem elterjedt sok cégnél. De kétségtelenül népszerű trenddé vált, és fontos, hogy próbáljunk részt venni a hozzá kapcsolódó folyamatokban, megközelítésekben és eszközökben. Vagy legalább legyünk tájékozottak a fejleményekről.
Kezdjük a motivációval, hogy miért használjuk ezt a megközelítést. Már beszéltünk arról, hogy a GitlabCI tesztek futtatásához legalább a Gitlab Runner indításához szükséges erőforrásokra van szükség. A böngészők/emulátorokkal rendelkező konténerek indításához VM-et vagy klasztert kell lefoglalnunk. A teszteléshez szükséges erőforrások mellett jelentős számú kapacitásra van szükség a fejlesztési, staging és production környezetek fenntartásához, ami magában foglalja az adatbázisokat, automatikus ütemezéseket, hálózati konfigurációkat, terhelésmegosztót, felhasználói jogosultságokat és így tovább. A kulcsprobléma a mindenhez szükséges támogatási erőfeszítésekben rejlik. Számos módja van annak, hogyan módosíthatunk és gördíthetünk ki frissítéseket. Például a GCP kontextusában használhatjuk a böngésző UI konzolját, és minden műveletet végrehajthatunk gombok kattintásával. Alternatív megoldásként használhatjuk az API-hívásokat, hogy interakcióba lépjünk a felhő entitásokkal, vagy alkalmazhatjuk a gcloud parancssori eszközt a szükséges műveletek elvégzéséhez. De ha valóban sok különböző entitás és infrastrukturális elem van, akkor nehézzé vagy akár lehetetlenné válik minden művelet manuális végrehajtása. Továbbá, minden ilyen manuális akció nem ellenőrzött. Nem tudjuk őket review-ra küldeni végrehajtás előtt, nem használhatjuk a verziókezelő rendszert, és gyorsan visszaállítani a módosításokat, amelyek incidenshez vezettek. E problémák megoldására az mérnökök automatikus bash/shell szkriptek létrehozásával foglalkoztak, ami nem sokkal jobb, mint a korábbi módszerek, mivel nem igazán könnyű ezeket gyorsan elolvasni, megérteni, karbantartani és módosítani eljárásos stílusban.
Ebben a cikkben és gyakorlati útmutatóban két olyan eszközt használok, amelyek az IaC gyakorlatához tartoznak. Ezek a Terraform és az Ansible. Néhányan úgy vélik, hogy nincs értelme ezeket egyidejűleg használni, mivel a funkcióik hasonlóak és kölcsönösen helyettesíthetik egymást. Az igazság azonban az, hogy eredetileg teljesen más feladatokat látnak el. A tény, hogy ezeket az eszközöket kiegészítik egymást, a HashiCorp és a RedHat cégeket képviselő fejlesztők közös prezentációján is megerősítették. A koncepcionális különbség abban rejlik, hogy a Terraform egy provisioning-eszköz, amely a szerverek kezelésére szolgál. Míg az Ansible egy konfigurációkezelő eszköz, amelynek feladata a szoftver telepítése, beállítása és kezelése ezeken a szervereken.
Ezeknek az eszközöknek egy másik kulcsfontosságú megkülönböztető jellemzője a kód írásának stílusa. A bash és az Ansible-tól eltérően a Terraform deklaratív stílust használ, amely a kívánt végállapot leírásán alapul, amelyet el kell érni a végrehajtás eredményeképpen. Például, ha 10 VMs-t szeretnénk létrehozni, és a változtatásokat a Terraform segítségével alkalmazzuk, akkor 10 VMs-t kapunk. Ha a szkriptet ismét alkalmazzuk, akkor nem történik semmi, mivel már van 10 VMs, és a Terraform tud erről, mivel az aktuális infrastruktúra állapotát a state-fájlban tárolja. Az Ansible viszont procedurális megközelítést alkalmaz, és ha megkérjük, hogy hozzon létre 10 VMs-t, akkor az első futtatáskor 10 VMs-t kapunk, hasonlóan a Terraformhoz. De egy ismételt futtatáskor már 20 VMs-ünk lesz. Ez a fontos különbség. A procedurális stílusban nem tároljuk az aktuális állapotot, és egyszerűen csak leírjuk a végrehajtandó lépések sorrendjét. Természetesen kezelhetjük a különböző helyzeteket, hozzáadhatunk néhány ellenőrzést az erőforrások létezésére és az aktuális állapotra, de nincs értelme időt pazarolni és erőfeszítéseket fordítani ennek a logikának az irányítására. Ráadásul ez növeli a hibázás kockázatát.
Összefoglalva az eddig elhangzottakat, megállapíthatjuk, hogy a szerverek provisioning-jára a megfelelőbb eszköz a Terraform és a deklaratív jelölés. Ezzel szemben a konfigurációkezelési feladatokat jobb delegálni az Ansible-re. Miután ezzel tisztában vagyunk, nézzünk meg néhány példát az automatizálás kontextusában.
Érték az automatizálási infrastruktúrához
Fontos megérteni, hogy a tesztelési automatizálás infrastruktúráját a vállalat teljes infrastruktúrájának részének kell tekinteni. Ez azt jelenti, hogy minden IaC-gyakorlatot globálisan kell alkalmazni a szervezet összes erőforrására. A felelősség attól függ, hogy milyenek a folyamataik. A DevOps csapat tapasztaltabb ezeken a területeken, ők látják az események teljes képét. Ugyanakkor a QA mérnökök jobban részt vesznek az automatizálás felépítésében és a pipeline struktúrájában, ami lehetővé teszi számukra, hogy jobban átlássák az összes szükséges változtatást és a fejlesztési lehetőségeket. A legjobb megoldás, ha együtt dolgoznak, megosztják tudásukat és ötleteiket a várt eredmények elérésének érdekében.
Néhány példát hoznék a Terraform és Ansible tesztelési automatizálásban való felhasználására, valamint az eddig tárgyalt eszközökre:
1. A Terraform segítségével leírni a szükséges jellemzőket és paramétereket a VMs-hez és a klaszterekhez.
2. Az Ansible segítségével telepíteni a teszteléshez szükséges eszközöket: docker, Selenoid, Selenium Grid, és letölteni a szükséges böngésző/verziókat.
3. A Terraform segítségével leírni a VM jellemzőit, amelyben a GitLab Runner fog futni.
4. Az Ansible segítségével telepíteni a GitLab Runner-t és a szükséges kiegészítő eszközöket, beállítani a konfigurációkat.
A jelenlegi infrastruktúra állapotának illusztrációja
Tanulmányozásra ajánlott linkek:
Hasonló eszközök
Összefoglalva!
Lépés
Technológia
Helyi futtatás (web / android bemutató tesztek előkészítése és helyi futtatásuk)
Érték az automatizálási infrastruktúrához
1
Helyi futtatás
Verziókezelő rendszerek
- A legnépszerűbb eszközök web és mobil számára
- Több nyelv és platform (beleértve a Node.js-t) támogatása
2
Git
Konténerizálás
- Hasonló előnyök a fejlesztési kódhoz
3
Docker, Selenium grid, Selenoid (Web, Android)
CI / CD
- Párhuzamos tesztfuttatás
- Elkülönített környezetek
- Egyszerű, rugalmas verziófrissítés
- Dinamika az inaktív erőforrások leállításakor
- Könnyen beállítható
4
Gitlab CI
Felhőplatformok
- A tesztek részei a folyamatnak
- Gyors visszajelzés
- Átláthatóság az egész vállalat / csapat számára
5
Orkesztráció
Google Cloud Platform
- Erőforrások igény szerint (csak akkor fizetünk, amikor szükséges)
- Könnyen kezelhető és frissíthető
- Minden erőforrás átláthatósága és ellenőrzése
6
Infrastruktúra mint kód (IaC)
Kubernetes
A konténerekkel, böngészőkkel / emulátorokkal belső pods kontextusában:
- Skálázás / automatikus skálázás
- Ön-helyreállítás
- Frissítések és visszagörgetések megszakítás nélkül
7
Terraform, Ansible
Minden szakasz felépítése
- Hasonló előnyök a fejlesztési infrastruktúrával
- A kód verzionálásának minden előnye
- Könnyű módosítani és karbantartani
- Teljesen automatizált
Elmetér-diagrammok: az infrastruktúra evolúciója
step1: Helyi
step2: VCS
step3: Konténerizálás
step4: CI/CD
step5: Felhőplatformok
step6: Orkesztráció
step7: IaC
Mi következik?
Tehát ez a cikk vége. De a zárásként szeretnék néhány megállapodást kötni veletek.
A te részedről
Ahogy az elején mondtam, szeretném, ha a cikk gyakorlati hasznot hozna, és segítene a megszerzett tudás gyakorlati alkalmazásában. Még egyszer megosztom veletek.
De még ennél is fontosabb, hogy ne álljatok meg, gyakoroljatok, tanulmányozzátok a releváns linkeket és könyveket, ismerjétek meg, hogyan működik mindez nálatok a cégnél, találjátok meg a fejlesztésre váró helyeket, és vegyetek részt ebben. Sok sikert!
Az én részemről
A cím alapján látható, hogy ez csak az első rész volt. Bár elég terjedelmes lett, még mindig fontos témák nincsenek kifejtve. A második részben az automatizálás infrastruktúráját kívánom megvizsgálni az IOS kontextusában. Az Apple által bevezetett korlátozások, amelyeket az IOS szimulátorok futtatására csak macOS rendszerekre alkalmaznak, lecsökkentik a megoldásaink körét. Például nem használhatjuk a Dockert a szimulátor futtatására, és a nyilvános felhők sem állnak rendelkezésre virtuális gépek indításához. De ez nem jelenti azt, hogy nincsenek más alternatívák. Igyekszem tájékoztatni benneteket a legújabb megoldásokról és korszerű eszközökről!
Emellett nem említettem a monitorozással kapcsolatos elég jelentős témákat. A 3. részben a legnépszerűbb infrastruktúra-monitorozó eszközöket fogom áttekinteni, valamint azokat az adatokat és metrikákat, amelyeket figyelembe érdemes venni.
Végül pedig. A jövőben szeretnék kiadni egy videós kurzust a tesztelési infrastruktúra felállításáról és népszerű eszközökről. Jelenleg az interneten számos kurzus és előadás található a DevOpsról, de minden anyag a fejlesztés kontextusában van, nem pedig a tesztelés automatizálásáról. Ebben a kérdésben nagyon fontos lenne a visszajelzés, hogy érdekes és értékes lenne-e egy ilyen kurzus a tesztelők és automatizálók közössége számára. Előre is köszönöm!
Forrás: habr.com
