sidion labor

Entwickler Blog

Mit der zunehmenden Verbreitung von Computern mit ARM64 Architektur, wie zum Beispiel Raspberry Pi, AWS Gravitron oder Apple M1, zur Entwicklung und Betrieb von Anwendungen müssen auch Build-Pipelines für Containerimages etabliert werden, die nicht nur für eine, sondern mehrere Plattformen Images bauen kann.

Jedes IoT Gerät, sei es nun ein Sensor oder ein FireTV Stick, benötigt einen Server mit dem es Daten austauschen kann. Und da nicht jedes beliebige Gerät Informationen mit dem Server austauschen soll, benötigt es eine Möglichkeit sich beim Server zu authentifizieren. Bei manchen Geräten kann man die Zugangsdaten bereits bei der Auslieferung fest hinterlegen, da sie vom Endbenutzer nicht mehr weiter konfiguriert werden müssen. Bei anderen Geräten ist allerdings eine individuelle Kennung bzw. Benutzeraccount notwendig.

Messaging-Systeme sind am leistungsfähigsten, wenn sie problemlos mit externen Systemen wie Datenbanken und anderen Messaging-Systemen verwendet werden können. Mit Pulsar IO-Konnektoren können Sie problemlos Konnektoren erstellen, bereitstellen und verwalten, die mit externen Systemen interagieren.

Ein neuer Ansatz für die Build Pipeline.

Was wäre, wenn man für die Build Pipeline keinen Server mehr bräuchte?
Die ganze Pipeline könnte überall ausgeführt werden, sogar auf den PCs der Entwickler.

Tekton ist ein Open Source Projekt der Continuous Delivery Foundation, dass die Build Pipeline in den
Kubernetes Cluster verlagert. Die Pipeline wird über Kubernetes Resourcen deklariert.
Sie besteht damit nur noch aus ein paar Dateien, die auf jedem Kubernetes Cluster deployed und ausgeführt werden können.

Spätestens seit der neuen Release Politik von Java, muss man sich als Backend-Entwickler immer öfter mit Migrationen von Programmiersprachen & Libraries beschäftigen. Im Frontend beispielsweise bringt Angular jedes halbe Jahr ein neues Release raus (zum Zeitpunkt des Schreibens ist Angular 12 die aktuellste Version). Hier habe ich im Kundenprojekt das bestehende Projekt bereits von Angular 7 auf 8 und dann noch mal von 8 auf 10 aktualisiert.
Im Backend wird bisher am häufigsten noch Java 8 verwendet. Es gibt aber auch schon hier und da Projekte, die Java 11 oder höher verwenden. Bei Java lohnt es sich wohl nur auf die LTS Versionen 8, 11 und dann 17 (gegen Ende des Jahres 2021) zu migrieren, sonst sollte man jedes halbe Jahr jede Version mitnehmen.
Java ist die Grundlage für Spring Boot und auch JUnit. Spring Boot hat mit dem Release Version 2.2.0 auf JUnit 5 umgestellt. Was das bedeutet und welche Erfahrungen ich mit der Migration eines Kundenprojekts von JUnit 4 auf JUnit 5 gesammelt habe, das möchte ich in diesem Artikel kurz beschreiben. (Dies soll aber kein JUnit 5 Tutorial sein!)