Agile Methoden bieten in der Anwendungsentwicklung viele Optionen, fordern aber auch zahlreiche Entscheidungen. Automatisierungen und Standards halten Projekte beherrschbar und flexibel. Im zweiten Teil unseres Blog-Beitrages informieren wir Sie über die Faktoren, die Agile GitOps zum Erfolg verhelfen.
Wenn Unternehmen ein neues Projekt aufsetzen, ist eine der zeitaufwendigen Aufgaben, Technologien auszuwählen und die geeignete Entwicklungsumgebung einzurichten. Dieses Problem wird bei der Vielzahl an zur Verfügung stehenden Open-Source-Technologien immer größer und die Verantwortlichen müssen immer mehr Parameter in die Rechnung einbeziehen. Neben der rein fachlichen und technischen Entscheidung stellen sich Fragen wie:
- Welche Unternehmen unterstützen und nutzen das Projekt?
- Wie viele Personen arbeiten an dem Projekt?
- Wie aktiv ist das Projekt und wie häufig wird released?
Microservice Toolstack
Materna setzt hier auf einen Standard-Toolstack, sofern es im jeweiligen Projekt möglich ist. Für die speziellen Anforderungen des Projekts muss dann immer noch einiges entschieden werden, beispielsweise mit welchen Tools die „speziellen Anforderungen“ umgesetzt werden sollen. Vieles steht jedoch fest. Das führt dazu, dass ein großer Anteil der Entwickler diesen Toolstack beherrschen und sie flexibel eingesetzt werden können. Ferner muss gerade zu Beginn weniger abgestimmt werden. Der Standard-Toolstack umfasst modernste Backend-Technologien für Microservice-Architekturen, die On-Premise, hybrid oder in einer Public Cloud wie AWS (Amazon Web Services) gehostet werden können. Materna präferiert die Cloud-Lösung, da dort der Agile GitOps-Ansatz seine volle Wirksamkeit entfaltet. Im Frontend werden sowohl Single Page-Applikationen als auch mobile Anwendungen unterstützt. Bei der Standardisierung setzen wir jedoch noch früher an, nämlich wenn die Tools für die Entwicklung gewählt werden. Hierzu zählen die Entwicklungsumgebung, das Build-Management-Tool, der DevOps-Toolstack und der Cloud-Provider.
Infrastructure as Code
In klassischen Vorgehensmodellen war die Entwicklung vom Betrieb klar getrennt. Mit dem Aufkommen von DevOps wachsen diese Bereiche stärker zusammen. In den Anfängen hat sich das darauf beschränkt, wie Anwendungen erstellt, getestet und deployed werden. Mit Infrastructure as Code (IaC), das heißt, der Möglichkeit, formal zu beschreiben, wie die Infrastruktur einer Anwendung aussehen soll und welche Bestandteile der Software wo laufen, wird das auf ein neues Level gebracht. Dadurch wird der Aufbau einer Infrastruktur weniger fehleranfällig, wiederholbar und ist selbstdokumentierend. Auch die Infrastruktur für die Entwicklung kann so automatisiert erstellt werden. Die Grenzen zwischen Laufzeit und Compile-Zeit (Fachbegriff für Erstellungszeit) beginnen zu verschwimmen. Es ist durchaus möglich, einen Teil der Infrastruktur direkt aus der Anwendung heraus zu erweitern. Das ermöglicht insbesondere, Multi-Mandantensysteme und Produktlinien elegant umzusetzen.
Cloud
Infrastructure as Code spielt seine Stärke erst in einer Public Cloud wie AWS richtig aus, weil hier Ressourcen dynamisch und in kürzester Zeit allokiert werden können. Im Zusammenspiel mit Serverless-Diensten, das heißt, Ressourcen, bei denen der Cloud-Provider die Verwaltung und Skalierung vollständig übernimmt, kann sich ein Entwicklungsteam auf die Umsetzung der Fachlichkeit konzentrieren. Auch fortgeschrittene Betriebsthemen wie Monitoring und Alarming, Backup-Strategien, Disaster Recovery, Canary Releases, Green-Blue Deployments und Edge Computing unterstützen und vereinfachen AWS.
CI/CQ/CD
Ein zentraler Bestandteil von „Do Less“ ist die Continuous Integration (CI), bei der auf verschiedenen Stages, das heißt, Installationen der Software auf zugehörigen Umgebungen, automatisiert getestet wird. Jede Stage führt die Gesamtanwendung näher an die Produktion und es wird in den späteren Stages immer umfassender getestet. Dadurch wird das Zusammenspiel der verschiedenen Features, Services und schließlich der produktionsnahen Umgebung inkl. pseudonymisiertem Datenbestand geprüft. Die Erfahrung zeigt, dass auf all diesen Ebenen Fehler aufgedeckt werden können. Die Teststrecke in mehrere Stages aufzuteilen, ist aus mehreren Perspektiven sinnvoll. Beispielsweise sind frühzeitige Stages kleiner, schneller zu erstellen und die Tests schneller durchgeführt. Dadurch werden Probleme zeitnah und mit weniger Aufwand zurückgemeldet. Spätere Stages, die also versuchen, die Produktionsumgebung abzubilden, sind aufwendiger aufzusetzen und daher teurer. Weiterhin können Fehler auf frühzeitigen Stages einfacher lokalisiert werden, weil sie nicht in einer komplexen Infrastruktur untergehen. Es ist daher vorteilhaft, Fehler frühzeitig im Prozess zu erkennen, zu finden und zu beheben.
Während der Tests werden Daten gesammelt, die die Qualität und Aussagekraft der Tests widerspiegeln. In dem Zuge wird der Quellcode auch statisch analysiert. Die Ergebnisse werden zu einem Tool für die Umsetzung von Continuous Quality (CQ) weitergeleitet. Dort werden sie grafisch aufbereitet und können eingesehen werden. Ferner werden Quality Gates definiert, anhand derer automatisiert entschieden wird, ob die Anwendung den Qualitätsansprüchen der Stage genügt oder nicht.
Die letzte Stage ist das Produktivsystem. Wird der Agile GitOps-Ansatz konsequent umgesetzt, ist auch der Schritt in die Produktion automatisiert. Allerdings wird er zuvor von dem Produktverantwortlichen, dem sogenannten Product Owner (PO), geprüft und abgesegnet. Dieser Schritt führt zu dem eigentlichen Clou: nämlich, dass der Entwicklungs- und Freigabeprozess Tool-gestützt durch die Versionsverwaltung Git gesteuert wird.
Git und DevOps -> GitOps
Bei GitOps wird die Staging-Strategie auf das Branching-Modell (siehe Abbildung 2) abgebildet, wobei Branches in einer Versionsverwaltung die verschiedenen Entwicklungsstände einer Software widerspiegeln. Dadurch ist auf dem zugehörigen Branch der Stand, der erfolgreich die jeweilige Stage durchlaufen hat. Neue Funktionen werden unabhängig in Feature-Branches entwickelt. Eine Anfrage, dass Änderungen aus einem Branch in einen anderen übernommen werden, wird Merge Request genannt. Über Merge Requests wird angestoßen, dass die zugehörige Stage erzeugt wird. Hierfür wird automatisiert eine neue Umgebung aufgesetzt und die einzelnen Services werden erzeugt, als Container in eine zugehörige Registry geladen, in einem Container Service deployed und die zugehörigen Tests ausgeführt.
Nur wenn die Tests erfolgreich durchlaufen und die Quality Gates erfüllt sind, wird dem Verantwortlichen der Stage die Möglichkeit gegeben, den Merge Request zu bestätigen und durchzuführen. Spätestens für die Produktionsumgebung ist das der Product Owner. Hierdurch ist gewährleistet, dass die objektivierbaren Qualitätsansprüche, die bei Scrum in der Definition of Done (DoD) festgehalten werden, erfüllt sind und auch der oder die Verantwortliche mit dem Ergebnis zufrieden ist, bevor die Anwendung in die nächste Stage bzw. die Produktion gelangt. All diese Prozesse sind automatisiert und werden durch Git gesteuert. Die Entwickler nutzen Git auf der Konsole oder ihre Entwicklungsumgebung und der Product Owner kann die Web-Oberfläche eines DevOps-Tools wie z. B. GitLab verwenden.
Auf dem Weg von einer Anforderung bis hin zu einem Merge Request getriebenen Staging-Prozess entstehen keine Medienbrüche und keine fehleranfälligen manuellen Schritte. Wenn in dem Ablauf ein Test oder Quality Gate fehlschlägt, wird ebenfalls automatisch eine Benachrichtigung an den Entwickler, der die letzte Änderung gemacht hat, gesendet und der Übergang in den nächsten Prozessschritt wird automatisch abgebrochen. Das Problem kann zeitnah von der Person, die es verursacht hat, analysiert und behoben werden.
Fazit
Die Erfahrung zeigt, dass dieses Vorgehen schneller ist, zu besseren Ergebnissen führt und es ermöglicht, Anwendungen zu erstellen, die den heutigen Ansprüchen von Nutzern gerecht werden. Um Agile GitOps umsetzen zu können, muss ein Entwicklungsteam diszipliniert und professionell sein sowie ein umfassendes Spektrum an Werkzeugen beherrschen. Materna zeigt in vielen Projekten der vergangenen Jahre, dass dies Teil ihrer DNA geworden ist.
Sie haben den ersten Teil verpasst? Dann lesen Sie hier den Beitrag „Do Less – Die Effizienz der Faulheit in der Anwendungsentwicklung“.
Sie brauchen Unterstützung bei Ihren Software-Entwicklungsprojekten? Erfahren Sie mehr.
