Teil 1: Web/Android
Beachten: Dieser Artikel ist eine Übersetzung des Originalartikels ins Russische Alle Abbildungen, Links, Zitate und Begriffe sind jedoch in der Originalsprache erhalten, um eine Verzerrung der Bedeutung bei der Übersetzung ins Russische zu vermeiden. Ich wünsche dir viel Spaß beim Lernen!
Derzeit ist die DevOps-Spezialität eine der gefragtesten in der IT-Branche. Wenn Sie beliebte Jobsuchseiten öffnen und nach Gehalt filtern, werden Sie feststellen, dass DevOps-bezogene Jobs ganz oben auf der Liste stehen. Es ist jedoch wichtig zu verstehen, dass es sich dabei hauptsächlich um eine „leitende“ Position handelt, was bedeutet, dass der Kandidat über ein hohes Maß an Fähigkeiten, Technologie- und Werkzeugkenntnissen verfügt. Damit verbunden ist auch ein hohes Maß an Verantwortung für den unterbrechungsfreien Produktionsbetrieb. Allerdings begannen wir zu vergessen, was DevOps ist. Dabei handelte es sich zunächst nicht um eine konkrete Person oder Abteilung. Wenn wir nach Definitionen dieses Begriffs suchen, werden wir viele schöne und korrekte Substantive finden, wie z. B. Methodik, Praktiken, Kulturphilosophie, Konzeptgruppe und so weiter.
Meine Spezialisierung ist ein Testautomatisierungsingenieur (QA-Automatisierungsingenieur), aber ich glaube, dass diese nicht nur mit dem Schreiben von Autotests oder der Entwicklung einer Test-Framework-Architektur verbunden sein sollte. Auch im Jahr 2020 sind Kenntnisse der Automatisierungsinfrastruktur unerlässlich. Dadurch können Sie den Automatisierungsprozess selbst organisieren, von der Durchführung von Tests bis hin zur Bereitstellung der Ergebnisse für alle Beteiligten entsprechend Ihren Zielen. Daher sind DevOps-Kenntnisse ein Muss, um die Arbeit zu erledigen. Und das alles ist gut, aber leider gibt es ein Problem (Spoiler: Dieser Artikel versucht, dieses Problem zu vereinfachen). Der Punkt ist, dass DevOps schwierig ist. Und das liegt auf der Hand, denn Unternehmen zahlen nicht viel für etwas, das einfach zu erledigen ist ... In der DevOps-Welt gibt es eine Vielzahl von Tools, Begriffen und Praktiken, die beherrscht werden müssen. Dies ist besonders zu Beginn einer Karriere schwierig und hängt von der gesammelten technischen Erfahrung ab.
Source:
Hier werden wir wahrscheinlich mit dem Einführungsteil abschließen und uns auf den Zweck dieses Artikels konzentrieren.
Wovon handelt der Artikel?
In diesem Artikel werde ich meine Erfahrungen beim Aufbau einer Testautomatisierungsinfrastruktur teilen. Im Internet gibt es viele Informationsquellen zu verschiedenen Tools und deren Verwendung, ich möchte sie jedoch rein im Kontext der Automatisierung betrachten. Ich glaube, dass viele Automatisierungsingenieure die Situation kennen, wenn niemand außer Ihnen die entwickelten Tests durchführt oder sich um deren Wartung kümmert. Dies führt dazu, dass Tests veraltet sind und Sie Zeit für die Aktualisierung aufwenden müssen. Auch dies kann zu Beginn einer Karriere eine ziemlich schwierige Aufgabe sein: klug zu entscheiden, welche Tools zur Beseitigung eines bestimmten Problems beitragen sollen, wie man sie auswählt, konfiguriert und wartet. Einige Tester wenden sich hilfesuchend an DevOps (Menschen), und seien wir ehrlich: Dieser Ansatz funktioniert. In vielen Fällen ist dies möglicherweise die einzige Option, da wir nicht alle Abhängigkeiten einsehen können. Aber wie wir wissen, sind DevOps sehr beschäftigte Leute, weil sie je nach Organisation/Team über die gesamte Unternehmensinfrastruktur, Bereitstellung, Überwachung, Microservices und andere ähnliche Aufgaben nachdenken müssen. Wie üblich steht die Automatisierung nicht im Vordergrund. In einem solchen Fall müssen wir versuchen, von Anfang bis Ende unser Möglichstes zu tun. Dadurch werden Abhängigkeiten reduziert, Arbeitsabläufe beschleunigt, unsere Fähigkeiten verbessert und es uns ermöglicht, das Gesamtbild des Geschehens zu sehen.
Der Artikel stellt die beliebtesten und beliebtesten Tools vor und zeigt Schritt für Schritt, wie man damit eine Automatisierungsinfrastruktur aufbaut. Jede Gruppe wird durch Werkzeuge repräsentiert, die durch persönliche Erfahrung getestet wurden. Das bedeutet aber nicht, dass Sie dasselbe verwenden müssen. Die Werkzeuge selbst sind nicht wichtig, sie tauchen auf und werden veraltet. Unsere technische Aufgabe besteht darin, die Grundprinzipien zu verstehen: Warum wir diese Gruppe von Werkzeugen benötigen und welche Arbeitsprobleme wir mit ihrer Hilfe lösen können. Aus diesem Grund hinterlasse ich am Ende jedes Abschnitts Links zu ähnlichen Tools, die in Ihrer Organisation verwendet werden können.
Was steht nicht in diesem Artikel
Ich wiederhole noch einmal, dass es in dem Artikel nicht um bestimmte Tools geht, daher wird es keine Codeeinfügungen aus der Dokumentation und Beschreibungen bestimmter Befehle geben. Aber am Ende jedes Abschnitts hinterlasse ich Links zum detaillierten Studium.
Dies geschieht, weil:
- dieses Material ist in verschiedenen Quellen (Dokumentation, Bücher, Videokurse) sehr leicht zu finden;
- Wenn wir tiefer gehen, müssen wir 10, 20, 30 Teile dieses Artikels schreiben (während die Pläne 2-3 sind);
- Ich möchte einfach nicht Ihre Zeit verschwenden, da Sie möglicherweise andere Tools verwenden möchten, um die gleichen Ziele zu erreichen.
Praxis
Ich möchte wirklich, dass dieses Material für jeden Leser nützlich ist und nicht nur gelesen und vergessen wird. In jedem Studium ist die Praxis ein sehr wichtiger Bestandteil. Darauf habe ich mich vorbereitet. Es warten auch Hausaufgaben auf Sie, um sicherzustellen, dass Sie nicht gedankenlos die Zeilen der Befehle kopieren, die Sie ausführen.
Planen
Schritt
Technologie
Tools
1
Lokale Ausführung (Web-/Android-Demotests vorbereiten und lokal ausführen)
Node.js, Selenium, Appium
2
Versionskontrollsysteme
Git
3
Containerisierung
Docker, Selenium-Gitter, Selenoid (Web, Android)
4
CI/CD
Gitlab-CI
5
Cloud-Plattformen
Google Cloud Platform
6
Besetzung
Kubernetes
7
Infrastruktur als Code (IaC)
Terraform, Ansible
Struktur jedes Abschnitts
Um die Erzählung klar zu halten, wird jeder Abschnitt gemäß der folgenden Gliederung beschrieben:
- kurze Beschreibung der Technologie,
- Mehrwert für die Automatisierungsinfrastruktur,
- Darstellung des aktuellen Zustands der Infrastruktur,
- Links zum Studium,
- ähnliche Werkzeuge.
1. Führen Sie Tests lokal durch
Kurze Beschreibung der Technologie
Dies ist nur ein vorbereitender Schritt, um die Demotests lokal auszuführen und zu überprüfen, ob sie erfolgreich sind. Im praktischen Teil wird Node.js verwendet, aber auch die Programmiersprache und die Plattform spielen keine Rolle und Sie können diejenigen verwenden, die in Ihrem Unternehmen verwendet werden.
Als Automatisierungstools empfehle ich jedoch die Verwendung von Selenium WebDriver für Webplattformen bzw. Appium für die Android-Plattform, da wir in den nächsten Schritten Docker-Images verwenden werden, die speziell auf die Arbeit mit diesen Tools zugeschnitten sind. Darüber hinaus sind diese Werkzeuge im Hinblick auf die Arbeitsanforderungen am gefragtesten auf dem Markt.
Wie Sie vielleicht bemerkt haben, berücksichtigen wir nur Web- und Android-Tests. Leider ist iOS eine ganz andere Geschichte (danke Apple). Ich habe vor, in den kommenden Teilen IOS-bezogene Lösungen und Praktiken vorzustellen.
Mehrwert für die Automatisierungsinfrastruktur
Aus Sicht der Infrastruktur bietet die lokale Ausführung keinen Mehrwert. Sie überprüfen lediglich, ob die Tests auf dem lokalen Computer in lokalen Browsern und Simulatoren ausgeführt werden. Aber auf jeden Fall ist dies ein notwendiger Ausgangspunkt.
Darstellung des aktuellen Zustands der Infrastruktur
Links zum Erkunden
Ähnliche Werkzeuge
- jede beliebige Programmiersprache in Verbindung mit Selenium/Appium-Tests;
- irgendwelche Tests;
- jeder Testläufer.
2. Versionskontrollsysteme (Git)
Kurze Beschreibung der Technologie
Es wird für niemanden eine große Offenbarung sein, wenn ich sage, dass die Versionskontrolle ein äußerst wichtiger Teil der Entwicklung ist, sowohl im Team als auch einzeln. Basierend auf verschiedenen Quellen kann man mit Sicherheit sagen, dass Git der beliebteste Vertreter ist. Ein Versionskontrollsystem bietet viele Vorteile, wie z. B. Code-Sharing, Speichern von Versionen, Wiederherstellen früherer Zweige, Überwachen des Projektverlaufs und Backups. Wir werden nicht auf jeden Punkt im Detail eingehen, da ich sicher bin, dass Sie damit bestens vertraut sind und es in Ihrer täglichen Arbeit nutzen. Sollte dies jedoch plötzlich nicht der Fall sein, empfehle ich, die Lektüre dieses Artikels zu unterbrechen und diese Lücke so schnell wie möglich zu schließen.
Mehrwert für die Automatisierungsinfrastruktur
Und hier können Sie eine vernünftige Frage stellen: „Warum erzählt er uns von Git?“ Jeder weiß das und nutzt es sowohl für Entwicklungscode als auch für Autotest-Code.“ Sie werden völlig Recht haben, aber in diesem Artikel sprechen wir über Infrastruktur und dieser Abschnitt dient als Vorschau auf Abschnitt 7: „Infrastruktur als Code (IaC)“. Für uns bedeutet dies, dass die gesamte Infrastruktur, einschließlich Tests, in Form von Code beschrieben wird, sodass wir auch darauf Versionierungssysteme anwenden können und ähnliche Vorteile wie bei Entwicklungs- und Automatisierungscode erzielen.
Wir werden uns IaC in Schritt 7 genauer ansehen, aber auch jetzt können Sie Git lokal verwenden, indem Sie ein lokales Repository erstellen. Das Gesamtbild wird erweitert, wenn wir der Infrastruktur ein Remote-Repository hinzufügen.
Darstellung des aktuellen Zustands der Infrastruktur
Links zum Erkunden
Ähnliche Werkzeuge
3. Containerisierung (Docker)
Kurze Beschreibung der Technologie
Um zu zeigen, wie die Containerisierung die Spielregeln verändert hat, gehen wir ein paar Jahrzehnte zurück in die Vergangenheit. Damals kauften und nutzten die Menschen Servermaschinen, um Anwendungen auszuführen. In den meisten Fällen waren die erforderlichen Startressourcen jedoch nicht im Voraus bekannt. Infolgedessen gaben Unternehmen Geld für die Anschaffung teurer, leistungsstarker Server aus, ein Teil dieser Kapazität wurde jedoch nicht vollständig ausgenutzt.
Die nächste Evolutionsstufe waren virtuelle Maschinen (VMs), die das Problem der Geldverschwendung für ungenutzte Ressourcen lösten. Diese Technologie ermöglichte es, Anwendungen unabhängig voneinander auf demselben Server auszuführen und dabei völlig isolierten Speicherplatz zuzuweisen. Aber leider hat jede Technologie ihre Nachteile. Der Betrieb einer VM erfordert ein vollständiges Betriebssystem, das CPU, RAM, Speicher verbraucht und je nach Betriebssystem auch Lizenzkosten berücksichtigt werden muss. Diese Faktoren beeinträchtigen die Ladegeschwindigkeit und erschweren die Portabilität.
Und jetzt kommen wir zur Containerisierung. Diese Technologie löst erneut das vorherige Problem, 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 eingeführt. Damals wurde viel geforscht, entwickelt und versucht. Aber es war Docker, der diese Technologie adaptierte und sie der breiten Masse leicht zugänglich machte. Wenn wir heutzutage von Containern sprechen, meinen wir in den meisten Fällen Docker. Wenn wir von Docker-Containern sprechen, meinen wir Linux-Container. Wir können Windows- und macOS-Systeme zum Ausführen von Containern verwenden, aber es ist wichtig zu verstehen, dass in diesem Fall eine zusätzliche Ebene erscheint. Docker auf dem Mac führt beispielsweise Container im Hintergrund in einer schlanken Linux-VM aus. Wir werden auf dieses Thema zurückkommen, wenn wir über die Ausführung von Android-Emulatoren in Containern sprechen. Hier gibt es also eine sehr wichtige Nuance, die detaillierter besprochen werden muss.
Mehrwert für die Automatisierungsinfrastruktur
Wir haben herausgefunden, dass Containerisierung und Docker cool sind. Betrachten wir dies im Kontext der Automatisierung, denn jedes Werkzeug oder jede Technologie muss ein Problem lösen. Lassen Sie uns die offensichtlichen Probleme der Testautomatisierung im Kontext von UI-Tests skizzieren:
- eine große Anzahl von Abhängigkeiten bei der Installation von Selenium und insbesondere Appium;
- Kompatibilitätsprobleme zwischen Versionen von Browsern, Simulatoren und Treibern;
- Mangel an isoliertem Platz für Browser/Simulatoren, was besonders wichtig für die parallele Ausführung ist;
- schwierig zu verwalten und zu warten, wenn Sie 10, 50, 100 oder sogar 1000 Browser gleichzeitig ausführen müssen.
Aber da Selenium das beliebteste Automatisierungstool und Docker das beliebteste Containerisierungstool ist, sollte es nicht überraschen, dass jemand versucht hat, sie zu kombinieren, um ein leistungsstarkes Tool zur Lösung der oben genannten Probleme zu schaffen. Betrachten wir solche Lösungen genauer.
Selenium-Gitter im Docker
Dieses Tool ist das beliebteste in der Selenium-Welt, um mehrere Browser auf mehreren Computern auszuführen und sie von einem zentralen Hub aus zu verwalten. Um zu beginnen, müssen Sie mindestens zwei Teile registrieren: Hub und Knoten. Hub ist ein zentraler Knoten, der alle Anfragen von Tests empfängt und an die entsprechenden Knoten verteilt. Für jeden Node können wir eine spezifische Konfiguration konfigurieren, indem wir beispielsweise den gewünschten Browser und seine Version angeben. Allerdings müssen wir uns noch selbst um kompatible Browsertreiber kümmern und diese auf den gewünschten Nodes installieren. Aus diesem Grund wird Selenium Grid nicht in seiner reinen Form verwendet, es sei denn, wir müssen mit Browsern arbeiten, die nicht auf dem Linux-Betriebssystem installiert werden können. In allen anderen Fällen wäre die Verwendung von Docker-Images zum Ausführen von Selenium Grid Hub und Nodes eine äußerst flexible und korrekte Lösung. Dieser Ansatz vereinfacht die Knotenverwaltung erheblich, da wir das benötigte Image mit kompatiblen Versionen von Browsern und bereits installierten Treibern auswählen können.
Trotz negativer Kritiken zur Stabilität, insbesondere bei der parallelen Ausführung einer großen Anzahl von Knoten, ist Selenium Grid immer noch das beliebteste Tool zur parallelen Ausführung von Selenium-Tests. Es ist wichtig zu beachten, dass in Open Source ständig verschiedene Verbesserungen und Modifikationen dieses Tools erscheinen, die verschiedene Engpässe bekämpfen.
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 hierbei nicht um eine weitere Modifikation des Selenium-Gitters. Stattdessen erstellten die Entwickler eine völlig neue Version von Selenium Hub in Golang, die in Kombination mit leichtgewichtigen Docker-Images für verschiedene Browser Impulse für die Entwicklung der Testautomatisierung gab. Darüber hinaus müssen wir im Fall von Selenium Grid alle benötigten Browser und deren Versionen im Voraus ermitteln, was bei der Arbeit mit nur einem Browser kein Problem darstellt. Aber wenn es um mehrere unterstützte Browser geht, ist Selenoid dank seiner „Browser-on-Demand“-Funktion die Lösung Nummer eins. Wir müssen lediglich die erforderlichen Bilder im Voraus mit Browsern herunterladen und die Konfigurationsdatei aktualisieren, mit der Selenoid interagiert. Nachdem Selenoid eine Anfrage von den Tests erhält, startet es automatisch den gewünschten Container mit dem gewünschten Browser. Wenn der Test abgeschlossen ist, wird Selenoid den Container außer Betrieb nehmen und so Ressourcen für zukünftige Anfragen freigeben. Dieser Ansatz eliminiert das bekannte Problem der „Knotenverschlechterung“, das im Selenium-Grid häufig auftritt, vollständig.
Aber leider ist Selenoid immer noch kein Allheilmittel. Wir haben die Funktion „Browser auf Abruf“ erhalten, aber die Funktion „Ressourcen auf Abruf“ ist immer noch nicht verfügbar. Um Selenoid nutzen zu können, müssen wir es auf physischer Hardware oder auf einer VM bereitstellen, was bedeutet, dass wir im Voraus wissen müssen, wie viele Ressourcen zugewiesen werden müssen. Ich denke, das ist kein Problem für kleine Projekte, die 10, 20 oder sogar 30 Browser parallel ausführen. Was aber, wenn wir 100, 500, 1000 und mehr brauchen? Es macht keinen Sinn, ständig so viele Ressourcen zu warten und zu bezahlen. In den Abschnitten 5 und 6 dieses Artikels besprechen wir Lösungen, die eine Skalierung ermöglichen und so die Unternehmenskosten deutlich senken.
Selenoid für Android
Nach dem Erfolg von Selenoid als Web-Automatisierungstool wollten die Leute etwas Ähnliches für Android. Und es geschah – Selenoid wurde mit Android-Unterstützung veröffentlicht. Aus der Sicht eines Benutzers auf hoher Ebene ähnelt das Funktionsprinzip der Webautomatisierung. Der einzige Unterschied besteht darin, dass Selenoid anstelle von Browser-Containern Android-Emulator-Container ausführt. Meiner Meinung nach ist dies derzeit das leistungsstärkste kostenlose Tool zum parallelen Ausführen von Android-Tests.
Ich möchte wirklich nicht über die negativen Aspekte dieses Tools sprechen, da es mir wirklich sehr gut gefällt. Dennoch gibt es die gleichen Nachteile, die auch für die Webautomatisierung gelten und mit der Skalierung verbunden sind. Darüber hinaus müssen wir über eine weitere Einschränkung sprechen, die uns überraschen könnte, wenn wir das Tool zum ersten Mal einrichten. Um Android-Images auszuführen, benötigen wir eine physische Maschine oder VM mit Unterstützung für verschachtelte Virtualisierung. In der Anleitung zeige ich, wie man dies auf einer Linux-VM aktiviert. Wenn Sie jedoch ein macOS-Benutzer sind und Selenoid lokal bereitstellen möchten, ist die Ausführung von Android-Tests nicht möglich. Sie können jedoch jederzeit eine Linux-VM lokal mit konfigurierter „verschachtelter Virtualisierung“ ausführen und Selenoid darin bereitstellen.
Darstellung des aktuellen Zustands der Infrastruktur
Im Rahmen dieses Artikels werden wir zwei Tools hinzufügen, um die Infrastruktur zu veranschaulichen. Dies sind Selenium Grid für Webtests und Selenoid für Android-Tests. Im GitHub-Tutorial zeige ich Ihnen auch, wie Sie Selenoid zum Ausführen von Webtests verwenden.
Links zum Erkunden
Ähnliche Werkzeuge
- Es gibt andere Containerisierungstools, aber Docker ist das beliebteste. Wenn Sie etwas anderes ausprobieren möchten, bedenken Sie, dass die von uns behandelten Tools zum parallelen Ausführen von Selenium-Tests nicht sofort funktionieren.
- Wie bereits erwähnt, gibt es viele Modifikationen des Selenium-Gitters, zum Beispiel:.
4.CI/CD
Kurze Beschreibung der Technologie
Die Praxis der kontinuierlichen Integration erfreut sich in der Entwicklung großer Beliebtheit und ist mit Versionskontrollsystemen vergleichbar. Dennoch habe ich das Gefühl, dass die Terminologie verwirrend ist. In diesem Absatz möchte ich aus meiner Sicht 3 Modifikationen dieser Technologie beschreiben. Im Internet finden Sie viele Artikel mit unterschiedlichen Interpretationen und es ist völlig normal, wenn Sie anderer Meinung sind. Das Wichtigste ist, dass Sie mit Ihren Kollegen auf einer Wellenlänge sind.
Es gibt also drei Begriffe: CI – Continuous Integration, CD – Continuous Delivery und wiederum CD – Continuous Deployment. (Im Folgenden werde ich diese Begriffe auf Englisch verwenden). Jede Änderung fügt Ihrer Entwicklungspipeline mehrere zusätzliche Schritte hinzu. Aber das Wort kontinuierlich (kontinuierlich) ist das Wichtigste. In diesem Zusammenhang meinen wir etwas, das von Anfang bis Ende ohne Unterbrechung oder manuellen Eingriff geschieht. Schauen wir uns in diesem Zusammenhang CI & CD und CD an.
- Kontinuierliche Integration Dies ist der erste Schritt der Evolution. Nachdem wir neuen Code an den Server übermittelt haben, erwarten wir eine schnelle Rückmeldung, dass unsere Änderungen in Ordnung sind. Typischerweise umfasst CI die Ausführung statischer Code-Analysetools und Unit-/interner API-Tests. Dadurch können wir innerhalb weniger Sekunden/Minuten Informationen über unseren Code erhalten.
- Kontinuierliche Liefer ist ein fortgeschrittenerer Schritt, bei dem wir Integrations-/UI-Tests durchführen. Allerdings erzielen wir in diesem Stadium nicht so schnell Ergebnisse wie mit CI. Erstens dauert die Durchführung dieser Art von Tests länger. Zweitens müssen wir vor dem Start unsere Änderungen in der Test-/Staging-Umgebung bereitstellen. Wenn wir darüber hinaus über mobile Entwicklung sprechen, besteht ein zusätzlicher Schritt darin, einen Build unserer Anwendung zu erstellen.
- Continuous Deployment geht davon aus, dass wir unsere Änderungen automatisch für die Produktion freigeben, wenn alle Abnahmetests in den vorherigen Phasen bestanden wurden. Darüber hinaus können Sie nach der Veröffentlichungsphase verschiedene Phasen konfigurieren, z. B. die Durchführung von Smoke-Tests in der Produktion und die Erfassung relevanter Metriken. Continuous Deployment ist nur mit einer guten Abdeckung durch automatisierte Tests möglich. Wenn manuelle Eingriffe erforderlich sind, einschließlich Tests, ist dies nicht mehr der Fall Kontinuierlich (kontinuierlich). Dann können wir sagen, dass unsere Pipeline nur der Praxis der kontinuierlichen Lieferung entspricht.
Mehrwert für die Automatisierungsinfrastruktur
In diesem Abschnitt sollte ich klarstellen, dass wenn wir über End-to-End-UI-Tests sprechen, dies bedeutet, dass wir unsere Änderungen und zugehörigen Dienste in Testumgebungen bereitstellen sollten. Kontinuierliche Integration – der Prozess ist für diese Aufgabe nicht anwendbar und wir müssen uns um die Implementierung mindestens von Continuous Deliver-Praktiken kümmern. Continuous Deployment macht auch im Kontext von UI-Tests Sinn, wenn wir diese in der Produktion ausführen wollen.
Und bevor wir uns die Veranschaulichung der Architekturänderung ansehen, möchte ich ein paar Worte zu GitLab CI sagen. Im Gegensatz zu anderen CI/CD-Tools bietet GitLab ein Remote-Repository und viele andere zusätzliche Funktionen. GitLab ist also mehr als CI. Es umfasst Quellcodeverwaltung, Agile-Management, CI/CD-Pipelines, Protokollierungstools und die Sammlung von Metriken sofort einsatzbereit. Die GitLab-Architektur besteht aus Gitlab CI/CD und GitLab Runner. Hier ist eine kurze Beschreibung von der offiziellen Website:
Gitlab CI/CD ist eine Webanwendung mit einer API, die ihren Status in einer Datenbank speichert, Projekte/Builds verwaltet und eine Benutzeroberfläche bereitstellt. GitLab Runner ist eine Anwendung, die Builds verarbeitet. Es kann separat bereitgestellt werden und funktioniert über eine API mit GitLab CI/CD. Für die Ausführung von Tests benötigen Sie sowohl die Gitlab-Instanz als auch den Runner.
Darstellung des aktuellen Zustands der Infrastruktur
Links zum Erkunden
Ähnliche Werkzeuge
- Und viele andere
5. Cloud-Plattformen
Kurze Beschreibung der Technologie
In diesem Abschnitt werden wir über einen beliebten Trend namens „Public Clouds“ sprechen. Trotz der enormen Vorteile, die die oben beschriebenen Virtualisierungs- und Containerisierungstechnologien bieten, benötigen wir immer noch Rechenressourcen. Unternehmen kaufen teure Server oder mieten Rechenzentren. In diesem Fall müssen jedoch (manchmal unrealistische) Berechnungen angestellt werden, wie viele Ressourcen wir benötigen, ob wir sie rund um die Uhr nutzen und für welche Zwecke. Für die Produktion ist beispielsweise ein Server erforderlich, der rund um die Uhr läuft. Aber benötigen wir ähnliche Ressourcen für Tests außerhalb der Arbeitszeit? Es hängt auch von der Art der durchgeführten Tests ab. Ein Beispiel wären Belastungs-/Stresstests, die wir außerhalb der Arbeitszeit durchführen möchten, um am nächsten Tag Ergebnisse zu erhalten. Für durchgängig automatisierte Tests und insbesondere nicht für manuelle Testumgebungen ist eine Serververfügbarkeit rund um die Uhr jedoch definitiv nicht erforderlich. In solchen Situationen wäre es sinnvoll, sich bei Bedarf so viele Ressourcen wie nötig zu besorgen, sie zu nutzen und mit der Zahlung aufzuhören, 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. Schauen wir uns die Definition an:
„Unter der Public Cloud versteht man Rechendienste, die von Drittanbietern über das öffentliche Internet angeboten werden und sie jedem zur Verfügung stellen, der sie nutzen oder erwerben möchte. Sie können kostenlos sein oder auf Abruf verkauft werden, sodass Kunden nur pro Nutzung für die von ihnen verbrauchten CPU-Zyklen, Speicher oder Bandbreite zahlen müssen.“
Es gibt die Meinung, dass öffentliche Clouds teuer sind. Ihre Kernidee besteht jedoch darin, die Unternehmenskosten zu senken. Wie bereits erwähnt, ermöglichen Ihnen öffentliche Clouds den Bezug von Ressourcen nach Bedarf und zahlen nur für die Zeit, die Sie sie nutzen. Manchmal vergessen wir auch, dass Mitarbeiter Gehälter erhalten und auch Spezialisten eine teure Ressource sind. Es muss berücksichtigt werden, dass öffentliche Clouds die Infrastrukturunterstützung erheblich erleichtern, sodass sich Ingenieure auf wichtigere Aufgaben konzentrieren können.
Mehrwert für die Automatisierungsinfrastruktur
Welche spezifischen Ressourcen benötigen wir für End-to-End-UI-Tests? Im Grunde handelt es sich hierbei um virtuelle Maschinen oder Cluster (wir werden im nächsten Abschnitt über Kubernetes sprechen) zum Ausführen von Browsern und Emulatoren. Je mehr Browser und Emulatoren wir gleichzeitig ausführen möchten, desto mehr CPU und Speicher werden benötigt und desto mehr Geld müssen wir dafür bezahlen. Somit ermöglichen uns öffentliche Clouds im Kontext der Testautomatisierung, eine große Anzahl (100, 200, 1000...) von Browsern/Emulatoren bei Bedarf auszuführen, Testergebnisse so schnell wie möglich zu erhalten und nicht mehr für solch wahnsinnig ressourcenintensive Tests zu zahlen Leistung.
Die beliebtesten Cloud-Anbieter sind Amazon Web Services (AWS), Microsoft Azure und Google Cloud Platform (GCP). Die Anleitung enthält Beispiele für die Verwendung von GCP. Im Allgemeinen spielt es jedoch keine Rolle, was Sie für Automatisierungsaufgaben verwenden. Sie bieten alle ungefähr die gleiche Funktionalität. Normalerweise konzentriert sich das Management bei der Auswahl eines Anbieters auf die gesamte Infrastruktur und die Geschäftsanforderungen des Unternehmens, was den Rahmen dieses Artikels sprengen würde. Für Automatisierungsingenieure wird es interessanter sein, die Nutzung von Cloud-Anbietern mit der Nutzung von Cloud-Plattformen speziell für Testzwecke wie Sauce Labs, BrowserStack, BitBar usw. zu vergleichen. Also lasst es uns auch tun! Meiner Meinung nach ist Sauce Labs die bekannteste Cloud-Testfarm, weshalb ich sie zum Vergleich herangezogen habe.
GCP vs. Sauce Labs für Automatisierungszwecke:
Stellen wir uns vor, dass wir 8 Webtests und 8 Android-Tests gleichzeitig ausführen müssen. Dazu werden wir GCP verwenden und 2 virtuelle Maschinen mit Selenoid betreiben. Im ersten Fall werden wir 8 Container mit Browsern erstellen. Auf der zweiten befinden sich 8 Container mit Emulatoren. Werfen wir einen Blick auf die Preise:
Um einen Container mit Chrome auszuführen, benötigen wir n1-Standard-1 Auto. Im Fall von Android wird es so sein n1-Standard-4 für einen Emulator. Tatsächlich ist es eine flexiblere und kostengünstigere Möglichkeit, spezifische Benutzerwerte für CPU/Speicher festzulegen, aber im Moment ist dies für den Vergleich mit Sauce Labs nicht wichtig.
Und hier sind die Tarife für die Nutzung von Sauce Labs:
Ich glaube, Sie haben den Unterschied bereits bemerkt, aber ich werde trotzdem eine Tabelle mit Berechnungen für unsere Aufgabe bereitstellen:
Benötigte Ressourcen
Monatlich
Arbeitszeit(8:8 - XNUMX:XNUMX Uhr)
Arbeitszeit+Präventiv
GCP für Web
n1-Standard-1 x 8 = n1-Standard-8
$194.18
23 Tage * 12 Stunden * 0.38 = 104.88 $
23 Tage * 12 Stunden * 0.08 = 22.08 $
Sauce Labs für das Web
Virtuelle Cloud8-Paralleltests
$1.559
-
-
GCP für Android
n1-Standard-4 x 8: n1-Standard-16
$776.72
23 Tage * 12 Stunden * 1.52 = 419.52 $
23 Tage * 12 Stunden * 0.32 = 88.32 $
Sauce Labs für Android
Real Device Cloud 8 Paralleltests
$1.999
-
-
Wie Sie sehen, ist der Kostenunterschied enorm, insbesondere wenn Sie Tests nur während eines zwölfstündigen Arbeitszeitraums durchführen. Sie können die Kosten jedoch noch weiter senken, wenn Sie präemptive Maschinen verwenden. Was ist es?
Eine präemptive VM ist eine Instanz, die Sie zu einem viel günstigeren Preis als normale Instanzen erstellen und ausführen können. Compute Engine beendet diese Instanzen jedoch möglicherweise (preempt), wenn für andere Aufgaben Zugriff auf diese Ressourcen erforderlich ist. Bei präemptiven Instanzen handelt es sich um überschüssige Compute Engine-Kapazität, sodass ihre Verfügbarkeit je nach Nutzung variiert.
Wenn Ihre Apps fehlertolerant sind und möglichen Instanzpräemptionen standhalten können, können präemptive Instanzen Ihre Compute Engine-Kosten erheblich senken. Beispielsweise können Stapelverarbeitungsjobs auf präemptiven Instanzen ausgeführt werden. Wenn einige dieser Instanzen während der Verarbeitung beendet werden, verlangsamt sich der Job, wird aber nicht vollständig gestoppt. Präemptive Instanzen erledigen Ihre Stapelverarbeitungsaufgaben, ohne Ihre vorhandenen Instanzen zusätzlich zu belasten und ohne dass Sie den vollen Preis für zusätzliche normale Instanzen zahlen müssen.
Und es ist immer noch nicht vorbei! Tatsächlich bin ich mir sicher, dass niemand 12 Stunden lang ohne Pause Tests durchführt. Und wenn ja, dann 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 reduziert werden. Dann sinkt die Zahlung im Rahmen unserer Aufgabe für 11 Browser auf 8 $ pro Monat. Ist das nicht wunderbar? Aber bei präemptiven Maschinen müssen wir vorsichtig sein und auf Unterbrechungen und Instabilität vorbereitet sein, obwohl diese Situationen in der Software berücksichtigt und gehandhabt werden können. Das ist es wert!
Aber ich sage keineswegs: „Verwenden Sie niemals Cloud-Testfarmen“. Sie haben eine Reihe von Vorteilen. Erstens handelt es sich hierbei nicht nur um eine virtuelle Maschine, sondern um eine vollwertige Testautomatisierungslösung mit einer Reihe sofort einsatzbereiter Funktionen: Fernzugriff, Protokolle, Screenshots, Videoaufzeichnung, verschiedene Browser und physische Mobilgeräte. In vielen Situationen kann dies eine unverzichtbare, schicke Alternative sein. Testplattformen sind besonders nützlich für die IOS-Automatisierung, wenn öffentliche Clouds nur Linux/Windows-Systeme anbieten können. Aber wir werden in den folgenden Artikeln über iOS sprechen. Ich empfehle, immer die Situation zu betrachten und von den Aufgaben auszugehen: In manchen Fällen ist es günstiger und effizienter, Public Clouds zu nutzen, in anderen Fällen sind die Testplattformen das ausgegebene Geld auf jeden Fall wert.
Darstellung des aktuellen Zustands der Infrastruktur
Links zum Erkunden
Ähnliche Tools:
6. Orchestrierung
Kurze Beschreibung der Technologie
Ich habe gute Neuigkeiten – wir sind fast am Ende des Artikels angelangt! Derzeit besteht unsere Automatisierungsinfrastruktur aus Web- und Android-Tests, die wir parallel über GitLab CI ausführen und dabei Docker-fähige Tools verwenden: Selenium Grid und Selenoid. Darüber hinaus nutzen wir über GCP erstellte virtuelle Maschinen, um Container mit Browsern und Emulatoren zu hosten. Um die Kosten zu senken, starten wir diese virtuellen Maschinen nur bei Bedarf und stoppen sie, wenn keine Tests durchgeführt werden. Gibt es noch etwas, das unsere Infrastruktur verbessern kann? Die Antwort ist ja! Lernen Sie Kubernetes (K8s) kennen!
Schauen wir uns zunächst an, wie die Wörter Orchestrierung, Cluster und Kubernetes miteinander zusammenhängen. Auf hoher Ebene ist Orchestrierung das System, das Anwendungen bereitstellt und verwaltet. Für die Testautomatisierung sind solche Containeranwendungen Selenium Grid und Selenoid. Docker und K8s ergänzen sich. Der erste wird für die Anwendungsbereitstellung verwendet, der zweite für die Orchestrierung. K8s wiederum ist ein Cluster. Die Aufgabe des Clusters besteht darin, VMs als Knoten zu nutzen, wodurch Sie verschiedene Funktionen, Programme und Dienste innerhalb eines Servers (Clusters) installieren können. Wenn einer der Knoten ausfällt, werden andere Knoten den Betrieb aufnehmen, was den unterbrechungsfreien Betrieb unserer Anwendung gewährleistet. Darüber hinaus verfügt K8s über wichtige Funktionen im Zusammenhang mit der Skalierung, dank derer wir automatisch die optimale Menge an Ressourcen basierend auf der Auslastung und den festgelegten Grenzwerten erhalten.
Tatsächlich ist die manuelle Bereitstellung von Kubernetes von Grund auf keine triviale Aufgabe. Ich hinterlasse einen Link zur berühmten Anleitung „Kubernetes The Hard Way“, und wenn Sie interessiert sind, können Sie es üben. Aber zum Glück gibt es alternative Methoden und Werkzeuge. Der einfachste Weg ist die Verwendung von Google Kubernetes Engine (GKE) in GCP, wodurch Sie mit wenigen Klicks einen fertigen Cluster erhalten. Ich empfehle, diesen Ansatz zu Beginn des Lernens zu verwenden, da Sie sich so darauf konzentrieren können, zu lernen, wie Sie die K8s für Ihre Aufgaben verwenden, anstatt zu lernen, wie die internen Komponenten miteinander integriert werden sollten.
Mehrwert für die Automatisierungsinfrastruktur
Werfen wir einen Blick auf einige wichtige Funktionen des K8s:
- Anwendungsbereitstellung: Verwendung eines Clusters mit mehreren Knoten anstelle von VMs;
- dynamische Skalierung: Reduziert die Kosten für Ressourcen, die nur bei Bedarf verwendet werden;
- Selbstheilung: automatische Wiederherstellung von Pods (wodurch auch Container wiederhergestellt werden);
- Rollout von Updates und Rollback von Änderungen ohne Ausfallzeiten: Die Aktualisierung von Tools, Browsern und Emulatoren unterbricht die Arbeit aktueller Benutzer nicht
Aber der K8s ist immer noch kein Allheilmittel. Um alle Vorteile und Einschränkungen im Zusammenhang mit den von uns betrachteten Werkzeugen (Selengitter, Selenoid) zu verstehen, werden wir kurz die Struktur von K8s diskutieren. Der Cluster enthält zwei Arten von Knoten: Master-Knoten und Worker-Knoten. Masterknoten sind für Management-, Bereitstellungs- und Planungsentscheidungen verantwortlich. Auf Worker-Knoten werden Anwendungen gestartet. Knoten enthalten auch eine Container-Laufzeitumgebung. In unserem Fall ist dies Docker, der für Container-bezogene Vorgänge zuständig ist. Es gibt aber beispielsweise auch alternative Lösungen. Es ist wichtig zu verstehen, dass Skalierung oder Selbstheilung nicht direkt für Container gilt. Dies wird durch Hinzufügen/Verringern der Anzahl von Pods umgesetzt, die wiederum Container enthalten (normalerweise ein Container pro Pod, aber je nach Aufgabe können es auch mehr sein). Die übergeordnete Hierarchie besteht aus Worker-Knoten, in denen sich Pods befinden, in denen Container angehoben werden.
Die Skalierungsfunktion ist von entscheidender Bedeutung und kann sowohl auf Knoten innerhalb eines Cluster-Knotenpools als auch auf Pods innerhalb eines Knotens angewendet werden. Es gibt zwei Arten der Skalierung, die sowohl für Knoten als auch für Pods gelten. Der erste Typ ist horizontal – die Skalierung erfolgt durch Erhöhung der Anzahl der Knoten/Pods. Dieser Typ ist vorzuziehen. Der zweite Typ ist dementsprechend vertikal. Die Skalierung erfolgt durch Erhöhen der Größe der Knoten/Pods und nicht durch deren Anzahl.
Schauen wir uns nun unsere Tools im Kontext der oben genannten Begriffe an.
Selengitter
Wie bereits erwähnt, ist Selenium Grid ein sehr beliebtes Tool und es ist keine Überraschung, dass es in Containern zusammengefasst wurde. Daher ist es nicht verwunderlich, dass das Selenium-Gitter in K8s eingesetzt werden kann. Ein Beispiel dafür finden Sie im offiziellen K8s-Repository. Wie üblich füge ich am Ende des Abschnitts Links hinzu. Darüber hinaus zeigt die Anleitung, wie man dies in Terraform macht. Es gibt auch Anweisungen zum Skalieren der Anzahl der Pods, die Browser-Container enthalten. Aber die automatische Skalierungsfunktion im Kontext von K8s ist immer noch keine völlig selbstverständliche Aufgabe. Als ich mit dem Studium begann, fand ich keine praktischen Anleitungen oder Empfehlungen. Nach mehreren Studien und Experimenten mit Unterstützung des DevOps-Teams haben wir uns für den Ansatz entschieden, Container mit den erforderlichen Browsern in einem Pod zu erstellen, der sich innerhalb eines Worker-Knotens befindet. Mit dieser Methode können wir die Strategie der horizontalen Skalierung von Knoten anwenden, indem wir deren Anzahl erhöhen. Ich hoffe, dass sich dies in Zukunft ändern wird und wir insbesondere nach der Veröffentlichung von Selenium Grid 4 mit geänderter interner Architektur immer mehr Beschreibungen besserer Ansätze und fertiger Lösungen sehen werden.
Selenoid:
Der Selenoid-Einsatz in K8 ist derzeit die größte Enttäuschung. Sie sind nicht kompatibel. Theoretisch können wir einen Selenoid-Container in einem Pod erstellen, aber wenn Selenoid beginnt, Container mit Browsern zu starten, befinden sie sich immer noch im selben Pod. Dies macht eine Skalierung unmöglich und die Arbeit von Selenoid innerhalb eines Clusters unterscheidet sich daher nicht von der Arbeit innerhalb einer virtuellen Maschine. Ende der Geschichte.
Mond:
Da die Entwickler diesen Engpass bei der Arbeit mit Selenoid kannten, veröffentlichten sie ein leistungsfähigeres Tool namens Moon. Dieses Tool wurde ursprünglich für die Zusammenarbeit mit Kubernetes entwickelt und daher kann und sollte die Autoscaling-Funktion verwendet werden. Darüber hinaus würde ich sagen, dass es im Moment so ist lediglich ein Tool in der Selenium-Welt, das standardmäßig native K8s-Cluster-Unterstützung bietet (nicht mehr verfügbar, siehe nächstes Tool ). Die Hauptfunktionen von Moon, die diese Unterstützung bieten, sind:
Völlig staatenlos. Selenoid speichert im Speicher Informationen über aktuell laufende Browsersitzungen. Wenn der Prozess aus irgendeinem Grund abstürzt, gehen alle laufenden Sitzungen verloren. Im Gegensatz dazu hat Moon keinen internen Status und kann über mehrere Rechenzentren hinweg repliziert werden. Browsersitzungen bleiben auch dann aktiv, wenn ein oder mehrere Replikate ausfallen.
Moon ist also eine großartige Lösung, aber es gibt ein Problem: Es ist nicht kostenlos. Der Preis richtet sich nach der Anzahl der Sitzungen. Sie können nur 0–4 Sitzungen kostenlos durchführen, was nicht besonders nützlich ist. Ab der fünften Sitzung müssen Sie jedoch jeweils 5 US-Dollar bezahlen. Die Situation kann von Unternehmen zu Unternehmen unterschiedlich sein, aber in unserem Fall ist die Verwendung von Moon sinnlos. Wie ich oben beschrieben habe, können wir VMs mit Selenium Grid bei Bedarf ausführen oder die Anzahl der Knoten im Cluster erhöhen. Für etwa eine Pipeline starten wir 500 Browser und stoppen alle Ressourcen, nachdem die Tests abgeschlossen sind. Wenn wir Moon verwenden würden, müssten wir zusätzlich 500 x 5 = 2500 $ pro Monat zahlen, egal wie oft wir Tests durchführen. Auch hier sage ich nicht, dass Sie Moon nicht verwenden sollten. Für Ihre Aufgaben kann dies eine unverzichtbare Lösung sein, wenn Sie beispielsweise viele Projekte/Teams in Ihrer Organisation haben und einen riesigen gemeinsamen Cluster für alle benötigen. Wie immer hinterlasse ich am Ende einen Link und empfehle, alle notwendigen Berechnungen im Kontext Ihrer Aufgabe durchzuführen.
Callisto: (Aufmerksamkeit! Dies steht nicht im Originalartikel und ist nur in der russischen Übersetzung enthalten)
Wie gesagt, Selenium ist ein sehr beliebtes Tool und der IT-Bereich entwickelt sich sehr schnell. Während ich an der Übersetzung arbeitete, tauchte im Internet ein neues vielversprechendes Tool namens Callisto auf (Hallo Cypress und andere Selenium-Killer). Es funktioniert nativ mit K8s und ermöglicht die Ausführung von Selenoid-Containern in Pods, die über Knoten verteilt sind. Alles funktioniert sofort nach dem Auspacken, einschließlich der automatischen Skalierung. Fantastisch, muss aber getestet werden. Es ist mir bereits gelungen, dieses Tool einzusetzen und mehrere Experimente durchzuführen. Aber es ist noch zu früh, um Schlussfolgerungen zu ziehen, nachdem ich über längere Zeit Ergebnisse erhalten habe, werde ich vielleicht in zukünftigen Artikeln eine Rezension verfassen. Im Moment hinterlasse ich nur Links für unabhängige Recherchen.
Darstellung des aktuellen Zustands der Infrastruktur
Links zum Erkunden
Ähnliche Werkzeuge
7. Infrastruktur als Code (IaC)
Kurze Beschreibung der Technologie
Und jetzt kommen wir zum letzten Abschnitt. Typischerweise liegen diese Technologie und damit verbundene Aufgaben nicht in der Verantwortung von Automatisierungsingenieuren. Und dafür gibt es Gründe. Erstens unterliegen Infrastrukturprobleme in vielen Organisationen der Kontrolle der DevOps-Abteilung und die Entwicklungsteams kümmern sich nicht wirklich darum, was die Pipeline zum Funktionieren bringt und wie alles, was damit zusammenhängt, unterstützt werden muss. Zweitens: Seien wir ehrlich, die Praxis von Infrastructure as Code (IaC) wird in vielen Unternehmen immer noch nicht übernommen. Aber es ist definitiv ein beliebter Trend geworden und es ist wichtig, sich an den damit verbundenen Prozessen, Ansätzen und Tools zu beteiligen. Oder bleiben Sie zumindest auf dem Laufenden.
Beginnen wir mit der Motivation für die Verwendung dieses Ansatzes. Wir haben bereits besprochen, dass wir zum Ausführen von Tests in GitlabCI mindestens die Ressourcen benötigen, um Gitlab Runner auszuführen. Und um Container mit Browsern/Emulatoren auszuführen, müssen wir eine VM oder einen Cluster reservieren. Zusätzlich zu den Testressourcen benötigen wir eine erhebliche Menge an Kapazität zur Unterstützung von Entwicklungs-, Staging- und Produktionsumgebungen, einschließlich Datenbanken, automatischen Zeitplänen, Netzwerkkonfigurationen, Lastausgleichsfunktionen, Benutzerrechten usw. Das Hauptproblem ist der Aufwand, der erforderlich ist, um alles zu unterstützen. Es gibt verschiedene Möglichkeiten, wie wir Änderungen vornehmen und Updates einführen können. Im Kontext von GCP können wir beispielsweise die UI-Konsole im Browser verwenden und alle Aktionen durch Klicken auf Schaltflächen ausführen. Eine Alternative wäre die Verwendung von API-Aufrufen zur Interaktion mit Cloud-Entitäten oder die Verwendung des gcloud-Befehlszeilendienstprogramms zur Durchführung der gewünschten Manipulationen. Aber bei einer wirklich großen Anzahl unterschiedlicher Einheiten und Infrastrukturelemente wird es schwierig oder sogar unmöglich, alle Vorgänge manuell durchzuführen. Darüber hinaus sind alle diese manuellen Aktionen unkontrollierbar. Wir können sie nicht vor der Ausführung zur Überprüfung einreichen, kein Versionskontrollsystem verwenden und die Änderungen, die zu dem Vorfall geführt haben, nicht schnell rückgängig machen. Um solche Probleme zu lösen, erstellten und erstellen Ingenieure automatische Bash/Shell-Skripte, die nicht viel besser sind als frühere Methoden, da sie nicht so einfach schnell zu lesen, zu verstehen, zu warten und in einem prozeduralen Stil zu ändern sind.
In diesem Artikel und dieser Anleitung verwende ich zwei Tools im Zusammenhang mit der IaC-Praxis. Dies sind Terraform und Ansible. Manche Leute glauben, dass es keinen Sinn macht, sie gleichzeitig zu verwenden, da ihre Funktionalität ähnlich und sie austauschbar sind. Fakt ist aber, dass ihnen zunächst ganz andere Aufgaben übertragen werden. Und dass sich diese Tools gegenseitig ergänzen sollten, wurde bei einer gemeinsamen Präsentation von Entwicklern von HashiCorp und RedHat bestätigt. Der konzeptionelle Unterschied besteht darin, dass Terraform ein Bereitstellungstool zur Verwaltung der Server selbst ist. Während Ansible ein Konfigurationsmanagement-Tool ist, dessen Aufgabe darin besteht, Software auf diesen Servern zu installieren, zu konfigurieren und zu verwalten.
Ein weiteres wesentliches Unterscheidungsmerkmal dieser Tools ist der Codierungsstil. Im Gegensatz zu Bash und Ansible verwendet Terraform einen deklarativen Stil, der auf einer Beschreibung des gewünschten Endzustands basiert, der als Ergebnis der Ausführung erreicht werden soll. Wenn wir beispielsweise 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 weiß davon, weil es den aktuellen Status der Infrastruktur in einer Statusdatei speichert. Aber Ansible verwendet einen prozeduralen Ansatz und wenn Sie es auffordern, 10 VMs zu erstellen, erhalten wir beim ersten Start 10 VMs, ähnlich wie bei Terraform. Aber nach dem Neustart werden wir bereits 20 VMs haben. Das ist der wichtige Unterschied. Im prozeduralen Stil speichern wir nicht den aktuellen Zustand und beschreiben lediglich eine Abfolge von Schritten, die ausgeführt werden müssen. Natürlich können wir mit verschiedenen Situationen umgehen und mehrere Prüfungen auf das Vorhandensein von Ressourcen und den aktuellen Status hinzufügen, aber es macht keinen Sinn, unsere Zeit zu verschwenden und Mühe darauf zu verwenden, diese Logik zu kontrollieren. Darüber hinaus erhöht sich dadurch das Risiko, Fehler zu machen.
Wenn wir alle oben genannten Punkte zusammenfassen, können wir zu dem Schluss kommen, dass Terraform und die deklarative Notation ein geeigneteres Werkzeug für die Bereitstellung von Servern sind. Es ist jedoch besser, die Arbeit des Konfigurationsmanagements an Ansible zu delegieren. Nachdem dies geklärt ist, schauen wir uns Anwendungsfälle im Kontext der Automatisierung an.
Mehrwert für die Automatisierungsinfrastruktur
Wichtig ist hier nur zu verstehen, dass die Testautomatisierungsinfrastruktur als Teil der gesamten Unternehmensinfrastruktur betrachtet werden sollte. Das bedeutet, dass alle IaC-Praktiken global auf die Ressourcen der gesamten Organisation angewendet werden müssen. Wer hierfür verantwortlich ist, hängt von Ihren Prozessen ab. Das DevOps-Team hat mehr Erfahrung mit diesen Problemen und sieht das Gesamtbild dessen, was passiert. QS-Ingenieure sind jedoch stärker in den Prozess der Gebäudeautomation und die Struktur der Pipeline involviert, wodurch sie alle erforderlichen Änderungen und Verbesserungsmöglichkeiten besser erkennen können. Die beste Option besteht darin, zusammenzuarbeiten, Wissen und Ideen auszutauschen, um das erwartete Ergebnis zu erzielen.
Hier sind einige Beispiele für die Verwendung von Terraform und Ansible im Kontext der Testautomatisierung und der zuvor besprochenen Tools:
1. Beschreiben Sie die notwendigen Eigenschaften und Parameter von VMs und Clustern mit Terraform.
2. Installieren Sie mit Ansible die zum Testen erforderlichen Tools: Docker, Selenoid, Selenium Grid und laden Sie die erforderlichen Versionen von Browsern/Emulatoren herunter.
3. Beschreiben Sie mithilfe von Terraform die Eigenschaften der VM, in der GitLab Runner gestartet wird.
4. Installieren Sie GitLab Runner und die notwendigen Begleittools mit Ansible, legen Sie Einstellungen und Konfigurationen fest.
Darstellung des aktuellen Zustands der Infrastruktur
Links zum Erkunden:
Ähnliche Werkzeuge
Fassen wir es zusammen!
Schritt
Technologie
Tools
Mehrwert für die Automatisierungsinfrastruktur
1
Lokales Laufen
Node.js, Selenium, Appium
- Die beliebtesten Tools für Web und Mobilgeräte
- Unterstützt viele Sprachen und Plattformen (einschließlich Node.js)
2
Versionskontrollsysteme
Git
- Ähnliche Vorteile mit Entwicklungscode
3
Containerisierung
Docker, Selenium-Gitter, Selenoid (Web, Android)
- Parallele Durchführung von Tests
- Isolierte Umgebungen
- Einfache, flexible Versions-Upgrades
- Dynamisches Stoppen ungenutzter Ressourcen
- Einfach einzurichten
4
CI/CD
Gitlab-CI
- Testet einen Teil der Pipeline
- Schnelles Feedback
- Sichtbarkeit für das gesamte Unternehmen/Team
5
Cloud-Plattformen
Google Cloud Platform
- Ressourcen auf Abruf (wir zahlen nur bei Bedarf)
- Einfach zu verwalten und zu aktualisieren
- Sichtbarkeit und Kontrolle aller Ressourcen
6
Besetzung
Kubernetes
Im Zusammenhang mit Containern mit Browsern/Emulatoren in Pods:
- Skalierung/Autoskalierung
- Selbstheilung
- Updates und Rollbacks ohne Unterbrechung
7
Infrastruktur als Code (IaC)
Terraform, Ansible
- Ähnliche Vorteile mit der Entwicklungsinfrastruktur
- Alle Vorteile der Codeversionierung
- Einfache Änderungen und Wartung
- Vollautomatisch
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 kommt als nächstes?
Das ist also das Ende des Artikels. Abschließend möchte ich jedoch einige Vereinbarungen mit Ihnen treffen.
Von deiner Seite
Wie ich eingangs sagte, möchte ich, dass der Artikel einen praktischen Nutzen hat und Ihnen hilft, die gewonnenen Erkenntnisse in der Praxis anzuwenden. Ich füge noch einmal hinzu.
Aber hören Sie auch danach nicht auf, üben Sie, studieren Sie relevante Links und Bücher, finden Sie heraus, wie es in Ihrem Unternehmen funktioniert, finden Sie Orte, die verbessert werden können, und beteiligen Sie sich daran. Viel Glück!
Von meiner Seite aus
Anhand des Titels kann man erkennen, dass dies nur der erste Teil war. Trotz der Tatsache, dass es recht umfangreich ausgefallen ist, werden wichtige Themen hier immer noch nicht behandelt. Im zweiten Teil plane ich, die Automatisierungsinfrastruktur im Kontext von IOS zu betrachten. Aufgrund der Einschränkungen von Apple, iOS-Simulatoren nur auf macOS-Systemen auszuführen, ist unser Lösungsangebot eingeschränkt. Beispielsweise können wir Docker nicht zum Ausführen des Simulators oder öffentliche Clouds zum Ausführen virtueller Maschinen verwenden. Das heißt aber nicht, dass es keine anderen Alternativen gibt. Ich werde versuchen, Sie mit fortschrittlichen Lösungen und modernen Tools auf dem Laufenden zu halten!
Außerdem habe ich nicht ganz große Themen im Zusammenhang mit der Überwachung erwähnt. In Teil 3 werde ich mir die beliebtesten Tools zur Infrastrukturüberwachung ansehen und welche Daten und Metriken zu berücksichtigen sind.
Und schlussendlich. In Zukunft plane ich die Veröffentlichung eines Videokurses zum Aufbau einer Testinfrastruktur und zu beliebten Tools. Derzeit gibt es im Internet eine ganze Reihe von Kursen und Vorträgen zu DevOps, aber alle Materialien werden im Kontext der Entwicklung und nicht im Kontext der Testautomatisierung präsentiert. Zu diesem Thema brauche ich dringend Feedback dazu, ob ein solcher Kurs für die Community der Tester und Automatisierungsingenieure interessant und wertvoll sein wird. Vielen Dank im Voraus!
Source: habr.com