1. rész: Web/Android
Megjegyzés: ez a cikk az eredeti cikk orosz nyelvű fordítása Mindazonáltal minden illusztrációt, linket, idézetet és kifejezést megőrzünk az eredeti nyelven, hogy elkerüljük a jelentés torzulását az orosz nyelvre történő fordításkor. Boldog tanulást kívánok!
Jelenleg a DevOps specialitás az egyik legkeresettebb az IT-iparban. Ha megnyitja a népszerű álláskereső oldalakat, és fizetés szerint szűr, látni fogja, hogy a DevOps-hoz kapcsolódó állások a lista elején vannak. Fontos azonban megérteni, hogy ez elsősorban a „Senior” pozícióra vonatkozik, ami azt jelenti, hogy a jelölt magas szintű készségekkel, technológiával és eszközökkel rendelkezik. Ez a termelés zavartalan működéséhez kapcsolódó nagyfokú felelősséggel is jár. Kezdtük azonban elfelejteni, mi is az a DevOps. Kezdetben nem volt konkrét személy vagy osztály. Ha ennek a kifejezésnek a definícióit keressük, sok szép és helyes főnevet találunk, mint például módszertan, gyakorlatok, kultúrfilozófia, fogalomcsoport stb.
Szakterületem tesztautomatizálási mérnök (QA automation engineer), de úgy gondolom, hogy ezt nem szabad csak az automatikus tesztek írásával vagy a teszt keretrendszer architektúrájának fejlesztésével társítani. 2020-ban az automatizálási infrastruktúra ismerete is elengedhetetlen. Ez lehetővé teszi, hogy saját maga szervezze meg az automatizálási folyamatot, a tesztek futtatásától az összes érdekelt fél számára elért eredmények eléréséig a céljainak megfelelően. Ennek eredményeként a DevOps készségek elengedhetetlenek a munka elvégzéséhez. És ez mind jó, de sajnos van egy probléma (spoiler: ez a cikk megpróbálja leegyszerűsíteni ezt a problémát). A lényeg az, hogy a DevOps nehéz. Ez pedig nyilvánvaló, mert a cégek nem fognak sokat fizetni valamiért, amit könnyű megcsinálni... A DevOps világában rengeteg eszköz, kifejezés és gyakorlat létezik, amelyeket el kell sajátítani. Ez különösen nehéz a karrier elején, és a felhalmozott technikai tapasztalattól függ.
Forrás:
Itt valószínűleg befejezzük a bevezető részt, és a cikk céljára összpontosítunk.
Miről szól ez a cikk?
Ebben a cikkben a tesztautomatizálási infrastruktúra kiépítésével kapcsolatos tapasztalataimat fogom megosztani. Az interneten számos információforrás található a különféle eszközökről és azok használatáról, de én ezeket pusztán az automatizálással összefüggésben szeretném megvizsgálni. Úgy gondolom, hogy sok automatizálási mérnök ismeri azt a helyzetet, amikor rajtad kívül senki nem futtatja le a kifejlesztett teszteket, és nem törődik azok karbantartásával. Ennek eredményeként a tesztek elavulnak, és időt kell tölteni a frissítésükkel. Ez megint csak egy karrier elején elég nehéz feladat lehet: bölcsen eldönteni, hogy mely eszközök segítsenek kiküszöbölni egy adott problémát, hogyan kell kiválasztani, konfigurálni és karbantartani azokat. Egyes tesztelők a DevOps-hoz (emberekhez) fordulnak segítségért, és legyünk őszinték, ez a megközelítés működik. Sok esetben ez lehet az egyetlen lehetőség, mivel nem látunk minden függőséget. De mint tudjuk, a DevOp-ok nagyon elfoglalt srácok, mert szervezettől/csapattól függően a teljes cég infrastruktúrájára, telepítésére, monitorozására, mikroszolgáltatásaira és egyéb hasonló feladatokra kell gondolniuk. Mint általában, az automatizálás nem prioritás. Ilyen esetben az elejétől a végéig meg kell próbálnunk mindent megtenni a magunk részéről. Ez csökkenti a függőséget, felgyorsítja a munkafolyamatot, javítja készségeinket, és lehetővé teszi számunkra, hogy nagyobb képet lássunk arról, hogy mi történik.
A cikk bemutatja a legnépszerűbb és legnépszerűbb eszközöket, és lépésről lépésre bemutatja, hogyan lehet ezeket felhasználni egy automatizálási infrastruktúra felépítéséhez. Minden csoportot személyes tapasztalatok alapján tesztelt eszközök képviselnek. De ez nem jelenti azt, hogy ugyanazt kell használnia. Maguk az eszközök nem fontosak, megjelennek és elavulnak. Mérnöki feladatunk az alapelvek megértése: miért van szükségünk erre az eszközcsoportra, és milyen munkaproblémákat tudunk megoldani a segítségükkel. Ezért minden szakasz végén hivatkozásokat hagyok hasonló eszközökre, amelyeket az Ön szervezetében használhatnak.
Ami nincs ebben a cikkben
Még egyszer megismétlem, hogy a cikk nem konkrét eszközökről szól, így nem lesz kód beillesztés a dokumentációból és az adott parancsok leírásából. De minden szakasz végén linkeket hagyok a részletes tanulmányozáshoz.
Ez azért történik, mert:
- ez az anyag nagyon könnyen megtalálható különféle forrásokban (dokumentáció, könyvek, videó tanfolyamok);
- ha elkezdünk mélyebbre menni, 10, 20, 30 részt kell megírnunk ebből a cikkből (míg a tervek 2-3);
- Csak nem akarom vesztegetni az idejét, mert esetleg más eszközöket is szeretne használni ugyanazon célok elérése érdekében.
Gyakorlat
Nagyon szeretném, ha ez az anyag minden olvasó számára hasznos lenne, nem csak elolvasva, elfelejtve. Minden tanulmányban a gyakorlat nagyon fontos összetevő. Erre készültem fel. Otthoni feladat is vár rád, hogy megbizonyosodj arról, hogy ne másold le ész nélkül a végrehajtott parancsok sorait.
terv
Lépés
Technológia
Eszközök
1
Helyi futtatás (webes / Android demó tesztek előkészítése és helyi futtatása)
Node.js, szelén, Appium
2
Verziókezelő rendszerek
megy
3
Konténerezés
Docker, Selenium grid, Selenoid (web, Android)
4
CI/CD
Gitlab CI
5
Felhő platformok
Google Cloud Platform
6
hangszerelés
Kubernetes
7
Infrastruktúra mint kód (IaC)
Terraform, Ansible
Az egyes szakaszok felépítése
A narratíva egyértelműségének megőrzése érdekében az egyes szakaszok leírása a következő vázlat szerint történik:
- a technológia rövid leírása,
- az automatizálási infrastruktúra értéke,
- az infrastruktúra jelenlegi állapotának szemléltetése,
- linkek a tanuláshoz,
- hasonló eszközök.
1. Futtasson teszteket helyben
A technológia rövid leírása
Ez csak egy előkészítő lépés a demótesztek helyben történő futtatásához és annak ellenőrzéséhez, hogy sikeresek-e. A gyakorlati részben a Node.js-t használjuk, de a programozási nyelv és a platform sem fontos, és használhatod azokat, amelyeket a cégedben használnak.
Automatizálási eszközként azonban a Selenium WebDriver használatát javaslom webes platformokhoz, illetve az Appiumot Android platformhoz, mivel a következő lépésekben olyan Docker-képeket használunk, amelyek kifejezetten ezekkel az eszközökkel működnek. Ráadásul a munkaköri követelményekre hivatkozva ezek az eszközök a legkeresettebbek a piacon.
Amint azt már észrevette, csak a webes és Android-teszteket vesszük figyelembe. Sajnos az iOS teljesen más történet (köszönet az Apple-nek). Terveim szerint az IOS-hez kapcsolódó megoldásokat és gyakorlatokat a következő részekben mutatom be.
Érték az automatizálási infrastruktúra számára
Infrastrukturális szempontból a helyi futás nem ad értéket. Csak azt ellenőrizze, hogy a tesztek a helyi gépen futnak-e helyi böngészőkben és szimulátorokban. De mindenesetre ez egy szükséges kiindulópont.
Illusztráció az infrastruktúra jelenlegi állapotáról
Linkek a felfedezéshez
Hasonló eszközök
- tetszőleges programozási nyelv a Selenium/Appium tesztekkel együtt;
- bármilyen teszt;
- bármely tesztfutó.
2. Verzióvezérlő rendszerek (Git)
A technológia rövid leírása
Nem lesz nagy felfedezés senki számára, ha azt mondom, hogy a verziókezelés rendkívül fontos része a fejlesztésnek, csapatban és egyénileg is. Különféle források alapján nyugodtan kijelenthetjük, hogy a Git a legnépszerűbb képviselő. A verziókezelő rendszer számos előnnyel jár, mint például a kódmegosztás, a verziók tárolása, a korábbi ágakra való visszaállítás, a projektelőzmények figyelése és a biztonsági mentések. Nem fogunk minden pontot részletesen tárgyalni, mert biztos vagyok benne, hogy nagyon jól ismeri és használja a mindennapi munkája során. De ha hirtelen nem, akkor azt javaslom, hogy hagyja abba a cikk elolvasását, és mielőbb pótolja ezt a hiányt.
Érték az automatizálási infrastruktúra számára
És itt feltehet egy ésszerű kérdést: „Miért beszél nekünk Gitről? Mindenki tudja ezt, és mind fejlesztői, mind automatikus tesztkódhoz használja.” Teljesen igaza lesz, de ebben a cikkben az infrastruktúráról beszélünk, és ez a rész a 7. szakasz előnézeteként működik: „Infrastruktúra mint kód (IaC)”. Számunkra ez azt jelenti, hogy a teljes infrastruktúra, beleértve a tesztelést is, kód formájában le van írva, így verziókezelő rendszereket is alkalmazhatunk rá, és hasonló előnyökhöz juthatunk, mint a fejlesztési és automatizálási kódoknál.
A 7. lépésben részletesebben megvizsgáljuk az IaC-t, de még most is megkezdheti a Git helyi használatát egy helyi tároló létrehozásával. A nagy kép kibővül, ha egy távoli adattárat adunk az infrastruktúrához.
Illusztráció az infrastruktúra jelenlegi állapotáról
Linkek a felfedezéshez
Hasonló eszközök
3. Konténerezés (Docker)
A technológia rövid leírása
Hogy bemutassuk, hogyan változtatta meg a konténerezés a játékszabályokat, menjünk vissza néhány évtizedet az időben. Akkoriban az emberek szervergépeket vásároltak és használtak alkalmazások futtatására. De a legtöbb esetben a szükséges indítási erőforrásokat nem ismerték előre. Ennek eredményeként a cégek pénzt költöttek drága, nagy teljesítményű szerverek vásárlására, de ennek a kapacitásnak egy részét nem használták ki teljesen.
Az evolúció következő szakaszát a virtuális gépek (VM-ek) jelentették, amelyek megoldották a fel nem használt erőforrásokra való pénzpazarlás problémáját. Ez a technológia lehetővé tette az alkalmazások egymástól független futtatását ugyanazon a szerveren belül, teljesen elszigetelt területet lefoglalva. De sajnos minden technológiának megvannak a maga hátrányai. A virtuális gép futtatásához teljes operációs rendszerre van szükség, amely CPU-t, RAM-ot, tárhelyet fogyaszt, és az operációs rendszertől függően a licencköltségekkel is számolni kell. Ezek a tényezők befolyásolják a betöltési sebességet és megnehezítik a hordozhatóságot.
És most elérkeztünk a konténerezéshez. Ez a technológia ismét megoldja a korábbi problémát, mivel a konténerek nem használnak teljes operációs rendszert, ami nagy mennyiségű erőforrást szabadít fel, és gyors és rugalmas megoldást kínál a hordozhatóságra.
Természetesen a konténerezési technológia nem újdonság, és először a 70-es évek végén vezették be. Akkoriban rengeteg kutatás, fejlesztés és próbálkozás folyt. De a Docker adaptálta ezt a technológiát, és tette könnyen elérhetővé a tömegek számára. Manapság, amikor konténerekről beszélünk, a legtöbb esetben a Dockerre gondolunk. Amikor Docker-tárolókról beszélünk, Linux-tárolókra gondolunk. Használhatunk Windows és macOS rendszereket a konténerek futtatására, de fontos megérteni, hogy ebben az esetben egy további réteg jelenik meg. Például a Mac rendszerű Docker csendesen futtatja a konténereket egy könnyű Linux virtuális gépen belül. Vissza fogunk térni ehhez a témához, amikor az Android emulátorok konténereken belüli futtatását tárgyaljuk, ezért van egy nagyon fontos árnyalat, amelyet részletesebben meg kell tárgyalni.
Érték az automatizálási infrastruktúra számára
Megtudtuk, hogy a konténerezés és a Docker jó. Nézzük ezt az automatizálás összefüggésében, mert minden eszköznek vagy technológiának meg kell oldania egy problémát. Vázoljuk fel a tesztautomatizálás nyilvánvaló problémáit az UI-tesztek kontextusában:
- hatalmas számú függőség a szelén és különösen az Appium telepítésekor;
- kompatibilitási problémák a böngészők, szimulátorok és illesztőprogramok verziói között;
- elszigetelt hely hiánya a böngészők/szimulátorok számára, ami különösen kritikus a párhuzamos futtatáshoz;
- nehéz kezelni és karbantartani, ha egyszerre 10, 50, 100 vagy akár 1000 böngészőt kell futtatnia.
De mivel a Selenium a legnépszerűbb automatizálási eszköz, és a Docker a legnépszerűbb konténerező eszköz, nem meglepő, hogy valaki megpróbálta kombinálni őket egy hatékony eszköz létrehozására a fent említett problémák megoldására. Tekintsük az ilyen megoldásokat részletesebben.
Szelén rács a dokkolóban
Ez az eszköz a legnépszerűbb a Selenium világában több böngésző futtatására több gépen és ezek központi hubról történő kezelésére. A kezdéshez legalább 2 részt kell regisztrálnia: Hubot és csomópontot. A hub egy központi csomópont, amely megkapja a tesztekből származó összes kérést, és elosztja azokat a megfelelő csomópontokhoz. Minden csomóponthoz beállíthatunk egy adott konfigurációt, például a kívánt böngésző és annak verziójának megadásával. A kompatibilis böngésző-illesztőprogramokról azonban továbbra is magunknak kell gondoskodnunk, és telepítenünk kell azokat a kívánt Node-okra. Emiatt a Selenium grid-et nem használják tiszta formájában, kivéve, ha olyan böngészőkkel kell dolgoznunk, amelyek nem telepíthetők Linux operációs rendszerre. Minden más esetben lényegesen rugalmas és helyes megoldás a Docker-képek használata a Selenium grid Hub és Nodes futtatására. Ez a megközelítés nagymértékben leegyszerűsíti a csomópontok kezelését, hiszen a már telepített kompatibilis böngésző- és illesztőprogram-verziókkal tudjuk kiválasztani a szükséges képet.
A stabilitással kapcsolatos negatív vélemények ellenére, különösen, ha sok csomópontot futtat párhuzamosan, a Selenium grid továbbra is a legnépszerűbb eszköz a szeléntesztek párhuzamos futtatására. Fontos megjegyezni, hogy ennek az eszköznek a különféle fejlesztései és módosításai folyamatosan jelennek meg nyílt forráskódú környezetben, amelyek különféle szűk keresztmetszetek ellen küzdenek.
Szelenoid a webhez
Ez az eszköz áttörést jelent a szelén világában, mivel azonnal működik, és sok automatizálási mérnök életét megkönnyítette. Először is, ez nem a szelénrács újabb módosítása. Ehelyett a fejlesztők elkészítették a Golangban található Selenium Hub egy teljesen új verzióját, amely a különféle böngészőkhöz készült könnyű Docker-képekkel kombinálva lendületet adott a tesztautomatizálás fejlesztésének. Sőt, 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 probléma, ha csak egy böngészővel dolgozunk. Ha azonban több támogatott böngészőről van szó, a Selenoid az első számú megoldás az „igény szerinti böngésző” funkciónak köszönhetően. Mindössze annyit kell tőlünk, hogy előzetesen letöltsük a szükséges képeket a böngészőkkel, és frissítsük a konfigurációs fájlt, amellyel a Selenoid kölcsönhatásba lép. Miután a Selenoid kérést kap a tesztektől, automatikusan elindítja a kívánt tárolót a kívánt böngészővel. Amikor a teszt befejeződik, a Selenoid megszünteti a tárolót, ezáltal erőforrásokat szabadít fel a jövőbeli kérések számára. Ez a megközelítés teljesen kiküszöböli a „csomópont-degradáció” jól ismert problémáját, amellyel gyakran találkozunk a szelénrácsban.
De sajnos, a szelenoid még mindig nem egy ezüstgolyó. Megkaptuk a „böngésző igény szerinti” funkciót, de az „igény szerinti erőforrások” funkció továbbra sem érhető el. A Selenoid használatához fizikai hardverre vagy virtuális gépre kell telepítenünk, ami azt jelenti, hogy előre tudnunk kell, hány erőforrást kell lefoglalni. Gondolom ez nem jelent problémát a 10, 20 vagy akár 30 böngészőt párhuzamosan futtató kis projekteknél. De mi van akkor, ha 100, 500, 1000 és több kell? Nincs értelme ennyi erőforrást folyamatosan fenntartani és fizetni. A cikk 5. és 6. részében olyan megoldásokat tárgyalunk, amelyek lehetővé teszik a méretezést, ezáltal jelentősen csökkentve a vállalati költségeket.
Szelenoid Androidra
A Selenoid, mint webautomatizálási eszköz sikere után az emberek valami hasonlót akartak az Android számára. És megtörtént - a Selenoid Android támogatással jelent meg. Magas szintű felhasználói szempontból a működési elv hasonló a webautomatizáláshoz. Az egyetlen különbség az, hogy a böngészőtárolók helyett a Selenoid Android-emulátor-tárolókat futtat. Véleményem szerint jelenleg ez a legerősebb ingyenes eszköz az Android tesztek párhuzamos futtatására.
Nem szeretnék ennek az eszköznek a negatív oldalairól beszélni, mert nagyon szeretem. Ennek ellenére ugyanazok a hátrányok vannak, amelyek a webautomatizálásra vonatkoznak, és a méretezéshez kapcsolódnak. Ezen kívül még egy korlátozásról kell beszélnünk, ami meglepő lehet, ha először állítjuk be az eszközt. Az Android képek futtatásához szükségünk van egy beágyazott virtualizációt támogató fizikai gépre vagy virtuális gépre. A használati útmutatóban bemutatom, hogyan engedélyezhető ez egy Linux virtuális gépen. Ha azonban Ön macOS-felhasználó, és helyileg szeretné telepíteni a Selenoidot, akkor ez nem tudja futtatni az Android-teszteket. De mindig futtathat egy Linux virtuális gépet helyben, konfigurált „beágyazott virtualizációval”, és telepítheti a Selenoidot belül.
Illusztráció az infrastruktúra jelenlegi állapotáról
Ennek a cikknek a keretében 2 eszközt adunk hozzá az infrastruktúra illusztrálására. Ezek a Selenium grid a webes tesztekhez és a Selenoid az Android tesztekhez. A GitHub oktatóanyagában azt is megmutatom, hogyan használhatod a Selenoidot webes tesztek futtatására.
Linkek a felfedezéshez
Hasonló eszközök
- Vannak más konténerező eszközök is, de a Docker a legnépszerűbb. Ha valami mást szeretne kipróbálni, ne feledje, hogy azok az eszközök, amelyeket a szeléntesztek párhuzamos futtatásához ismertettünk, a dobozból nem működnek.
- Mint már említettük, a szelénrácsnak számos módosítása létezik, például,.
4.CI/CD
A technológia rövid leírása
A folyamatos integráció gyakorlata meglehetősen népszerű a fejlesztésben, és egyenrangú a verziókezelő rendszerekkel. Ennek ellenére úgy érzem, zavar van a terminológiában. Ebben a bekezdésben ennek a technológiának 3 módosítását szeretném ismertetni az én szempontomból. Az interneten sok különböző értelmezésű cikket talál, és teljesen normális, ha a véleménye eltér. A legfontosabb, hogy egy oldalon legyél a kollégáiddal.
Tehát 3 kifejezés létezik: CI - Folyamatos integráció, CD - Folyamatos szállítás és ismét CD - Folyamatos telepítés. (Az alábbiakban ezeket a kifejezéseket használom angolul). Minden módosítás több további lépést ad a fejlesztési folyamathoz. De a szó folyamatos (folyamatos) a legfontosabb. Ebben az összefüggésben olyasvalamit értünk, ami az elejétől a végéig, megszakítás vagy kézi beavatkozás nélkül történik. Nézzük meg a CI-t és a CD-t és a CD-t ebben az összefüggésben.
- Folyamatos integráció ez az evolúció kezdeti lépése. Miután elküldtük az új kódot a szervernek, gyors visszajelzést kapunk arról, hogy a módosításaink rendben vannak. A CI rendszerint statikus kódelemző eszközöket és egység/belső API-teszteket tartalmaz, amelyek segítségével néhány másodperc/perc alatt információt szerezhetünk a kódunkról.
- Folyamatos szállítás egy fejlettebb lépés, ahol integrációs/UI teszteket futtatunk. Ebben a szakaszban azonban nem érünk el olyan gyorsan eredményt, mint a CI-vel. Először is, az ilyen típusú tesztek befejezése hosszabb ideig tart. Másodszor, az indítás előtt telepítenünk kell a változtatásainkat a teszt/staging környezetben. Sőt, ha mobilfejlesztésről beszélünk, akkor megjelenik egy további lépés az alkalmazásunk buildjének létrehozásához.
- Folyamatos telepítés azt feltételezi, hogy a változtatásainkat automatikusan feladjuk a termelésben, ha az előző szakaszokban az összes átvételi tesztet sikeresen teljesítették. Ezenkívül a kiadási szakasz után különféle szakaszokat konfigurálhat, például füstteszteket futtathat a termelésben, és összegyűjtheti az érdeklődésre számot tartó mutatókat. A folyamatos üzembe helyezés csak jó lefedettség mellett lehetséges automatizált tesztekkel. Ha bármilyen kézi beavatkozásra van szükség, beleértve a tesztelést is, akkor ez már nem szükséges Folyamatos (folyamatos). Ekkor azt mondhatjuk, hogy csővezetékünk csak a Folyamatos Szállítás gyakorlatának felel meg.
Érték az automatizálási infrastruktúra számára
Ebben a részben tisztáznom kell, hogy amikor végpontok közötti felhasználói felület-tesztekről beszélünk, az azt jelenti, hogy a változtatásainkat és a kapcsolódó szolgáltatásokat a tesztelési környezetekben kell üzembe helyeznünk. Folyamatos integráció - a folyamat nem alkalmazható erre a feladatra, és gondoskodnunk kell legalább a Continuous Deliver gyakorlatok megvalósításáról. A folyamatos üzembe helyezésnek az UI-tesztek kontextusában is van értelme, ha éles környezetben futtatjuk őket.
És mielőtt megnéznénk az architektúraváltás illusztrációját, szeretnék néhány szót ejteni a GitLab CI-ről. Más CI/CD-eszközökkel ellentétben a GitLab távoli adattárat és sok egyéb kiegészítő szolgáltatást biztosít. Így a GitLab több, mint a CI. Tartalmazza a forráskód-kezelést, az Agilis kezelést, a CI/CD-folyamatokat, a naplózási eszközöket és a mérőszámok gyűjtését. A GitLab architektúra a Gitlab CI/CD-ből és a GitLab Runnerből áll. Íme egy rövid leírás a hivatalos weboldalról:
A Gitlab CI/CD egy API-val rendelkező webalkalmazás, amely adatbázisban tárolja állapotát, kezeli a projekteket/építéseket és felhasználói felületet biztosít. A GitLab Runner egy olyan alkalmazás, amely a buildeket dolgozza fel. Külön telepíthető, és API-n keresztül működik a GitLab CI/CD-vel. A tesztek futtatásához szükség van a Gitlab példányra és a Runnerre is.
Illusztráció az infrastruktúra jelenlegi állapotáról
Linkek a felfedezéshez
Hasonló eszközök
- És sokan mások
5. Felhőplatformok
A technológia rövid leírása
Ebben a részben a „nyilvános felhők” nevű népszerű trendről fogunk beszélni. Annak ellenére, hogy a fent ismertetett virtualizációs és konténerezési technológiák óriási előnyökkel járnak, még mindig szükségünk van számítási erőforrásokra. A cégek drága szervereket vásárolnak, vagy adatközpontokat bérelnek, de ilyenkor számításokat kell végezni (néha irreális), hogy mennyi erőforrásra lesz szükségünk, 24/7 használjuk-e és milyen célra. Például a termeléshez szükség van egy XNUMX órás kiszolgálóra, de szükségünk van-e hasonló erőforrásokra a munkaidőn kívüli teszteléshez? Ez az elvégzett vizsgálat típusától is függ. Példa erre a terhelési/stressz tesztek, amelyeket munkaidőn kívül tervezünk futtatni, hogy másnap eredményt kapjunk. De határozottan nem szükséges a XNUMX órás kiszolgáló rendelkezésre állása a végpontok közötti automatizált tesztekhez, és különösen nem a kézi tesztelési környezetekhez. Ilyen helyzetekben jó lenne igény szerint annyi erőforrást beszerezni, amennyire szükség van, felhasználni, és abbahagyni a fizetést, ha már nincs rá szükség. Sőt, jó lenne néhány egérkattintással vagy néhány szkript futtatásával azonnal megkapni őket. Erre használják a nyilvános felhőket. Nézzük a definíciót:
„A nyilvános felhő definíciója szerint olyan számítástechnikai szolgáltatások, amelyeket külső szolgáltatók kínálnak a nyilvános interneten keresztül, és mindenki számára elérhetővé teszik azokat, akik használni akarják vagy megvásárolják azokat. Lehetnek ingyenesek vagy igény szerint értékesíthetők, lehetővé téve az ügyfelek számára, hogy csak használatonként fizessenek az általuk fogyasztott CPU-ciklusokért, tárhelyért vagy sávszélességért."
Van egy vélemény, hogy a nyilvános felhők drágák. De a legfontosabb ötletük a vállalati költségek csökkentése. Ahogy korábban említettük, a nyilvános felhők lehetővé teszik, hogy igény szerint szerezzen be erőforrásokat, és csak a használat idejéért fizessen. Emellett néha elfelejtjük, hogy az alkalmazottak fizetést kapnak, és a szakemberek is drága erőforrást jelentenek. Figyelembe kell venni, hogy a nyilvános felhők jelentősen megkönnyítik az infrastruktúra támogatását, ami lehetővé teszi a mérnökök számára, hogy a fontosabb feladatokra koncentráljanak.
Érték az automatizálási infrastruktúra számára
Milyen konkrét erőforrásokra van szükségünk a végpontok közötti felhasználói felület teszteléséhez? Alapvetően ezek virtuális gépek vagy fürtök (a Kubernetesről a következő részben fogunk beszélni) böngészők és emulátorok futtatására. 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ünk, és annál több pénzt kell fizetnünk érte. Így a nyilvános felhők a tesztautomatizálással összefüggésben lehetővé teszik, hogy igény szerint nagyszámú (100, 200, 1000...) böngészőt/emulátort futtassunk, a lehető leggyorsabban megkapjuk a teszteredményeket, és ne fizessünk az ilyen őrülten erőforrás-igényesekért. erő.
A legnépszerűbb felhőszolgáltatók az Amazon Web Services (AWS), a Microsoft Azure, a Google Cloud Platform (GCP). A használati útmutató példákat ad a GCP használatára, de általában nem mindegy, hogy mit használ az automatizálási feladatokhoz. Mindegyik megközelítőleg ugyanazt a funkciót nyújtja. A szolgáltató kiválasztásakor a menedzsment általában a vállalat általános infrastruktúrájára és üzleti követelményeire összpontosít, ami túlmutat e cikk keretein. Az automatizálási mérnökök számára érdekesebb lesz összehasonlítani a felhőszolgáltatók használatát a kifejezetten tesztelési célú felhőplatformok használatával, mint például a Sauce Labs, BrowserStack, BitBar stb. Tehát csináljuk mi is! Véleményem szerint a Sauce Labs a leghíresebb felhőtesztelő farm, ezért is használtam összehasonlításra.
GCP vs Sauce Labs automatizálási célokra:
Képzeljük el, hogy 8 webes és 8 Android-tesztet kell futtatnunk egyszerre. Ehhez GCP-t fogunk használni, és 2 virtuális gépet futtatunk Selenoiddal. Az elsőn 8 konténert emelünk ki böngészőkkel. A másodikon 8 tartály van emulátorokkal. Nézzük az árakat:
Egy konténer Chrome-mal való futtatásához szükségünk van n1-standard-1 autó. Android esetén ez lesz n1-standard-4 egy emulátorhoz. Valójában egy rugalmasabb és olcsóbb módszer a CPU/Memory specifikus felhasználói értékek beállítása, de ez jelenleg nem fontos a Sauce Labs-szal való összehasonlításhoz.
És itt vannak a Sauce Labs használatának díjai:
Azt hiszem, Ön már észrevette a különbséget, de a feladatunkhoz továbbra is adok egy táblázatot számításokkal:
Szükséges erőforrások
Havi
Munkaórák(8:8-XNUMX:XNUMX)
Munkaórák+ Megelőzhető
GCP webhez
n1-szabvány-1 x 8 = n1-szabvány-8
$194.18
23 nap * 12 óra * 0.38 = 104.88 USD
23 nap * 12 óra * 0.08 = 22.08 USD
Sauce Labs for Web
Virtual Cloud8 párhuzamos tesztek
$1.559
-
-
GCP Androidhoz
n1-standard-4 x 8: n1-standard-16
$776.72
23 nap * 12 óra * 1.52 = 419.52 USD
23 nap * 12 óra * 0.32 = 88.32 USD
Sauce Labs Androidra
Real Device Cloud 8 párhuzamos tesztek
$1.999
-
-
Amint látja, óriási a különbség a költségek között, különösen, ha csak tizenkét órás munkaidő alatt végez teszteket. De még tovább csökkentheti a költségeket, ha megelőzhető gépeket használ. Mi az?
A megelőző virtuális gép olyan példány, amelyet a normál példányoknál sokkal olcsóbban hozhat létre és futtathat. A Compute Engine azonban leállíthatja (megelőzheti) ezeket a példányokat, ha más feladatokhoz hozzáférést igényel ezekhez az erőforrásokhoz. A megelőzhető példányok a Compute Engine túlzott kapacitása, így elérhetőségük a használat függvényében változik.
Ha az alkalmazásai hibatűrők, és képesek ellenállni a lehetséges példányok megelőzésének, akkor a megelőző példányok jelentősen csökkenthetik a Compute Engine költségeit. Például a kötegelt feldolgozási feladatok futhatnak megelőzhető példányokon. Ha ezek közül néhány a feldolgozás során leáll, a feladat lelassul, de nem áll le teljesen. A megelőző példányok anélkül hajtják végre a kötegelt feldolgozási feladatokat, hogy további terhelést rónának a meglévő példányokra, és anélkül, hogy teljes árat kellene fizetnie a további normál példányokért.
És még mindig nincs vége! A valóságban biztos vagyok benne, hogy senki sem végez teszteket 12 órán keresztül szünet nélkül. És ha igen, akkor automatikusan elindíthatja és leállíthatja a virtuális gépeket, amikor nincs rájuk szükség. A tényleges használati idő napi 6 órára csökkenthető. Ekkor a feladatunkkal összefüggésben a fizetés havi 11 dollárra csökken 8 böngésző esetén. Hát nem csodálatos? Ám a megelõzhetõ gépeknél óvatosnak kell lennünk és fel kell készülnünk a megszakításokra, instabilitásokra, bár ezek a helyzetek szoftveresen elõírhatók és kezelhetõk. Megéri!
De semmi esetre sem azt mondom, hogy „soha ne használjon felhőtesztfarmot”. Számos előnnyel rendelkeznek. Először is, ez nem pusztán egy virtuális gép, hanem egy teljes értékű tesztautomatizálási megoldás egy sor funkciókészlettel: távoli hozzáférés, naplók, képernyőképek, videórögzítés, különféle böngészők és fizikai mobileszközök. Sok helyzetben ez elengedhetetlen elegáns alternatíva lehet. A tesztelési platformok különösen hasznosak az IOS automatizáláshoz, amikor a nyilvános felhők csak Linux/Windows rendszereket kínálnak. De az iOS-ről a következő cikkekben fogunk beszélni. Azt javaslom, hogy mindig nézd meg a helyzetet, és a feladatokból indulj ki: egyes esetekben olcsóbb és hatékonyabb a nyilvános felhők használata, máskor pedig a tesztplatformok mindenképpen megérik a ráfordított pénzt.
Illusztráció az infrastruktúra jelenlegi állapotáról
Linkek a felfedezéshez
Hasonló eszközök:
6. Hangszerelés
A technológia rövid leírása
Van egy jó hírem: a cikk végére értünk! Jelenleg az automatizálási infrastruktúránk webes és Android tesztekből áll, amelyeket párhuzamosan futtatunk a GitLab CI-n keresztül, Docker-kompatibilis eszközökkel: Selenium grid és Selenoid. Ezenkívül a GCP-n keresztül létrehozott virtuális gépeket használjuk böngészőkkel és emulátorokkal rendelkező konténerek hosztolá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, ha a tesztelés nem történik meg. Van még valami, ami javíthatja infrastruktúránkat? A válasz igen! Ismerje meg Kubernetes (K8s)!
Először nézzük meg, hogyan kapcsolódnak egymáshoz a hangszerelés, a klaszter és a Kubernetes szavak. Magas szinten a hangszerelés az a rendszer, amely telepíti és kezeli az alkalmazásokat. A tesztautomatizáláshoz ilyen konténeres alkalmazások a Selenium grid és a Selenoid. A Docker és a K8 kiegészítik egymást. Az elsőt az alkalmazások telepítéséhez, a másodikat a hangszereléshez használják. A K8s viszont egy klaszter. A fürt feladata a virtuális gépek csomópontként való használata, amely lehetővé teszi különböző funkciók, programok és szolgáltatások telepítését egy szerveren (fürtön) belül. Ha valamelyik csomópont meghibásodik, más csomópontok is felvesznek, ami biztosítja az alkalmazásunk zavartalan működését. A K8s emellett fontos skálázással kapcsolatos funkcióval is rendelkezik, melynek köszönhetően a terhelés és a beállított korlátok alapján automatikusan megkapjuk az optimális mennyiségű erőforrást.
Valójában a Kubernetes kézi üzembe helyezése a semmiből egyáltalán nem triviális feladat. Hagyok egy linket a híres "Kubernetes The Hard Way" útmutatóhoz, és ha érdekel, gyakorolhatod. De szerencsére vannak alternatív módszerek és eszközök. A legegyszerűbb módja a Google Kubernetes Engine (GKE) használata a GCP-ben, amely lehetővé teszi, hogy néhány kattintással kész klasztert kapjon. Azt javaslom, hogy ezt a megközelítést használja a tanulás megkezdéséhez, mivel ez lehetővé teszi, hogy a K8-asok használatának megtanulására összpontosítson ahelyett, hogy megtanulná, hogyan kell a belső összetevőket integrálni egymással.
Érték az automatizálási infrastruktúra számára
Vessünk egy pillantást néhány fontos funkcióra, amelyeket a K8s nyújt:
- alkalmazástelepítés: több csomópontból álló fürt használata virtuális gépek helyett;
- dinamikus skálázás: csökkenti a csak igény szerint felhasznált erőforrások költségét;
- öngyógyítás: a hüvelyek automatikus helyreállítása (aminek eredményeként a tartályok is helyreállnak);
- a frissítések és a változtatások visszaállítása állásidő nélkül: az eszközök, böngészők és emulátorok frissítése nem szakítja meg a jelenlegi felhasználók munkáját
De a K8s még mindig nem egy ezüstgolyó. Annak érdekében, hogy megértsük az általunk vizsgált eszközök (szelénrács, szelenoid) minden előnyét és korlátját, röviden megvitatjuk a K8-ak szerkezetét. A fürt kétféle csomópontot tartalmaz: főcsomópontokat és dolgozó csomópontokat. A főcsomópontok felelősek a kezelési, telepítési és ütemezési döntésekért. A Workers csomópontok azok, ahol az alkalmazások elindulnak. A csomópontok tároló futási környezetet is tartalmaznak. Esetünkben ez a Docker, amely a konténerekkel kapcsolatos műveletekért felelős. De vannak alternatív megoldások is, pl. Fontos megérteni, hogy a méretezés vagy az öngyógyítás nem vonatkozik közvetlenül a tartályokra. Ezt úgy valósítjuk meg, hogy hozzáadjuk/csökkentjük a podok számát, amelyek viszont konténereket tartalmaznak (általában egy konténer podonként, de a feladattól függően több is lehet). A magas szintű hierarchia dolgozói csomópontokból áll, amelyek belsejében podok találhatók, amelyek belsejében konténerek vannak kiemelve.
A skálázási funkció kulcsfontosságú, és alkalmazható mind a fürt csomópont-készletén belüli csomópontokra, mind a csomóponton belüli podokra. Kétféle méretezés létezik, amelyek mind a csomópontokra, mind a podokra vonatkoznak. Az első típus vízszintes – a méretezés a csomópontok/podok számának növelésével történik. Ez a típus előnyösebb. A második típus ennek megfelelően függőleges. A méretezés a csomópontok/podok méretének növelésével történik, nem pedig a számuk növelésével.
Most pedig nézzük meg eszközeinket a fenti kifejezésekkel összefüggésben.
Szelén rács
Mint korábban említettük, a szelénrács nagyon népszerű eszköz, és nem meglepő, hogy konténerbe helyezték. Ezért nem meglepő, hogy a Selenium grid bevethető a K8-asokban. Egy példa erre a hivatalos K8s adattárban található. Szokás szerint linkeket csatolok a rész végére. Ezenkívül a használati útmutató bemutatja, hogyan kell ezt megtenni a Terraformban. Útmutatások is találhatók a böngészőtárolókat tartalmazó podok számának skálázásához. De az automatikus méretezési funkció a K8-as kontextusban még mindig nem teljesen nyilvánvaló feladat. Amikor elkezdtem tanulni, nem találtam semmilyen gyakorlati útmutatást vagy ajánlást. Számos tanulmány és kísérlet után a DevOps csapatának támogatásával azt a megközelítést választottuk, hogy a konténereket a szükséges böngészőkkel egy podon belül emeljük, amely egy dolgozó csomóponton belül található. Ez a módszer lehetővé teszi, hogy a csomópontok vízszintes skálázásának stratégiáját alkalmazzuk számuk növelésével. Remélem, hogy ez a jövőben változni fog, és egyre több leírást fogunk látni jobb megközelítésekről, kész megoldásokról, különösen a megváltozott belső architektúrával rendelkező Selenium grid 4 megjelenése után.
Szelenoid:
A szelenoidok bevezetése a K8-ban jelenleg a legnagyobb csalódás. Nem kompatibilisek. Elméletileg fel tudunk emelni egy Selenoid tárolót egy pod belsejében, de amikor a Selenoid elindítja a konténereket a böngészőkkel, azok továbbra is ugyanabban a dobozban lesznek. Ez lehetetlenné teszi a méretezést, és ennek eredményeként a Selenoid fürtön belüli munkája nem különbözik a virtuális gépen belüli munkától. Vége a történetnek.
Hold:
Ismerve ezt a szűk keresztmetszetet a Selenoiddal való munka során, a fejlesztők kiadtak egy erősebb eszközt, a Holdat. Ezt az eszközt eredetileg a Kubernetes-szel való együttműködésre tervezték, és ennek eredményeként az automatikus skálázás funkciót lehet és kell használni. Sőt, azt mondanám, hogy jelenleg az az egyetlen egy eszköz a Selenium világban, amely natív K8s-fürt támogatással rendelkezik (gyárilag)már nem elérhető, lásd a következő eszközt ). A Moon legfontosabb jellemzői, amelyek ezt a támogatást nyújtják:
Teljesen hontalan. A szelenoid a memóriában tárolja az aktuális böngészőmunkamenetek adatait. Ha valamilyen okból a folyamat összeomlik - akkor minden futó munkamenet elveszik. Ezzel szemben a Holdnak nincs belső állapota, és az adatközpontokban replikálható. A böngészőmunkamenetek akkor is életben maradnak, ha egy vagy több replika leáll.
Szóval a Hold remek megoldás, de van egy probléma: nem ingyenes. Az ár az ülések számától függ. Csak 0-4 alkalom futhat ingyen, ami nem különösebben hasznos. De az ötödik munkamenettől kezdve mindegyikért 5 dollárt kell fizetnie. A helyzet cégenként eltérő lehet, de esetünkben értelmetlen a Moon használata. Ahogy fentebb leírtam, igény szerint futtathatunk Selenium Griddel rendelkező virtuális gépeket, vagy növelhetjük a csomópontok számát a fürtben. Körülbelül egy folyamat során 500 böngészőt indítunk el, és a tesztek befejezése után minden erőforrást leállítunk. Ha Moont használnánk, további 500 x 5 = 2500 dollárt kellene fizetnünk havonta, függetlenül attól, hogy milyen gyakran futtatunk teszteket. Ismétlem, nem azt mondom, hogy ne használd a Holdat. Az Ön feladataihoz ez nélkülözhetetlen megoldás lehet például, ha sok projekt/csapat van a szervezetében, és hatalmas közös klaszterre van szüksége mindenki számára. Mint mindig, a végén hagyok egy linket, és azt javaslom, hogy végezzen el minden szükséges számítást a feladatával összefüggésben.
Callisto: (Figyelem! Ez nem szerepel az eredeti cikkben, és csak az orosz fordítás tartalmazza)
Mint mondtam, a szelén nagyon népszerű eszköz, és az informatikai terület nagyon gyorsan fejlődik. Amíg a fordításon dolgoztam, egy új ígéretes eszköz, Callisto jelent meg a weben (hello Cypress and other Selenium killers). Natív módon működik a K8-al, és lehetővé teszi a Selenoid konténerek podokban történő futtatását, csomópontok között elosztva. A dobozból minden működik, beleértve az automatikus skálázást is. Fantasztikus, de ki kell próbálni. Már sikerült üzembe helyeznem ezt az eszközt, és számos kísérletet lefuttatnom. De még túl korai következtetéseket levonni, miután hosszú távú eredményeket kaptam, talán áttekintést fogok készíteni a jövőbeli cikkekben. Egyelőre csak linkeket hagyok a független kutatásokhoz.
Illusztráció az infrastruktúra jelenlegi állapotáról
Linkek a felfedezéshez
Hasonló eszközök
7. Infrastruktúra mint kód (IaC)
A technológia rövid leírása
És most elérkezünk az utolsó részhez. Ez a technológia és a kapcsolódó feladatok jellemzően nem az automatizálási mérnökök feladata. És ennek megvannak az okai. Először is, sok szervezetben az infrastrukturális problémák a DevOps részleg irányítása alatt állnak, és a fejlesztőcsapatokat nem igazán érdekli, hogy mitől működik a csővezeték, és hogyan kell mindent, ami azzal kapcsolatos, támogatni. Másodszor, legyünk őszinték, az Infrastructure as Code (IaC) gyakorlatát még mindig nem alkalmazzák sok vállalatnál. De mindenképpen népszerű irányzattá vált, és fontos, hogy megpróbáljunk részt venni a vele kapcsolatos folyamatokban, megközelítésekben és eszközökben. Vagy legalább maradjon naprakész.
Kezdjük ennek a megközelítésnek a motivációjával. Már megbeszéltük, hogy a tesztek GitlabCI-ben történő futtatásához legalább a Gitlab Runner futtatásához szükséges erőforrásokra lesz szükségünk. A tárolók böngészőkkel/emulátorokkal való futtatásához le kell foglalnunk egy virtuális gépet vagy fürtöt. Az erőforrások tesztelése mellett jelentős kapacitásra van szükségünk a fejlesztési, staging, éles környezetek támogatásához, amely magában foglalja az adatbázisokat, az automatikus ütemezéseket, a hálózati konfigurációkat, a terheléselosztókat, a felhasználói jogokat stb. A kulcskérdés a mindezek támogatásához szükséges erőfeszítés. Számos módja van a módosításoknak és a frissítések bevezetésének. Például a GCP kontextusában használhatjuk a UI konzolt a böngészőben, és minden műveletet a gombokra kattintva hajthatunk végre. Alternatív megoldás az API-hívások használata a felhő-entitásokkal való interakcióhoz, vagy a gcloud parancssori segédprogram használata a kívánt manipulációk végrehajtásához. De nagyon sok különböző entitás és infrastruktúraelem esetén nehéz vagy akár lehetetlenné válik az összes művelet manuális végrehajtása. Ráadásul mindezen manuális műveletek ellenőrizhetetlenek. Nem küldhetjük be őket ellenőrzésre a végrehajtás előtt, nem használhatunk verziókezelő rendszert, és nem vonhatjuk vissza gyorsan az incidenshez vezető változtatásokat. Az ilyen problémák megoldására a mérnökök automatikus bash/shell szkripteket hoztak létre és hoznak létre, amelyek nem sokkal jobbak a korábbi módszereknél, mivel nem olyan könnyű őket gyorsan elolvasni, megérteni, karbantartani és eljárási stílusban módosítani.
Ebben a cikkben és az útmutatóban két, az IaC gyakorlattal kapcsolatos eszközt használok. Ezek a Terraform és az Ansible. Vannak, akik úgy vélik, hogy nincs értelme egyszerre használni őket, mivel a funkcióik hasonlóak, és felcserélhetők. De tény, hogy kezdetben teljesen más feladatokat kapnak. Azt pedig, hogy ezeknek az eszközöknek ki kell egészíteniük egymást, a HashiCorp és a RedHat fejlesztői egy közös bemutatón erősítették meg. Az elvi különbség az, hogy a Terraform egy kiépítési eszköz maguknak a szervereknek a kezelésére. Míg az Ansible egy konfigurációkezelő eszköz, amelynek feladata szoftverek telepítése, konfigurálása és kezelése ezeken a kiszolgálókon.
Ezen eszközök másik fontos megkülönböztető jellemzője a kódolási stílus. A bash-tól és az Ansible-től eltérően a Terraform deklaratív stílust használ, amely a végrehajtás eredményeként elérni kívánt végállapot leírásán alapul. Például, ha 10 virtuális gépet fogunk létrehozni, és a változtatásokat a Terraformon keresztül alkalmazzuk, akkor 10 virtuális gépet fogunk kapni. Ha újra lefuttatjuk a szkriptet, semmi sem fog történni, hiszen már 10 virtuális gépünk van, a Terraform pedig tud erről, mert egy állapotfájlban tárolja az infrastruktúra aktuális állapotát. De az Ansible procedurális megközelítést használ, és ha 10 virtuális gép létrehozását kéri, akkor az első indításkor 10 virtuális gépet kapunk, hasonlóan a Terraformhoz. De újraindítás után már 20 virtuális gépünk lesz. Ez a lényeges különbség. A procedurális stílusban nem tároljuk az aktuális állapotot, hanem egyszerűen leírjuk a végrehajtandó lépések sorozatát. Természetesen kezelhetjük a különböző helyzeteket, hozzáadhatunk némi ellenőrzést az erőforrások meglétére és az aktuális állapotra vonatkozóan, de nincs értelme az időnket vesztegetni, és erőfeszítéseket tenni ennek a logikának az ellenőrzésére. Ráadásul ez növeli a hibák elkövetésének kockázatát.
A fentieket összefoglalva megállapíthatjuk, hogy a Terraform és a deklaratív jelölés alkalmasabb eszköz a szerverek kiépítésére. De jobb, ha a konfigurációkezelést az Ansible-re bízza. Ha ez nem megy, nézzük meg a használati eseteket az automatizálás kontextusában.
Érték az automatizálási infrastruktúra számára
Az egyetlen fontos dolog, amit itt meg kell érteni, az az, hogy a tesztautomatizálási infrastruktúrát a teljes vállalati infrastruktúra részének kell tekinteni. Ez azt jelenti, hogy minden IaC gyakorlatot globálisan kell alkalmazni a teljes szervezet erőforrásaira. Hogy ki felelős ezért, az az Ön folyamataitól függ. A DevOps csapata tapasztaltabb ezekben a kérdésekben, ők látják a teljes képet a történésekről. A minőségbiztosítási mérnökök azonban jobban részt vesznek az épületautomatizálási folyamatban és a csővezeték felépítésében, ami lehetővé teszi számukra, hogy jobban átlássák az összes szükséges változtatást és fejlesztési lehetőséget. A legjobb megoldás a közös munka, az ismeretek és ötletek cseréje a várt eredmény elérése érdekében.
Íme néhány példa a Terraform és az Ansible használatára a tesztautomatizálás és a korábban tárgyalt eszközök kontextusában:
1. Ismertesse a virtuális gépek és fürtök szükséges jellemzőit és paramétereit Terraform segítségével.
2. Az Ansible segítségével telepítse a teszteléshez szükséges eszközöket: docker, Selenoid, Selenium Grid és töltse le a böngészők/emulátorok szükséges verzióit.
3. A Terraform segítségével írja le annak a virtuális gépnek a jellemzőit, amelyben a GitLab Runner elindul.
4. Telepítse a GitLab Runnert és a szükséges kapcsolódó eszközöket az Ansible segítségével, állítsa be a beállításokat és konfigurációkat.
Illusztráció az infrastruktúra jelenlegi állapotáról
Linkek a felfedezéshez:
Hasonló eszközök
Foglaljuk össze!
Lépés
Technológia
Eszközök
Érték az automatizálási infrastruktúra számára
1
Helyi futás
Node.js, szelén, Appium
- A legnépszerűbb webes és mobileszközök
- Számos nyelvet és platformot támogat (beleértve a Node.js-t is)
2
Verziókezelő rendszerek
megy
- Hasonló előnyök a fejlesztési kóddal
3
Konténerezés
Docker, Selenium grid, Selenoid (web, Android)
- Tesztek párhuzamos futtatása
- Elszigetelt környezetek
- Egyszerű, rugalmas verziófrissítések
- A fel nem használt erőforrások dinamikus leállítása
- Könnyen beállítható
4
CI/CD
Gitlab CI
- A csővezeték egy részét teszteli
- Gyors visszajelzés
- Láthatóság az egész cég/csapat számára
5
Felhő platformok
Google Cloud Platform
- Igény szerinti erőforrások (csak szükség esetén fizetünk)
- Könnyen kezelhető és frissíthető
- Az összes erőforrás láthatósága és ellenőrzése
6
hangszerelés
Kubernetes
Böngészőket/emulátorokat tartalmazó tárolók esetében:
- Méretezés/automatikus méretezés
- Öngyógyítás
- Frissítések és visszaállítások megszakítás nélkül
7
Infrastruktúra mint kód (IaC)
Terraform, Ansible
- Hasonló előnyök a fejlesztési infrastruktúrával
- A kódverziókészítés minden előnye
- Könnyen módosítható és karbantartható
- Teljesen automatizált
Gondolattérkép diagramok: az infrastruktúra evolúciója
lépés: Helyi
2. lépés: VCS
3. lépés: Konténerezés
4. lépés: CI/CD
5. lépés: Felhőplatformok
6. lépés: Hangszerelés
7. lépés: IaC
Mi a következő lépés?
Tehát itt a cikk vége. Végezetül azonban szeretnék néhány megállapodást kötni Önnel.
A te oldaladról
Ahogy az elején is mondtam, szeretném, ha a cikk gyakorlati hasznát venné, és segítene a megszerzett ismeretek valós munkában való alkalmazásában. – teszem hozzá újra.
De még ezek után se állj meg, gyakorolj, tanulmányozd a releváns linkeket, könyveket, tudd meg, hogyan működik ez a cégedben, keress fejleszthető helyeket és vegyél részt benne. Sok szerencsét!
Az én oldalamról
A címből látszik, hogy ez még csak az első rész volt. Annak ellenére, hogy elég nagynak bizonyult, a fontos témák még mindig nem foglalkoznak itt. A második részben az automatizálási infrastruktúrát tervezem megvizsgálni az IOS kontextusában. Mivel az Apple korlátozza az iOS szimulátorok csak macOS rendszereken való futtatását, megoldásaink köre szűkült. Például nem tudjuk használni a Dockert a szimulátor futtatásához, vagy a nyilvános felhőket virtuális gépek futtatásához. De ez nem jelenti azt, hogy ne lenne más alternatíva. Korszerű megoldásokkal és modern eszközökkel igyekszem naprakészen tartani!
Ezenkívül nem említettem a figyeléssel kapcsolatos túl nagy témákat. A 3. részben áttekintem a legnépszerűbb infrastruktúra-figyelő eszközöket, valamint azt, hogy milyen adatokat és mérőszámokat érdemes figyelembe venni.
És végül. A jövőben tervezek egy videotanfolyam kiadását a tesztinfrastruktúra és a népszerű eszközök kiépítéséről. Jelenleg elég sok tanfolyam és előadás található a DevOps-ról az interneten, de minden anyag a fejlesztés, nem pedig a tesztautomatizálás keretében kerül bemutatásra. Ebben a kérdésben valóban visszajelzésre lenne szükségem, hogy egy ilyen tanfolyam érdekes és értékes lesz-e a tesztelők és automatizálási mérnökök közössége számára. Előre is köszönöm!
Forrás: will.com