Für Product Owner, Entwickler und weitere Stakeholder können Bildschirmaufnahmen hilfreich sein, um schnell und einfach einen Einblick in den Entwicklungsstand einer Webanwendung zu erlagen. In diesem Post berichte ich von meinen Erfahrungen, einen Prozess aufzusetzen, um in einer Build-Pipeline automatisch Videos und Screenshots einer Anwendung aufzunehmen und diese bereitzustellen. Realisiert habe ich dieses Vorhaben sowohl mit Playwright als auch mit Puppeteer.

Heutzutage ist es wichtiger denn je, dass Anwendungen auf verschiedenen Architekturen und Plattformen reibungslos funktionieren. Man denke z.B. an den erfolgreichen Schwenk von Apple auf die ARM-Plattform und die Kosteneffizienz, die ARM auch...

Bei Drone CI handelt es sich um einen OpenSource continuous integration (CI) Server. Dabei setzt Drone CI auf die Ausführung des Builds mittels Containern. Typischerweise werden dabei Docker oder Kubernetes als Container Plattform eingesetzt.

Eine Buildpipeline wird in YAML definiert, dabei können sowohl services definiert werden, die im Build verwendet werden, als auch persistente volumes und natürlich die Buildabläufe als steps.

Ein typisches Java Projekt besteht nicht nur aus dem eigenen Code, sondern in der Regel auch vielen externen Bibliotheken als Abhängigkeiten.
Diese Abhängigkeiten machen dabei in einem Microservice mehr als 90% Anteil am gesamten Code aus. Die Wartung erfolgt zwar durch den jeweiligen Hersteller, jedoch muss das Projekt Team darauf achten, dass entsprechende Aktualisierungen auch im Projekt aufgenommen werden. Kritisch wird es dann, wenn Sicherheitsupdates zwar verfügbar sind, jedoch nicht die zugehörige Maven oder Gradle Konfiguration aktualisiert wird.

Um das Problem zu lösen gibt es verschiedene Ansätze mit einem unterschiedlichen Automatisierungsgrad. Wir wollen einen pragmatischen Ansatz vorstellen, der sich in der Praxis sehr bewährt hat und seinerseits keine zusätzlichen Abhängigkeiten einführt.

Auch wenn Microservice Architekturen und damit einhergehend Single-Module-Repositories im Trend liegen, gibt es immer wieder Gründe für ein Multi-Module Projekt. Sogar bei Microservice als Deployment.
Wenn es nun darum geht, die Code-Coverage zu ermitteln, um diese bei GitLab CI anzuzeigen oder Trends zu ermitteln, muss man sich etwas behelfen. GitLab CI ist im Verglech zu Jenkins nämlich deutlich dünner ausgestattet, so dass eine Fancy Plugins die Arbeit abnehmen. Damit ist Jenkins nicht automatisch besser oder GitLab CI schlechter, als Jenkins: Die Ausrichtung ist einfach anders.

Im folgenden betrachten wir einmal, wie die modulübergreifende Auswertung von Code Coverage, erhoben mit dem JaCoCo Maven Plugin, aussehen könnte. Der Ansatz lässt sich natürlich auf andere Coverage-Tools und Sprachen analog übertragen.

Container, allen voran Docker, sind in aktuellen Infrastrukturen ein fester Bestandteil. Waren früher gerade Buildserver und CI-Umgebungen schwer zu warten, da diverse Werkzeuge oftmals jeweils in mehreren Versionen gepflegt werden müssen, können Build-Container alle benötigten Werkzeuge direkt mitbringen.

Moderne Buildserver wie DroneCI oder GitLab CI unterstützen daher nativ die Verwendung von Werkzeugcontainern in Form von Docker Images. Für Angular gibt es beispielsweise mit https://hub.docker.com/r/trion/ng-cli-karma ein Image, in dem Angular CLI und Webbrowser bereitgestellt werden.

In diesem Beitrag werfen wir einen Blick auf Cypress, dass sich sehr gut zur Umsetzung von Integrations- und Ende-zu-Ende Tests eignet. Cypress kann prinzipiell mit beliebigen Technologien kombiniert werden, beispielsweise serverseitig gerenderten Anwendungen, oder mit Angular, React oder Vue im Browser umgesetzten Anwendungen.
Wir verwenden in diesem Beispiel React, jedoch sollte die Übertragung auf andere Frameworks dem Entwickler sehr einfach von der Hand gehen.

Im vorhergehenden Artikel wurde der Einsatz von GitHub Actions beschrieben, um eine Angular Anwendungen auf GitHub zu testen und zu bauen.
Das Thema Deployment wurde dabei aufgrund der Vielzahl an Varianten nicht weiter behandelt. In diesem Beitrag wird nun erklärt, wie die ebenfalls von GitHub bereitgestellte Plattform zum Hosting von statischen Seiten, GitHub Pages, genutzt werden kann, um darauf eine Angular Anwendung bereitzustellen.

Der große Vorteil von clientseitigen Frameworks kommt dabei voll zur Geltung: Es wird lediglich ein simpler Webserver benötigt, der die HTML, JavaScript und CSS Dateien ausliefert. Serverseitige Logik wird für das Angular Frontend an sich nicht benötigt.

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.

Um Anwendungen erfolgreich bauen zu können, ist - je nach Anwendung - ein hoher Aufwand in die Einrichtung der Umgebung zu investieren. Beispielsweise für ein Android-Projekt muss Java installiert sein, es werden die Android-Tools mit dem Android-SDK benötigt und der Build muss passend konfiguriert werden. Dieses Setup wird aber nicht nur auf den Entwickler-Rechnern benötigt, auch die Countinuous-Integration-Umgebung des Buildservers muss entsprechende Werkzeuge bereitstellen. Um Reproduzierbarkeit zu gewährleisten, sollte sichergestellt sein, dass in allen diesen Umgebungen die gleichen Versionen der Tools genutzt werden.

In diesem Artikel werden wir uns damit beschäftigen, wie auf einfachem Wege eine zur Entwicklung von Android-Projekten geeignete Umgebung mit Hilfe von Docker erstellt werden kann. Am Beispiel von Gitlab-CI wird der Einsatz des entsprechenden Docker-Containers in einer CI-Umgebung gezeigt.

Im zweiten Teil der Artikelserie rund um das Thema Buildautomatisierung mit Jenkins für JavaScript-Anwendungen wird die Verwendung des Jenkinsfile beschrieben.

Ein Jenkinsfile wird genau wie die entwickelte Software selbst verwaltet. Diese Infrastructure-as-Code erlaubt es, die gleichen Vorgehensweisen zur Entwicklung, Test und Qualitätssicherung der Infastruktur zu verwenden, wie für den eigentlichen Quellcode.