Nachdem wir uns im letzten Teil das quay.io-Container-Repository aufgesetzt haben Das Aufsetzen der OpenShift basierten GitHub Action Runner ist der letzte Schritt, den wir noch brauchen, um die CI-Pipeline fertig zu haben. Und darum kümmern wir uns in diesem Artikel.
Weiterlesen In diesem Teil der Artikelserie befassen wir uns, nachdem das GitHub-Source-Repository existert, mit dem quay.io-Repository und dem Einrichten eines Robot-Benutzers für die Nutzung durch GitHub Actions.
Weiterlesen In diesem Teil der Artikelserie befassen wir uns mit dem GitHub-Repository und natürlich dem Workflow für die GitHub Actions.
Außerdem verliere ich ein paar Worte über den Maven-Build und die Integration des Helmcharts in diesen Build.
Weiterlesen In der Softwareentwicklung gehören CI/CD-Pipelines inzwischen zum guten Ton. Allerdings braucht man hierfür einiges an Infrastruktur, um den Buildprozess so weit zu automatisieren. In dieser kurzen Artikelserie will ich eine mögliche Pipeline auf Basis von GitHub, GitHub Actions, quay.io und OpenShift-basierten Runnern für GitHub Actions betrachten. Ich nutze hier OpenShift, da ich einen OKD-Cluster zu Verfügung habe, aber die Runner lassen sich auch 1:1 für Kubernetes-Cluster nutzen.
Meine Software ist eine Java spring-boot-Anwendung, die per Maven gebaut wird. Aber dies betrifft nur den kurzen build-Teil der Pipeline und man kann die gleiche Methode auch für Gradle-Builds oder auch für node.js nutzen – man muss gegebenenfalls einen anderen Build-Runner aussuchen.
In manchen Java-Projekten hat man das Problem, dass Entwickler unter Windows, Linux und MacOS arbeiten. Damit stellt schon das Build-Tooling ein Problem dar. Obwohl moderne Build-Systeme meistens in der JVM laufen und damit eigentlich betriebssystemunabhängig sein sollten, stößt man oft an das Problem, dass Pfadangaben leider nicht so unabhängig sind.
Um trotzdem lokal bauen zu können, wäre ein System schön, das wie ein zentraler Build-Server fungiert. Aber halt lokal. Und hier kommt Vagrant ins Spiel …
SQL-Datenbanken gehören trotz der großen Aufmerksamkeit für NOSQL zum Brot-und-Butter-Handwerkzeug eines Softwareentwicklers. Und zumindest im Unternehmensumfeld wird des wohl noch lange so bleiben, denn dort setzen sich neue Konzepte nur langsam durch. Doch schon während der Softwareentwicklung stößt man im Team auf das Problem, dass Änderungen an den Datenstrukturen verwaltet werden müssen. Die Kollegen brauchen bei Softwareänderungen auch geänderte Testdatenbanken, man will auch nachhalten, welcher Commit welche Datenbankänderung nach sich zog.
Hier kommen dann Datenbankversionierungstools wie Flyway oder eben Liquibase ins Spiel. Flyway habe ich uns vor langer Zeit nur kurz angeschaut, aber eine persönliche Präferenz des für das damalige Projekt verantwortlichen Softwarearchitekten für XML-basierte Tools hat mich dann zu Liquibase geführt. Wie es in ein Mavenprojekt integriert werden kann, damit Integrationstests immer auf eine aktuelle Datenbank zugreifen können, will ich im folgenden beschreiben.