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.

NativeScript vereinfacht die plattformübergreifende Entwicklung nativer Mobile-Apps für iOS und Android. Es ermöglicht mit Angular und Vue.js die Verwendung unterschiedlicher Frameworks. Außerdem wird neben JavaScript auch TypeScript als Programmiersprache unterstützt, das mit der Zeit immer beliebter wird. Bei den stackoverflow Developer Survey Results von 2019 wurde TypeScript bei den beliebtesten Programmiersprache bereits auf Platz 3 gewählt. Mit dem NativeScript CLI bietet NativeScript zudem ein mächtiges und zugleich einfaches Tool zur Automatisierung des Builds mittels einer CI-Pipeline.

In diesem Artikel beschreiben wir die Provisionierung eines macOS-Systems für NativeScript. In folgenden Artikeln schauen wir uns noch an, wie wir das System als Runner in Gitlab einbinden und zum Upload von NativeScript-Apps zum Apple App Store nutzen können.

Sichere Kommunikation ist gerade dann wichtig, wenn Infrastruktur zum Einsatz kommt, die nicht voll vertrauenswürdig ist. Dazu zählt zum Beispiel ein Kafka / Zookeeper Deployment in einer Cloud Umgebung.
Zwischen Kafka und Zookeeper ist es möglich, die Kommunikation mit TLS zu verschlüsseln und damit zu sichern.

Kubernetes bietet mit seiner erweiterbaren API eine sehr einfache Möglichkeit zusätzliches Verhalten mit Kubernetes zu integrieren. Neben der API-Spezifikation als OpenAPI (ehemals Swagger) stellt das Kubernetes-Projekt auch fertige Clients für verschiedene Programmiersprachen an. Eine besondere Rolle nimmt der Kubernetes Go-Client ein, da dieser auch innerhalb von Kubernetes selbst eingesetzt wird.

Auf Basis der OpenAPI-Spezifikation stehen generierte Clients für Java, Python, C# und JavaScript. Zu den offiziellen Kubernetes-Clients kommen noch durch die Community erstellte und gepflegte Libraries für diverse Sprachen hinzu.

Im Folgenden wird demonstriert, wie die Kubernets-API mit Java verwendet werden kann. Wie der dazu benötigte lesende API-Zugriff eingerichtet werden kann, wurde bereits in Kubernetes Readonly API Zugriff erklärt.