Teil 1: Web / Android
Hinweis: Dieser Artikel ist eine Übersetzung des originalen Artikels ins Deutsche. Alle Illustrationen, Links, Zitate und Begriffe bleiben jedoch in der Originalsprache, um Verzerrungen des Sinns bei der Übersetzung ins Deutsche zu vermeiden. Ich wünsche Ihnen viel Freude beim Lernen!
Derzeit ist die Spezialisierung DevOps eine der gefragtesten in der IT-Branche. Wenn Sie beliebte Jobportale besuchen und nach Gehältern filtern, werden Sie feststellen, dass die Stellenanzeigen im Zusammenhang mit DevOps ganz oben auf der Liste stehen. Allerdings ist es wichtig zu verstehen, dass dies hauptsächlich für die Position des ‚Senior‘ gilt, was bedeutet, dass der Kandidat über ein hohes Maß an Fähigkeiten und Kenntnisse in Technologien und Werkzeugen verfügt. Dies bringt auch eine hohe Verantwortung für den reibungslosen Betrieb der Produktion mit sich. Doch wir scheinen zu vergessen, was DevOps eigentlich ist. Ursprünglich war es keine spezifische Person oder Abteilung. Wenn wir nach Definitionen dieses Begriffs suchen, finden wir viele schöne und korrekte Substantive wie Methodologie, Praktiken, kulturelle Philosophie, eine Gruppe von Konzepten und so weiter.
Meine Spezialisierung ist Ingenieur für Testautomatisierung (QA Automation Engineer), doch ich bin der Meinung, dass diese nicht nur mit dem Schreiben von automatisierten Tests oder der Entwicklung der Architektur von Testframeworks verbunden sein sollte. Im Jahr 2020 sind auch Kenntnisse in der Infrastrukturautomatisierung notwendig. Dies ermöglicht es, den Automatisierungsprozess selbständig zu organisieren, von der Durchführung von Tests bis hin zur Bereitstellung der Ergebnisse für alle Beteiligten gemäß den festgelegten Zielen. Daher sind DevOps-Fähigkeiten ein notwendiger Faktor für diese Arbeit. Und das ist alles gut, aber leider gibt es ein Problem (Spoiler: Dieser Artikel versucht, dieses Problem zu vereinfachen). Es besteht darin, dass DevOps kompliziert ist. Und das ist offensichtlich, denn Unternehmen werden nicht viel für das bezahlen, was leicht zu machen ist... In der Welt von DevOps gibt es eine Vielzahl von Tools, Begriffen und Praktiken, die gemeistert werden müssen. Besonders am Anfang der Karriere kann das eine Herausforderung sein und hängt vom angesammelten technischen Wissen ab.
Quelle:
Hier beenden wir möglicherweise den einleitenden Teil und konzentrieren uns auf das Ziel dieses Artikels.
Worüber handelt dieser Artikel
In diesem Artikel möchte ich meine Erfahrungen im Aufbau einer Testautomatisierungsinfrastruktur teilen. Im Internet gibt es viele Informationsquellen über verschiedene Werkzeuge und deren Nutzung, aber ich möchte sie ausschließlich im Kontext der Automatisierung betrachten. Ich glaube, vielen Automatisierungsingenieuren ist die Situation bekannt, in der die entwickelten Tests außer Ihnen niemand ausführt oder sich um deren Wartung kümmert. Dies führt dazu, dass die Tests veraltet sind und Zeit für deren Aktualisierung aufgewendet werden muss. Gerade zu Beginn der Karriere kann dies eine ziemlich herausfordernde Aufgabe sein: die richtigen Werkzeuge auszuwählen, die dabei helfen können, dieses Problem zu lösen, sowie sie zu wählen, einzurichten und zu warten. Einige Tester wenden sich an DevOps (die Leute), und seien wir ehrlich, dieser Ansatz funktioniert. In vielen Fällen kann dies die einzige Option sein, da wir keine Sicht auf alle Abhängigkeiten haben. Doch, wie wir wissen, sind DevOps sehr beschäftigte Leute, da sie über die Infrastruktur des gesamten Unternehmens, Deployment, Monitoring, Mikrodienste und andere ähnliche Aufgaben nachdenken müssen, abhängig von der Organisation/dem Team. Wie so oft hat die Automatisierung dabei keine Priorität. In einem solchen Fall müssen wir versuchen, alles in unserer Macht Stehende von Anfang bis Ende zu tun. Dies wird die Abhängigkeiten reduzieren, den Arbeitsablauf beschleunigen, unsere Fähigkeiten verbessern und uns ermöglichen, einen umfassenderen Überblick über das Geschehen zu bekommen.
In diesem Artikel werden die gefragtesten und beliebtesten Tools vorgestellt und erläutert, wie man sie für den schrittweisen Aufbau einer Automatisierungsinfrastruktur nutzen kann. Jede Gruppe wird durch Werkzeuge repräsentiert, die aus persönlicher Erfahrung getestet wurden. Das bedeutet jedoch nicht, dass Sie dieselben verwenden müssen. Die Tools selbst sind nicht entscheidend; sie kommen und gehen. Unsere ingenieurtechnische Aufgabe besteht darin, die grundlegenden Prinzipien zu verstehen: Warum brauchen wir diese Gruppe von Tools und welche Arbeitsaufgaben können wir damit lösen? Daher lasse ich am Ende jeder Sektion Links zu ähnlichen Tools, die möglicherweise in Ihrer Organisation verwendet werden.
Was in diesem Artikel nicht enthalten ist
Ich wiederhole, dass es in diesem Artikel nicht um spezifische Tools geht, weshalb es hier keine Code-Snippets aus der Dokumentation und keine Beschreibungen spezifischer Befehle geben wird. Aber am Ende jeder Sektion lasse ich Links für eine detaillierte Betrachtung.
Dies geschieht aus folgendem Grund:
- Dieses Material ist in verschiedenen Quellen (Dokumentationen, Bücher, Videokurse) sehr leicht zu finden;
- Wenn wir tiefer eintauchen, müssten wir 10, 20 oder 30 Teile dieses Artikels schreiben (während nur 2-3 geplant sind);
- Ich möchte einfach nicht Ihre Zeit verschwenden, da Sie möglicherweise andere Werkzeuge zur Erreichung derselben Ziele nutzen möchten.
Praxis
Ich wünsche mir sehr, dass dieses Material für jeden Leser nützlich ist und nicht einfach gelesen und vergessen wird. Praxis ist ein sehr wichtiger Bestandteil jedes Lernprozesses. Deshalb habe ichSie erwartet auch Hausaufgaben, um sicherzustellen, dass Sie die ausgeführten Befehle nicht gedankenlos kopiert haben.
Gliederung
Schritt
Technologie
Tools
1
Lokaler Betrieb (Vorbereitung von Web-/Android-Demo-Tests und lokalem Betrieb)
Node.js, Selenium, Appium
2
Versionskontrollsysteme
Git
3
Containerisierung
Docker, Selenium Grid, Selenoid (Web, Android)
4
CI / CD
(geschrieben in
5
Cloud-Plattformen
Google Cloud Platform
6
Orchestrierung
Kubernetes
7
Infrastructure as Code (IaC)
Terraform, Ansible
Struktur jeder Sektion
Um die Erzählung übersichtlich zu gestalten, wird jede Sektion nach folgendem Plan beschrieben:
- kurze Beschreibung der Technologie,
- Wert für die Infrastrukturautomatisierung,
- Illustration des aktuellen Stands der Infrastruktur,
- Links zum Studieren,
- ähnliche Werkzeuge.
1. Lokaler Testlauf
Kurze Beschreibung der Technologie
Dies ist nur ein vorbereitender Schritt, um lokale Demotests zu starten und zu überprüfen, ob sie erfolgreich durchgeführt werden. In der praktischen Anwendung wird Node.js verwendet, aber die Programmiersprache und Plattform sind ebenfalls nicht wichtig; Sie können die verwenden, die in Ihrem Unternehmen genutzt werden.
Als Automatisierungswerkzeuge empfehle ich jedoch, Selenium WebDriver für Webplattformen und Appium für Android-Plattformen zu verwenden. In den nächsten Schritten werden wir Docker-Images nutzen, die speziell für die Arbeit mit diesen Werkzeugen optimiert sind. Darüber hinaus sind diese Werkzeuge laut den Anforderungen in den Stellenanzeigen auf dem Markt am gefragtesten.
Wie Sie möglicherweise bemerkt haben, betrachten wir nur Web- und Android-Tests. Leider ist iOS eine ganz andere Geschichte (danke Apple). Ich plane, Lösungen und Praktiken im Zusammenhang mit iOS in den nächsten Teilen zu demonstrieren.
Wert für die Automatisierungsinfrastruktur
Aus infrastruktureller Sicht bietet ein lokaler Launch keinen Mehrwert. Sie überprüfen lediglich, ob die Tests auf der lokalen Maschine in lokalen Browsern und Emulatoren funktionieren. Trotzdem ist dies ein notwendiger Ausgangspunkt.
Illustration des aktuellen Infrastrukturstatus
Ressourcen zum Lernen
Ähnliche Werkzeuge
- jede Programmiersprache, die Ihnen gefällt, in Verbindung mit Selenium/Appium - Tests;
- beliebige Tests;
- irgendein Test-Runner.
2. Versionskontrollsysteme (Git)
Kurze Beschreibung der Technologie
Es wird niemanden überraschen, wenn ich sage, dass ein Versionskontrollsystem ein äußerst wichtiger Bestandteil der Entwicklung ist, sowohl im Team als auch individuell. Verschiedene Quellen bestätigen, dass Git der verbreitetste Vertreter ist. Ein Versionskontrollsystem bietet zahlreiche Vorteile, darunter den Austausch von Code, die Speicherung von Versionen, die Wiederherstellung früherer Branches, die Überwachung der Projektgeschichte und Backups. Wir werden nicht auf jeden einzelnen Punkt im Detail eingehen, da ich sicher bin, dass Sie damit bereits gut vertraut sind und es in Ihrer täglichen Arbeit nutzen. Sollte das jedoch nicht der Fall sein, empfehle ich Ihnen, das Lesen dieses Artikels zu unterbrechen und dieses Wissen so schnell wie möglich nachzuholen.
Wert für die Automatisierungsinfrastruktur
Hier können Sie sich berechtigterweise fragen: „Warum erzählt er uns von Git? Das wissen doch alle und nutzen es sowohl für die Entwicklungscode als auch für den automatischen Testcode.“ Sie haben vollkommen recht, aber in diesem Artikel sprechen wir über Infrastruktur, und dieser Abschnitt dient als Vorschau für Abschnitt 7: „Infrastructure as Code (IaC)“. Für uns bedeutet das, dass die gesamte Infrastruktur, einschließlich der Testinfrastruktur, in Form von Code beschrieben wird. Daher können wir auch Versionsverwaltungssysteme darauf anwenden und ähnliche Vorteile erzielen, wie sie für Entwicklungs- und Automatisierungscode gelten.
Wir werden IaC detaillierter in Schritt 7 betrachten, aber selbst jetzt können Sie lokal mit Git beginnen, indem Sie ein lokales Repository erstellen. Das Gesamtbild wird erweitert, wenn wir ein Remote-Repository zur Infrastruktur hinzufügen.
Illustration des aktuellen Infrastrukturstatus
Ressourcen zum Lernen
Ähnliche Werkzeuge
3. Containerisierung (Docker)
Kurze Beschreibung der Technologie
Um zu demonstrieren, wie die Containerisierung die Spielregeln verändert hat, begeben wir uns einige Jahrzehnte zurück in die Vergangenheit. Damals kauften und verwendeten die Menschen Servermaschinen, um Anwendungen auszuführen. In den meisten Fällen waren jedoch die benötigten Ressourcen für den Betrieb im Voraus nicht bekannt. Dies führte dazu, dass Unternehmen Geld für den Kauf teurer, leistungsstarker Server ausgaben, von denen ein Teil nicht vollständig genutzt wurde.
Der nächste Evolutionsschritt waren virtuelle Maschinen (VM), die das Problem der Verschwendung ungenutzter Ressourcen lösten. Diese Technologie ermöglichte es, Anwendungen unabhängig voneinander auf einem Server auszuführen und dabei vollständig isolierte Bereiche bereitzustellen. Leider hat jede Technologie auch ihre Nachteile. Der Betrieb von VMs benötigt ein vollständiges Betriebssystem, das CPU, RAM und Speicherplatz verbraucht. Abhängig vom OS müssen auch Lizenzkosten berücksichtigt werden. Diese Faktoren beeinflussen die Ladegeschwindigkeit und erschweren die Portabilität.
Und hier kommen wir zur Containerisierung. Auch diese Technologie hat das vorherige Problem gelöst, da Container kein vollständiges Betriebssystem verwenden, was eine große Menge an Ressourcen freisetzt und eine schnelle und flexible Lösung für die Portabilität bietet.
Natürlich ist die Containerisierungstechnologie nichts Neues und wurde erstmals Ende der 70er Jahre vorgestellt. In dieser Zeit wurde viel geforscht, entwickelt und ausprobiert. Doch Docker hat diese Technologie angepasst und sie für die Massen leicht zugänglich gemacht. Heutzutage, wenn wir von Containern sprechen, meinen wir in den meisten Fällen Docker. Wenn wir von Docker-Containern sprechen, beziehen wir uns auf Linux-Container. Wir können Windows- und macOS-Systeme verwenden, um Container zu betreiben, aber es ist wichtig zu verstehen, dass in diesem Fall eine zusätzliche Schicht entsteht. Zum Beispiel startet Docker auf dem Mac Container innerhalb einer leichten Linux-VM. Wir werden dieses Thema noch einmal aufgreifen, wenn wir über das Ausführen von Android-Emulatoren innerhalb von Containern sprechen, da hierbei ein sehr wichtiger Aspekt auftritt, der genauer betrachtet werden muss.
Wert für die Automatisierungsinfrastruktur
Wir haben herausgefunden, dass Containerisierung und Docker großartig sind. Lassen Sie uns das im Kontext der Automatisierung betrachten, denn jedes Tool oder jede Technologie sollte ein bestimmtes Problem lösen. Lassen Sie uns die offensichtlichen Automatisierungsprobleme im Kontext der UI-Tests betrachten:
- eine Vielzahl von Abhängigkeiten beim Installieren von Selenium und insbesondere Appium;
- Kompatibilitätsprobleme zwischen Versionen von Browsern, Simulatoren und Treibern;
- fehlender isolierter Raum für Browser/Simulatoren, was besonders kritisch für den parallelen Betrieb ist;
- schwierig zu verwalten und zu warten, wenn es notwendig ist, 10, 50, 100 oder sogar 1000 Browser gleichzeitig zu starten.
Aber da Selenium das beliebteste Automatisierungstool ist und Docker das beliebteste Containerisierungstool ist, sollte es niemanden überraschen, dass jemand versucht hat, sie zu kombinieren, um ein leistungsstarkes Tool zur Lösung der oben genannten Probleme zu schaffen. Lassen Sie uns solche Lösungen näher betrachten.
Selenium Grid in Docker
Dieses Tool gilt als das weltweit beliebteste Selenium-Tool für die Ausführung mehrerer Browser auf verschiedenen Maschinen und deren Verwaltung von einem zentralen Knoten aus. Um es zu starten, müssen wir mindestens zwei Teile registrieren: Hub und Node(s). Der Hub ist der zentrale Knoten, der alle Anfragen von den Tests entgegennimmt und an die entsprechenden Nodes verteilt. Für jede Node können wir eine spezifische Konfiguration festlegen, zum Beispiel den gewünschten Browser und dessen Version angeben. Dennoch müssen wir für die Browser kompatible Treiber bereitstellen und diese auf den entsprechenden Nodes installieren. Aus diesem Grund wird das Selenium-Grid in seiner reinen Form nur verwendet, wenn wir mit Browsern arbeiten müssen, die nicht auf Linux-OS installiert werden können. Für alle anderen Fälle ist die Verwendung von Docker-Images für die Ausführung von Selenium-Grid-Hub und Nodes eine deutlich flexiblere und passendere Lösung. Dieser Ansatz vereinfacht das Management der Knoten erheblich, da wir das gewünschte Image mit bereits installierten kompatiblen Versionen von Browsern und Treibern auswählen können.
Trotz negativer Bewertungen zur Stabilität, insbesondere beim gleichzeitigen Start einer großen Anzahl von Nodes, bleibt Selenium Grid dennoch das beliebteste Tool für die parallele Ausführung von Selenium-Tests. Es ist wichtig zu beachten, dass im Open-Source-Bereich ständig verschiedene Erweiterungen und Modifikationen dieses Tools entwickelt werden, die gegen diverse Engpässe ankämpfen.
Selenoid für Web
Dieses Tool ist eine Revolution in der Welt von Selenium, da es direkt einsatzbereit ist und das Leben vieler Automatisierungsingenieure erheblich erleichtert hat. Vor allem handelt es sich hierbei nicht um eine weitere Modifikation von Selenium Grid. Vielmehr haben die Entwickler eine völlig neue Version des Selenium Hub in Golang erstellt, was in Kombination mit leichtgewichtigen Docker-Images für verschiedene Browser den Fortschritt in der Automatisierung von Tests erheblich gefördert hat. Darüber hinaus müssen wir bei Selenium Grid alle erforderlichen Browser und deren Versionen im Voraus festlegen, was zwar kein Problem darstellt, wenn wir nur mit einem bestimmten Browser arbeiten. Wenn es jedoch um mehrere unterstützte Browser geht, ist Selenoid die Nummer eins, dank der Funktion „Browser on demand“. Alles, was wir tun müssen, ist, die benötigten Browser-Images im Voraus herunterzuladen und die Konfigurationsdatei zu aktualisieren, mit der Selenoid interagiert. Sobald Selenoid eine Anfrage von den Tests erhält, startet es automatisch den benötigten Container mit dem passenden Browser. Wenn der Test abgeschlossen ist, entfernt Selenoid den Container und gibt so die Ressourcen für die nächsten Anfragen frei. Dieser Ansatz beseitigt vollständig das bekannte Problem der „Knotenabnahme“, das wir häufig bei Selenium Grid antreffen.
Leider ist Selenoid immer noch keine Allheilmittel. Wir haben die Funktion ‚Browser on Demand‘ erhalten, aber die Funktion ‚Ressourcen on Demand‘ ist weiterhin nicht verfügbar. Um Selenoid zu nutzen, müssen wir es auf physischer Hardware oder in einer VM bereitstellen, was bedeutet, dass wir im Voraus wissen müssen, wie viele Ressourcen benötigt werden. Ich denke, das ist kein Problem für kleine Projekte, die 10, 20 oder sogar 30 Browser parallel ausführen. Aber was ist, wenn wir 100, 500, 1000 oder mehr benötigen? Es macht keinen Sinn, so viele Ressourcen dauerhaft zu halten und zu bezahlen. In den Abschnitten 5 und 6 dieses Artikels werden wir Lösungen diskutieren, die eine Skalierung ermöglichen und somit die Kosten des Unternehmens erheblich senken.
Selenoid für Android
Nach dem Erfolg von Selenoid als Tool für die Webautomatisierung wollten die Leute etwas Ähnliches für Android. Und das ist geschehen – Selenoid wurde mit Unterstützung für Android veröffentlicht. Aus der Sicht eines hochgradigen Nutzers funktioniert es ähnlich wie die Webautomatisierung. Der einzige Unterschied besteht darin, dass Selenoid anstelle von Containern mit Browsern Container mit Android-Emulatoren startet. Meiner Meinung nach ist dies derzeit das leistungsstärkste kostenlose Tool zum parallelen Ausführen von Android-Tests.
Ich möchte ungern über die negativen Aspekte dieses Tools sprechen, da ich es wirklich sehr mag. Dennoch gibt es auch hier dieselben Nachteile, die mit Web-Automatisierung in Verbindung stehen und zu Skalierungsproblemen führen können. Außerdem gibt es eine weitere Einschränkung, die überraschend sein könnte, wenn wir das Tool zum ersten Mal einrichten. Um Android-Images zu starten, benötigen wir eine physische Maschine oder eine VM mit unterstützter verschachtelter Virtualisierung. In der praktischen Anleitung zeige ich, wie man das auf einer Linux-VM aktiviert. Wenn Sie jedoch macOS-Benutzer sind und Selenoid lokal bereitstellen möchten, wird es nicht möglich sein, Android-Tests durchzuführen. Sie können jedoch jederzeit eine Linux-VM lokal mit aktivierter „verschachtelter Virtualisierung“ starten und Selenoid darin bereitstellen.
Illustration des aktuellen Infrastrukturstatus
Im Rahmen dieses Artikels fügen wir zwei Tools hinzu, um die Infrastruktur zu veranschaulichen. Das sind Selenium Grid für Web-Tests und Selenoid für Android-Tests. Im GitHub-Handbuch werde ich auch zeigen, wie man Selenoid für die Ausführung von Web-Tests verwendet.
Ressourcen zum Lernen
Ähnliche Werkzeuge
- Es gibt andere Containerisierungstools, aber Docker ist das beliebteste. Wenn Sie etwas anderes ausprobieren möchten, beachten Sie bitte, dass die Tools, die wir für die parallele Ausführung von Selenium-Tests besprochen haben, nicht von Haus aus funktionieren.
- Wie bereits erwähnt, gibt es viele Modifikationen von Selenium Grid, zum Beispiel.
4. CI / CD
Kurze Beschreibung der Technologie
Die Praxis der kontinuierlichen Integration ist in der Softwareentwicklung recht populär und steht auf einer Stufe mit Versionskontrollsystemen. Dennoch habe ich das Gefühl, dass es Verwirrung in der Terminologie gibt. In diesem Absatz möchte ich aus meiner Perspektive drei Modifikationen dieser Technologie erläutern. Im Internet finden Sie viele Artikel mit unterschiedlichen Interpretationen, und es ist absolut normal, wenn Ihre Meinung davon abweicht. Das Wichtigste ist, dass Sie mit Ihren Kollegen auf einer Wellenlänge sind.
Es gibt also drei Begriffe: CI — Continuous Integration (kontinuierliche Integration), CD — Continuous Delivery (kontinuierliche Lieferung) und erneut CD — Continuous Deployment (kontinuierliche Bereitstellung). (In der Folge werde ich diese Begriffe in englischer Sprache verwenden.). Jede Modifikation fügt mehrere zusätzliche Schritte zu Ihrer Entwicklungs-Pipeline hinzu. Aber das Wort kontinuierlich ist das Wichtigste. In diesem Kontext meinen wir etwas, das von Anfang bis Ende ohne Unterbrechungen oder manuelle Eingriffe geschieht. Lassen Sie uns CI & CD und CD in diesem Zusammenhang betrachten.
- Kontinuierliche Integration – ist der erste Schritt in der Evolution. Nachdem neuer Code auf den Server hochgeladen wurde, erwarten wir schnelles Feedback, dass mit unseren Änderungen alles in Ordnung ist. In der Regel umfasst CI das Ausführen von statischen Codeanalyse-Tools sowie modulare/internen API-Tests. Dies ermöglicht es, bereits wenige Sekunden/Minuten nach der Durchführung unserer Änderungen Informationen über unseren Code zu erhalten.
- Continuous Delivery stellt einen fortschrittlicheren Schritt dar, bei dem wir Integrations-/UI-Tests durchführen. In dieser Phase erhalten wir jedoch nicht so schnell Ergebnisse wie im Fall von CI. Erstens benötigen diese Testarten mehr Zeit für die Durchführung. Zweitens müssen wir vor dem Start unsere Änderungen in der Test-/Staging-Umgebung bereitstellen. Darüber hinaus kommt im Bereich der mobilen Entwicklung ein zusätzlicher Schritt für die Erstellung unserer App-Version hinzu.
- Continuous Deployment bedeutet, dass wir unsere Änderungen automatisch in die Produktion bereitstellen, sofern alle Abnahmetests in den vorherigen Phasen bestanden wurden. Darüber hinaus können nach der Veröffentlichung verschiedene Schritte eingerichtet werden, wie das Ausführen von Smoke-Tests in der Produktion und das Sammeln relevanter Metriken. Continuous Deployment ist nur bei guter Abdeckung durch automatisierte Tests möglich. Wenn manuelle Eingriffe, einschließlich Testungen, erforderlich sind, sprechen wir nicht mehr von Continuous (kontinuierlich). Dann können wir sagen, dass unsere Pipeline nur der Praxis des Continuous Delivery entspricht.
Wert für die Automatisierungsinfrastruktur
In diesem Abschnitt möchte ich klarstellen, dass wir bei end-to-end UI-Tests davon ausgehen, dass wir unsere Änderungen und die zugehörigen Dienste in Testumgebungen bereitstellen müssen. Continuous Integration ist für diese Aufgabe nicht anwendbar, und wir müssen sicherstellen, dass wir mindestens Continuous Delivery-Praktiken implementieren. Continuous Deployment macht auch Sinn im Kontext von UI-Tests, wenn wir planen, diese in der Produktion auszuführen.
Bevor wir uns das Diagramm zur Architekturanpassung ansehen, möchte ich ein paar Worte zu GitLab CI sagen. Im Gegensatz zu anderen CI/CD-Tools bietet GitLab ein entferntes Repository und viele weitere Zusatzfunktionen. Daher ist GitLab mehr als nur CI. Es umfasst von Haus aus die Verwaltung des Quellcodes, agile Verwaltung, CI/CD-Pipelines, Logging-Tools und die Erhebung von Metriken. Die Architektur von GitLab besteht aus GitLab CI/CD und GitLab Runner. Hier eine kurze Beschreibung von der offiziellen Website:
GitLab CI/CD ist eine Webanwendung mit einer API, die ihren Zustand in einer Datenbank speichert, Projekte/Bauten verwaltet und eine Benutzeroberfläche bereitstellt. GitLab Runner ist eine Anwendung, die Builds verarbeitet. Sie kann separat bereitgestellt werden und arbeitet über eine API mit GitLab CI/CD zusammen. Für das Ausführen von Tests benötigen Sie sowohl eine GitLab-Instanz als auch einen Runner.
Illustration des aktuellen Infrastrukturstatus
Ressourcen zum Lernen
Ähnliche Werkzeuge
- Und viele andere
5. Cloud-Plattformen
Kurze Beschreibung der Technologie
In diesem Abschnitt sprechen wir über einen beliebten Trend, der als ‚öffentliche Clouds‘ bekannt ist. Trotz der enormen Vorteile, die die oben beschriebenen Technologien der Virtualisierung und Containerisierung bieten, benötigen wir nach wie vor Rechenressourcen. Unternehmen erwerben teure Server oder mieten Rechenzentren, aber in solchen Fällen müssen oft unrealistische Berechnungen angestellt werden, wie viele Ressourcen wir benötigen, ob wir sie rund um die Uhr nutzen werden und zu welchen Zwecken. Zum Beispiel benötigt eine Produktionsumgebung einen Server, der rund um die Uhr verfügbar ist, aber benötigen wir ähnliche Ressourcen für Tests außerhalb der Arbeitszeiten? Das hängt auch von der Art der durchgeführten Tests ab. Ein Beispiel könnten Last- oder Stresstests sein, die wir in den Nichtarbeitsstunden durchführen, um am nächsten Tag Ergebnisse zu erhalten. Aber sicher ist, dass eine rund um die Uhr Verfügbarkeit der Server nicht für End-to-End-Automatisierungstests und insbesondere für manuelle Testumgebungen erforderlich ist. Für solche Situationen wäre es ideal, nur nach Bedarf so viele Ressourcen zu erhalten, wie nötig, diese zu nutzen und die Zahlungen einzustellen, wenn sie nicht mehr benötigt werden. Darüber hinaus wäre es großartig, sie sofort zu erhalten, indem man ein paar Mausklicks macht oder ein paar Skripte ausführt. Genau dafür werden öffentliche Clouds eingesetzt. Lassen Sie uns die Definition ansehen:
„Die öffentliche Cloud wird definiert als Computerleistungen, die von Drittanbietern über das öffentliche Internet angeboten werden, sodass sie für jeden verfügbar sind, der sie nutzen oder erwerben möchte. Sie können kostenlos oder nach Bedarf verkauft werden, sodass die Kunden nur für die CPU-Zyklen, den Speicher oder die Bandbreite bezahlen, die sie verbrauchen.“
Es besteht die Auffassung, dass öffentliche Clouds teuer sind. Doch die zentrale Idee dahinter ist die Senkung der Unternehmensausgaben. Wie bereits erwähnt, ermöglichen öffentliche Clouds den Zugriff auf Ressourcen nach Bedarf und die Zahlung nur für die Zeit, in der sie genutzt werden. Zudem vergessen wir manchmal, dass Mitarbeiter Gehälter beziehen und Fachkräfte ebenfalls teure Ressourcen sind. Es ist zu berücksichtigen, dass öffentliche Clouds die Verwaltung der Infrastruktur erheblich erleichtern, sodass Ingenieure sich auf wichtigere Aufgaben konzentrieren können.
Wert für die Automatisierungsinfrastruktur
Welche spezifischen Ressourcen benötigen wir für End-to-End-UI-Tests? Hauptsächlich handelt es sich um virtuelle Maschinen oder Cluster (wir werden in der nächsten Sektion über Kubernetes sprechen), um Browser und Emulatoren auszuführen. Je mehr Browser und Emulatoren wir gleichzeitig starten möchten, desto mehr CPU und RAM werden benötigt, und desto mehr Geld müssen wir dafür ausgeben. In diesem Zusammenhang ermöglichen öffentliche Clouds bei der Automatisierung von Tests, eine große Anzahl (100, 200, 1000 …) von Browsern/Emulatoren nach Bedarf zu starten, die Testergebnisse so schnell wie möglich zu erhalten und nicht mehr für solche wahnsinnig ressourcenintensiven Kapazitäten zu bezahlen.
Die bekanntesten Cloud-Anbieter sind Amazon Web Services (AWS), Microsoft Azure und Google Cloud Platform (GCP). In diesem praktischen Leitfaden finden Sie Beispiele für die Nutzung von GCP, wobei es im Grunde genommen jedoch unerheblich ist, welchen Anbieter Sie für Automatisierungsaufgaben verwenden. Sie bieten alle weitgehend dieselben Funktionen. Bei der Auswahl eines Anbieters konzentriert sich die Anleitung in der Regel auf die gesamte Infrastruktur des Unternehmens und die geschäftlichen Anforderungen, was den Rahmen dieses Artikels sprengt. Für Automatisierungsingenieure ist es interessanter, die Nutzung von Cloud-Anbietern mit spezifischen Cloud-Plattformen zu vergleichen, die für Testzwecke wie Sauce Labs, BrowserStack, BitBar usw. verwendet werden. Lassen Sie uns das also ebenfalls tun! Meiner Meinung nach ist Sauce Labs die bekannteste Plattform für Cloud-Testing, weshalb ich sie für den Vergleich gewählt habe.
GCP gegen Sauce Labs für Automatisierungszwecke:
Angenommen, wir müssen gleichzeitig 8 Web-Tests und 8 Android-Tests durchführen. Dazu verwenden wir GCP und starten 2 virtuelle Maschinen mit Selenoid. Auf der ersten erstellen wir 8 Container mit Browsern. Auf der zweiten 8 Container mit Emulatoren. Schauen wir uns die Preise an:
Um einen Container mit Chrome zu starten, benötigen wir n1-standard-1 eine Maschine. Bei Android handelt es sich um n1-standard-4 einen Emulator. Tatsächlich ist eine flexiblere und kostengünstigere Methode, spezifische Benutzerwerte für CPU/Memory anzugeben, jedoch ist dies derzeit für den Vergleich mit Sauce Labs nicht entscheidend.
Hier sind die Tarife für die Nutzung von Sauce Labs:
Ich nehme an, Sie haben bereits den Unterschied bemerkt, aber ich werde dennoch eine Tabelle mit Berechnungen für unsere Aufgabe anführen:
Benötigte Ressourcen
Monatlich
Arbeitsstunden(8 Uhr - 20 Uhr)
Arbeitsstunden+ Preemptible
GCP für Web
n1-standard-1 x 8 = n1-standard-8
$194.18
23 Tage * 12h * 0.38 = 104.88$
23 Tage * 12h * 0.08 = 22.08$
Sauce Labs für Web
Virtuelle Cloud mit 8 parallelen Tests
$1.559
—
—
GCP für Android
n1-standard-4 x 8: n1-standard-16
$776.72
23 Tage * 12h * 1.52 = 419.52$
23 Tage * 12h * 0.32 = 88.32$
Sauce Labs für Android
Real Device Cloud mit 8 parallelen Tests
$1.999
—
—
Wie man sieht, ist der Kostenunterschied riesig, insbesondere wenn man die Tests nur im Arbeitszeitfenster von zwölf Stunden durchführt. Aber man kann die Ausgaben noch weiter senken, wenn man preemptible Maschinen verwendet. Was genau ist das?
Eine preemptible VM ist eine Instanz, die man zu einem viel niedrigeren Preis als normale Instanzen erstellen und betreiben kann. Allerdings kann das Compute Engine diese Instanzen beenden (preempt), wenn es auf diese Ressourcen für andere Aufgaben zugreifen muss. Preemptible Instanzen sind überschüssige Kapazitäten von Compute Engine, daher variiert deren Verfügbarkeit je nach Nutzung.
Wenn Ihre Anwendungen ausfallsicher sind und mögliche Instanzunterbrechungen überstehen können, können vorübergehende Instanzen Ihre Compute Engine-Kosten erheblich senken. Beispielsweise können Batchverarbeitungsjobs auf vorübergehenden Instanzen ausgeführt werden. Wenn einige dieser Instanzen während der Verarbeitung beendet werden, verlangsamt sich der Job, stoppt jedoch nicht vollständig. Vorübergehende Instanzen erledigen Ihre Batchverarbeitungsaufgaben, ohne eine zusätzliche Last auf Ihren bestehenden Instanzen zu erzeugen und ohne dass Sie den vollen Preis für zusätzliche normale Instanzen zahlen müssen.
Und das ist noch nicht alles! Tatsächlich bin ich mir sicher, dass niemand Tests über 12 Stunden ohne Unterbrechung durchführt. Und wenn dem so ist, können Sie virtuelle Maschinen automatisch starten und stoppen, wenn sie nicht benötigt werden. Die tatsächliche Nutzungszeit kann auf 6 Stunden pro Tag sinken. Dann würde die Bezahlung in unserem Kontext auf bis zu 11 $ pro Monat für 8 Browser sinken. Ist das nicht großartig? Aber bei vorübergehenden Maschinen müssen wir vorsichtig sein und auf Unterbrechungen und instabile Operationen vorbereitet sein, auch wenn diese Situationen vorhergesehen und programmatisch behandelt werden können. Es lohnt sich!
Aber ich sage auf keinen Fall: 'Verwenden Sie niemals Cloud-Testfarmen'. Sie bieten eine Reihe von Vorteilen. Vor allem sind sie nicht nur virtuelle Maschinen, sondern vollständige Lösungen zur Automatisierung von Tests, die eine Reihe von Funktionen out-of-the-box bieten: Remote-Zugriff, Protokolle, Screenshots, Videoaufzeichnung, verschiedene Browser und physische mobile Geräte. In vielen Situationen kann dies eine unverzichtbare, luxuriöse Alternative sein. Besonders Testplattformen sind nützlich für die IOS-Automatisierung, da öffentliche Clouds nur Linux-/Windows-Systeme anbieten können. Aber das Thema IOS wird in kommenden Artikeln behandelt. Ich empfehle, die Situation stets zu betrachten und sich an den Aufgaben zu orientieren: In einigen Fällen ist es günstiger und effizienter, öffentliche Clouds zu nutzen, während in anderen Fällen Testplattformen definitiv das investierte Geld wert sind.
Illustration des aktuellen Infrastrukturstatus
Ressourcen zum Lernen
Ähnliche Tools:
6. Orchestrierung
Kurze Beschreibung der Technologie
Ich habe gute Nachrichten – wir stehen kurz vor dem Ende des Artikels! Derzeit besteht unsere Automatisierungsinfrastruktur aus Web- und Android-Tests, die wir parallel über GitLab CI ausführen, unter Verwendung von Docker-unterstützten Tools: Selenium Grid und Selenoid. Darüber hinaus nutzen wir die über GCP erstellten virtuellen Maschinen, um Container mit Browsern und Emulatoren zu starten. Um Kosten zu senken, fahren wir diese virtuellen Maschinen nur auf Abruf hoch und stoppen sie, wenn keine Tests durchgeführt werden. Gibt es noch etwas, das unsere Infrastruktur verbessern könnte? Die Antwort lautet: Ja! Begrüßen wir Kubernetes (K8s)!
Zunächst betrachten wir, wie die Begriffe Orchestrierung, Cluster und Kubernetes miteinander verbunden sind. Auf hoher Ebene ist Orchestrierung ein System, das Anwendungen bereitstellt und verwaltet. Automatisierte Tests von containerisierten Anwendungen wie Selenium Grid und Selenoid sind dabei von Bedeutung. Docker und K8s ergänzen sich hierbei. Docker wird zur Bereitstellung von Anwendungen verwendet, während K8s für die Orchestrierung verantwortlich ist. K8s selbst bildet somit ein Cluster. Die Aufgabe eines Clusters besteht darin, VMs als Nodes zu nutzen, was es ermöglicht, verschiedene Funktionen, Programme und Dienste innerhalb eines Servers (Clusters) zu installieren. Fällt einer der Nodes aus, übernehmen andere Nodes, was unserer Anwendung einen unterbrechungsfreien Betrieb garantiert. Darüber hinaus bietet K8s wichtige Funktionen im Zusammenhang mit dem Skalieren, wodurch wir automatisch die optimale Anzahl an Ressourcen basierend auf der Last und den festgelegten Einschränkungen erhalten.
Ehrlich gesagt ist das manuelle Einrichten von Kubernetes von Grund auf eine alles andere als triviale Aufgabe. Ich werde einen Link zu dem bekannten Praktikumsleitfaden „Kubernetes The Hard Way“ hinterlassen; wenn Sie interessiert sind, können Sie es ausprobieren. Aber zum Glück gibt es alternative Methoden und Werkzeuge. Die einfachste davon ist die Verwendung von Google Kubernetes Engine (GKE) in GCP, mit der Sie einen einsatzbereiten Cluster nach nur wenigen Klicks erhalten. Für den Einstieg empfehle ich diesen Ansatz, da Sie sich auf das Lernen konzentrieren können, wie Sie K8s für Ihre Aufgaben nutzen, anstatt herauszufinden, wie die internen Komponenten integriert werden sollten.
Wert für die Automatisierungsinfrastruktur
Lassen Sie uns einige bedeutende Funktionen betrachten, die K8s bietet:
- Anwendungsbereitstellung: Verwendung eines Multi-Node-Clusters anstelle von VMs;
- Dynamische Skalierung: senkt die Kosten für Ressourcen, die nur bei Bedarf genutzt werden;
- Selbstheilung (Self-healing): automatisches Wiederherstellen von Pods (wodurch auch die Container wiederhergestellt werden);
- Rollen von Updates und Rollbacks ohne Ausfallzeiten: Das Aktualisieren von Tools, Browsern und Emulatoren unterbricht nicht die Arbeit der aktuellen Benutzer.
Aber K8s ist immer noch keine Alleskönnerlösung. Um die Vorteile und Einschränkungen im Kontext der betrachteten Tools (Selenium Grid, Selenoid) zu verstehen, lassen Sie uns die Struktur von K8s kurz erörtern. Ein Cluster enthält zwei Arten von Nodes: Master Nodes und Worker Nodes. Master Nodes sind für das Management, die Bereitstellung und die Planungsentscheidungen verantwortlich. Worker Nodes sind die, auf denen die Anwendungen laufen. Nodes enthalten auch die Container-Laufumgebung. In unserem Fall ist das Docker, das für containerbezogene Operationen zuständig ist. Es gibt jedoch auch alternative Lösungen, wie. Es ist wichtig zu verstehen, dass Skalierung oder Selbstheilung nicht direkt auf Container zutrifft. Dies wird durch das Hinzufügen/Reduzieren der Anzahl von Pods realisiert, die wiederum Container enthalten (normalerweise ein Container pro Pod, aber je nach Aufgabe können es auch mehr sein). Die hierarchische Struktur auf hoher Ebene besteht aus Worker Nodes, in denen Pods enthalten sind, in denen Container betrieben werden.
Die Skalierungsfunktion ist entscheidend und kann sowohl auf Nodes innerhalb eines Cluster-Node-Pools als auch auf Pods innerhalb eines Nodes angewendet werden. Es gibt zwei Arten der Skalierung, die sowohl für Nodes als auch für Pods gelten. Der erste Typ ist die horizontale Skalierung, die durch die Erhöhung der Anzahl von Nodes/Pods erfolgt. Diese Art ist vorzuziehen. Der zweite Typ ist entsprechend die vertikale Skalierung, bei der die Größe von Nodes/Pods erhöht wird, nicht deren Anzahl.
Lassen Sie uns nun unsere Werkzeuge im Kontext der zuvor genannten Begriffe betrachten.
Selenium Grid
Wie bereits erwähnt, ist Selenium Grid ein sehr beliebtes Tool, und es ist nicht überraschend, dass es containerisiert wurde. Daher ist es wenig überraschend, dass Selenium Grid in K8s bereitgestellt werden kann. Ein Beispiel dafür, wie man das macht, findet sich im offiziellen K8s-Repository. Wie üblich füge ich am Ende des Abschnitts Links bei. Zusätzlich wird in der praktischen Anleitung gezeigt, wie dies mit Terraform durchgeführt werden kann. Es gibt auch eine Anleitung dazu, wie man die Anzahl der Pods, die Container mit Browsern enthalten, skalieren kann. Allerdings bleibt die Funktion der automatischen Skalierung im Kontext von K8s eine noch nicht ganz eindeutige Aufgabe. Als ich anfing, mich damit zu beschäftigen, fand ich kein praktisches Handbuch oder Empfehlungen. Nach mehreren Studien und Experimenten mit Unterstützung des DevOps-Teams wählten wir den Ansatz, Container mit den benötigten Browsern innerhalb eines Pods zu starten, der sich auf einem Worker-Node befindet. Diese Methode ermöglicht es uns, die Strategie der horizontalen Skalierung der Nodes zu verfolgen, indem wir deren Anzahl erhöhen. Ich hoffe, dass sich die Situation in Zukunft ändert und wir immer mehr Beschreibungen der besten Ansätze und fertigen Lösungen sehen, insbesondere nach der Veröffentlichung von Selenium Grid 4 mit einer veränderten internen Architektur.
Selenoid:
Derzeit ist die Bereitstellung von Selenoid in K8s die größte Enttäuschung. Sie sind nicht kompatibel. Theoretisch können wir den Selenoid-Container innerhalb eines Pods starten, aber wenn Selenoid beginnt, Container mit Browsern zu starten, befinden sich diese immer noch innerhalb desselben Pods. Das macht das Scaling unmöglich, und als Ergebnis wird die Arbeit von Selenoid innerhalb des Clusters nicht anders sein als die Arbeit innerhalb einer virtuellen Maschine. Ende der Geschichte.
Moon:
In Anbetracht dieses Engpasses beim Arbeiten mit Selenoid haben die Entwickler ein leistungsfähigeres Werkzeug geschaffen, das sie Moon genannt haben. Dieses Werkzeug wurde ursprünglich für die Arbeit mit Kubernetes entworfen und ermöglicht daher die Nutzung der Autoskalierungsfunktion. Darüber hinaus würde ich sagen, dass es derzeit die einzige das Werkzeug in der Welt von Selenium ist, das standardmäßig native K8s-Cluster-Unterstützung bietet (nicht mehr, siehe folgendes Werkzeug ). Ein entscheidendes Merkmal von Moon, das diese Unterstützung bietet, ist:
Völlig zustandslos. Selenoid speichert Informationen über aktuell laufende Browsersitzungen im Speicher. Wenn aus irgendeinem Grund sein Prozess abstürzt, sind alle laufenden Sitzungen verloren. Im Gegensatz dazu hat Moon keinen internen Zustand und kann über Rechenzentren hinweg repliziert werden. Browsersitzungen bleiben aktiv, auch wenn eine oder mehrere Replikate ausfallen.
Moon ist eine großartige Lösung, hat jedoch ein Problem: Es ist nicht kostenlos. Der Preis hängt von der Anzahl der Sitzungen ab. Kostenlos kann man nur 0-4 Sitzungen starten, was nicht besonders nützlich ist. Ab der fünften Sitzung muss man dann 5 $ für jede zusätzliche Sitzung bezahlen. Die Situation kann von Unternehmen zu Unternehmen unterschiedlich sein, aber in unserem Fall ist die Nutzung von Moon sinnlos. Wie bereits erwähnt, können wir VMs mit Selenium Grid nach Bedarf starten oder die Anzahl der Nodes im Cluster erhöhen. Für einen Pipeline starten wir ungefähr 500 Browser und stoppen alle Ressourcen nach Abschluss der Tests. Wenn wir Moon verwenden würden, müssten wir zusätzlich 500 x 5 = 2500 $ pro Monat bezahlen, unabhängig davon, wie oft wir die Tests ausführen. Und nochmals, ich sage nicht: "Nutzen Sie Moon nicht." Für Ihre Aufgaben könnte es eine unverzichtbare Lösung sein, insbesondere wenn Sie in Ihrer Organisation viele Projekte/Teams haben und einen großen gemeinsamen Cluster für alle benötigen. Wie immer hinterlasse ich den Link am Ende und empfehle, alle notwendigen Berechnungen im Kontext Ihrer speziellen Aufgaben vorzunehmen.
Callisto: (Achtung! Dies ist nicht im Originalartikel enthalten und findet sich nur in der russischen Übersetzung.)
Wie ich bereits sagte, ist Selenium ein sehr beliebtes Werkzeug, und die IT-Branche entwickelt sich rasant. Während ich mit der Übersetzung beschäftigt war, erschien ein neues vielversprechendes Werkzeug namens Callisto (Hallo Cypress und andere Selenium-Killer). Es funktioniert nativ mit K8s und ermöglicht das Starten von Selenoid-Containern in Pods, verteilt über Nodes. Alles funktioniert sofort out-of-the-box, inklusive automatischer Skalierung. Fantastisch, aber es ist notwendig, es zu testen. Ich konnte dieses Werkzeug bereits einrichten und einige Experimente durchführen. Aber es ist zu früh, um Schlussfolgerungen zu ziehen. Nach Erhalt der Ergebnisse auf lange Sicht werde ich möglicherweise eine Übersicht in zukünftigen Artikeln machen. Bis dahin lasse ich nur Links für eigenständige Recherchen.
Illustration des aktuellen Infrastrukturstatus
Ressourcen zum Lernen
Ressourcen zum Lernen
Ähnliche Werkzeuge
7. Infrastruktur als Code (IaC)
Kurze Beschreibung der Technologie
Und nun sind wir beim letzten Abschnitt angekommen. In der Regel fallen diese Technologien und die damit verbundenen Aufgaben nicht in den Verantwortungsbereich von Automatisierungsingenieuren. Dafür gibt es mehrere Gründe. Erstens, in vielen Organisationen fallen infrastrukturelle Fragen in den Aufgabenbereich des DevOps-Teams, und die Entwicklungsteams kümmern sich nicht wirklich darum, wie die Pipeline funktioniert und wie alles, was damit zusammenhängt, aufrechterhalten werden muss. Zweitens, um ehrlich zu sein, wird die Praxis "Infrastructure as Code (IaC)" in vielen Unternehmen noch nicht umgesetzt. Dennoch hat sich dies definitiv zu einem beliebten Trend entwickelt, und es ist wichtig, sich um die damit verbundenen Prozesse, Ansätze und Werkzeuge zu bemühen. Oder zumindest auf dem Laufenden zu bleiben.
Lassen Sie uns mit den Gründen für diesen Ansatz beginnen. Wir haben bereits besprochen, dass wir für den Start von Tests in GitLab CI mindestens Ressourcen für den Betrieb des GitLab Runners benötigen. Zum Start von Containern mit Browsern/Emulatoren müssen wir eine VM oder einen Cluster reservieren. Neben den Testressourcen benötigen wir beträchtliche Kapazitäten zur Unterstützung von Entwicklungs-, Staging- und Produktionsumgebungen, einschließlich Datenbanken, automatisierten Zeitplänen, Netzwerkkonfigurationen, Lastenausgleich, Benutzerrechten usw. Das zentrale Problem sind die erforderlichen Anstrengungen zur Pflege all dieser Komponenten. Es gibt mehrere Möglichkeiten, wie wir Änderungen vornehmen und Updates bereitstellen können. Beispielsweise können wir im Kontext von GCP die UI-Konsole im Browser verwenden und alle Aktionen per Mausklick durchführen. Eine alternative Methode könnte die Nutzung von API-Aufrufen zur Interaktion mit Cloud-Entitäten oder der Einsatz des Befehlszeilen-Tools gcloud sein, um die gewünschten Manipulationen durchzuführen. Doch bei einer wirklich Vielzahl von verschiedenen Entitäten und infrastrukturellen Elementen wird es schwierig oder sogar unmöglich, alle Operationen manuell auszuführen. Darüber hinaus sind all diese manuellen Aktionen unkontrolliert. Wir können sie nicht zur Überprüfung vor der Ausführung einreichen, ein Versionskontrollsystem nutzen oder schnell Änderungen zurücksetzen, die zu einem Vorfall geführt haben. Um solche Probleme zu lösen, haben Ingenieure automatische Bash-/Shell-Skripte entwickelt, was nicht viel besser ist als die vorherigen Methoden, da sie nicht so leicht schnell zu lesen, zu verstehen, zu warten und im prozeduralen Stil zu modifizieren sind.
In diesem Artikel und praktischen Leitfaden verwende ich zwei Werkzeuge, die zur IaC-Praxis gehören: Terraform und Ansible. Einige glauben, dass es sinnlos ist, sie gleichzeitig zu verwenden, da ihre Funktionalität ähnlich ist und sie austauschbar sind. Doch ursprünglich werden ihnen völlig unterschiedliche Aufgaben zugewiesen. Der Fakt, dass diese Werkzeuge sich gegenseitig ergänzen sollten, wurde auf einer gemeinsamen Präsentation von Entwicklern der Unternehmen HashiCorp und RedHat bestätigt. Der konzeptionelle Unterschied besteht darin, dass Terraform ein Provisioning-Tool zur Verwaltung der Server selbst ist. Während Ansible ein Konfigurationsmanagement-Tool ist, dessen Aufgabe die Installation, Konfiguration und Verwaltung der Software auf diesen Servern ist.
Ein weiteres Schlüsselmerkmal dieser Werkzeuge ist der Code-Stil. Im Gegensatz zu Bash und Ansible verwendet Terraform einen deklarativen Stil, der auf der Beschreibung des gewünschten Endzustands basiert, der durch die Ausführung erreicht werden soll. Wenn wir zum Beispiel 10 VMs erstellen und die Änderungen über Terraform anwenden, erhalten wir 10 VMs. Wenn wir das Skript erneut ausführen, passiert nichts, da wir bereits 10 VMs haben und Terraform dies weiß, weil es den aktuellen Zustand der Infrastruktur in einer Statusdatei speichert. Ansible hingegen verwendet einen prozeduralen Ansatz. Wenn wir es bitten, 10 VMs zu erstellen, erhalten wir beim ersten Durchlauf auch 10 VMs, ähnlich wie bei Terraform. Aber nach dem erneuten Ausführen haben wir bereits 20 VMs. Das ist das wesentliche Unterscheidungsmerkmal. Im prozeduralen Stil speichern wir den aktuellen Zustand nicht und beschreiben einfach die Reihenfolge der Schritte, die ausgeführt werden sollen. Natürlich können wir verschiedene Situationen behandeln, einige Überprüfungen auf die Existenz von Ressourcen und den aktuellen Zustand hinzufügen, aber es macht wenig Sinn, unsere Zeit zu verschwenden und Aufwand in die Kontrolle dieser Logik zu stecken. Außerdem erhöht dies das Risiko, Fehler zu machen.
Zusammenfassend lässt sich sagen, dass Terraform mit seiner deklarativen Notation das geeignetste Werkzeug für die Bereitstellung von Servern ist. Für das Konfigurationsmanagement hingegen ist es besser, Ansible zu delegieren. Nachdem wir das geklärt haben, lassen Sie uns Beispiele für den Einsatz im Kontext der Automatisierung betrachten.
Wert für die Automatisierungsinfrastruktur
Hier ist es wichtig zu verstehen, dass die Infrastruktur für automatisierte Tests als Teil der gesamten Infrastruktur des Unternehmens betrachtet werden sollte. Das bedeutet, dass alle IaC-Praktiken global auf die Ressourcen der gesamten Organisation angewendet werden müssen. Wer dafür verantwortlich ist, hängt von Ihren Prozessen ab. Das DevOps-Team hat in diesen Fragen mehr Erfahrung und hat einen umfassenden Überblick über die Situation. Allerdings sind QA-Ingenieure stärker am Aufbau der Automatisierung und der Pipeline-Struktur beteiligt, was ihnen ermöglicht, alle notwendigen Änderungen und Verbesserungsmöglichkeiten besser zu erkennen. Die beste Lösung ist, gemeinsam zu arbeiten, Wissen und Ideen auszutauschen, um das gewünschte Ergebnis zu erreichen.
Hier sind einige Beispiele für die Verwendung von Terraform und Ansible im Kontext der Testautomatisierung und der zuvor besprochenen Tools:
1. Die erforderlichen Eigenschaften und Parameter von VMs und Clustern über Terraform beschreiben.
2. Die für die Tests erforderlichen Tools mit Ansible installieren: Docker, Selenoid, Selenium Grid und die benötigten Versionen von Browsern/Emulatoren herunterladen.
3. Die Eigenschaften der VM, in der der GitLab Runner ausgeführt wird, über Terraform beschreiben.
4. Mit Ansible den GitLab Runner und die notwendigen begleitenden Tools installieren, Einstellungen und Konfigurationen festlegen.
Illustration des aktuellen Infrastrukturstatus
Ressourcen für weitere Studien:
Ähnliche Werkzeuge
Fassen wir zusammen!
Schritt
Technologie
Tools
Wert für die Automatisierungsinfrastruktur
1
Lokale Ausführung
Node.js, Selenium, Appium
- Die beliebtesten Tools für Web und Mobil
- Unterstützung vieler Sprachen und Plattformen (einschließlich Node.js)
2
Versionskontrollsysteme
Git
- Ähnliche Vorteile wie in der Entwicklungsumgebung
3
Containerisierung
Docker, Selenium Grid, Selenoid (Web, Android)
- Parallelbetrieb von Tests
- Isolierte Umgebungen
- Einfache, flexible Versionsaktualisierungen
- Dynamische Beendigung ungenutzter Ressourcen
- Einfach zu konfigurieren
4
CI / CD
(geschrieben in
- Tests sind Teil des Prozesses
- Schnelles Feedback
- Sichtbarkeit für das gesamte Unternehmen / Team
5
Cloud-Plattformen
Google Cloud Platform
- Ressourcen nach Bedarf (wir zahlen nur, wenn wir sie brauchen)
- Einfach zu verwalten und zu aktualisieren
- Sichtbarkeit und Kontrolle über alle Ressourcen
6
Orchestrierung
Kubernetes
Im Kontext von Containern mit Browsern/Emulatoren innerhalb der Pods:
- Skalierung / automatisches Skalieren
- Selbstheilung
- Updates und Rollbacks ohne Unterbrechungen
7
Infrastructure as Code (IaC)
Terraform, Ansible
- Ähnliche Vorteile mit der Entwicklungsinfrastruktur
- Alle Vorteile der Versionskontrolle
- Änderungen leicht einzuführen und zu pflegen
- Vollständig automatisiert
Mindmap-Diagramme: Evolution der Infrastruktur
Schritt 1: Lokal
Schritt 2: VCS
Schritt 3: Containerisierung
Schritt 4: CI/CD
Schritt 5: Cloud-Plattformen
Schritt 6: Orchestrierung
Schritt 7: IaC
Wie geht es weiter?
Das ist das Ende des Artikels. Aber zum Abschluss möchte ich einige Vereinbarungen mit Ihnen treffen.
Von Ihrer Seite
Wie zu Beginn erwähnt, möchte ich, dass der Artikel praktischen Nutzen bringt und Ihnen hilft, das erworbene Wissen in der Praxis anzuwenden. Hier nochmal.
Aber auch danach sollten Sie nicht aufhören, üben, lernen Sie die entsprechenden Links und Bücher kennen, erfahren Sie, wie es in Ihrem Unternehmen funktioniert, finden Sie Verbesserungsmöglichkeiten und beteiligen Sie sich daran. Viel Glück!
Von meiner Seite
Aus der Überschrift geht hervor, dass dies nur der erste Teil war. Obwohl er recht umfangreich ist, wurden hier wichtige Themen noch nicht behandelt. Im zweiten Teil plane ich, die Automatisierungsinfrastruktur im Kontext von iOS zu betrachten. Aufgrund der Einschränkungen von Apple, die iOS-Simulatoren nur auf macOS-Systemen auszuführen, ist unser Lösungsangebot eingeschränkt. Beispielsweise sind wir nicht in der Lage, Docker zum Starten des Simulators oder öffentliche Clouds zum Ausführen virtueller Maschinen zu verwenden. Aber das bedeutet nicht, dass es keine anderen Alternativen gibt. Ich werde versuchen, Sie über moderne Lösungen und aktuelle Tools auf dem Laufenden zu halten!
Außerdem habe ich einige bedeutende Themen im Zusammenhang mit dem Monitoring nicht erwähnt. In Teil 3 werde ich die gängigsten Tools zur Überwachung der Infrastruktur sowie die Daten und Metriken erörtern, die berücksichtigt werden sollten.
Und zum Schluss. In Zukunft plane ich, einen Videokurs zum Aufbau einer Testinfrastruktur und zu beliebten Werkzeugen herauszubringen. Derzeit gibt es im Internet viele Kurse und Vorträge über DevOps, aber alle Materialien sind im Kontext der Entwicklung präsent und nicht der Testautomatisierung. In dieser Hinsicht benötige ich dringend Feedback, ob ein solcher Kurs für die Gemeinschaft der Tester und Automatisierer interessant und wertvoll wäre. Vielen Dank im Voraus!
Quelle: habr.com
