Neuigkeiten von trion.
Immer gut informiert.

Bei dem Meetup Digital Innovation Ruhr behandelte Thomas Kruse in seinem Vortrag "Frontend Architektur für Microservices" verschiedene Architektur Optionen, um mit den Herausforderungen des Frontends bei einer Microservice Architektur umzugehen.

Für den Vortrag wurden die Erfahrungen aus verschiedenen Projekten in einem zeitlichen und technologischen Kontext eingeordnet und liefern damit Entscheidungshilfen für Architekten, die sich mit dem Thema Frontend im Microservice Kontext befassen.

Ein besonderes Augenmerk wurde dabei auf den Systemschnitt aus der Perspektive des Frontends und des Nutzers gelegt, der in der Regel eine integrierte Oberfläche ohne Brüche im Prozess erwartet.

Dank aktueller Entwicklungen eignen sich inzwischen Webcomponents für bestimmte Aufgabenstellungen und wurden mit einem Beispiel auf Basis von Angular Elements praktisch demonstriert.

Eine Webanwendung läuft - und das ist gerade der große Benefit - nicht aussschließlich in einem Webbrowser auf einem Desktop Gerät. Mit zunehmend anspruchsvolleren Anwendungen müssen diese Rahmenbedingungen von Plattform und Displayformat bei Tests mit berücksichtigt werden.
Für Anwender zähle nämlich schon lange nicht mehr rein funktionale Gesichtspunkte, sondern auch nichtfunktionale Anforderungen wie Geschwindigkeit und eine gute Bedienbarkeit spielen eine Rolle.

In dem vierten Teil seiner Artikelserie rund um Testing von Web Anwendungen betrachtet Karsten Sitterberg nun spezielle Szenarien:
Dabei werden Fragen beantwortet, die sich um das Testen von HTML5 Anwendungen, Web-Anwendungen auf mobilen Endgräten beantwortet. Zudem wird erklärt, wie mit Devices in der Cloud getestet werden kann, wie sich eine Anwendung auf einer speziellen Plattform und dem zugehörigen Display-Format verhält.

Bereits in diesem Beitrag zu Docker Multi-Arch Images wurden die Grundlagen erläutert, wie Docker-Images dank Manifest automatisch passend für die jeweilige Plattform ausgewählt werden.

Doch die Erstellung solcher multiplen Images und der zugehörigen Manifest-Dateien ist mit dem automatischen Build auf Docker Hub nicht so intuitiv umsetzbar, wie bei regulären Images. Eine Lösung kann da ein eigener Buildserver inkl. Build-Agents für die zu unterstützenden Plattformen darstellen.

Dieser Beitrag erklärt, wie unter Verwendung von QEMU zur Cross-Compilation und den DockerHub Build Hooks entsprechende Docker-Images und das Manifest vollautomatisch erzeugt und publiziert werden können. (Hintergründe zum Cross Build von Docker Images finden sich hier: Docker Multi-Arch Images )

Update: In diesem Artikel wird ein ähnliches Verfahren, jedoch mit GitHub Actions vorgestellt: Multi Arch Images mit GitHub Actions.

In der Softwareentwicklung sollte es selbstverständlich sein, das Verhalten einer Anwendung stets basierend auf der fachlichen Spezifikation zu implementieren. Um sicherzustellen zu können, dass die fachlichen Vorganben eingehalten werden, werden Integrations- und auch Ende-zu-Ende-Tests (E2E-Tests) geschrieben.

Aufgrund ihrer jeweiligen Komplexität befinden sich die E2E-Tests in der Testpyramide über den Integrationstests, diese befinden sich über den Unit-Tests. Somit sollten sowohl Integrations- als auch E2E-Tests einen geringeren Anteil am geschriebenen Testcode haben als Unit-Tests. Im dritten Teil seiner Artikelserie hat Karsten Sitterberg beschrieben, mit welchem Vorgehen und welchen Tools bei der Erstellung eben solcher E2E- und Intergations-Tests vorgegangen werden kann.

Bei Web Anwendungen stellt sich die Frage nach einer guten Testbarkeit und auch nach einer guten Vorgehensweise bei Web Tests. Als grundlegende Metrik, um Aufwand und Menge der Tests abzuschätzen, hat sich die Testpyramide eingebürgert.

Auf der untersten Ebene befinden sich die Unit-Tests, die sich durch eine eher geringe Komplexität auszeichnen, dafür jedoch den Großteil der Tests ausmachen. Wie das Vorgehen bei der Erstellung von Unit-Tests aussehen kann, und welche Libraries und Frameworks bei Unit Tests für Webanwendungen helfen können, hat Karsten Sitterberg im zweiten Teil seiner Artikelserie zum Testen von Browser Anwendungen beschrieben.

Von Rancher Labs stammt eine abgespeckte Version von Kubernetes mit dem Namen k3s. Kubernetes wird oft als k8s abgekürzt, so dass eine reduzierte Version passenderweise als k3s bezeichnet werden kann.

Das Ziel von k3s ist, eine Kubernetes Umgebung anbieten zu können, wenn begrenzte Resourcen in der Betriebsumgebung den Einsatz einer regulären Kubernetes Installation erschweren oder unmöglich machen.

Im Gegensatz zum vollen Kubernetes Stack benötigt k3s kein etcd als Datenspeicher, sondern setzt auf SQLite. Hier macht sich die Architektur von Kubernetes natürlich besonders bezahlt: Da lediglich der Kubernetes API Server auf die Persistenz zugreifen darf, merken alle weiteren Komponenten von der Umstellung nichts. Um weiteren Hauptspeicher zu sparen wurden auch viele Controller Manager entfernt, die in der Zielumgebung jedoch sowieso nicht sinnvoll zum Einsatz kommen würden.

Im folgenden schauen wir uns an, wie mit Docker und k3s ein Kubernetes Cluster als Docker Container aufgesetzt werden kann. Das ist besonders praktisch, wenn es darum geht, Tests zu machen oder mit Kubernetes zu entwickeln. So spart man sich Minikube oder einen Testcluster.
Übringens arbeitet man auch bei Kubernetes selbst daran, Docker als Umgebung nutzen zu können: Das kind-Projekt (Kubernetes in Docker) verfolgt einen vergleichbaren Ansatz: https://kind.sigs.k8s.io/

Natürlich kann k3s auch ganz ohne Docker eingesetzt werden und ist sogar der Regelfall, denn k3s soll z.B. in Kombination mit Raspberry Pi und vergleichbaren Single Board Computer (SBC) gut verwendet werden können.
Mehr zu k3s gibt es auf der offiziellen Homepage: https://k3s.io/

In den vorherigen NativeScript-Artikeln haben wir zunächst ein kleines HelloWorld-NativeScript-Projekt erstellt und dieses dann auf einem GitLab-Server in einer Pipeline gebaut.

Nun wollen wir einen Schritt weiter gehen und das erstellte Projekt über die GitLab-Pipeline zu App Store Connect hochladen, um damit die Basis für Continuous Delivery zu legen.

Für manche Testszenarien muss auch ein Dateidownload mit getestet werden, z.B. um die resultierende Datei auf Korrektheit zu prüfen. Für Ende-zu-Ende Tests gibt es diverse Werkzeuge, eins davon ist das von Google entwickelte Puppeteer. Mit Puppeteer lässt sich aktuell der Chrome Browser fernsteuern, eine Erweiterung auf Mozilla Firefox ist ebenfalls in Arbeit.

In diesem Beitrag wird gezeigt, wie mit Docker und Puppeteer ein entsprechendes Testszenario umgesetzt werden kann.

Im letzten Artikel haben wir ein macOS-Environment für NativeScript provisioniert. Nun wollen wir dieses System nutzen und als Runner in Gitlab registrieren, um dort eine CI-Pipeline für ein NativeScript-Projekt zu erstellen.

Seitdem Frameworks wie Angular und React zusammen mit TypeScript die Möglichkeit eröffnen, komplexe Frontend Anwendungen zu erstellen, kommt auch die Frage auf, wie diese langfristig wartbar und erweiterbar konzipiert werden können. Als Antwort auf diese Frage liefert Karsten Sitterberg die bereits bei Backend-Anwendungen bewährte Herangehensweise des Test-Driven-Development (TDD) für Browser Anwendungen.

Im ersten Teil seiner Artikel Serie führt Karsten Sitterberg die grundlegenden Begriffe und Motivation für Tests von Webanwendungen ein und liefert einen Fahrplan für eine optimale Entwicklung einer gut getesteten Anwendung.
Dabei werden sowohl die Bedürfnisse der Entwickler klassischer (MVC) Webanwendungen, als auch von Single Page Application (SPA) berücksichtigt.