Deel 1: Web/Android
Remarque: Dësen Artikel ass eng Iwwersetzung vum Originalartikel op Russesch Wéi och ëmmer, all Illustratiounen, Linken, Zitater a Begrëffer sinn an der Originalsprooch erhaalen fir Verzerrung vun der Bedeitung ze vermeiden wann se op Russesch iwwersat ginn. Ech wënschen Iech glécklech ze studéieren!
De Moment ass d'DevOps Spezialitéit eng vun de meeschte gefrot an der IT Industrie. Wann Dir populär Aarbechtssichsäiten opmaacht an no Pai filtert, gesitt Dir datt DevOps-relatéiert Aarbechtsplazen uewen op der Lëscht sinn. Wéi och ëmmer, et ass wichteg ze verstoen datt dëst haaptsächlech op eng 'Senior' Positioun bezitt, wat implizéiert datt de Kandidat en héije Niveau u Fäegkeeten, Wëssen iwwer Technologie an Tools huet. Dëst kënnt och mat engem héije Grad vu Verantwortung verbonne mat der onënnerbrach Operatioun vun der Produktioun. Wéi och ëmmer, mir hunn ugefaang ze vergiessen wat DevOps ass. Am Ufank war et keng spezifesch Persoun oder Departement. Wa mir no Definitioune vun dësem Begrëff kucken, fanne mir vill schéin a korrekt Substantiver, wéi Methodologie, Praktiken, Kulturphilosophie, Grupp vu Konzepter, asw.
Meng Spezialisatioun ass en Testautomatiséierungsingenieur (QA Automatisatiounsingenieur), awer ech gleewen datt et net nëmme mat Autotester schreiwen oder Testkaderarchitektur entwéckelen soll. Am Joer 2020 ass Wësse vun der Automatisatiounsinfrastruktur och wesentlech. Dëst erlaabt Iech den Automatisatiounsprozess selwer ze organiséieren, vun Tester lafen bis Resultater un all Akteuren am Aklang mat Ären Ziler. Als Resultat sinn DevOps Fäegkeeten e Must fir d'Aarbecht gemaach ze kréien. An dat alles ass gutt, awer leider gëtt et e Problem (Spoiler: Dësen Artikel probéiert dëse Problem ze vereinfachen). De Punkt ass datt DevOps schwéier ass. An dat ass evident, well Firmen net vill bezuelen fir eppes wat einfach ass ze maachen ... An der DevOps Welt ginn et eng grouss Unzuel vun Tools, Begrëffer a Praktiken déi musse beherrscht ginn. Dëst ass besonnesch schwéier am Ufank vun enger Carrière an hänkt vun der cumuléierter technescher Erfahrung of.
Source:
Hei wäerte mir wahrscheinlech mam Aféierungsdeel ofschléissen an op den Zweck vun dësem Artikel fokusséieren.
Iwwer wat geet dësen Artikel?
An dësem Artikel wäert ech meng Erfahrung deelen fir eng Testautomatiséierungsinfrastruktur ze bauen. Et gi vill Informatiounsquellen um Internet iwwer verschidden Tools a wéi se se benotzen, awer ech wéilt se reng am Kontext vun der Automatioun kucken. Ech gleewen datt vill Automatisatiounsingenieure mat der Situatioun vertraut sinn wann keen ausser Dir déi entwéckelt Tester leeft oder sech këmmert ëm se ze erhalen. Als Resultat ginn Tester veroudert an Dir musst Zäit verbréngen fir se ze aktualiséieren. Erëm, am Ufank vun enger Carrière, kann dëst eng zimlech schwiereg Aufgab sinn: verstänneg ze entscheeden wéi eng Tools hëllefe solle e bestëmmte Problem eliminéieren, wéi se auswielen, konfiguréieren an erhalen. E puer Tester wenden sech op DevOps (Mënschen) fir Hëllef an, loosst eis éierlech sinn, dës Approche funktionnéiert. A ville Fäll ass dëst déi eenzeg Optioun well mir keng Visibilitéit an all Ofhängegkeeten hunn. Awer wéi mir wëssen, sinn DevOps ganz beschäftegt Kärelen, well se mussen iwwer d'Infrastruktur vun der ganzer Firma denken, d'Deployment, d'Iwwerwaachung, d'Mikroservicer an aner ähnlech Aufgaben ofhängeg vun der Organisatioun / Team. Wéi normalerweis de Fall ass d'Automatisatioun keng Prioritéit. An esou engem Fall musse mir probéieren, vun Ufank bis Enn alles méiglech ze maachen. Dëst reduzéiert Ofhängegkeeten, beschleunegt de Workflow, verbessert eis Fäegkeeten an erlaabt eis dat méi grousst Bild ze gesinn wat geschitt.
Den Artikel präsentéiert déi populärst a populär Tools a weist wéi se se benotze fir eng Automatisatiounsinfrastruktur Schrëtt fir Schrëtt ze bauen. All Grupp gëtt duerch Tools vertrueden, déi duerch perséinlech Erfahrung getest goufen. Awer dat heescht net datt Dir datselwecht benotze musst. D'Instrumenter selwer sinn net wichteg, si erschéngen a ginn al. Eis Ingenieursaufgab ass d'Basisprinzipien ze verstoen: firwat mir dës Grupp vun Tools brauchen a wéi eng Aarbechtsproblemer kënne mir mat hirer Hëllef léisen. Dofir loossen ech um Enn vun all Sektioun Linken op ähnlech Tools déi an Ärer Organisatioun benotzt kënne ginn.
Wat ass net an dësem Artikel
Ech widderhuelen nach eng Kéier datt den Artikel net iwwer spezifesch Tools ass, also gëtt et keng Inserts vum Code aus der Dokumentatioun an Beschreiwunge vu spezifesche Kommandoen. Awer um Enn vun all Sektioun verloossen ech Links fir detailléiert Studie.
Dëst gëtt gemaach well:
- dëst Material ass ganz einfach a verschiddene Quellen ze fannen (Dokumentatioun, Bicher, Videocoursen);
- wa mir ufänken méi déif ze goen, musse mir 10, 20, 30 Deeler vun dësem Artikel schreiwen (während d'Pläng 2-3 sinn);
- Ech wëll just Är Zäit net verschwenden well Dir vläicht aner Tools benotze wëllt fir déiselwecht Ziler z'erreechen.
Praxis
Ech hätt wierklech gär datt dëst Material fir all Lieser nëtzlech ass, an net nëmme gelies a vergiess. An all Etude ass Praxis e ganz wichtege Bestanddeel. Fir dëst hunn ech virbereet. Et gëtt och Hausaufgaben op Iech gewaart fir sécherzestellen datt Dir d'Zeilen vun de Kommandoen déi Dir ausféiert net ouni Gedanken kopéiert.
Plang
Schrëtt
Technology
Tools
1
Lokal Lafen (virbereet Web / Android Demo Tester a lafen se lokal)
Node.js, Selenium, Appium
2
Versioun Kontroll Systemer
goen
3
Containeriséierung
Docker, Selenium Gitter, Selenoid (Web, Android)
4
CI/CD
Gitlab CI
5
Cloud Plattformen
Google Cloud Plattform
6
Orchestratioun
Kubernetes
7
Infrastruktur als Code (IaC)
Terraform, Ansible
Struktur vun all Sektioun
Fir d'narrativ kloer ze halen, gëtt all Sektioun no de folgende Kontur beschriwwen:
- kuerz Beschreiwung vun der Technologie,
- Wäert fir Automatisatiounsinfrastruktur,
- Illustratioun vum aktuellen Zoustand vun der Infrastruktur,
- Linke fir ze studéieren,
- ähnlechen Tools.
1. Run Tester lokal
Kuerz Beschreiwung vun der Technologie
Dëst ass just e Virbereedungsschrëtt fir d'Demo Tester lokal auszeféieren an z'iwwerpréiwen datt se passéieren. Am prakteschen Deel gëtt Node.js benotzt, awer d'Programméierungssprooch an d'Plattform sinn och net wichteg an Dir kënnt déi benotzen déi an Ärer Firma benotzt ginn.
Wéi och ëmmer, als Automatisatiounsinstrumenter, recommandéieren ech Selenium WebDriver fir Webplattformen an Appium fir Android Plattform ze benotzen, respektiv, well an den nächste Schrëtt wäerte mir Docker Biller benotzen, déi ugepasst sinn fir speziell mat dësen Tools ze schaffen. Ausserdeem, bezunn op d'Aarbechtsfuerderunge, sinn dës Tools am meeschte gefrot um Maart.
Wéi Dir vläicht gemierkt hutt, betruechte mir nëmmen Web- an Android Tester. Leider ass iOS eng komplett aner Geschicht (Merci Apple). Ech plangen IOS-relatéiert Léisungen a Praktiken an de kommenden Deeler ze weisen.
Wäert fir Automatisatiounsinfrastruktur
Aus enger Infrastruktur Perspektiv gëtt lokal Lafen kee Wäert. Dir kontrolléiert nëmmen datt d'Tester op der lokaler Maschinn a lokalen Browser a Simulatoren lafen. Mä op alle Fall ass dëst en noutwendege Startpunkt.
Illustratioun vum aktuellen Zoustand vun der Infrastruktur
Links fir ze entdecken
Ähnlech Tools
- all Programméierungssprooch Dir gär a Verbindung mat Selenium / Appium Tester;
- all Tester;
- all Test Leefer.
2. Versiounskontrollsystemer (Git)
Kuerz Beschreiwung vun der Technologie
Et wäert keng grouss Offenbarung fir jiddereen sinn wann ech soen datt Versiounskontroll en extrem wichtegen Deel vun der Entwécklung ass, souwuel an engem Team wéi och individuell. Baséierend op verschidde Quellen ass et sécher ze soen datt Git de populärste Vertrieder ass. E Versiounskontrollsystem bitt vill Virdeeler, sou wéi Code Sharing, Versiounen späicheren, Restauréieren a fréiere Filialen, Iwwerwaachung vu Projetsgeschicht a Backups. Mir wäerten net all Punkt am Detail diskutéieren, well ech sécher sinn datt Dir ganz vertraut sidd an et an Ärer alldeeglecher Aarbecht benotzt. Awer wann op eemol net, da recommandéieren ech dësen Artikel ze liesen an dës Lück sou séier wéi méiglech ze fëllen.
Wäert fir Automatisatiounsinfrastruktur
An hei kënnt Dir eng raisonnabel Fro stellen: "Firwat seet hien eis iwwer Git? Jidderee weess dëst a benotzt et souwuel fir Entwécklungscode wéi och fir Auto-Testcode. Dir wäert absolut richteg sinn, awer an dësem Artikel schwätze mir iwwer Infrastruktur an dës Sektioun wierkt als Virschau fir Sektioun 7: "Infrastruktur als Code (IaC)". Fir eis heescht dat datt déi ganz Infrastruktur, inklusiv Testen, a Form vu Code beschriwwe gëtt, sou datt mir och Versiounssystemer dozou kënnen applizéieren an ähnlech Virdeeler kréien wéi fir Entwécklungs- an Automatisatiounscode.
Mir kucken IaC méi detailléiert am Schrëtt 7, awer och elo kënnt Dir Git lokal benotzen andeems Dir e lokale Repository erstellt. Dat grousst Bild gëtt erweidert wa mir e Remote Repository an d'Infrastruktur addéieren.
Illustratioun vum aktuellen Zoustand vun der Infrastruktur
Links fir ze entdecken
Ähnlech Tools
3. Containeriséierung (Docker)
Kuerz Beschreiwung vun der Technologie
Fir ze weisen wéi d'Containeriséierung d'Spillregele geännert huet, loosst eis e puer Joerzéngte zréck an d'Zäit goen. Deemools hunn d'Leit Servermaschinne kaaft a benotzt fir Uwendungen ze lafen. Awer am meeschte Fäll waren déi erfuerderlech Startressourcen net am Viraus bekannt. Als Resultat hunn d'Firmen Sue fir de Kaf vun deieren, mächtege Serveren ausginn, awer e puer vun dëser Kapazitéit gouf net komplett genotzt.
Déi nächst Etapp vun der Evolutioun war virtuell Maschinnen (VMs), déi de Problem vun Geldverschwendung op onbenotzt Ressourcen geléist. Dës Technologie huet et méiglech gemaach Uwendungen onofhängeg vuneneen am selwechte Server ze lafen, komplett isoléiert Raum ze verdeelen. Mee, leider, all Technologie huet seng Nodeeler. Fir e VM ze lafen erfuerdert e komplette Betribssystem, deen CPU, RAM, Späichere verbraucht an, ofhängeg vum OS, Lizenzkäschte musse berücksichtegt ginn. Dës Faktoren beaflossen d'Laaschtgeschwindegkeet a maachen d'Portabilitéit schwéier.
An elo komme mir zu Containeriséierung. Nach eng Kéier léist dës Technologie de fréiere Problem, well Container keng voll OS benotzen, wat eng grouss Quantitéit vu Ressourcen befreit an eng séier a flexibel Léisung fir Portabilitéit ubitt.
Natierlech ass d'Containeriséierungstechnologie näischt Neies a gouf fir d'éischt an de spéide 70er agefouert. An deenen Deeg goufe vill Fuerschung, Entwécklungen a Versuche gemaach. Awer et war Docker deen dës Technologie ugepasst huet an et fir d'Massen liicht zougänglech gemaach huet. Hautdesdaags, wa mir iwwer Container schwätzen, mengen mir an de meeschte Fäll Docker. Wa mir iwwer Docker Container schwätzen, mengen mir Linux Container. Mir kënnen Windows a MacOS Systemer benotze fir Container ze lafen, awer et ass wichteg ze verstoen datt an dësem Fall eng zousätzlech Schicht erschéngt. Zum Beispill, Docker op Mac leeft roueg Container an engem liichte Linux VM. Mir wäerten op dëst Thema zréckkommen wa mir Android Emulatoren an Containeren lafen, also hei ass eng ganz wichteg Nuance déi méi detailléiert diskutéiert muss ginn.
Wäert fir Automatisatiounsinfrastruktur
Mir hunn erausfonnt datt Containeriséierung an Docker cool sinn. Loosst eis dat am Kontext vun der Automatisatioun kucken, well all Tool oder Technologie muss e Problem léisen. Loosst eis déi offensichtlech Probleemer vun der Testautomatiséierung am Kontext vun UI Tester skizzéieren:
- eng grouss Unzuel vun Ofhängegkeeten beim Installatioun vu Selenium a besonnesch Appium;
- Kompatibilitéitsproblemer tëscht Versioune vu Browser, Simulatoren a Chauffeuren;
- Mangel un isoléiert Plaz fir Browser / Simulatoren, wat besonnesch kritesch ass fir parallel Lafen;
- schwéier ze verwalten an z'erhalen wann Dir 10, 50, 100 oder souguer 1000 Browser zur selwechter Zäit muss lafen.
Awer well Selenium dat populärste Automatisatiounsinstrument ass an Docker dat populärste Containeriséierungsinstrument ass, sollt et net iwwerraschen datt iergendeen probéiert huet se ze kombinéieren fir e mächtegt Tool ze kreéieren fir déi uewe genannte Probleemer ze léisen. Loosst eis esou Léisunge méi detailléiert betruechten.
Selenium Gitter am Docker
Dëst Tool ass de populärste an der Selenium Welt fir verschidde Browser op verschidde Maschinnen ze lafen an se vun engem zentrale Hub ze managen. Fir unzefänken, musst Dir op d'mannst 2 Deeler umellen: Hub an Node (en). Hub ass en zentrale Node deen all Ufroe vun Tester kritt an se op déi entspriechend Noden verdeelt. Fir all Node kënne mir eng spezifesch Konfiguratioun konfiguréieren, zum Beispill andeems Dir de gewënschten Browser a seng Versioun spezifizéiert. Wéi och ëmmer, mir mussen nach selwer kompatiblen Browser Treiber këmmeren an se op de gewënschten Noden installéieren. Aus dësem Grond gëtt Selenium Gitter net a senger reiner Form benotzt, ausser wa mir musse mat Browser schaffen, déi net op Linux OS installéiert kënne ginn. Fir all aner Fäll wier eng wesentlech flexibel a korrekt Léisung d'Docker Biller ze benotzen fir Selenium Gitter Hub an Noden ze lafen. Dës Approche vereinfacht immens Nodemanagement, well mir d'Bild auswielen, déi mir brauchen mat kompatiblen Versioune vu Browser a Chauffeuren déi scho installéiert sinn.
Trotz negativen Rezensiounen iwwer Stabilitéit, besonnesch wann Dir eng grouss Zuel vu Noden parallel leeft, Selenium Gitter ass ëmmer nach dat populärste Tool fir Selenium Tester parallel ze lafen. Et ass wichteg ze bemierken datt verschidde Verbesserungen an Ännerungen vun dësem Tool stänneg an der Open Source erschéngen, déi verschidde Flaschenhals bekämpfen.
Selenoid fir Web
Dëst Tool ass en Duerchbroch an der Welt vum Selenium well et direkt aus der Këscht funktionnéiert an d'Liewe vu villen Automatisatiounsingenieuren vill méi einfach gemaach huet. Als éischt ass dëst keng aner Ännerung vum Selenium Gitter. Amplaz hunn d'Entwéckler eng komplett nei Versioun vum Selenium Hub zu Golang erstallt, déi, kombinéiert mat liichte Docker Biller fir verschidde Browser, Impuls fir d'Entwécklung vun der Testautomatiséierung ginn. Ausserdeem, am Fall vum Selenium Grid, musse mir all déi erfuerderlech Browser an hir Versiounen am Viraus bestëmmen, wat kee Problem ass wann Dir nëmmen mat engem Browser schafft. Awer wann et ëm verschidde ënnerstëtzte Browser kënnt, ass Selenoid d'Nummer eent Léisung dank senger 'Browser on demand' Feature. Alles wat vun eis erfuerderlech ass ass déi néideg Biller mat Browser am Viraus erofzelueden an d'Konfiguratiounsdatei ze aktualiséieren, mat där Selenoid interagéiert. Nodeems de Selenoid eng Ufro vun den Tester kritt, gëtt et automatesch de gewënschten Container mat dem gewënschten Browser starten. Wann den Test fäerdeg ass, wäert Selenoid de Container zréckzéien, an doduerch Ressourcen fir zukünfteg Ufroe befreien. Dës Approche eliminéiert komplett de bekannte Problem vun der 'Node Degradatioun', déi mir dacks am Selenium Gitter begéinen.
Awer, leider, Selenoid ass nach ëmmer keng Sëlwerkugel. Mir hunn d'Funktioun 'Browser op Ufro' kritt, awer d'Funktioun 'Ressourcen op Ufro' ass nach ëmmer net verfügbar. Fir Selenoid ze benotzen, musse mir et op kierperlech Hardware oder op engem VM ofsetzen, dat heescht datt mir am Viraus musse wëssen, wéi vill Ressourcen musse verdeelt ginn. Ech denken, datt dëst kee Problem ass fir kleng Projeten déi 10, 20 oder souguer 30 Browser parallel lafen. Awer wat wa mir 100, 500, 1000 oder méi brauchen? Et mécht kee Sënn fir esou vill Ressourcen déi ganzen Zäit z'erhalen an ze bezuelen. An de Sektiounen 5 an 6 vun dësem Artikel wäerte mir Léisungen diskutéieren, déi Iech erlaben ze skaléieren, an doduerch d'Firmaskäschte wesentlech reduzéieren.
Selenoid fir Android
Nom Erfolleg vu Selenoid als Webautomatiséierungsinstrument wollten d'Leit eppes ähnlechen fir Android. An et ass geschitt - Selenoid gouf mat Android Support verëffentlecht. Vun engem héije Benotzer Siicht ass de Prinzip vun der Operatioun ähnlech wéi Webautomatiséierung. Deen eenzegen Ënnerscheed ass datt amplaz vu Browserbehälter Selenoid Android Emulatorbehälter leeft. Menger Meenung no ass dëst am Moment de mächtegste gratis Tool fir Android Tester parallel ze lafen.
Ech wéilt wierklech net iwwer déi negativ Aspekter vun dësem Tool schwätzen, well ech wierklech wierklech gär hunn. Awer nach ëmmer ginn et déiselwecht Nodeeler déi fir Webautomatiséierung gëllen a mat Skaléieren verbonne sinn. Zousätzlech zu dësem musse mir iwwer eng méi Begrenzung schwätzen, déi iwwerrascht ka kommen wa mir d'Tool fir d'éischte Kéier opstellen. Fir Android Biller ze lafen, brauche mir eng physesch Maschinn oder VM mat Nested Virtualization Support. Am How-to Guide weisen ech wéi een dëst op engem Linux VM aktivéiert. Wéi och ëmmer, wann Dir e MacOS Benotzer sidd a Selenoid lokal wëllt ofsetzen, da wäert dëst net méiglech sinn Android Tester auszeféieren. Awer Dir kënnt ëmmer e Linux VM lokal mat 'nested Virtualization' konfiguréiert lafen an Selenoid dobannen ofsetzen.
Illustratioun vum aktuellen Zoustand vun der Infrastruktur
Am Kontext vun dësem Artikel addéiere mir 2 Tools fir d'Infrastruktur ze illustréieren. Dëst sinn Selenium Gitter fir Web Tester a Selenoid fir Android Tester. Am GitHub Tutorial weisen ech Iech och wéi Dir Selenoid benotzt fir Webtester ze lafen.
Links fir ze entdecken
Ähnlech Tools
- Et ginn aner Containeriséierungsinstrumenter, awer Docker ass déi populärst. Wann Dir eppes anescht wëllt probéieren, denkt drun datt d'Tools déi mir iwwerdeckt hunn fir Selenium Tester parallel ze lafen net aus der Këscht funktionnéieren.
- Wéi scho gesot, ginn et vill Ännerunge vum Selenium Gitter, zum Beispill,.
4.CI/CD
Kuerz Beschreiwung vun der Technologie
D'Praxis vun der kontinuéierlecher Integratioun ass zimmlech populär an der Entwécklung an ass op Par mat Versiounskontrollsystemer. Trotzdem mengen ech datt et Duercherneen an der Terminologie ass. An dësem Paragraf géif ech gär 3 Ännerunge vun dëser Technologie aus menger Siicht beschreiwen. Um Internet fannt Dir vill Artikele mat verschiddenen Interpretatiounen, an et ass absolut normal wann Är Meenung anescht ass. Déi wichtegst Saach ass datt Dir op der selwechter Säit mat Äre Kollegen sidd.
Also, et ginn 3 Begrëffer: CI - Continuous Integration, CD - Continuous Delivery an erëm CD - Continuous Deployment. (Drënner wäert ech dës Begrëffer op Englesch benotzen). All Ännerung füügt e puer zousätzlech Schrëtt un Är Entwécklungspipeline. Awer d'Wuert kontinuéierlech sinn (kontinuéierlech) ass déi wichtegst Saach. Mir mengen an deem Kontext eppes wat vun Ufank bis Enn geschitt, ouni Ënnerbriechung oder manuell Interventioun. Loosst eis CI & CD an CD an dësem Kontext kucken.
- Kontinuéierlech Integratioun dëst ass den éischte Schrëtt vun der Evolutioun. Nodeems mir neie Code op de Server ofginn hunn, erwaarden mir séier Feedback ze kréien datt eis Ännerungen ok sinn. Typesch enthält CI Lafen statesch Code Analyse Tools an Eenheet / intern API Tester. Dëst erlaabt eis Informatiounen iwwert eise Code bannent e puer Sekonnen / Minutten ze kréien.
- Kontinuéierlech Liwwerung ass e méi fortgeschratt Schrëtt wou mir Integratioun / UI Tester lafen. Wéi och ëmmer, an dëser Etapp kréie mir net sou séier Resultater wéi mat CI. Als éischt daueren dës Zorte vun Tester méi laang fir ze kompletéieren. Zweetens, virum Start, musse mir eis Ännerunge fir d'Test / Staging Ëmfeld ofsetzen. Ausserdeem, wa mir iwwer mobil Entwécklung schwätzen, da schéngt en zousätzleche Schrëtt fir e Bau vun eiser Applikatioun ze kreéieren.
- Kontinuéierlech Implementatioun gëtt ugeholl datt mir automatesch eis Ännerunge fir d'Produktioun fräiginn wann all Akzeptanz Tester an de fréiere Stadien passéiert sinn. Zousätzlech zu dësem, no der Verëffentlechungsstadium, kënnt Dir verschidde Stadien konfiguréieren, sou wéi Rauchtester op d'Produktioun lafen a Metriken vun Interesse sammelen. Continuous Deployment ass nëmme méiglech mat gudder Ofdeckung duerch automatiséiert Tester. Wann manuell Interventiounen erfuerderlech sinn, och Testen, dann ass dat net méi Weider (kontinuéierlech). Da kënne mir soen datt eis Pipeline nëmme mat der Praxis vun der kontinuéierlecher Liwwerung entsprécht.
Wäert fir Automatisatiounsinfrastruktur
An dëser Sektioun soll ech klären datt wa mir iwwer End-to-End UI Tester schwätzen, heescht et datt mir eis Ännerungen an assoziéiert Servicer solle fir Ëmfeld testen. Kontinuéierlech Integratioun - de Prozess ass net uwendbar fir dës Aufgab a mir musse këmmere fir op d'mannst Continuous Deliver Praktiken ëmzesetzen. Continuous Deployment mécht och Sënn am Kontext vun UI Tester wa mir se an der Produktioun lafen.
A ier mer d'Illustratioun vun der Architektur änneren, wëll ech e puer Wierder iwwer GitLab CI soen. Am Géigesaz zu anere CI / CD Tools bitt GitLab e Remote Repository a vill aner zousätzlech Funktiounen. Also, GitLab ass méi wéi CI. Et enthält Quellcodemanagement, Agile Management, CI / CD Pipelines, Logging Tools a Metrik Sammlung aus der Këscht. D'GitLab Architektur besteet aus Gitlab CI/CD a GitLab Runner. Hei ass eng kuerz Beschreiwung vun der offizieller Websäit:
Gitlab CI / CD ass eng Webapplikatioun mat enger API déi säin Zoustand an enger Datebank späichert, Projeten / baut geréiert an eng User-Interface ubitt. GitLab Runner ass eng Applikatioun déi baut. Et kann separat ofgebaut ginn a funktionnéiert mat GitLab CI / CD duerch eng API. Fir Tester lafen braucht Dir souwuel Gitlab Instanz wéi Runner.
Illustratioun vum aktuellen Zoustand vun der Infrastruktur
Links fir ze entdecken
Ähnlech Tools
- A vill anerer
5. Cloud Plattformen
Kuerz Beschreiwung vun der Technologie
An dëser Rubrik wäerte mir iwwer e populäre Trend schwätzen, deen 'ëffentlech Wolleken' genannt gëtt. Trotz den enorme Virdeeler déi d'virtualiséierungs- a Containeriséierungstechnologien uewe beschriwwen ubidden, brauche mir nach ëmmer Rechenressourcen. Firmen kafen deier Serveren oder lounen Datenzenteren, awer an dësem Fall ass et néideg Berechnungen ze maachen (heiansdo onrealistesch) wéi vill Ressourcen mir brauchen, ob mir se 24/7 benotzen a fir wéi eng Zwecker. Zum Beispill erfuerdert d'Produktioun e Server deen XNUMX/XNUMX leeft, awer brauche mir ähnlech Ressourcen fir ausserhalb vun der Aarbechtszäit ze testen? Et hänkt och vun der Aart vum Test of, deen duerchgefouert gëtt. E Beispill wier Laascht / Stress Tester déi mir plangen während net-Aarbechtszäiten auszeféieren fir Resultater den nächsten Dag ze kréien. Awer definitiv XNUMX/XNUMX Serververfügbarkeet ass net erfuerderlech fir end-to-end automatiséiert Tester a besonnesch net fir manuell Testëmfeld. Fir esou Situatiounen wier et gutt esou vill Ressourcen ze kréien wéi néideg op Ufro, se ze benotzen an opzehalen ze bezuelen wann se net méi gebraucht ginn. Ausserdeem wier et super fir se direkt ze kréien andeems Dir e puer Mausklicken maacht oder e puer Scripte leeft. Dëst ass wat ëffentlech Wolleke fir benotzt ginn. Loosst eis d'Definitioun kucken:
"Déi ëffentlech Wollek ass definéiert als Informatikservicer, déi vun Drëtt-Partei Ubidder iwwer dem ëffentlechen Internet ugebuede ginn, fir se verfügbar ze maachen fir jiddereen deen se benotze wëllt oder kafen. Si kënne gratis sinn oder on-Demande verkaaft ginn, wat d'Clienten erlaabt nëmme pro Notzung fir d'CPU-Zyklen, d'Späichere oder d'Bandbreed ze bezuelen déi se verbrauchen.
Et gëtt eng Meenung datt ëffentlech Wolleken deier sinn. Awer hir Schlësselidee ass d'Firma Käschten ze reduzéieren. Wéi virdru scho gesot, ëffentlech Wolleken erlaben Iech Ressourcen op Ufro ze kréien an nëmme fir d'Zäit ze bezuelen déi Dir benotzt. Och heiansdo vergiesse mir datt d'Mataarbechter Paien kréien, a Spezialisten sinn och eng deier Ressource. Et muss berücksichtegt ginn datt ëffentlech Wolleken d'Infrastruktur Ënnerstëtzung vill méi einfach maachen, wat d'Ingenieuren erlaabt op méi wichteg Aufgaben ze fokusséieren.
Wäert fir Automatisatiounsinfrastruktur
Wéi eng spezifesch Ressourcen brauche mir fir end-to-end UI Tester? Prinzipiell sinn dës virtuell Maschinnen oder Cluster (mir schwätzen iwwer Kubernetes an der nächster Sektioun) fir Browser an Emulatoren ze lafen. Wat méi Browser an Emulatore mir wëllen gläichzäiteg lafen, wat méi CPU an Erënnerung erfuerderlech sinn an wat méi Sue musse mir dofir bezuelen. Also erlaben ëffentlech Wolleken am Kontext vun der Testautomatiséierung eng grouss Zuel (100, 200, 1000 ...) vu Browser/Emulatoren op Ufro ze lafen, Testresultater sou séier wéi méiglech ze kréien an opzehalen fir sou onheemlech ressourceintensiv ze bezuelen Muecht.
Déi populärste Cloud Ubidder sinn Amazon Web Services (AWS), Microsoft Azure, Google Cloud Platform (GCP). De How-to Guide liwwert Beispiller vu wéi Dir GCP benotzt, awer allgemeng ass et egal wat Dir fir Automatisatiounsaufgaben benotzt. Si bidden all ongeféier déiselwecht Funktionalitéit. Typesch, fir e Fournisseur ze wielen, konzentréiert d'Gestioun sech op d'ganz Infrastruktur an d'Geschäftsufuerderunge vun der Firma, wat iwwer den Ëmfang vun dësem Artikel ass. Fir Automatisatiounsingenieuren wäert et méi interessant sinn d'Benotzung vu Cloud Provider mat der Notzung vu Cloud Plattformen speziell fir Testzwecker ze vergläichen, wéi Sauce Labs, BrowserStack, BitBar, a sou weider. Also loosst eis et och maachen! Menger Meenung no, Sauce Labs ass de bekanntste Cloud Test Farm, dofir hunn ech et zum Verglach benotzt.
GCP vs Sauce Labs fir Automatisatiounszwecker:
Loosst eis virstellen datt mir 8 Webtester an 8 Android Tester gläichzäiteg musse lafen. Fir dëst wäerte mir GCP benotzen an 2 virtuell Maschinnen mat Selenoid lafen. Op der éischter wäerte mir 8 Container mat Browser erhéijen. Op der zweeter sinn et 8 Container mat Emulatoren. Loosst eis d'Präisser kucken:
Fir ee Container mat Chrome ze lafen, brauche mir n1-Standard-1 auto. Am Fall vun Android wäert et sinn n1-Standard-4 fir een Emulator. Tatsächlech ass e méi flexibelen a méi bëllege Wee fir spezifesch Benotzerwäerter fir CPU / Memory ze setzen, awer am Moment ass dëst net wichteg fir de Verglach mat Sauce Labs.
An hei sinn d'Tariffer fir Sauce Labs ze benotzen:
Ech gleewen datt Dir den Ënnerscheed schonn gemierkt hutt, awer ech wäert nach ëmmer en Dësch mat Berechnungen fir eis Aufgab ubidden:
Néideg Ressourcen
Montant
Aarbechtszäiten(8-8 Uhr)
Aarbechtszäiten+ Viraussiichtlech
GCP fir Web
n1-Standard-1 x 8 = n1-Standard-8
$194.18
23 Deeg * 12h * 0.38 = $ 104.88
23 Deeg * 12h * 0.08 = $ 22.08
Sauce Labs fir Web
Virtuell Cloud8 parallel Tester
$1.559
-
-
GCP fir Android
n1-Standard-4 x 8: n1-Standard-16
$776.72
23 Deeg * 12h * 1.52 = $ 419.52
23 Deeg * 12h * 0.32 = $ 88.32
Sauce Labs fir Android
Real Apparat Cloud 8 parallel Tester
$1.999
-
-
Wéi Dir gesitt, ass den Ënnerscheed an de Käschten enorm, besonnesch wann Dir Tester nëmmen während enger zwielef Stonn Aarbechtszäit leeft. Awer Dir kënnt d'Käschte nach méi reduzéieren wann Dir preemptible Maschinnen benotzt. Wat ass et?
E preemptible VM ass eng Instanz déi Dir kënnt erstellen a lafen zu engem vill méi héije Präis wéi normal Instanzen. Wéi och ëmmer, Compute Engine kann dës Instanzen ofschléissen (preemptéieren) wann et Zougang zu dëse Ressourcen fir aner Aufgaben erfuerdert. Preempbar Instanzen sinn iwwerschësseg Compute Engine Kapazitéit, sou datt hir Disponibilitéit variéiert mat der Notzung.
Wann Är Apps Feeler-tolerant sinn a méiglech Instanz Viraussetzunge widderstoen, da kënnen preempibel Instanzen Är Compute Engine Käschten wesentlech reduzéieren. Zum Beispill kënne Batchveraarbechtungsjobs op preemptiblen Instanzen lafen. Wann e puer vun dësen Instanzen während der Veraarbechtung ophalen, verlangsamt d'Aarbecht awer net komplett. Preempbar Instanzen kompletéiere Är Batchveraarbechtungsaufgaben ouni zousätzlech Aarbechtsbelaaschtung op Är existent Instanzen ze setzen an ouni datt Dir de ganze Präis fir zousätzlech normal Instanzen erfuerdert.
An et ass nach ëmmer net eriwwer! A Wierklechkeet sinn ech sécher datt keen Tester fir 12 Stonnen ouni Paus mécht. A wann jo, da kënnt Dir automatesch virtuell Maschinnen starten an stoppen wann se net gebraucht ginn. Tatsächlech Notzungszäit kann op 6 Stonnen den Dag reduzéiert ginn. Da wäert d'Bezuelung am Kontext vun eiser Aufgab op $11 pro Mount fir 8 Browser erofgoen. Ass dat net wonnerbar? Awer mat preemptible Maschinnen musse mir virsiichteg sinn a virbereet sinn op Ënnerbriechungen an Onstabilitéit, obwuel dës Situatiounen an der Software virgesinn a gehandhabt kënne ginn. Et ass derwäert!
Awer op kee Fall soen ech "benotzt ni Cloud Test Farmen". Si hunn eng Rei vu Virdeeler. Als éischt ass dëst net nëmmen eng virtuell Maschinn, awer eng vollwäerteg Testautomatiséierungsléisung mat enger Set vu Funktionalitéit aus der Këscht: Fernzougang, Logbicher, Screenshots, Videoopnam, verschidde Browser a kierperlech mobilen Apparater. A ville Situatiounen kann dëst eng wesentlech chic Alternativ sinn. Testplattformen si besonnesch nëtzlech fir IOS Automatioun, wann ëffentlech Wolleken nëmme Linux / Windows Systemer ubidden. Awer mir schwätzen iwwer iOS an den folgenden Artikelen. Ech recommandéieren ëmmer d'Situatioun ze kucken a vun den Aufgaben unzefänken: an e puer Fäll ass et méi bëlleg a méi effizient fir ëffentlech Wolleken ze benotzen, an anerer sinn d'Testplattformen definitiv d'Suen wäert.
Illustratioun vum aktuellen Zoustand vun der Infrastruktur
Links fir ze entdecken
Ähnlech Tools:
6. Orchestratioun
Kuerz Beschreiwung vun der Technologie
Ech hu gutt Noriicht - mir si bal um Enn vum Artikel! Am Moment besteet eis Automatisatiounsinfrastruktur aus Web- an Android Tester, déi mir parallel duerch GitLab CI lafen, mat Docker-aktivéierten Tools: Selenium Gitter a Selenoid. Ausserdeem benotze mir virtuelle Maschinnen erstallt iwwer GCP fir Container mat Browser an Emulatoren ze hosten. Fir Käschten ze reduzéieren, starten mir dës virtuell Maschinnen nëmmen op Ufro a stoppen se wann Tester net duerchgefouert ginn. Gëtt et nach eppes wat eis Infrastruktur verbessert? D'Äntwert ass jo! Trefft Kubernetes (K8s)!
Als éischt kucke mer wéi d'Wierder Orchestratioun, Cluster a Kubernetes matenee verbonne sinn. Op engem héijen Niveau ass d'Orchestratioun de System deen Uwendungen ofsetzt a geréiert. Fir Testautomatiséierung sinn esou containeriséiert Uwendungen Selenium Gitter a Selenoid. Docker a K8s ergänzen sech. Déi éischt gëtt fir Uwendungsdeployment benotzt, déi zweet fir Orchestratioun. Am Tour ass K8s e Stärekoup. D'Aufgab vum Cluster ass VMs als Noden ze benotzen, wat Iech erlaabt verschidde Funktionalitéit, Programmer a Servicer bannent engem Server (Cluster) z'installéieren. Wann iergendeen vun den Noden feelt, ginn aner Noden opgeholl, wat eng onënnerbrach Operatioun vun eiser Applikatioun garantéiert. Zousätzlech zu dësem huet K8s wichteg Funktionalitéit am Zesummenhang mat der Skaléierung, duerch déi mir automatesch déi optimal Quantitéit u Ressourcen op Basis vun der Belaaschtung kréien a Limiten setzen.
An der Wourecht, manuell Kubernetes aus Schrummen z'installéieren ass guer net eng trivial Aufgab. Ech verloossen e Link op de berühmte How-to Guide "Kubernetes The Hard Way" a wann Dir interesséiert sidd, kënnt Dir et üben. Awer glécklecherweis ginn et alternativ Methoden an Tools. Deen einfachste Wee ass Google Kubernetes Engine (GKE) am GCP ze benotzen, wat Iech erlaabt e fäerdege Cluster an e puer Mausklicken ze kréien. Ech recommandéieren dës Approche ze benotzen fir ze léieren, well et Iech erlaabt Iech ze fokusséieren wéi Dir d'K8s fir Är Aufgaben benotzt anstatt ze léieren wéi déi intern Komponente matenee integréiert solle ginn.
Wäert fir Automatisatiounsinfrastruktur
Loosst eis e puer bedeitend Feature kucken, déi de K8s ubitt:
- Applikatioun Détachement: mat engem Multi-Node Cluster amplaz VMs;
- dynamesch Skala: reduzéiert d'Käschte vun de Ressourcen, déi nëmmen op Nofro benotzt ginn;
- Self-Heelung: automatesch Erhuelung vun pods (als Resultat vun deem Container och restauréiert ginn);
- Ausrollung vun Aktualiséierungen an Rollbacks vun Ännerungen ouni Ausdauer: Aktualiséierungsinstrumenter, Browser an Emulatoren ënnerbrach d'Aarbecht vun den aktuellen Benotzer net
Awer d'K8s ass nach ëmmer keng Sëlwerkugel. Fir all d'Virdeeler an Aschränkungen am Kontext vun den Tools ze verstoen, déi mir berücksichtegen (Selenium Gitter, Selenoid), wäerte mir kuerz iwwer d'Struktur vu K8s diskutéieren. Cluster enthält zwou Aarte vu Noden: Master Nodes an Workers Nodes. Master Node si verantwortlech fir d'Gestioun, d'Deployment an d'Fuerplang Entscheedungen. Aarbechter Noden sinn wou Uwendungen lancéiert ginn. Noden enthalen och e Container Runtime Ëmfeld. An eisem Fall ass dëst Docker, dee verantwortlech ass fir Containerbezunnen Operatiounen. Mä et ginn zum Beispill och alternativ Léisungen. Et ass wichteg ze verstoen datt d'Skaléierung oder d'Selbstheilung net direkt op Container gëlt. Dëst gëtt ëmgesat andeems d'Zuel vun de Pods bäigefüügt / reduzéiert gëtt, déi am Tour Container enthalen (normalerweis ee Container pro Pod, awer ofhängeg vun der Aufgab kann et méi sinn). Déi héich-Niveau Hierarchie besteet aus Aarbechter Wirbelen, bannenzeg vun deenen et Pods sinn, bannenzeg vun deenen Container opgewuess sinn.
D'Skaléierungsfunktioun ass Schlëssel a kann op béid Node bannent engem Cluster Node-Pool a Pods bannent engem Node applizéiert ginn. Et ginn 2 Aarte vu Skalen déi op béid Noden a Pods gëllen. Déi éischt Zort ass horizontal - Skaléieren geschitt duerch d'Erhéijung vun der Unzuel vun Noden / Pods. Dës Zort ass méi bevorzugt. Déi zweet Zort ass deementspriechend vertikal. Skaléieren gëtt duerch d'Erhéijung vun der Gréisst vun de Wirbelen / Pods duerchgefouert, an net hir Zuel.
Loosst eis elo eis Tools am Kontext vun den uewe genannte Begrëffer kucken.
Selenium Gitter
Wéi virdru scho gesot, Selenium Gitter ass e ganz populär Tool, an et ass keng Iwwerraschung datt et containeriséiert gouf. Dofir ass et keng Iwwerraschung datt Selenium Gitter a K8s agesat ka ginn. E Beispill vu wéi een dat mécht kann am offiziellen K8s Repository fonnt ginn. Wéi gewinnt, befestegt ech Linken um Enn vun der Rubrik. Zousätzlech weist de How-to Guide wéi Dir dëst an Terraform maacht. Et ginn och Instruktioune fir d'Zuel vun de Pods ze skaléieren déi Browser Container enthalen. Awer déi automatesch Skaléierungsfunktioun am Kontext vu K8s ass nach ëmmer net eng komplett offensichtlech Aufgab. Wéi ech ugefaang ze studéieren, hunn ech keng praktesch Orientatioun oder Empfehlungen fonnt. No e puer Studien an Experimenter mat der Ënnerstëtzung vum DevOps Team hu mir d'Approche gewielt fir Container mat den néidege Browser an engem Pod z'erhéijen, deen an engem Aarbechtsknuet läit. Dës Method erlaabt eis d'Strategie vun der horizontaler Skaléierung vun Noden z'applizéieren andeems se hir Zuel erhéijen. Ech hoffen, datt dëst an der Zukunft ännert a mir wäerte méi a méi Beschreiwunge vu bessere Approche a fäerdeg Léisungen gesinn, besonnesch no der Verëffentlechung vum Selenium Gitter 4 mat enger geännerter interner Architektur.
Selenoid:
Selenoid Deployment an K8s ass de Moment déi gréissten Enttäuschung. Si sinn net kompatibel. An der Theorie kënne mir e Selenoid Container an engem Pod erhéijen, awer wann Selenoid ufänkt Container mat Browser ze lancéieren, wäerte se nach ëmmer am selwechte Pod sinn. Dëst mécht d'Skaléierung onméiglech an als Resultat wäert d'Aarbecht vum Selenoid an engem Cluster net vun der Aarbecht an enger virtueller Maschinn ënnerscheeden. Enn vun der Geschicht.
Äerdmound:
Wësse vun dësem Flaschenhals beim Schaffen mat Selenoid, hunn d'Entwéckler e méi mächtegt Tool mam Numm Moon verëffentlecht. Dëst Tool gouf ursprénglech entwéckelt fir mat Kubernetes ze schaffen an als Resultat kann d'Autoscaling Feature benotzt ginn a soll benotzt ginn. Ausserdeem géif ech soen, datt et de Moment ass déi eenzeg e Tool an der Selenium Welt, déi gebierteg K8s Cluster Support aus der Këscht huet (net méi sinn, gesinn nächst Outil ). D'Schlëssel Feature vum Mound déi dës Ënnerstëtzung ubidden sinn:
Ganz statelos. Selenoid späichert an Erënnerung Informatiounen iwwer aktuell Lafen Browser Sessiounen. Wann aus irgendege Grënn säi Prozess crasht - da sinn all Lafen Sessiounen verluer. De Mound huet dogéint keen internen Zoustand a kann iwwer Datenzenter replizéiert ginn. Browser Sessiounen bleiwen lieweg och wann een oder méi Repliken erofgoen.
Also, Mound ass eng super Léisung, awer et gëtt ee Problem: et ass net gratis. De Präis hänkt vun der Unzuel vun de Sessiounen of. Dir kënnt nëmmen 0-4 Sessiounen gratis lafen, wat net besonnesch nëtzlech ass. Awer, ab der fënnefter Sessioun, musst Dir $ 5 fir all bezuelen. D'Situatioun ka vun der Firma zu der Firma ënnerscheeden, awer an eisem Fall ass d'Benotzung vum Mound sënnlos. Wéi ech uewen beschriwwen hunn, kënne mir VMs mat Selenium Grid op Ufro lafen oder d'Zuel vun den Noden am Cluster erhéijen. Fir ongeféier eng Pipeline lancéiere mir 500 Browser a stoppen all Ressourcen nodeems d'Tester ofgeschloss sinn. Wa mir de Mound benotzt hunn, musse mir zousätzlech 500 x 5 = $ 2500 pro Mount bezuelen, egal wéi dacks mir Tester maachen. Erëm, ech soen net, datt de Mound net benotzt. Fir Är Aufgaben kann dëst eng onverzichtbar Léisung sinn, zum Beispill wann Dir vill Projeten/Equipen an Ärer Organisatioun hutt an Dir braucht e grousse gemeinsame Cluster fir jiddereen. Wéi ëmmer loossen ech e Link um Enn a recommandéieren all déi néideg Berechnungen am Kontext vun Ärer Aufgab ze maachen.
Callisto: (Opgepasst! Dëst ass net am Originalartikel an ass nëmmen an der russescher Iwwersetzung enthale)
Wéi gesot, Selenium ass e ganz populär Tool, an den IT Feld entwéckelt sech ganz séier. Wärend ech un der Iwwersetzung geschafft hunn, erschéngt en neit verspriechend Tool mam Numm Callisto um Internet (Moien Cypress an aner Selenium Killer). Et funktionnéiert natiirlech mat K8s an erlaabt Iech Selenoid Container a Pods ze lafen, verdeelt iwwer Noden. Alles funktionnéiert direkt aus der Këscht, inklusiv Autoskaléierung. Fantastesch, awer muss getest ginn. Ech hunn et scho fäerdeg bruecht dëst Tool z'installéieren an e puer Experimenter auszeféieren. Awer et ass ze fréi fir Conclusiounen ze zéien, nodeems ech Resultater iwwer eng laang Distanz kritt hunn, vläicht wäert ech eng Iwwerpréiwung an zukünfteg Artikelen maachen. Fir de Moment loossen ech nëmme Linke fir onofhängeg Fuerschung.
Illustratioun vum aktuellen Zoustand vun der Infrastruktur
Links fir ze entdecken
Ähnlech Tools
7. Infrastruktur als Code (IaC)
Kuerz Beschreiwung vun der Technologie
An elo komme mir zu der leschter Rubrik. Typesch sinn dës Technologie a verbonne Aufgaben net d'Verantwortung vun Automatisatiounsingenieuren. An et gi Grënn dofir. Als éischt, a villen Organisatiounen sinn d'Infrastrukturproblemer ënner der Kontroll vum DevOps Departement an d'Entwécklungséquipen këmmeren sech net wierklech ëm wat d'Pipeline funktionnéiert a wéi alles mat deem verbonne muss ënnerstëtzt ginn. Zweetens, loosst eis éierlech sinn, ass d'Praxis vun Infrastructure as Code (IaC) nach ëmmer net a ville Firmen ugeholl. Awer et ass definitiv e populäre Trend ginn an et ass wichteg ze probéieren an de Prozesser, Approchen an Tools verbonne matzemaachen. Oder op d'mannst bleiwen um Datum.
Loosst eis mat der Motivatioun ufänken fir dës Approche ze benotzen. Mir hu scho diskutéiert datt fir Tester am GitlabCI ze lafen, mir brauche op d'mannst d'Ressourcen fir Gitlab Runner ze lafen. A fir Container mat Browser / Emulatoren ze lafen, musse mir e VM oder Cluster reservéieren. Zousätzlech fir d'Ressourcen ze testen, brauche mir e wesentleche Betrag u Kapazitéit fir d'Entwécklung, d'Staging, d'Produktiounsëmfeld z'ënnerstëtzen, déi och Datenbanken, automatesch Zäitplang, Netzwierkkonfiguratiounen, Lastbalancer, Benotzerrechter, asw. De Schlësselproblem ass den Effort, deen néideg ass fir alles z'ënnerstëtzen. Et gi verschidde Weeër fir Ännerungen ze maachen an Updates auszerollen. Zum Beispill, am Kontext vu GCP, kënne mir d'UI Konsole am Browser benotzen an all Aktiounen ausféieren andeems Dir Knäppercher klickt. Eng Alternativ wier d'API-Uriff ze benotzen fir mat Cloud-Entitéiten ze interagéieren, oder d'gcloud Kommandozeil-Utility ze benotzen fir déi gewënschte Manipulatiounen auszeféieren. Awer mat enger wierklech grousser Zuel vu verschiddenen Entitéiten an Infrastrukturelementer gëtt et schwéier oder souguer onméiglech all Operatiounen manuell ze maachen. Ausserdeem sinn all dës manuell Handlungen onkontrolléierbar. Mir kënnen se net fir Iwwerpréiwung virun der Ausféierung ofginn, e Versiounskontrollsystem benotzen, a séier d'Ännerungen zréckrollen, déi zum Virfall gefouert hunn. Fir esou Probleemer ze léisen, hunn d'Ingenieuren automatesch Bash/Shell Scripten erstallt an erstallt, déi net vill besser sinn wéi virdrun Methoden, well se net sou einfach sinn an engem prozedurale Stil ze liesen, ze verstoen, z'erhalen an z'änneren.
An dësem Artikel a wéi-ze Guide, Ech benotzen 2 Tools Zesummenhang mat IaC Praxis. Dëst sinn Terraform an Ansible. E puer Leit gleewen datt et kee Sënn mécht se zur selwechter Zäit ze benotzen, well hir Funktionalitéit ähnlech ass a se austauschbar sinn. Awer de Fakt ass datt se am Ufank komplett aner Aufgaben ginn. An d'Tatsaach, datt dës Tools géigesäiteg ergänzen, gouf op enger gemeinsamer Presentatioun vun Entwéckler bestätegt, déi HashiCorp a RedHat representéieren. De konzeptuellen Ënnerscheed ass datt Terraform e Bestëmmungsinstrument ass fir d'Servere selwer ze managen. Wärend Ansible ass e Konfiguratiounsmanagement Tool deem seng Aufgab ass Software op dëse Serveren z'installéieren, ze konfiguréieren an ze verwalten.
Eng aner Schlëssel Ënnerscheedung Feature vun dësen Tools ass de Kodéierungsstil. Am Géigesaz zu Bash an Ansible benotzt Terraform en deklarativen Stil baséiert op enger Beschreiwung vum gewënschten Ennzoustand, deen als Resultat vun der Ausféierung erreecht gëtt. Zum Beispill, wa mir 10 VMs erstellen an d'Ännerungen duerch Terraform applizéieren, da kréie mir 10 VMs. Wa mir de Skript nach eng Kéier lafen, geschitt näischt well mir schonn 10 VMs hunn, an Terraform weess iwwer dëst well et den aktuellen Zoustand vun der Infrastruktur an engem Staatsdatei späichert. Awer Ansible benotzt eng prozedural Approche a wann Dir et freet 10 VMs ze kreéieren, da kréie mir um éischte Start 10 VMs, ähnlech wéi Terraform. Awer nom Restart hu mir scho 20 VMs. Dëst ass de wichtegen Ënnerscheed. Am Prozedurstil späichere mir den aktuellen Zoustand net a beschreiwen einfach eng Sequenz vu Schrëtt, déi musse gemaach ginn. Natierlech kënne mir verschidde Situatiounen handhaben, verschidde Kontrollen op d'Existenz vu Ressourcen an den aktuellen Zoustand addéieren, awer et huet kee Sënn eis Zäit ze verschwenden an Effort ze maachen fir dës Logik ze kontrolléieren. Zousätzlech erhéicht dëst de Risiko vu Feeler.
Zesummegefaasst all déi uewe genannte kënne mir schléissen datt Terraform an deklarativ Notatioun e méi gëeegent Tool sinn fir Serveren zur Verfügung ze stellen. Awer et ass besser d'Aarbecht vum Konfiguratiounsmanagement op Ansible ze delegéieren. Mat deem aus dem Wee, loosst eis Benotzungsfäll am Kontext vun der Automatioun kucken.
Wäert fir Automatisatiounsinfrastruktur
Déi eenzeg wichteg Saach hei ze verstoen ass datt d'Testautomatiséierungsinfrastruktur soll als Deel vun der ganzer Firmainfrastruktur ugesi ginn. Dëst bedeit datt all IaC Praktiken global op d'Ressourcen vun der ganzer Organisatioun applizéiert ginn. Wien dofir verantwortlech ass hänkt vun Äre Prozesser of. D'DevOps Team ass méi erlieft an dësen Themen, si gesinn dat ganzt Bild vun deem wat geschitt. Wéi och ëmmer, QA Ingenieuren si méi am Prozess vun der Bauautomatiséierung an der Struktur vun der Pipeline involvéiert, wat et hinnen erlaabt all déi erfuerderlech Ännerungen a Verbesserungsméiglechkeeten besser ze gesinn. Déi bescht Optioun ass zesummen ze schaffen, Wëssen an Iddien auszetauschen fir dat erwaart Resultat z'erreechen.
Hei sinn e puer Beispiller fir Terraform an Ansible ze benotzen am Kontext vun der Testautomatiséierung an d'Tools déi mir virdru diskutéiert hunn:
1. Beschreift déi néideg Charakteristiken a Parameteren vu VMs a Cluster mat Terraform.
2. Benotzt Ansible, installéiert déi néideg Tools fir Testen: Docker, Selenoid, Selenium Grid an lued déi erfuerderlech Versioune vu Browser / Emulatoren erof.
3. Benotzt Terraform, beschreiwen d'Charakteristiken vun der VM an deem GitLab Runner lancéiert ginn.
4. Installéiert GitLab Runner an déi néideg Begleedungsinstrumenter mat Ansible, setzen Astellungen a Konfiguratiounen.
Illustratioun vum aktuellen Zoustand vun der Infrastruktur
Links fir ze entdecken:
Ähnlech Tools
Loosst eis et zesummefaassen!
Schrëtt
Technology
Tools
Wäert fir Automatisatiounsinfrastruktur
1
Lokal Lafen
Node.js, Selenium, Appium
- Déi populärste Tools fir Web an Handy
- Ënnerstëtzt vill Sproochen a Plattformen (inklusiv Node.js)
2
Versioun Kontroll Systemer
goen
- Ähnlech Virdeeler mat Entwécklungscode
3
Containeriséierung
Docker, Selenium Gitter, Selenoid (Web, Android)
- Lafen Tester parallel
- Isoléiert Ëmfeld
- Einfach, flexibel Versioun Upgrades
- Dynamesch stoppen onbenotzt Ressourcen
- Einfach opzestellen
4
CI/CD
Gitlab CI
- Testen Deel vun der Pipeline
- Schnell Feedback
- Visibilitéit fir déi ganz Firma / Team
5
Cloud Plattformen
Google Cloud Plattform
- Ressourcen op Ufro (mir bezuelen nëmmen wann néideg)
- Einfach ze managen an ze aktualiséieren
- Visibilitéit a Kontroll vun all Ressourcen
6
Orchestratioun
Kubernetes
Am Kontext vu Container mat Browser / Emulatoren an Pods:
- Skaléieren / Auto Skaléieren
- Selbstheilung
- Updates an Rollbacks ouni Ënnerbriechung
7
Infrastruktur als Code (IaC)
Terraform, Ansible
- Ähnlech Virdeeler mat Entwécklungsinfrastruktur
- All d'Virdeeler vun der Code Versioun
- Einfach Ännerungen ze maachen an z'erhalen
- Ganz automatiséiert
Mind Map Diagrammer: Evolutioun vun der Infrastruktur
Schrëtt 1: Lokal
Schrëtt 2: VCS
step3: Containerization
Schrëtt 4: CI / CD
step5: Cloud Plattformen
Schrëtt 6: Orchestratioun
Schrëtt 7: IaC
Wat d'nächst?
Also, dëst ass den Enn vum Artikel. Mä als Ofschloss wëll ech e puer Accorde mat Iech opstellen.
Vun Ärer Säit
Wéi am Ufank gesot, ech hätt gär datt den Artikel praktesch ass an Iech hëlleft d'Wëssen an der realer Aarbecht ëmzesetzen. Ech addéieren nach eng Kéier.
Awer och duerno net ophalen, üben, relevant Linken a Bicher studéieren, erausfannen wéi et an Ärer Firma funktionnéiert, Plazen fannen déi kënne verbessert ginn an dorun deelhuelen. Vill Gléck!
Vun menger Säit
Aus dem Titel gesäit een, datt dëst nëmmen den éischten Deel war. Trotz der Tatsaach, datt et zimmlech grouss ass, sinn hei wichteg Themen nach ëmmer net ofgedeckt. Am zweeten Deel plangen ech d'Automatisatiounsinfrastruktur am Kontext vun IOS ze kucken. Wéinst dem Apple seng Restriktiounen fir iOS Simulatoren nëmmen op macOS Systemer ze bedreiwen, ass eis Palette vu Léisunge verklengert. Zum Beispill kënne mir Docker net benotze fir de Simulator oder ëffentleche Wolleken ze lafen fir virtuell Maschinnen ze lafen. Mä dat heescht net datt et keng aner Alternativen gëtt. Ech probéieren Iech mat fortgeschrattene Léisungen a modernen Tools um neiste Stand ze halen!
Och, ech hunn net ganz grouss Themen ugeschwat iwwer Iwwerwaachung ernimmt. Am Deel 3 wäert ech déi populärste Infrastruktur Iwwerwaachungsinstrumenter kucken a wéi eng Daten a Metriken ze berücksichtegen.
An endlech. An der Zukunft plangen ech e Videocours fir Testinfrastrukturen a populär Tools ze bauen. De Moment ginn et zimmlech e puer Coursen a Virträg iwwer DevOps um Internet, awer all Material gëtt am Kontext vun der Entwécklung presentéiert, net Testautomatiséierung. Zu dësem Thema brauch ech wierklech Feedback ob esou e Cours interessant a wäertvoll ass fir d'Gemeinschaft vun Tester an Automatisatiounsingenieuren. Merci am Viraus!
Source: will.com