Trittsicher Schritt für Schritt

Der Begriff "Golden Path" wurde 2020 von Spotify geprägt und zielte auf eine stärkere Ausrichtung der Entwickler:innen-Werkzeuge ab. Die empfohlenen Tools und Muster sollten leicht auffindbar und klar sein; ebenso sollte es eine hochwertige Dokumentation geben. Des Weiteren sollte jede/r Mitarbeiter:in eindeutig erkennen können, an wen sie/er sich bei Fragen wenden kann. Der Goldene Pfad ist somit der "geprüfte und unterstützte Weg", um eine neue Software Schritt für Schritt auf eine Plattform zu bringen.

Produktives Deployment

Auch Red Hat propagiert den Einsatz eines Goldenen Pfades. Der allgemeine Gedanke hinter diesem Konzept ist, dass die Plattform eine Form von vordefinierten und unterstützenden Ansätzen für die Entwicklung und Bereitstellung einer bestimmten Software bietet. Wenn ein Team diesen Weg als anwendbar/geeignet betrachtet - weil die Anforderungen an das zu entwickelnde Produkt dies zulassen - erhält es einen angeleiteten Weg bis zum produktiven Deployment der neuen Software, ohne sich mit den Details der für die Erstellung dieses Weges verwendeten Technologien vertraut machen zu müssen.

Raschere Anwendungsentwicklung

Dieser Ansatz beschleunigt typische Anwendungsentwicklungsfälle etwa das Onboarding eines neuen Teammitglieds oder das Onboarding einer neuen Anwendung und führt gleichzeitig die in der Vergangenheit erlernten Best Practices ein. Je ausgefeilter die Golden Paths sind, desto mehr werden sie übernommen und sorgen so für eine einheitlichere Konfiguration und ein einheitlicheres Verhalten im gesamten Anwendungsportfolio.

Mit nur ein paar Klicks

Was beinhaltet nun so ein Goldener Pfad? Einfache Antwort: das kommt darauf an! Aber in der Regel sind es Vorlagen, welche ein "Hello World und alles rundherum" enthalten. Ein gutes Beispiel aus dem Bereich der Java Programmierung ist spring initializer - ein paar Klicks und man kann ein kompilierbares und ausführbares Projekt herunterladen.

BRZ-Container-Plattform

Unser Golden Path kreist um die BRZ-Container-Plattform; also die OpenShift-Plattform mit all ihren Tools und besonderen Gegebenheiten. Die Zielsetzung des Projektteams war es, einen Pfad "vom Source Code bis zur Release | Produktion auf der Plattform" darzustellen. Dieser Pfad basiert aktuell auf Java (.NET coming soon) und beinhaltet die gesamte "Tool-Kette" bestehend aus Bitbucket, Jenkins, Artifactory, ArgoCD, Helm und natürlich der Red Hat Openshift Platform. Dabei werden die üblichen kubernetes Objekte wie z. B. Deployments, Routen, Services, Volume Claims, Configmaps, Secrets (auch sealed) usw. in einer Schritt für Schritt Anleitung abgedeckt, sodass man kein/e kubernetes-Expertin bzw. Experte sein muss, um damit arbeiten zu können.

The box in the middle

Wir wollten nicht bloß ein high-level-pattern erzeugen nach dem Motto "something magic happens in the box in the middle", sondern ein release-fähiges, konkret nutzbares Muster. Dieses Muster muss nun seinen ersten Feldeinsatz im zeitlich kritischen Projekt bestehen - und wird im Zuge dessen noch optimiert. Nach der Erstellung und Erprobung dieses Musters folgt die Automatisierung. Ziel ist es, alle relevanten Artefakte und Komponenten automatisch anzulegen. Also z. B. ein Bitbucket-Projekt mit den relevanten Repos, die Jenkins Pipeline(s), Projektbereiche in Artifactory und Sonarqube, usw. Diese Automatisierung ermöglicht es dann, Personen von Routinetätigkeiten zu entlasten und die Durchlaufzeit zu optimieren. Außerdem kann man durch die Abstrahierung hinter den Kulissen leichter etwas austauschen oder optimieren – z. B. Quay anstatt Artifactory für die Ablage von Images verwenden, oder Tekton anstatt Jenkins als CI/CD Tool.

Neugierig geworden?

Am 28. September wird das BRZ-Projektteam im Rahmen der Austrian Platform Engineering Community dazu ins Detail gehen. Anmeldungen dafür werden noch angenommen.