Teil 1: Web / Android
Hinweis: Dieser Artikel ist eine Übersetzung des Originals ins Deutsche. Allerdings sind alle Illustrationen, Links, Zitate und Begriffe in der Originalsprache erhalten geblieben, um Verzerrungen des Sinns bei der Übersetzung ins Deutsche zu vermeiden. Ich wünsche Ihnen viel Freude beim Lernen!
Derzeit ist der Beruf DevOps einer der gefragtesten in der IT-Branche. Wenn Sie beliebte Jobportale aufrufen und die Gehaltsfilter setzen, werden Sie sehen, dass DevOps-Jobangebote ganz oben auf der Liste stehen. Es ist jedoch wichtig zu verstehen, dass dies hauptsächlich für die Position „Senior“ gilt, was bedeutet, dass der Kandidat über ein hohes Fähigkeitsniveau, Kenntnisse in Technologien und Werkzeugen verfügt. Dazu gehört auch ein hohes Maß an Verantwortung, das mit dem reibungslosen Betrieb von Produktionssystemen verbunden ist. Doch wir haben vergessen, was DevOps tatsächlich ist. Ursprünglich war es keine bestimmte Person oder Abteilung. Wenn wir nach Definitionen dieses Begriffs suchen, finden wir viele schöne und zutreffende Substantive wie Methodologie, Praktiken, kulturelle Philosophie, Konzeptgruppe und so weiter.
Meine Spezialisierung ist Ingenieur für Testautomatisierung (QA Automation Engineer), aber ich glaube, dass sie nicht nur mit dem Schreiben von automatisierten Tests oder der Entwicklung der Architektur eines Test-Frameworks verbunden sein sollte. Im Jahr 2020 sind Kenntnisse in Automatisierungsinfrastruktur ebenfalls notwendig. Dies ermöglicht es, den Automatisierungsprozess selbstständig zu organisieren, beginnend mit dem Start der Tests und endend mit der Bereitstellung der Ergebnisse für alle Interessierten gemäß den festgelegten Zielen. Daher sind DevOps-Fähigkeiten ein entscheidender Faktor für die Ausführung dieser 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, da Unternehmen nicht bereit sind, viel Geld für etwas auszugeben, was leicht zu erledigen ist... In der Welt von DevOps gibt es eine große Anzahl von Werkzeugen, Begriffen und Praktiken, die es zu beherrschen gilt. Besonders am Anfang der Karriere ist dies schwierig und hängt vom angesammelten technischen Wissen ab.
Quelle:
Hier wollen wir wohl mit der Einleitung abschließen und uns auf das Ziel dieses Artikels konzentrieren.
Worum geht es in diesem Artikel
In diesem Artikel möchte ich meine Erfahrungen im Aufbau einer Infrastruktur für automatisiertes Testen 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 von Ihnen selbst niemand ausführt oder sich um deren Wartung kümmert. Infolgedessen werden die Tests veraltet, und es muss Zeit aufgewendet werden, um sie zu aktualisieren. Zu Beginn der Karriere kann dies eine ziemlich herausfordernde Aufgabe sein: herauszufinden, welche Werkzeuge helfen sollten, dieses Problem zu lösen, wie man sie auswählt, einrichtet und wartet. Einige Tester wenden sich um Hilfe an DevOps (Menschen), und seien wir ehrlich, dieser Ansatz funktioniert. In vielen Fällen kann dies die einzige Option sein, da wir keinen Überblick über alle Abhängigkeiten haben. Aber 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 ist Automatisierung nicht prioritär. In diesem Fall sollten wir versuchen, alles Mögliche von unserer Seite aus von Anfang bis Ende zu tun. Das wird die Abhängigkeiten verringern, den Arbeitsablauf beschleunigen, unsere Fähigkeiten verbessern und uns helfen, ein umfassenderes Bild von den Vorgängen zu bekommen.
Der Artikel präsentiert die gefragtesten und populärsten Werkzeuge und zeigt, wie man sie für den schrittweisen Aufbau einer Automatisierungsinfrastruktur verwendet. Jede Gruppe wird durch Werkzeuge repräsentiert, die auf persönlicher Erfahrung basieren. Das bedeutet jedoch nicht, dass Sie dasselbe verwenden sollten. Die Werkzeuge selbst sind nicht wichtig, sie kommen und veralten. Unsere ingenieurtechnische Aufgabe besteht darin, die grundlegenden Prinzipien zu verstehen: Warum benötigen wir diese Gruppe von Werkzeugen, und welche Arbeitsaufgaben können wir mit ihrer Hilfe lösen? Daher lasse ich am Ende jedes Abschnitts Links zu ähnlichen Werkzeugen, die möglicherweise in Ihrer Organisation verwendet werden.
Was in diesem Artikel nicht vorhanden ist
Ich wiederhole noch einmal, dass der Artikel nicht über spezifische Werkzeuge handelt, daher wird es hier keine Code-Snippets aus der Dokumentation und keine Beschreibung spezifischer Befehle geben. Aber am Ende jedes Abschnitts lasse ich Links für eine detaillierte Untersuchung.
Dies geschieht aus folgendem Grund:
- dieses Material ist sehr leicht in verschiedenen Quellen (Dokumentation, Bücher, Video-Kurse) zu finden;
- wenn wir tiefer eintauchen, müssten wir 10, 20, 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 verwenden möchten, um die gleichen Ziele zu erreichen.
Praxis
Ich würde mir sehr wünschen, dass dieses Material für jeden Leser nützlich ist und nicht einfach nur gelesen und vergessen wird. In jedem Lernen ist die Praxis ein sehr wichtiger Bestandteil. Dafür habe ich vorbereitet. Sie erwartet auch eine Hausaufgabe, um sicherzustellen, dass Sie nicht gedankenlos ausgeführte Befehle kopiert haben.
Plan
Schritt
Technologie
Werkzeuge
1
Lokale Ausführung (Bereiten Sie Web-/Android-Demo-Tests vor und führen Sie sie lokal aus)
Node.js, Selenium, Appium
2
Versionskontrollsysteme
Git
3
Containerisierung
Docker, Selenium-Grid, Selenoid (Web, Android)
4
CI / CD
Gitlab CI
5
Cloud-Plattformen
Google Cloud Platform
6
Orchestrierung
Kubernetes
7
Infrastruktur als Code (IaC)
Terraform, Ansible
Struktur jeder Sektion
Um den Erzählfluss anschaulich zu halten, ist jede Sektion nach folgendem Plan beschrieben:
- kurze Beschreibung der Technologie,
- Wert für die Automatisierungsinfrastruktur,
- Darstellung des aktuellen Zustands der Infrastruktur,
- Links zum Lernen,
- ähnliche Werkzeuge.
1. Lokale Ausführung von Tests
Kurze Beschreibung der Technologie
Dies ist lediglich ein Vorbereitungsschritt, um Demo-Tests lokal auszuführen und zu überprüfen, ob sie erfolgreich durchgeführt werden. In dem praktischen Teil wird Node.js verwendet, jedoch ist die Programmiersprache und Plattform auch nicht wichtig und es können die verwendet werden, die in Ihrem Unternehmen genutzt werden.
Allerdings empfehle ich als Automatisierungswerkzeuge Selenium WebDriver für Web-Plattformen und Appium für die Android-Plattform, da wir in den nächsten Schritten Docker-Images verwenden werden, die speziell für die Arbeit mit diesen Werkzeugen optimiert sind. Darüber hinaus sind diese Werkzeuge, wie aus den Anforderungen in den Stellenangeboten ersichtlich ist, am meisten nachgefragt auf dem Markt.
Wie Sie vielleicht bemerkt haben, betrachten wir nur Web- und Android-Tests. Leider ist iOS eine ganz andere Geschichte (Danke Apple). Ich plane, Lösungen und Praktiken zu iOS in den folgenden Teilen vorzustellen.
Wert für die Automatisierungsinfrastruktur
Aus der Sicht der Infrastruktur bringt ein lokaler Start keinen Wert. Sie überprüfen nur, ob die Tests auf der lokalen Maschine in den lokalen Browsern und Simulatoren funktionieren. Aber in jedem Fall ist dies ein notwendiger Ausgangspunkt.
Illustration des aktuellen Standes der Infrastruktur
Links zum Lernen
Ähnliche Tools
- jede Programmiersprache, die Ihnen gefällt, in Verbindung mit Selenium/Appium – Tests;
- beliebige Tests;
- jeder Test-Runner.
2. Versionskontrollsysteme (Git)
Kurze Beschreibung der Technologie
Es wird niemanden überraschen, wenn ich sage, dass ein Versionskontrollsystem ein äußerst wichtiger Teil der Entwicklung, sowohl im Team als auch individuell, ist. Basierend auf verschiedenen Quellen kann man mit Sicherheit sagen, dass Git der beliebteste Vertreter ist. Das Versionskontrollsystem bietet viele Vorteile, wie Code-Sharing, Versionierung, Wiederherstellung früherer Branches, Überwachung der Projektgeschichte, Backups. Wir werden nicht jeden Punkt im Detail besprechen, da ich mir sicher bin, dass Sie damit gut vertraut sind und es in Ihrer täglichen Arbeit verwenden. Aber falls nicht, empfehle ich, das Lesen dieses Artikels zu unterbrechen und so schnell wie möglich diese Lücke zu schließen.
Wert für die Automatisierungsinfrastruktur
Und hier können Sie eine berechtigte Frage stellen: „Warum erzählt er uns von Git? Das wissen doch alle und verwenden es sowohl für die Code-Entwicklung als auch für den Code von automatisierten Tests.“ Sie haben völlig Recht, aber in diesem Artikel sprechen wir über Infrastruktur, und dieser Abschnitt spielt eine Rolle als Vorschau auf Abschnitt 7: „Infrastruktur als Code (IaC)“. Für uns bedeutet das, dass gesamte Infrastruktur, einschließlich der Testinfrastruktur, in Form von Code beschrieben wird, was bedeutet, dass wir auch Versionskontrollsysteme anwenden können und die ähnlichen Vorteile wie für den Entwicklungs- und Automatisierungscode erhalten.
Wir werden IaC im Schritt 7 ausführlicher betrachten, aber selbst jetzt können Sie Git lokal verwenden, indem Sie ein lokales Repository erstellen. Das Gesamtbild wird erweitert, wenn wir ein entferntes Repository zur Infrastruktur hinzufügen.
Illustration des aktuellen Standes der Infrastruktur
Links zum Lernen
Ähnliche Tools
3. Containerisierung (Docker)
Kurze Beschreibung der Technologie
Um zu demonstrieren, wie die Containerisierung die Spielregeln geändert hat, machen wir einen Sprung mehrere Jahrzehnte zurück. Damals kauften und nutzten die Menschen Servermaschinen zur Ausführung von Anwendungen. Doch in den meisten Fällen waren die benötigten Ressourcen für die Ausführung im Voraus nicht bekannt. Daher gaben Unternehmen Geld für den Kauf teurer, leistungsstarker Server aus, wobei ein Teil dieser Kapazitäten nicht vollständig ausgelastet war.
Der nächste Schritt in der Evolution waren virtuelle Maschinen (VM), die das Problem der Ausgaben für ungenutzte Ressourcen lösten. Diese Technologie ermöglichte das parallele Ausführen von Anwendungen auf einem einzigen Server, indem vollständig isolierter Raum bereitgestellt wurde. Leider hat jede Technologie ihre Nachteile. Das Starten von VMs erfordert ein vollständiges Betriebssystem, das CPU, RAM und Speicher verbraucht, und je nach OS müssen Lizenzkosten berücksichtigt werden. Diese Faktoren beeinflussen die Bootgeschwindigkeit und erschweren die Portabilität.
Und hier kommen wir zur Containerisierung. Auch diese Technologie löste das vorherige Problem, denn Container verwenden kein vollständiges Betriebssystem, was eine große Menge an Ressourcen freisetzt und eine schnelle sowie flexible Lösung für die Portabilität bietet.
Natürlich ist die Containertechnologie nichts Neues und wurde erstmals Ende der 70er Jahre vorgestellt. Damals gab es viele Forschungen, Entwicklungen und Versuche. Aber 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 unauffällig Container innerhalb einer leichten Linux-VM. Wir werden dieses Thema noch einmal aufgreifen, wenn wir über das Ausführen von Android-Emulatoren in Containern sprechen, da hier ein sehr wichtiges Detail auftaucht, das wir näher betrachten sollten.
Wert für die Automatisierungsinfrastruktur
Wir haben festgestellt, dass Containerisierung und Docker großartige Technologien sind. Lassen Sie uns dies im Kontext der Automatisierung betrachten, denn jedes Werkzeug oder jede Technologie sollte ein Problem lösen. Lassen Sie uns die offensichtlichen Probleme der Automatisierung von Tests im Kontext von UI-Tests identifizieren:
- eine riesige Anzahl von Abhängigkeiten bei der Installation von Selenium, insbesondere bei Appium;
- Kompatibilitätsprobleme zwischen Versionen von Browsern, Simulatoren und Treibern;
- das Fehlen eines isolierten Raums für Browser/Simulatoren, was besonders kritisch für paralleles Testen ist;
- schwierig zu verwalten und zu warten, wenn es notwendig ist, 10, 50, 100 oder sogar 1000 Browser gleichzeitig auszuführen.
Da Selenium jedoch das beliebteste Automatisierungswerkzeug und Docker das beliebteste Containerisierungstool ist, sollte es niemanden überraschen, dass jemand versucht hat, diese beiden zu kombinieren, um ein leistungsstarkes Werkzeug zur Lösung der oben genannten Probleme zu schaffen. Lassen Sie uns solche Lösungen genauer betrachten.
Selenium Grid in Docker
Dieses Tool ist das beliebteste der Welt für Selenium, um mehrere Browser auf mehreren Maschinen zu starten und von einem zentralen Knoten aus zu steuern. Um es zu starten, müssen mindestens 2 Komponenten registriert werden: Hub und Node(s). Hub ist der zentrale Knoten, der alle Anfragen von Tests erhält und sie an die entsprechenden Nodes verteilt. Für jeden Node können wir eine spezifische Konfiguration festlegen, indem wir den gewünschten Browser und dessen Version angeben. Wir müssen jedoch selbst für kompatible Treiber für die Browser sorgen und diese auf den benötigten Nodes installieren. Aus diesem Grund wird das Selenium Grid in seiner reinen Form nicht verwendet, es sei denn, wir müssen mit Browsern arbeiten, die nicht auf Linux OS installiert werden können. Für alle anderen Fälle ist es erheblich flexibler und sinnvoller, Docker-Images zu verwenden, um das Selenium Grid Hub und die Nodes zu starten. Dieser Ansatz vereinfacht das Management der Knoten erheblich, da wir das benötigte Image mit bereits installierten kompatiblen Browser- und Treiberversionen auswählen können.
Trotz negativer Rückmeldungen zur Stabilität, insbesondere beim gleichzeitigen Starten einer großen Anzahl von Nodes, bleibt das Selenium Grid immer noch das beliebteste Tool für den parallelen Start von Selenium-Tests. Es ist wichtig zu beachten, dass in der Open-Source-Welt ständig verschiedene Weiterentwicklungen und Modifikationen dieses Tools erscheinen, die gegen verschiedene Engpässe angehen.
Selenoid für Web
Dieses Tool ist ein Durchbruch in der Welt von Selenium, da es sofort einsatzbereit ist und das Leben vieler Automatisierungsingenieure erheblich erleichtert hat. Zunächst einmal handelt es sich nicht um eine weitere Modifikation von Selenium Grid. Stattdessen haben die Entwickler eine völlig neue Version von Selenium Hub in der Programmiersprache Golang erstellt, was zusammen mit den leichten Docker-Images für verschiedene Browser einen Schub in der Entwicklung der Testautomatisierung gegeben hat. Darüber hinaus müssen wir im Fall von Selenium Grid alle benötigten Browser und deren Versionen im Voraus festlegen, was kein Problem darstellt, wenn man nur mit einem einzelnen Browser arbeitet. Doch wenn es um mehrere unterstützte Browser geht, ist Selenoid die Nummer eins Lösung, dank der Funktion „Browser auf Abruf“. Alles, was wir tun müssen, ist, die benötigten Images mit den Browsern 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 entsprechenden Browser. Wenn der Test abgeschlossen ist, entfernt Selenoid den Container, wodurch Ressourcen für die nächsten Anfragen freiwerden. Dieser Ansatz beseitigt vollständig das bekannte Problem der „Verfallenden Knoten“, dem wir oft in Selenium Grid begegnen.
Aber leider ist Selenoid noch keine Silberkugel. Wir haben die Funktion „Browser auf Abruf“ erhalten, jedoch ist die Funktion „Ressourcen auf Abruf“ weiterhin nicht verfügbar. Um Selenoid zu nutzen, müssen wir es auf physischer Hardware oder auf einer VM bereitstellen, was bedeutet, dass wir im Voraus wissen müssen, wie viele Ressourcen wir zuweisen müssen. Ich denke, das ist kein Problem für kleine Projekte, die 10, 20 oder sogar 30 Browser parallel betreiben. Aber was ist, wenn wir 100, 500, 1000 oder mehr benötigen? Es macht keinen Sinn, ständig so viele Ressourcen zu unterstützen und zu bezahlen. In den Abschnitten 5 und 6 dieses Artikels werden wir Lösungen besprechen, die eine Skalierung ermöglichen und so die Ausgaben des Unternehmens erheblich senken.
Selenoid für Android
Nach dem Erfolg von Selenoid als Werkzeug zur Webautomatisierung wollten die Menschen etwas Ähnliches für Android. Und das ist geschehen – Selenoid wurde mit Unterstützung für Android veröffentlicht. Aus einer hochgradigen Benutzersicht ist das Prinzip ähnlich wie bei der 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 Werkzeug zum parallelen Ausführen von Android-Tests.
Ich möchte wirklich nicht über die negativen Seiten dieses Werkzeugs sprechen, da es mir wirklich gut gefällt. Aber dennoch gibt es hier die gleichen Nachteile, die auch bei der Webautomatisierung mit Skalierung verbunden sind. Darüber hinaus muss ich ein weiteres Einschränkung erwähnen, die überraschend sein kann, wenn wir das Werkzeug zum ersten Mal einrichten. Um Android-Images auszuführen, benötigen wir eine physische Maschine oder eine VM mit unterstützter verschachtelter Virtualisierung. In der praktischen Anleitung zeige ich, wie man dies auf einer Linux-VM aktiviert. Wenn Sie jedoch macOS-Benutzer sind und Selenoid lokal bereitstellen möchten, wird es unmöglich sein, Android-Tests auszuführen. Aber Sie können immer eine Linux-VM lokal mit aktivierter 'verschachtelter Virtualisierung' starten und Selenoid darin bereitstellen.
Illustration des aktuellen Standes der Infrastruktur
Im Kontext dieses Artikels fügen wir 2 Werkzeuge hinzu, um die Infrastruktur zu veranschaulichen. Dies sind Selenium Grid für Web-Tests und Selenoid für Android-Tests. In der Anleitung auf GitHub werde ich auch zeigen, wie man Selenoid verwendet, um Web-Tests auszuführen.
Links zum Lernen
Ähnliche Tools
- Es gibt andere Containerisierungswerkzeuge, aber Docker ist das populärste. Wenn Sie etwas anderes ausprobieren möchten, beachten Sie, dass die Werkzeuge, die wir für die parallele Ausführung von Selenium-Tests behandelt haben, nicht sofort funktionieren werden.
- 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 ziemlich populär und steht auf einer Stufe mit Versionskontrollsystemen. Trotzdem habe ich das Gefühl, dass es Verwirrung in der Terminologie gibt. In diesem Absatz möchte ich drei Varianten dieser Technologie aus meiner Sicht beschreiben. Im Internet können Sie viele Artikel mit unterschiedlichen Interpretationen finden, und es ist vollkommen in Ordnung, 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 Bereitstellung) und wieder CD – Continuous Deployment (kontinuierliches Deployment). (Ich werde diese Begriffe künftig auf Englisch verwenden). Jede Variante fügt Ihrer Entwicklungs-Pipeline einige zusätzliche Schritte hinzu. Aber das Wort continuous ist entscheidend. In diesem Kontext verstehen wir etwas, das von Anfang bis Ende ohne Unterbrechungen oder manuelle Eingriffe stattfindet. Lassen Sie uns CI & CD und CD in diesem Zusammenhang betrachten.
- Continuous Integration – ist der erste Schritt in der Evolution. Nachdem neuer Code auf den Server hochgeladen wurde, erwarten wir eine schnelle Rückmeldung, dass mit unseren Änderungen alles in Ordnung ist. Normalerweise beinhaltet CI die Ausführung von statischen Code-Analyse-Tools und Unit-/API-Tests. Dies ermöglicht es uns, bereits nach wenigen Sekunden/Minuten Informationen über unseren Code zu erhalten.
- Continuous Delivery ist ein fortgeschrittener Schritt, bei dem wir Integrations-/UI-Tests durchführen. Allerdings erhalten wir an dieser Stelle 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 unsere Änderungen in einer Test-/Staging-Umgebung bereitstellen, bevor wir sie ausführen. Zudem gibt es im Bereich der mobilen Entwicklung einen zusätzlichen Schritt zur Erstellung des Builds unserer Anwendung.
- Continuous Deployment Es wird davon ausgegangen, dass wir unsere Änderungen automatisch in der Produktion (Release) veröffentlichen, wenn alle Abnahmetests in den vorherigen Phasen bestanden wurden. Zusätzlich kann nach der Release-Phase eine Reihe verschiedener Schritte eingerichtet werden, wie das Ausführen von Smoke-Tests in der Produktion und das Sammeln interessanter Metriken. Continuous Deployment ist nur bei guter Abdeckung durch automatisierte Tests möglich. Wenn manuelle Eingriffe erforderlich sind, einschließlich Tests, ist es nicht mehr 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, wenn wir von End-to-End-UI-Tests sprechen, dies bedeutet, 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 uns darum kümmern, mindestens die Praktiken des Continuous Delivery einzuführen. Continuous Deployment ist auch im Kontext von UI-Tests sinnvoll, wenn wir beabsichtigen, sie in der Produktion auszuführen.
Und bevor wir uns die Illustration der Architekturänderung ansehen, möchte ich ein paar Worte über GitLab CI sagen. Im Gegensatz zu anderen CI/CD-Tools bietet GitLab ein Remote-Repository und viele weitere zusätzliche Funktionen. Somit ist GitLab mehr als nur CI. Es umfasst out-of-the-box die Verwaltung von Quellcode, Agile-Management, CI/CD-Pipelines, Logging-Tools und das Sammeln von Metriken. Die Architektur von GitLab besteht aus GitLab CI/CD und dem GitLab Runner. Hier ist eine kurze Beschreibung von der offiziellen Website:
GitLab CI/CD ist eine Webanwendung mit einer API, die ihren Zustand in einer Datenbank speichert, Projekte und Builds verwaltet und eine Benutzeroberfläche bereitstellt. GitLab Runner ist eine Anwendung, die Builds verarbeitet. Er 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 Standes der Infrastruktur
Links zum Lernen
Ähnliche Tools
- Und viele andere
5. Cloud-Plattformen
Kurze Beschreibung der Technologie
In diesem Abschnitt sprechen wir über einen beliebten Trend, der als 'öffentliche Cloud' bezeichnet wird. Trotz des enormen Nutzens, den die oben beschriebenen Virtualisierungs- und Containerisierungstechnologien bieten, benötigen wir weiterhin Rechenressourcen. Unternehmen erwerben teure Server oder mieten Rechenzentren, müssen jedoch in solchen Fällen Berechnungen (manchmal unrealistisch) anstellen, um festzustellen, wie viele Ressourcen wir benötigen, ob wir sie 24/7 nutzen werden und zu welchen Zwecken. Zum Beispiel benötigt die Produktion einen rund um die Uhr funktionierenden Server, aber brauchen wir ähnliche Ressourcen für Tests außerhalb der Arbeitszeiten? Das hängt auch von der Art der durchgeführten Tests ab. Belastungs-/Stresstests, die wir planen, außerhalb der Arbeitszeiten durchzuführen, um die Ergebnisse am nächsten Tag zu erhalten, sind ein Beispiel. Aber sicherlich wird für End-to-End-Autotests und insbesondere für manuelle Testumgebungen keine 24/7-Verfügbarkeit der Server benötigt. Für solche Situationen wäre es ideal, genau die Ressourcen nach Bedarf zu erhalten, sie zu nutzen und nicht mehr zu zahlen, 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. Dafür werden öffentliche Clouds genutzt. Lassen Sie uns die Definition betrachten:
„Die öffentliche Cloud wird definiert als Rechenleistungen, die von Drittanbietern über das öffentliche Internet angeboten werden und für jeden zugänglich 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 gibt die Meinung, dass öffentliche Clouds teuer sind. Aber ihre zentrale Idee ist die Reduzierung der Unternehmensausgaben. Wie bereits erwähnt, ermöglichen öffentliche Clouds den Zugriff auf Ressourcen nach Bedarf und das Bezahlen nur für die Dauer ihrer Nutzung. Außerdem vergessen wir manchmal, dass Mitarbeiter Gehälter erhalten und Fachkräfte ebenfalls eine teure Ressource darstellen. Es ist zu berücksichtigen, dass öffentliche Clouds die Unterstützung der Infrastruktur erheblich erleichtern, wodurch die Ingenieure sich auf wichtigere Aufgaben konzentrieren können.
Wert für die Automatisierungsinfrastruktur
Welche konkreten Ressourcen benötigen wir für End-to-End-UI-Tests? Hauptsächlich 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 Speicher benötigen wir und desto mehr Geld müssen wir dafür ausgeben. Somit ermöglichen öffentliche Clouds im Kontext der Testautomatisierung, eine große Anzahl (100, 200, 1000 …) von Browsern/Emulatoren nach Bedarf zu starten, Testergebnisse so schnell wie möglich zu erhalten und nicht für solch ressourcenintensive Kapazitäten zu zahlen.
Die beliebtesten Cloud-Anbieter sind Amazon Web Services (AWS), Microsoft Azure, Google Cloud Platform (GCP). In der praktischen Anleitung werden Beispiele für die Nutzung von GCP vorgestellt, aber insgesamt ist es unwichtig, was genau Sie für Automatisierungsaufgaben verwenden werden. Sie bieten alle ungefähr die gleiche Funktionalität. Normalerweise konzentriert sich die Auswahl des Anbieters auf die gesamte Infrastruktur des Unternehmens und die Geschäftsanforderungen, was über den Rahmen dieses Artikels hinausgeht. Für Automatisierungsingenieure ist es interessanter, die Nutzung von Cloud-Anbietern mit der Nutzung von Cloud-Plattformen speziell für Testzwecke zu vergleichen, wie Sauce Labs, BrowserStack, BitBar und so weiter. Also lassen Sie uns das tun! Meiner Meinung nach ist Sauce Labs die bekannteste Farm für Cloud-Tests, deshalb habe ich sie für den Vergleich ausgewählt.
GCP gegen Sauce Labs für Automatisierungszwecke:
Angenommen, wir müssen gleichzeitig 8 Web-Tests und 8 Android-Tests durchführen. Dafür verwenden wir GCP und starten 2 virtuelle Maschinen mit Selenoid. Auf der ersten werden wir 8 Container mit Browsern hochfahren. 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 Maschine. Im Falle von Android wird es sein mit automatischer Skalierung der Nodes (mindestens 4, maximal 16). für einen Emulator. Tatsächlich ist es eine flexiblere und kostengünstigere Möglichkeit, spezifische Benutzerwerte für CPU/Memory festzulegen, aber momentan ist das für den Vergleich mit Sauce Labs nicht entscheidend.
Hier sind die Preise für die Nutzung von Sauce Labs:
Ich nehme an, Sie haben den Unterschied bereits bemerkt, aber ich werde dennoch eine Tabelle mit Berechnungen für unsere Aufgabenstellung 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 das Web
Virtuelle Cloud8 parallele 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
Echter Geräte-Cloud 8 parallele Tests
$1.999
—
—
Wie man sieht, ist der Preisunterschied enorm, insbesondere wenn Tests nur im regulären zwölfstündigen Zeitraum durchgeführt werden. Aber man kann die Kosten noch weiter senken, wenn man vorübergehende Maschinen verwendet. Was ist das genau?
Eine vorübergehende VM ist eine Instanz, die Sie zu einem viel günstigeren Preis als normale Instanzen erstellen und betreiben können. Allerdings könnte das Compute Engine diese Instanzen (vorübergehend) beenden, wenn es Zugriff auf diese Ressourcen für andere Aufgaben benötigt. Vorübergehende Instanzen sind überschüssige Kapazitäten des Compute Engine, sodass ihre Verfügbarkeit je nach Nutzung variiert.
Wenn Ihre Apps fehlertolerant sind und mögliche Instanzunterbrechungen verkraften können, können vorübergehende Instanzen Ihre Compute Engine-Kosten erheblich senken. Beispielsweise können Batch-Verarbeitungsjobs auf vorübergehenden Instanzen ausgeführt werden. Wenn einige dieser Instanzen während der Verarbeitung beendet werden, verlangsamt sich der Job, stoppt aber nicht vollständig. Vorübergehende Instanzen schließen Ihre Batch-Verarbeitungsaufgaben ab, ohne zusätzliche Arbeitslast auf Ihren vorhandenen Instanzen zu legen und ohne dass Sie den vollen Preis für zusätzliche normale Instanzen zahlen müssen.
Und das ist noch nicht das Ende! Tatsächlich bin ich mir sicher, dass niemand Tests 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 Zahlung im Kontext unserer Aufgabe auf gerade einmal 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 Betriebsbedingungen vorbereitet sein, obwohl diese Situationen programmiert vorausgesehen und behandelt werden können. Es ist es wert!
Aber ich sage auf keinen Fall 'verwenden Sie niemals Cloud-Testfarmen'. Sie haben zahlreiche Vorteile. Vor allem sind sie nicht einfach nur virtuelle Maschinen, sondern eine umfassende Lösung für die Automatisierung von Tests mit einem umfangreichen Funktionsumfang direkt aus der Box: Fernzugriff, Protokolle, Screenshots, Videoaufzeichnung, verschiedene Browser und physische Mobilgeräte. In vielen Situationen kann das eine unverzichtbare großartige Alternative sein. Besonders Testplattformen sind hilfreich für iOS-Automatisierung, wenn öffentliche Clouds nur Linux-/Windows-Systeme anbieten können. Aber das Gespräch über iOS wird in den nächsten Artikeln stattfinden. Ich empfehle immer, die Situation zu betrachten und von den Aufgaben auszugehen: In einigen Fällen ist es günstiger und effektiver, öffentliche Clouds zu nutzen, während in anderen Testplattformen den ausgegebenen Geldbetrag eindeutig wert sind.
Illustration des aktuellen Standes der Infrastruktur
Links zum Lernen
Ähnliche Werkzeuge:
6. Orchestrierung
Kurze Beschreibung der Technologie
Ich habe gute Nachrichten – wir sind fast am Ende des Artikels! Derzeit besteht unsere Automatisierungsinfrastruktur aus Web- und Android-Tests, die wir parallel über GitLab CI ausführen, indem wir Docker-unterstützende Werkzeuge verwenden: Selenium Grid und Selenoid. Darüber hinaus nutzen wir durch GCP erstellte virtuelle Maschinen, um Container mit Browsern und Emulatoren zu betreiben. Um die Kosten zu senken, starten wir diese virtuellen Maschinen nur auf Anfrage und stoppen sie, wenn keine Tests durchgeführt werden. Gibt es noch etwas, das unsere Infrastruktur verbessern kann? Die Antwort ist ja! Willkommen Kubernetes (K8s)!
Lassen Sie uns zunächst betrachten, wie die Begriffe Orchestrierung, Cluster und Kubernetes miteinander verbunden sind. Auf hoher Ebene ist Orchestrierung ein System, das Anwendungen bereitstellt und verwaltet. Für die Automatisierung von Tests sind solche containerisierten Anwendungen Selenium Grid und Selenoid. Docker und K8s ergänzen sich gegenseitig. Ersteres wird zur Bereitstellung von Anwendungen verwendet, Letzteres zur Orchestrierung. K8s ist seinerseits ein Cluster. Die Aufgabe des Clusters besteht darin, VMs als Knoten zu verwenden, was es ermöglicht, verschiedene Funktionen, Programme und Dienste innerhalb eines Servers (Clusters) zu installieren. Wenn einer der Knoten ausfällt, übernehmen andere Knoten, was unserem Anwendung einen unterbrechungsfreien Betrieb gewährleistet. Zusätzlich verfügt K8s über wichtige Funktionen in Bezug auf das Skalieren, wodurch wir automatisch die optimale Menge an Ressourcen entsprechend der Auslastung und den festgelegten Grenzen erhalten.
Um ehrlich zu sein, ist das manuelle Einrichten von Kubernetes von Grund auf eine ganz und gar nicht triviale Aufgabe. Ich lasse einen Link zu dem bekannten praktischen Leitfaden "Kubernetes The Hard Way" da, und wenn es Sie interessiert, können Sie etwas üben. Aber zum Glück gibt es alternative Methoden und Werkzeuge. Die einfachste davon ist die Verwendung von Google Kubernetes Engine (GKE) in GCP, was es ermöglicht, nach wenigen Klicks einen einsatzbereiten Cluster zu erhalten. Für den Einstieg empfehle ich, genau diesen Ansatz zu verwenden, da er Ihnen erlaubt, sich auf das Lernen zu konzentrieren, wie man K8s für seine Aufgaben nutzen kann, anstatt zu erforschen, 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: Reduziert die Kosten für Ressourcen, die nur bei Bedarf genutzt werden;
- Selbstheilung: Automatische Wiederherstellung von Pods (die somit auch die Container wiederherstellen);
- Rollout von Updates und Rückrollungen ohne Ausfallzeiten: Die Aktualisierung von Werkzeugen, Browsern und Emulatoren unterbricht nicht den Betrieb der aktuellen Benutzer.
Aber K8s ist immer noch keine Silberkugel. Um alle Vorteile und Einschränkungen im Kontext der von uns betrachteten Werkzeuge (Selenium Grid, Selenoid) zu verstehen, lassen Sie uns kurz die Struktur von K8s besprechen. Ein Cluster besteht aus zwei Arten von Nodes: Master Nodes und Worker Nodes. Master Nodes sind für das Management, die Bereitstellung und die Scheduling-Entscheidungen verantwortlich. Worker Nodes sind das, wo die Anwendungen laufen. Nodes enthalten auch die Ausführungsumgebung für Container. In unserem Fall ist das Docker, das für containerbezogene Operationen verantwortlich ist. Aber es gibt auch alternative Lösungen, wie zum Beispiel. Es ist wichtig zu verstehen, dass Skalierung oder Selbstheilung nicht direkt auf Container zutreffen. Dies wird durch das Hinzufügen/Reduzieren der Anzahl von Pods realisiert, die wiederum Container enthalten (typischerweise ein Container pro Pod, aber je nach Aufgabe können es auch mehr sein). Die hochrangige Hierarchie besteht aus Worker Nodes, in denen sich Pods befinden, in denen die Container laufen.
Die Funktion der Skalierung ist entscheidend und kann sowohl auf Nodes innerhalb des Cluster-Node-Pools als auch auf Pods innerhalb des Nodes angewendet werden. Es gibt zwei Arten der Skalierung, die sich sowohl auf Nodes als auch auf Pods beziehen. Der erste Typ – die horizontale Skalierung – erfolgt durch die Erhöhung der Anzahl der Nodes/Pods. Dieser Typ ist bevorzugt. Der zweite Typ ist entsprechend die vertikale Skalierung. Bei der vertikalen Skalierung werden die Größen der Nodes/Pods erhöht, nicht deren Anzahl.
Lassen Sie uns nun unsere Werkzeuge im Kontext der oben genannten Begriffe betrachten.
Selenium Grid
Wie bereits erwähnt, ist das Selenium Grid ein sehr beliebtes Tool, und es ist keine Überraschung, dass es containerisiert wurde. Daher ist es auch nicht überraschend, dass das Selenium Grid in K8s bereitgestellt werden kann. Ein Beispiel dafür, wie das geht, findet sich im offiziellen K8s-Repository. Wie gewohnt füge ich am Ende des Abschnitts Links hinzu. Darüber hinaus wird in der praktischen Anleitung gezeigt, wie dies mit Terraform durchgeführt werden kann. Es gibt auch eine Anleitung, wie die Anzahl der Pods skaliert werden kann, die Container mit Browsern enthalten. Aber die Funktion der automatischen Skalierung im Kontext von K8s ist nach wie vor eine nicht ganz offensichtliche Aufgabe. Als ich mit dem Lernen begann, fand ich keine praktische Anleitung oder Empfehlungen. Nach mehreren Recherchen und Experimenten mit Unterstützung des DevOps-Teams wählten wir den Ansatz, Container mit den benötigten Browsern innerhalb eines Pods, der sich innerhalb eines Worker-Nodes befindet, zu erstellen. Dieser Ansatz ermöglicht es uns, eine Strategie der horizontalen Skalierung von Nodes durch die Erhöhung ihrer Anzahl anzuwenden. 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 bereitstellen, aber wenn Selenoid beginnt, Container mit Browsern zu starten, befinden sich diese immer noch innerhalb desselben Pods. Dies macht das Scaling unmöglich, und folglich wird die Ausführung von Selenoid innerhalb des Clusters nicht anders sein als die Ausführung innerhalb einer virtuellen Maschine. Ende der Geschichte.
Moon:
In Anbetracht dieses Engpasses bei der Arbeit mit Selenoid haben die Entwickler ein leistungsfähigeres Tool namens Moon veröffentlicht. Dieses Tool wurde ursprünglich für die Arbeit mit Kubernetes konzipiert und ermöglicht es, die Funktion des automatischen Skalierens effektiv zu nutzen. Darüber hinaus würde ich sagen, dass es derzeit das die einzige Tool in der Welt von Selenium ist, das sofort native K8s-Cluster-Unterstützung hat (gibt es nicht mehr, siehe das nächste Tool ). Ein Schlüsselelement von Moon, das diese Unterstützung bietet, ist:
Völlig zustandslos. Selenoid speichert Informationen über aktuell laufende Browsersitzungen im Speicher. Wenn aus irgendeinem Grund der Prozess abstürzt, gehen alle laufenden Sitzungen verloren. Moon hingegen hat keinen internen Zustand und kann über Rechenzentren hinweg repliziert werden. Browsersitzungen bleiben aktiv, auch wenn eine oder mehrere Replikate ausfallen.
Also, Moon ist eine großartige Lösung, hat aber 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 5 $ pro Sitzung zahlen. Die Situation kann von Unternehmen zu Unternehmen unterschiedlich sein, aber in unserem Fall macht die Nutzung von Moon keinen Sinn. Wie oben beschrieben, können wir VMs mit Selenium Grid bei Bedarf starten oder die Anzahl der Knoten im Cluster erhöhen. Für eine Pipeline starten wir ungefähr 500 Browser und stoppen sämtliche Ressourcen nach Abschluss der Tests. Wenn wir Moon verwenden würden, müssten wir zusätzliche 500 x 5 = 2500 $ pro Monat zahlen, unabhängig davon, wie oft wir die Tests ausführen. Und nochmals, ich sage nicht „verwenden Sie Moon nicht“. Für Ihre Aufgaben kann es eine unverzichtbare Lösung sein, zum Beispiel, wenn Sie in Ihrer Organisation viele Projekte/Teams haben und einen riesigen gemeinsamen Cluster für alle benötigen. Wie immer hinterlasse ich am Ende den Link und empfehle, alle erforderlichen Berechnungen im Kontext Ihrer Aufgaben vorzunehmen.
Callisto: (Achtung! Dies ist nicht im Originalartikel enthalten und steht nur in der russischen Übersetzung.)
Wie ich bereits sagte, ist Selenium ein sehr beliebtes Tool und der IT-Sektor entwickelt sich rasant. Während ich an der Übersetzung arbeitete, tauchte ein neues vielversprechendes Tool namens Callisto auf (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, einschließlich automatischer Skalierung. Fantastisch, aber es muss getestet werden. Es ist mir bereits gelungen, dieses Tool bereitzustellen und einige Experimente durchzuführen. Aber es ist noch zu früh für Schlussfolgerungen; nachdem ich Ergebnisse über einen längeren Zeitraum erhalten habe, werde ich vielleicht in zukünftigen Artikeln eine Übersicht geben. Ich hinterlasse vorerst nur Links für eigenständige Recherchen.
Illustration des aktuellen Standes der Infrastruktur
Links zum Lernen
Links zum Lernen
Ähnliche Tools
7. Infrastruktur als Code (IaC)
Kurze Beschreibung der Technologie
Und nun sind wir beim letzten Abschnitt angekommen. Normalerweise gehören diese Technologien und die damit verbundenen Aufgaben nicht zum Verantwortungsbereich von Automatisierungsingenieuren. Dafür gibt es eigene Gründe. Erstens sind in vielen Organisationen Infrastrukturfragen unter der Kontrolle der DevOps-Abteilung, und die Entwicklungsteams kümmern sich nicht besonders darum, wie die Pipeline funktioniert und wie alles, was damit verbunden ist, unterstützt werden muss. Zweitens, um ehrlich zu sein, wird die Praxis „Infrastruktur als Code (IaC)“ in vielen Unternehmen immer noch nicht angewendet. Aber es ist definitiv ein populärer Trend geworden, und es ist wichtig, sich in die damit verbundenen Prozesse, Ansätze und Tools einzubringen. Oder zumindest auf dem Laufenden zu bleiben.
Lassen Sie uns mit der Motivation beginnen, diesen Ansatz zu nutzen. Wir haben bereits besprochen, dass wir für das Starten von Tests in GitlabCI mindestens Ressourcen für das Starten des Gitlab Runner benötigen. Um Container mit Browsern/Emulatoren zu starten, müssen wir eine VM oder ein Cluster reservieren. Neben den Ressourcen für das Testen benötigen wir beträchtliche Kapazitäten zur Unterstützung der Entwicklungs-, Staging- und Produktionsumgebungen, die auch Datenbanken, automatisierte Zeitpläne, Netzwerkkonfigurationen, Lastenausgleicher, Benutzerrechte und so weiter umfassen. Das Hauptproblem besteht im erforderlichen Aufwand zur Unterstützung all dessen. Es gibt mehrere Möglichkeiten, wie wir Änderungen vornehmen und Updates bereitstellen können. Zum Beispiel können wir im Kontext von GCP die UI-Konsole im Browser verwenden und alle Aktionen durch Klicken auf Schaltflächen ausführen. Eine alternative Methode könnte die Nutzung von API-Calls zur Interaktion mit Cloud-Entitäten oder die Verwendung des gcloud-Befehlszeilenwerkzeugs sein, um die erforderlichen Manipulationen durchzuführen. Doch bei einer wirklich großen Anzahl verschiedener Entitäten und Infrastrukturkomponenten wird es schwierig oder sogar unmöglich, alle Operationen manuell auszuführen. Darüber hinaus sind all diese manuellen Aktionen nicht kontrollierbar. Wir können sie vor der Ausführung nicht zur Überprüfung einreichen, kein Versionskontrollsystem verwenden und keine Änderungen schnell zurücksetzen, die zu einem Vorfall geführt haben. Um solche Probleme zu lösen, haben Ingenieure automatische bash/shell-Skripte erstellt und erstellen sie weiterhin, was nur geringfügig 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 2 Werkzeuge, die zur Praxis von IaC gehören. Dies sind Terraform und Ansible. Einige glauben, dass es keinen Sinn macht, sie gleichzeitig zu verwenden, da ihre Funktionalität ähnlich ist und sie austauschbar sind. Aber die Tatsache ist, dass ihnen ursprünglich ganz unterschiedliche Aufgaben gestellt werden. Und die Tatsache, dass diese Werkzeuge sich gegenseitig ergänzen sollen, wurde bei einer gemeinsamen Präsentation von Entwicklern, die die Unternehmen HashiCorp und RedHat vertreten, bestätigt. Der konzeptionelle Unterschied besteht darin, dass Terraform ein Provisioning-Tool zur Verwaltung der Server selbst ist, während Ansible ein Tool zur Konfigurationsverwaltung ist, dessen Aufgabe die Installation, Konfiguration und Verwaltung der Software auf diesen Servern ist.
Eine weitere wesentliche Unterscheidungsmerkmal dieser Werkzeuge ist der Programmierstil. Im Gegensatz zu Bash und Ansible verwendet Terraform einen deklarativen Stil, der auf der Beschreibung des gewünschten Endzustands basiert, der erreicht werden soll. Zum Beispiel, wenn wir 10 VMs erstellen und die Änderungen mit Terraform anwenden, erhalten wir 10 VMs. Wenn das Skript erneut angewendet wird, passiert nichts, da wir bereits 10 VMs haben, und Terraform weiß dies, da es den aktuellen Zustand der Infrastruktur in einer State-Datei speichert. Ansible hingegen verwendet einen prozeduralen Ansatz, und wenn wir ihn bitten, 10 VMs zu erstellen, erhalten wir beim ersten Durchlauf auch 10 VMs, ähnlich wie bei Terraform. Aber nach einem erneuten Durchlauf haben wir dann bereits 20 VMs. Das ist der wesentliche Unterschied. Im prozeduralen Stil speichern wir den aktuellen Zustand nicht und beschreiben einfach die Abfolge von Schritten, die ausgeführt werden sollen. Natürlich können wir verschiedene Situationen behandeln, mehrere Prüfungen auf die Existenz von Ressourcen und den aktuellen Zustand hinzufügen, aber es hat keinen Sinn, unsere Zeit damit zu verbringen und Mühe aufzuwenden, um diese Logik zu kontrollieren. Außerdem erhöht das das Risiko, Fehler zu machen.
Zusammenfassend lässt sich sagen, dass Terraform und die deklarative Notation das geeignetere Werkzeug für das Provisioning von Servern sind. Die Aufgaben zur Verwaltung von Konfigurationen sollten besser an Ansible delegiert werden. Nachdem wir das geklärt haben, schauen wir uns einige Anwendungsbeispiele im Kontext der Automatisierung an.
Wert für die Automatisierungsinfrastruktur
Hier ist es wichtig zu verstehen, dass die Infrastruktur zur Automatisierung von Tests als Teil der gesamten Infrastruktur des Unternehmens betrachtet werden muss. Das bedeutet, dass alle IaC-Praktiken global auf die Ressourcen der gesamten Organisation angewendet werden sollten. Wer dafür verantwortlich ist, hängt von Ihren Prozessen ab. Das DevOps-Team hat mehr Erfahrung in diesen Fragen, sie sehen das gesamte Geschehen. QA-Ingenieure sind jedoch stärker in den Prozess des Aufbaus von Automatisierung und der Pipeline-Struktur involviert, was ihnen ermöglicht, alle erforderlichen Änderungen und Verbesserungsmöglichkeiten besser zu erkennen. Die beste Option ist, gemeinsam zu arbeiten, Wissen und Ideen auszutauschen, um das gewünschte Ergebnis zu erzielen.
Ich werde einige Beispiele für die Verwendung von Terraform und Ansible im Kontext der Automatisierung von Tests und der Werkzeuge, die wir zuvor besprochen haben, anführen:
1. Die notwendigen Eigenschaften und Parameter von VMs und Clustern über Terraform beschreiben.
2. Mit Ansible die erforderlichen Testwerkzeuge installieren: Docker, Selenoid, Selenium Grid und die benötigten Versionen von Browsern/Emulatoren herunterladen.
3. Die Eigenschaften der VM, auf der der GitLab Runner ausgeführt werden soll, über Terraform beschreiben.
4. Mit Ansible den GitLab Runner und die erforderlichen Begleitwerkzeuge installieren, Einstellungen und Konfigurationen festlegen.
Illustration des aktuellen Standes der Infrastruktur
Links zum Lernen:
Ähnliche Tools
Fassen wir zusammen!
Schritt
Technologie
Werkzeuge
Wert für die Automatisierungsinfrastruktur
1
Lokale Ausführung
Node.js, Selenium, Appium
- Die beliebtesten Werkzeuge für Web und Mobile
- Unterstützung vieler Sprachen und Plattformen (einschließlich Node.js)
2
Versionskontrollsysteme
Git
- Ähnliche Vorteile mit dem Entwicklungscode
3
Containerisierung
Docker, Selenium-Grid, Selenoid (Web, Android)
- Parallele Ausführung von Tests
- Isolierte Umgebungen
- Einfache, flexible Aktualisierung von Versionen
- Dynamisches Stoppen ungenutzter Ressourcen
- Einfach einzurichten
4
CI / CD
Gitlab CI
- Tests sind Teil der Pipeline
- Schnelles Feedback
- Sichtbarkeit für das gesamte Unternehmen / Team
5
Cloud-Plattformen
Google Cloud Platform
- Ressourcen nach Bedarf (wir zahlen nur, wenn sie benötigt werden)
- Einfach zu verwalten und zu aktualisieren
- Sichtbarkeit und Kontrolle aller Ressourcen
6
Orchestrierung
Kubernetes
Im Kontext von Containern mit Browsern/Emulatoren innerhalb von Pods:
- Skalierung / automatisches Skalieren
- Selbstheilung
- Aktualisierungen und Rollbacks ohne Unterbrechungen
7
Infrastruktur als Code (IaC)
Terraform, Ansible
- Ähnliche Vorteile mit der Entwicklungsinfrastruktur
- Alle Vorteile der Code-Versionierung
- Änderungen sind einfach vorzunehmen und zu pflegen
- Vollständig automatisiert
Mindmap-Diagramme: Entwicklung 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
Was folgt jetzt?
Das ist das Ende des Artikels. Aber zum Schluss möchte ich einige Vereinbarungen mit Ihnen treffen.
Von Ihrer Seite
Wie bereits zu Beginn erwähnt, möchte ich, dass der Artikel einen praktischen Nutzen bietet und Ihnen hilft, das Gelernte in der realen Arbeit anzuwenden. Ich füge noch einmal.
hinzu. Aber hören Sie selbst danach nicht auf, üben Sie weiter, studieren Sie die entsprechenden Links und Bücher, erfahren Sie, wie es in Ihrem Unternehmen funktioniert, finden Sie Verbesserungsmöglichkeiten und beteiligen Sie sich daran. Viel Erfolg!
Von meiner Seite
ist aus dem Titel ersichtlich, dass dies nur der erste Teil war. Obwohl er ziemlich lang war, wurden hier noch wichtige Themen 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 ausführen können, ist unser Lösungsangebot eingeschränkt. Zum Beispiel sind wir nicht in der Lage, Docker für die Ausführung des Simulators oder öffentliche Clouds für virtuelle Maschinen zu nutzen. Aber das bedeutet nicht, dass es keine anderen Alternativen gibt. Ich werde mein Bestes tun, um Sie über innovative Lösungen und moderne Tools auf dem Laufenden zu halten!
Außerdem habe ich einige enorm wichtige Themen bezüglich Monitoring nicht erwähnt. In Teil 3 werde ich die beliebtesten Tools für die Überwachung von Infrastruktur sowie die Daten und Metriken, die berücksichtigt werden sollten, erörtern.
Und schließlich. In Zukunft plane ich einen Videokurs zur Aufbau von Testinfrastrukturen und beliebten Tools zu veröffentlichen. Derzeit gibt es im Internet eine Vielzahl von Kursen und Vorlesungen zu DevOps, aber alle Materialien sind im Kontext der Entwicklung und nicht der Testautomatisierung dargestellt. In dieser Hinsicht benötige ich dringend Feedback, ob ein solcher Kurs für die Community der Tester und Automatisierer interessant und wertvoll wäre. Vielen Dank im Voraus!
Quelle: habr.com
